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.
Organizing Agile practices into a comprehensive framework
I would like to suggest that the agile community needs to organize agile practices into a comprehensive framework that can help make agile wisdom more accessible to developers and development managers who would like to adopt agile practices and, of course, become more agile in the process. One way to do this would be to start with a waterfall life cycle and simply show how agile practices map to each stage. I suspect that there are better ways to represent this and I invite our readers to send me their own suggestions on how this could be approached. One area that I would like to start with is looking at how to map requirements management.
Requirements should be "right-sized" based upon risk. It is just not enough to say that we value working software over volumes of out-of-date documentation. Sure we all agree with this principle, but still the missile guided software or the real time trading system still needs documentation AND we also need the software to work. Rightsizing the documentation, based upon risk, might very well be the best approach to deciding just how much documentation is needed. Test driven development can also help by producing some test scripts that can be used to document requirements as well. I have always advocated that every defect reported should always result in a new test case being written and that is implicitly useful requirements documentation.
Agile is here to stay and continues to provide wisdom and best practices that can help improve any software development effort. Developing a comprehensive framework would improve accessibility and speed adoption - while still allowing agile to maintain its core character and value! I would love to hear your input on how this effort could be approached!
About the Author
Bob Aiello is the Editor-in-Chief for CM Crossroads and an independent consultant specializing in Software Process Improvement including Software Configuration and Release Management. Mr. Aiello has over 25 years experience as a technical manager in several top NYC Financial Services firms where he had had company-wide responsibility for CM, often providing hands-on technical support for enterprise Source Code Management tools, SOX/Cobit compliance, build engineering, continuous integration and automated application deployment. Bob is a long standing member of the Steering Committee of the NYC Software Process Improvement Network (CitySPIN), where he serves as the chair of the CM SIG. Mr. Aiello holds a Masters in Industrial Psychology from NYU and a B.S. in Computer Science and Math from Hofstra University. You may contact Mr. Aiello at firstname.lastname@example.org or link with him at http://www.linkedin.com/in/bobaiello.