I know, I know. Performing iterations for the development phase only of a waterfall project is not exactly agile, but please bear with me while I give a little more context. Most large successful companies (say the Fortune 500) have been around for a while, and at some point on their road to success have decided to standardize their product development methodologies and lifecycle models. Senior managers responsible for a large portfolio of projects need consistent and accurate reporting of status. Even functions outside of engineering like sales and customer support need this information to be able to communicate release dates with customers and to gear up to support new product releases. Some organizations go even further and seek independent corroboration that their product realization processes have achieved sufficient maturity, and that they are repeatable and provide a basic degree of predictability and quality. Pursuing certification to one of the “Quality Management System” standards is a typical way of accomplishing this. In some cases standards like ISO9001 and TL 9000 are mandated by customers as part of their overall supplier agreements. These standards require companies to define, among other things, their lifecycle development models, and companies that undertake large development projects have typically done this via some form of “Phase/Gate” process.
Now even though many of the requirements of these standards are in no way in conflict with basic agile principles, or good engineering practices, the agile community are going to have a hard time accepting the expectations of auditors around how some of these requirements should be implemented. Let’s take a look at a few examples:
- Determination of requirements related to the product
- Review of requirements related to the product
- Requirements traceability
- Design and development planning
- Test planning
All of the above are basic product realization requirements from the ISO9001 and TL9000 standards. An auditor expects that you have defined how these are done, and also that “records” are available as evidence that you are actually carrying out what you defined in each of your projects. In a typical “waterfall” project the above items are reflected in the following project artifacts:
- Product Requirements Document (e.g. “PRD”)
- Requirements review report
- Requirements traceability matrix
- Project Plan
- Test Plan
|Product Requirements (“PRD”)||Product Backlog|
|Requirements review report||N/A|
This comparison may seem a bit harsh as many scrum teams may in fact do much of what is listed in the left hand column. However, there is no recognized “standard” for scrum (perhaps intentionally so), whereas the items on the left are defined in considerable detail (especially in the case of TL 9000). Even the typical scrum product backlog is going to have significant challenges surviving an audit. A product backlog comprised of sticky notes on a whiteboard is going to result in a major non-conformance due to lack of conformance to the fundamentals of document and record control.
The Transition Challenge
OK, so you are a ISO/TL-certified Fortune-500 company, and you want to become Agile. Or, you are a start-up, and have just inked a deal with a major service provider, but you need to sign a supplier agreement that has a clause requiring you to become ISO- or TL-9000 certified within the next 12 months. What’s the plan?