This month I had the opportunity to teach a class at a government contractor on the West Coast. These folks were responsible for writing mission critical software that had to work correctly or else very bad things could happen. I quickly saw that the class was composed of bright and experienced software engineers who worked through about four and half days material in less than three days. We even had time to talk about CM patterns and release management. With such a great class, I naturally asked them if they were using agile practices. They were not. I spoke about the benefits of continuous integration which was well received but overall they were used to a very disciplined software development framework that was most definitely not agile. What frustrated me most is that I did not have a solid framework to point them to in order to really get them interested in agile.
Why do we need a framework?
Last month I suggested that one way to meet the need for a comprehensive framework is to use existing standards and frameworks - for example mapping and harmonizing agile practices into the well thought out IEEE 12207 life cycle standard. I have been including agile practices in a framework that I am writing for a quality management effort and I certainly see value in that approach. It's true that agile has its own way of thinking and approaching software development and that has many benefits for successful development efforts. It's also true that developers need a better place to start in their quest to understand what agile is all about. I propose that agile needs a comprehensive framework that can aid as a tool in its adoption and use by development teams. That may mean that the extra documentation may run counter to the agile approach, but agile needs to mature into its rightful position in the software development world and right now it is just too hard for the average developer or software manager to really understand and manage the entire agile approach to development.
How do other frameworks approach this?
I am also knee deep in studying and applying both ISACA Cobit 4.1 and ITIL v3. The Cobit 4.1 framework uses a simple structure to organize 34 controls:
- Plan and Organize
- Acquire and Implement
- Deliver and Support
- Monitor and Evaluate
The ITIL v3 framework is organized into:
- Service Strategy
- Service Design
- Service Transition
- Service Operation
- Continual Service Improvement
Most of the CM and release management practices are in the service transition volume, but the entire framework is needed if you are going to implement the extremely popular configuration management database (CMDB). There is a lot of reading material to wade through in ITIL v 3 although it is very accessible and easy to understand. Whenever I take a deep dive it is easy to step back and see where I am in relation to the overall model. I don’t have that same experience when I read agile.
Alistair Cockburn does talk about methodologies in his text entitled “Agile Software Development – The Cooperative Game”. He also refers to methodologies as a straight jacket that people choose to use. Dr. Cockburn talks about the size of the methodology and the amount of “ceremony” – which is an indication of the rigidity of the process. “The amount of ceremony in a methodology depends on how life critical the system will be and on the fears and wishes of the methodology author..”, p. 157.
A framework would, of course, operate at a slightly higher level with the value of providing one-stop shopping to be able to understand and select the best methodology based upon the application team requirements and intrinsic characteristics.