Applying CM to Agile Teams: A Look Back
I recently came across an article from 2008 on CM Crossroads by Mario Moreira titled “Applying CM to Agile Teams.” In this article, Mario presents several areas where he feels CM needs to be more agile. I believe this article is just as relevant in 2012 as it was when it was written, and I wanted to revisit this topic.
My take is that CM is already agile and that developers are the ones who need to be more adaptive because of this. Mario and I have had several discussions in the CM Crossroads Forums, and others have jumped in as well who were both for and against Mario’s stance on agile for CM.
In this story, I’ll highlight some of Mario’s main points (in quotes) and contrast them with my own (in Counterpoint or Agreement).
Think Smaller—"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."
Counterpoint: I see no issue with CM in its current form doing this. We rarely have issues moving rapidly, and instead we have more issues with developers throwing their junk over the wall and expecting us to find their errors.
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.”
Counterpoint: Again this is not an issue with CM. When using waterfall methodology, it takes forever to get workable and stable code—that’s not CM’s fault. As far as continuous integration, I have never met a CM person who was opposed to doing that.
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...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…With the rapid pace of agile also comes the potential need for automated merging.”
Counterpoint: I definitely want everyone to have their own workspace; I don’t want them polluting the pristine code in the central repository. Branching is fine with me, with the caveat that the more branches you have, the slower the developer becomes. Regarding auto merging—good luck with that. Manual merging is tough enough. It will take a leap of faith on part of the developer if you trust a tool to auto merge. Again, none of these issues is a problem for CM.
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.”
Counterpoint: Using Serena Version Manager, I can set up ten individual repositories in less than five minutes or twenty repositories in ten minutes. I don’t see an issue here.
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.”
Counterpoint: As a CM practitioner, I want as many things automated as possible—I always have and always will. This has nothing to do with agile, spiral, waterfall, or any development methodology you care to name.
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."
Agreement: I agree 100 percent with Mario here. In agile development, there is little time for useless meetings or rubber stamp groups. Embed the business in the development team, collaborate, and get the project done.
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 fifteen minutes, this is not an unreasonable burden to the CM professional and helps them understand the context of the work at hand.”
Agreement: Again I agree with Mario: CM professionals should be invited to the fifteen-minute stand-up meetings mainly used in the Scrum methodology and any other meeting that development is discussing, regardless of methodology.
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.”
Agreement: No truer words have ever been spoken. Cutting all forms of waste in projects via metrics is a great idea. I agree that lean methods should bring out the fact that waterfall as a methodology has too much waste, which hurts everyone involved.
Mario’s article is still valid today. Since my conversation in the forums with Mario, we have learned to agree to disagree. CM is about efficiency, despite what many say or think. We just need to ask that developers clean their own house before telling us that ours is a wreck.
