The intern took it quite well initially and seemed to be treading the murky waters but looks could be deceiving.  Couple long hours with stress from the onslaught of build projects and we have a perfect gourmet ingredient for a time bomb.  Strenuous training regiments for new tools, processes, implementation details, and infrastructure management takes a heavy toll on the spirit overtime.

Time and time again, I’ve witnessed so many casualties from failed attempts of going for the prized position of Software Configuration Management Engineer.  Oftentimes its not because the lack of skills to thrive in the job, but rather a deeper sense of personal accomplishment, pride, satisfaction, and overall warm fuzzy feeling that you’ve made the development team’s lives so much easier.   But the amount of headaches an SCM must endure from unappreciative development teams/developers can be endless.  SCM Engineers don’t really need free lunches (albeit extremely grateful) from teams, we are happy if we were just acknowledged, appreciated, and/or given a nod of respect.  Anyhow, I digressed…

Back to our overworked and highly stressed intern; the person suddenly quit one day last week without giving us the courteous 2 weeks notice.  Now the already overburdened team has to pick up the slacks left by the departure.   Luckily we have a solid enough infrastructure and processes that the void left by the departed intern was quickly distributed to and covered by the rest of the team.

These daily stand-ups should be conducted just as the title implies; everyone must be standing.  Each meeting should last no longer than 15mins; less than 10mins is optimal.  This should be conducted on a round-table polling of each of the team members.  Three questions should be addressed by each of these individuals.  These questions are:

1. What did I do yesterday?
2. What am I planning on doing today?
3. What are the current roadblocks?

The most important of them all is question #3.   In my opinion, the whole Agile daily stand-up meetings evolved to solve this one particular pain point.   Oftentimes, roadblocks can set development schedule aback due to various lags within groups/departments/organizations/companies.  Lags such as phone and Email tagging, or request time stall due lack of authority to make a judgment call.  During the stand-up meeting, #3 can be quickly addressed with the help of the entire team and/or team manager/lead.  Afterall, one of the purposes of a lead or manager’s existence in any company is to provide the needed resources for their team members to function at peak productivity level.

What not to do with daily stand up meetings:

1. Too big of a group (10+)
2. Lasts longer than 15mins
3. Bicker and arguing between two members (should be taken offline)
4. Presentations
5. Treating this like a regular meeting

How does your team deal with daily roadblocks?

The way my current team uses this tool is we break it down to a monthly iterative model.  Within it, we have user stories outlining all the projects and tasks we can confidently complete for this iteration.   As each iteration goes by, we get a more accurate picture of how productive we can be in any given iteration based on the burn down charts.  From that, future iterations will have a more precise picture of what we can or cannot accomplish.

For example, if the current software configuration management group consists of 4 members and each member is highly productive in that every individual is capable of producing an output of 160 hours per month; each iteration would then contain enough user stories assigned equally to all members totaling up to 640 hours worth of tasks.  That is an ideal scenario!  As anyone who has been in SCM would know that the nature of our work is highly unpredictable. Due to such fact, we normally reserve approximately 60-80% of the expected output of each member for a particular iteration while saving the remaining hours for unexpected tasks or project supports (one of the most time consuming aspect of SCM).  Based on that, a monthly iteration for a 4 member software configuration management team should only be assigned 400-500 hours worth of tasks.  The remaining hours should have time allotted based on a higher priority for project supports.

• Engineering: These builds lives on the individual developer’s machine. It should never see the light of day beyond this scope. This is merely a convenient build tool designed to allow developers to easily build and debug their code. There are exceptions, however; for teams developing in the new .NET paradigm using the all inclusive solution (*.sln) files to build will have no need for this type of build. This is mainly useful for older softwares where several manual modification/moving/copying of file operations are need. These builds are then classified as on-demand.
• Continuous Integration (Development): These types of builds can also be referred to as the Continuous Integration (CI) builds. These builds lives on a stand-alone machine and the artifacts should only be made available to the immediate development team of the respective project. These builds should then be considered continuous since it is constantly polling for new check-ins.
• Software Configuration Management (Product Testing): These builds are on-demand and should only be initiated by team leads or managers of the particular development group. These builds should be built based on a label within the source control tool. There should not be any errors as these builds are derived from successful CI builds. The consumer for these builds will be the QA group.
• Software Configuration Management (Product Release): Similar to that of the product test SCM builds, these only differ in nature and title as they are meant for real world consumption.

To create quick build turn-arounds, plentiful CPU cycles, clean and reproducible build environments; each one of these build classifications should live on its own machine/server.   The two flavors of SCM builds can actually be on the same server, but Engineering, CI, and SCM must all exist separately.

There is another way of looking at this, especially when considering the agile process, and especially when in an enterprise software environment.

You still have the needs for a Engineer build and a CI build but instead of the SCM builds you instead “promote” the CI build.  What this effectively means is that someone chooses a CI build to push towards QA, and then this is pushed ultimately to production, etc.

As a process it has the advantage of being simplier and centralises all efforts around the automated build.   It is physically impossible for the wrong code to get built for production because someone changed a tag, instead the built artifact is the same (and can be checked against an MD5 to test it).

Although not as frequent in the .NET world its a common practice in the Java world.