Agility Becomes Mainstream

Wed, 05 Dec 2007 20:17:30 GMT

In today's article in the Financial Times Digital Business section called "What's on CIO wish lists?" Steve Bozzo, CIO of 1-800-Flowers.com, is reported to say that compaines must migrate to an "agile" architecture if they are to bring products to market that will have maningful impact on earnings and revenue. Mostly he is referring to SOA. But later on the article states:

Note how quickly methodologies such as "agility" - developing software in a quicker, less formal way - and "service-oriented architecture" - ways of persuading legacy systems to work with smart, new stuff - have moved from "might have" to "must have".

When FT is reporting on agility as a "must have" it is a sign that Agile Methodologies are beginning to mature.

When I was at the Patterns and Practices Summit 2007 at the Microsoft campus in Redmond last month, one of the sessions discussed the evolution of agile and was called "The Legacy of Agile Methodologies" by Steve McConnell of Construx. His slides from this talk are available here but require a registration. It was one of the better talks at the P&P Summit. He spoke about how he has witnessed an evolution over the 6 years from a more extreme to a more blended approach. For example:

6 Years Ago	Today
No design up front	Focus on design simplicity
40-Hour Work Week	Sustainable Pace
Package methods	Blended packages (e.g., elements of XP within Scrum)
Agile as a standalone process	Agile practices used within stage-gate process

Steve's clear #1 positive of Agile's legacy is "Heightened awareness of importance of short iterative and/or incremental development cycles." Which have pounded the final nail in Waterfall's coffin and provided a helpful check and balance against overly bureucratic CMM implementations.

Another important aspect of the talk, which you can see for yourself by downloading the slides, is the effect of defect removal. Both with iterative and agile methodologies, you have more opportunity to remove defects early on. The cost of defects become incresingly more costly as more and more progress is made in a project. The well defined activities in software development are requirements, architecutural design, detailed design, construction, developer test and integration test, and finally system test. Not counting moving to production and have the impact of the real users report defects. So if you have a defect in the requirements and you fix it during the requirements phase, it is much cheeper than fixing it later on. It also gets more costly, the further we get before we start fixing it. For example if there is a requirements defect that we identify and fix during detailed design, it may require some architecture changes and detailed design changes. But if we identify that same requirements defect during system test or worse when the applicaiton goes into production, then it becomes much more costly.

So think about this from every activity. Each activity (or phase in waterfall speak) has potential for defects. How do you best identify and fix them when it is the cheepest. Well, if you are using Waterfall, they all pile up at the end and it becomes death by change order. If it is iterative, then you get at each iteration the ability to identify and remove defects. It is better than waterfall, but ideally, with agile, you are delivering functionality early and often to the customer. This gives the customer and the development team opportunity to identify defects early and often when it is most cost effective to fix.

Another interesting thing I learned at the Patterns and Practices Summit 2007 was that XP and Scrum were meant to be together. I have always believed in using the best of the various methodologies and build your own that works best for your team and your project. But according to Peter Provost of the Patterns and Practices group, when Ken Schwaber wrote the book on Scrum, he didn't include all of the XP practices such as pair programming, because there was already a book on that, referring Kent Beck's book Extreme Programming Explained. But these two are very compatable with each other. Scrum defines the project management aspect and XP defines the practices to make agility work, such as unit testing and pair programming. It seems that many people in the early days of the Agile revolution (I'm talking 2001-2002 when agile was a new hot fad), many practitioners picked up a book such as Scrum or XP and said this is the methodology we are going to use. This is evident in Steve McConnell's talk on agile's legacy as he notes the trend from "packaged methods" to "blended packages".

I am a huge proponent of Agile and signed the Agile Manefesto the first year it was was up. If you are also a proponent of Agile methodolgies, I encourage you to join the ranks of Kent Beck, Ward Cunningham, Martin Fowler, Jim Newkirk, Ken Schwaber, and many others by signing the Agile Manifesto.

What is most important about agility is that don't just use agile practices and agile methodologies without understanding why you are doing it. Because, as described in Peter Provost's talk "Agile is more than 'Monkey see, Monkey do': You have to change how you think!" from the P&P Summit, the principals and values of agile are much more important than the practices.

Talbott Crowell's Development Blog: Agile Software Development

Agility Becomes Mainstream