Applying CM to Agile Teams

The short answer is yes and ‘identify' and ‘control' are critical to the ability to rapidly change which is a key part of Agile.  The long answer is that CM should be tailored to meet the pace of agile development.  CM should support the Agile working process while not sacrificing the CM principles.  CM should ensure the integrity of the value stream, by eliminating waste and being lean while enabling control of the changes.  Part of this means that what gets prioritized or ranked as having the highest value is what should get delivered.  By identifying all of the pieces of a value stream, you can more easily identify the waste.  There will always be rejected work, incomplete work, and defects by the end of an iteration, and CM principles can help identify them. 

Adjusting CM for Agile
Now that Agile has been around awhile, it is important to understand that the implementation of CM should be adjusted to ensure Agile principles remain intact without damaging any of the CM principles.  Keep in mind that identifying, controlling, auditing, and reporting are CM principles that are agnostic to the development methodology applied.  As long as the CM principles remain intact, CM can be applied in different ways per the need of the development methodology. 

In many cases, CM finds itself in an organization that has a traditional methodology that consists of waterfall or sometimes a hybrid that has some parallel phases.  Less frequently, but more often than in the past, CM finds itself in an organization that is Agile (or part Agile and part traditional).  In all cases, as Agile gets introduced, the implementation of CM should be adjusted to fit the need of Agile development methodology.  So, the question is, what are some of the adjustments to CM to ensure that it fits the need of Agile development while still maintaining the principles of CM?  Some areas to consider are the following:               

Think Smaller
One of the key focuses in agile is to think in smaller iterations and increments of work.  CM must support the ability to manage smaller increments of work and the increase in the rate of change.  CM for Agile is not minimal CM, but CM that can handle rapid identification and control in order to maintain the high pace of change while at the same time minimizes the effort in managing the change.  While this is really more of a Product Management or Release Management function, CM needs to be ready to accommodate the smaller chunks of work and higher rate of change.  Typically this means that there are more incremental deliveries (both internal and external) with the implication of a greater need for automation, adjustments in branching and a stronger need for automated merging (more on this shortly).     

Build... Continuously
In a traditional development methodology with longer release cycles, building the code does not typically start until the development phase and the build frequently may be weekly with some teams reducing this to several times a week or even nightly.  In an agile methodology, builds should be continuous meaning as frequently as daily or nightly and more typically after every check-in (or promotion) into the integration stream.  Also, it is critical that a successful build occur in the private workspace with the local changes and the latest baseline of code from the parent or backing stream prior to promoting or checking in the code to the parent stream (note, this is a good practice irrespective of the development methodology used).       

The ability to perform continuous builds also implies that you have both the tools and processes in place to manage this frequency.  Implementing build tools such as CruiseControl or BuildForge (and there are many others) will help to achieve this.  Another option is to script a build function upon check-in. 

In addition, there is a strong need to understand the current build practice and adapt it with the build types that are needed (private, shared, integration, release) and levels of builds (component, product, etc).  This helps determine where the bottle-necks are - ergo, where the waste is.    

Workspaces, Branching and Merging
In Agile, everyone should have their own workspace.  There may be a need for shared workspaces if pair programming is being used.  This way, the same two people can share the workspace and changes therein.  Most of the time they will work together, but sometimes they may need to work separately. 

The number of branches that are needed depends on the Agile project and how it integrates with other projects.  If the Agile project is small and independent of other projects, having a private workspace off of the mainline is not unreasonable.  However, as the team gets larger, the need to have another layer of integration between personal workspace and main-line may be needed, but one should attempt to keep this a minimum if possible to reduce effort in integration. 

With the rapid pace of Agile also comes the potential need for automated merging.  Most CM tools today come with this feature so this should be a given in most cases.  If not, consider upgrading.  This becomes more of a need the larger the Agile project is or when more people must touch the same code modules. 

CM Co-op environments
If your organization plans to deploy Agile in a big way, you need to have a CM Co-op environment (tools, infrastructure, and processes) available to quickly bring Agile projects online and use CM immediately.  In a more traditional methodology, you have until the development phase to get the CM environment up and running.  With an Agile methodology, the CM environment needs to be ready right after iteration planning which is much earlier than the development phase of a more traditional method.  This is where an organization should consider a CM Co-op service model to more quickly bring projects into using CM environment.  This can be particularly advantageous when an organization is trying to bring several Agile projects online within the same time period.  The CM Co-op eliminates the need for installing the CM tools, setting up the infrastructure, and establishing the processes.  Instead, all that needs to occur is either setting up a repository following the established CM process or setting up a project branch within an existing repository.       

Automate...
Simply put, CM for Agile requires more automation.  Agile implies that the project team is developing product earlier and faster than the traditional methodology.  Manual processes start to become bottlenecks to the progress that Agile can provide.  Moving to more automated solutions removes bottlenecks and allows the team to focus more on development.  Of course, having automation within any methodology is beneficial, but for Agile it becomes necessary.  Some examples previously discussed are build automation (for continuous builds) and merge automation.   In addition, unit test automation and integration test automation can be added.  Automating other types of testing is also beneficial (e.g., regression testing, performance testing, etc.) but outside of the realm of CM.  

Moving Change Control into Iteration Planning
In a traditional development methodology, change control meetings are used to review and manage change.  It is needed because the project is long enough that it has passed a requirements baseline phase and changes must now be managed.  Because Agile works in short iterations, Change control is not needed and becomes imbedded in the iteration planning session.  Of course, changes can get identified at any time and should be captured.  However, the changes should get discussed during the next iteration planning session and not within iteration of work.  Keep in mind there are times that a change does stop the iteration due to the nature of the change, but typically this is rare.    

Role
A CM professional can support development in both a traditional methodology and an agile methodology at the same time.  On the Agile projects, the CM professionals (particularly Build and Release engineers) should be invited to the daily stand-up meetings to ensure they hear of any CM-related problems without delay for quicker resolution.  Since daily stand-ups typically last no more than 15 minutes, this is not an unreasonable burden to the CM professional and helps them understand the context of the work at hand.  Note, if the daily stand-up meetings last longer than 15 minutes, then it is probably breaking an agile rule and should be investigated. 

The CM role may also be shared by the development folks if the build process is automated or well scripted.  In general, if it is the final build of the iteration (which always has the possibility of becoming the release build), then the CM professional should be involved.  The CM professional should continue to be the person to migrate the built code to the next level to ensure integrity. 

Adjusting CM metrics to identify waste
CM metrics can be a valuable part of any methodology, especially when they are focused on measuring waste which is often a key component of Agile related metrics.  Introducing the notion of waste from lean methods can help.  This focuses on over-production, wait-time, transportation, processing, inventory, motion, and defects as introduced by Taiichi Ohno for manufacturing, then translated by Mary Poppendieck for software development.  Examples of CM metrics that can help an Agile project are:

o        Compare the stories or requirements that were prioritized for the release vs. what was delivered (inventory or requirements). 

o        Identify the additional changes made not identified in the value stream (over-production or extra features). 

o        Capture time spent on recovery from broken builds (defects).  Broken builds are outages and should be measured. 

o        Identify the number of builds that occurred vs. what was used further down the migration path (extra processing).  This determines what the downstream processes can actually handle.  

References

•  "Software Configuration Management Implementation Roadmap", Chapter 1 section 2.1, by Mario Moreira, Wiley Publishing, June 04. 
• Lean-based Metrics for Agile CM Environment, by Robert Cowham, Brad Appleton, and Steve Berczuk, CM Crossroad CM Journal, March 2007
• Lean Branching, by Robert Cowham, Brad Appleton, and Steve Berczuk, CM Crossroad CM Journal, July 2007
•  Principals of Leaning Thinking by Mary Poppendieck, Poppendieck LLC, 2002

Trackback(0)

TrackBack URI for this entry

Comments (1)

Subscribe to this comment's feed

Janie Jones said:

... This is helpful, but more info would be more helpful. For example, how should identification practices change in an agile environment? Should we be identifying a different set of "stuff", or identifying it with a different type of identification scheme? You say change control must adapt to the short iterations, but beyond "discussing" changes in a daily meeting, how should a CM person record and keep status when things are changing so quickly? I appreciate the "what" aspects of this article, but I need more "how."

report abuse vote down vote up

November 18, 2009
Votes: +0

Write comment

Name

Comment

smaller | bigger

Subscribe via email (registered users only)

Write the displayed characters

Add Comment