Advocating Agile in a CMM or MSF shop – level 200

That’s exactly what I’m doing right now. My development shop used to be MSF waterfall and is now pushing for CMM. This is a push from management. It is very difficult to write good, maintainable software in this fashion. Sure, we can crank out version 1 and maybe 2 without a hitch, but as soon as the developers who intimately know the software leave, or forget, you immediately have legacy code. You don’t know what you can change without breaking other things.

I don’t recall from whom I heard the quote, but I’ve heard it said that:

Legacy code is code for which there are insufficient unit tests.

I could not agree with that more. I’m the pusher for TDD in my work group, so it’s difficult getting there, but there is a significant difference in the code that is written using TDD and the other code that exists (and is being added) without unit tests. The design is different too (TDD is design). It is incredibly obvious that 1) the TDDed code has fewer bugs and can be changed with confidence, and 2) The other code is a ball of mystery (legacy) that you don’t want to touch for fear of unforeseen consequences.

Another Agile practice I’m pushing is automated builds. Our build is scheduled to run twice a day. It does everything to get the new source built an on a development server. It runs the unit tests and reports. I use NAnt for that, and it works very well. I intend to hook up FxCop and CruiseControl.Net to our build process soon.

One thing I’m not sure will change is the manner in which we plan projects. Our project managers _must_ use CMM in their planning, so it’s probably a losing battle right there. The schedule will be set, the features will be planned, the headcount will be assigned, and then it’s expected that the team deliver 100% of the scope on the due date. No incremental releases with requirements verification and reprioritization, but pure waterfall. Plan phase, dev phase, stabilization phase, and deploy. Then 5 years down the road, replace the app because it’s become hard to maintain, but create the new app in the exact same manner. It’s quite confusing.

I also have some more general observations about much of the industry as a whole. I’ve heard when replacing an application that “we’re going to do it right this time”. I firmly believe that the first go-round was not preceded with the thought “let’s do it wrong this time”, yet when we identify that an app has turned out to be unmaintainable, and it needs to be replaced, why don’t we identify the reasons it became unmaintainable? Why don’t we fundamentally change the way the new app is written because just rewriting an app using the same process as the first is going to get the same result as the first.

If an application needs to be replaced, we should analyze why it failed. If it didn’t fail, and we just want to move to a new technology, then pieces of it should be wrapped and leveraged in the new app. If that can’t be done, then I would say the old app failed. It can’t be reused. It’s life is over. Going a step further, if you absolutely want all the code to be in the new technology, then just port the code. If _that_ can’t be done, then the app is a failure. The app is dead.

Agile methods, coupled with able developers, promise (and deliver) maintainable, well-designed software that will never become a rigid legacy application. As the word implies, the application will remain agile.

Tim Haughton 6:16 am on April 26, 2005

It seems to be quite a common situation. In particular, managers who’ve heard that being ‘Agile’ is the way to go, but who feel secure behind their phasist waterfall process.

There’s a nice anecdote in Uncle Bob’s Agile Software Development book (could be wrong – memory is a sieve); he asks a friend what he was working on these days, his friend replied "We’re writing legacy code". Of course the self contradiction disappears when you understand what he’s saying.

I’ve learned through experience that pushing too hard and too fast for Agile development can be counterproductive. It’s best treated as a case of "Softly, softly, catchee monkey." (http://c2.com/cgi/wiki?SoftlySoftlyCatcheeMonkey).

When there’s a great deal of process inertia, the method that I find works well, is treating the process as being under iterative development. For example, every month, try to identify what the biggest problem facing the team is. Then, from your "Agile practice bag", pull out the appropriate agile practice that addresses the problem you’ve got. Because some agile practices involve changes to the way some non-developers work, tiny steps is the key.

Good luck 🙂
Jeremy Miller 11:23 am on April 26, 2005

Better you than me. I flopped in the exact same situation at your employer a couple years ago.

Technically, XP or agile can be used within a CMM framework. Agile is all about the optimization of the execution and delivery of working software. CMM is really a means of certifying the management of a software organization rather than a true prescriptive process. "It’s a framework, not a process."

You could try selling Agile by preempting the "Yeah, but is it CMM" by showing how agile development practices map to the CMM KPA’s. Try this: http://www.sei.cmu.edu/publications/articles/paulk/xp-from-a-cmm-perspective.html

There is an effort to create an "Agile Maturity Model" to be a direct alternative to CMM certification, but who knows if it will ever be adopted or accepted.
Joshua Flanagan 8:44 am on April 27, 2005

I think you would be better off to show how Agile is compatible with CMM (thanks for the link Jeremy), rather than trying to sell an alternative like "AMM". Management is already convinced that CMM is good, and there really isn’t a need to convince them otherwise. CMM isn’t the enemy, the waterfall process is.
I don’t know enough (yet) about agile development methodologies to wage a proper battle, but I know enough about waterfall to know it is broken.
Jeffrey Palermo 10:49 am on April 27, 2005

Jeremy, you make a great point, and that article was really good. Agile _can_ coexist with CMM.

Josh,
Yes, management just cares about CMM, and the project managers care about CMM. We, as a development team can embrace Agile methods while still running the project within the CMM framework. Our schedules would be shorter, and we’d call the iterations. And, of course, the actual coding methods can be used anywhere.
Jeremy Miller 6:23 am on May 4, 2005

Josh, some sort of guidance does need to happen for Agile within CMM, because the CMM auditors are very uneven in their handling of XP and other agile methods.

Be careful though about running Agile inside CMM. Iterative development works far better when the project management, analysts, and testers are working in the same incremental mode. Doing iterative development unofficially inside of a CMM waterfall process is risky.

I do know of teams that have satisfied some CMM requirements while doing XP by auto-generating UML diagrams and unit test reports within the CI build. Satisfying CMM weanies doesn’t have to mean fancy Rational Rose drawings.
jmiller 12:40 pm on July 26, 2005

“Legacy code is code for which there are insufficient unit tests.” is from Michael Feathers in his book on Legacy Code – Jeremy

Comments are closed.

Programming with Palermo

Jeffrey Palermo, Microsoft MVP, Author, Speaker, Clear Measure Chief Architect, Azure DevOps Expert

Advocating Agile in a CMM or MSF shop – level 200

Related