Tools such as XPlanner should be the cornerstone of an SCM group. This iteration and user-stories based model planning tool allows SCMs to have a more complete picture of what the current tasks/projects are and what’s in the back-burner.

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 SCM 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 SCM 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.

No Comments »

To promote the spirit of Agile Development and Continuous Integration, groups of builds must be classified and treated differently within the development organization. These builds are as follows:

• 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.
• CI (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.
• SCM (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.
• SCM (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.

No Comments »