It's Time to Be Clear about Agile SCM
By now, most of us are familiar with the agile software development methodology. Typically this methodology uses Scrum, kanban, or some other discipline to help teams move rapidly and iteratively toward the completion of a software product. It involves frequent customer interaction with the evolving product, so that customer issues can be addressed before product delivery.
But what about agile software configuration management? Brad Appleton, Steve Berczuk, and Robert Cowham (the ABC team?) have published a series of articles on CMCrossroads covering Agile SCM articles that addresses this topic—a great resource to be sure!
The only problem I have is that the term “agile SCM” is ambiguous. On the one hand, it refers to software CM for agile development, and on the other, it refers to an agile way of doing software CM.
Perhaps the purists might argue that agile methodology needs no management tools, just a storyboard and regular meetings to supplement the usual compile and link tools. But there are all sorts of tools out there for agile (LiquidPlanner, Mingle, and Rally, to name a few). However, it is important that CM tools exist that both support the agile methodology and are themselves consistent with the agile philosophy.
A CM tool for agile methodology will collect user stories and trace the changes made against each story. It will identify burn down rates based on actual repository content. It will assist the product owner in managing story priorities, partitioning stories into releases and iterations, and assigning stories to developers or design managers. A CM tool for agile will clearly identify backlogs for each iteration, release, and the product as a whole; this includes both problem and feature backlogs.
A CM tool and process that is itself agile will eliminate the idea that there is overhead in doing CM. Rather than imposing on the developer, it will increase developer productivity. How? Change packages (aka updates) will allow repetitive operations—such as check-in, delta reporting, merge, roll-back, and promotion—to be done once per change, instead of file-by-file.
Personalized, prioritized to-do lists for the current and next iterations will always be just a single click away. Accomplishments will also be a click away, ready to display for the next scrum. Story boards can be electronically viewed or updated from anywhere. Status information is updated by the CM tool based on each developer’s actions. Continuous integration maintains the integrity of the evolving product.
One further clarification—some speak of “agile” and “ALM” in the same breath as if one implies the other, or as if ALM is just Agile CM. They are independent terms, with many ALM tools trying to cater to the agile development.
So when we’re talking agile SCM, let’s be clear. We’re not talking just CM for agile shops, or agile CM tools and process. We’re talking both. To dig deeper, see my article, “CM: The Next Generation of Agile CM.”
