Characteristics of the Agile SCM Solution

process by Developers in order to test their changes.  Let's look at a typical project of 5 developers over a one-month period. It is not uncommon for a developer to do 5-10 builds in their private workspace per day to verify their work. Over a one-month period, the Developers on this team will have performed 825 builds of the software - and that's just the first month. The point is that this is activity is done over and over again and should be automated to save time and ensure consistency.

Build systems that have manual steps have no traceability except through separate documentation, which is rarely accurate.  By having the build fully automated and part of the project, you are tracking all changes to the build system along side changes to the application, therefore providing build system traceability.

5- Simplicity  and Flexibility

When it comes to tools for an agile project, the agile community is very clear to say that simplicity and flexibility are mandatory. There are many tools on the market that implement processes not compatible with the project's approach, not compatible with other tools being used, etc. The cost of implementing these types of solutions can be very expensive and most commonly show up as slowed productivity for the development team.

Agile incorporates "iterative" development, which by nature requires built in flexibility. I recently heard a good analogy for "iterative" from Mike Cohn (XP Denver member, that compared iterative to playing golf. When you tee off, you shouldn't have to analyze in detail the breaks of the green - you should be considering wind, general direction of the green, hazards, etc. You are trying to get the ball closer to the green to set yourself up for your next shot. You then analyze the detail that is necessary for your next shot, and so on until you put the ball in the cup. Waterfall says that you analyze ALL details before you tee off, put the plan together and stick to the plan. In real life, we get smarter as we go and should set ourselves up to adjust easily as needed. Therefore, we need processes and tools available that allow us to modify our plans as we go.

Traditional SCM says that we put together a rigorous SCM Plan up-front that dictates what artifacts we'll create, how we'll build the system, all dependencies that we have, etc. To change any of these requires an act of Congress along with a documentation effort, and likely unnecessary approvals from folks who aren't "in the know." For an agile project, we really don't need to know all of these things when we're teeing off. So, the initial SCM Plan for an agile project should document only those things that are necessary for that first shot as well as more static characteristics of the application. We'll have time to refine things when we walk down and assess our lie. This is where flexibility is so important. SCM solutions must provide traceability on artifacts even though they're being renamed, deleted or copied, or new file types added. They must provide a frictionless way to associate file changes to "business level units of change" called Change Requests (CRs), User Stories, Requirements, etc.  As discussed earlier, SCM solutions should put up inexpensive guardrails instead of forcing expensive process. Tools that enforce process excessively require significant administrative overhead, decrease the team's velocity and increase the time and resources required to make adjustments to the process.

I'm not saying that to be flexible, the tool shouldn't enforce process.  The SCM solution you implement to support your agile