In the previous article we discussed how transitioning to agile while satisfying the requirements of quality management system standards was a challenge confronting both mature companies and startups. In this second article we will present an evolutionary framework that accomplishes this goal at minimum risk.
Agile Stage 1
First, let’s consider a generic phase/gate model, typical of waterfall organizations (click on the image to see a larger version).
Let’s call this “Agile Stage 1″. I’m calling it Agile Stage 1 because I am assuming that the starting point is a solid process baseline that produces software releases in a consistent and predictable way. You can not build a successful agile framework on top of a sloppy set of development practices. In fact, this is likely to make organizational performance worse.
The central goal of agile adoption is to eliminate or minimize sources of delay in the software production process. In the above process some of the major sources of delay are in the handoffs, internal work queues, and re-work. One of the most obvious items for elimination should be the handoff between development and validation. Why can’t these be done concurrently? Let’s call this Agile Stage 2.
Agile Stage 2
To achieve concurrency, and to do it effectively, requires a number of prerequisites to be in place. These include:
- Continuous integration
- Automated regression testing, and
- Code in a potentially shippable state at the end of each sprint
The validation team begins testing as soon as the first User Story is declared ‘done’ by development. (The triggers and user story state transitions associated with this require good tools. More on this in the third article). Having a potentially shippable increment at the end of each iteration requires continuous integration and testing of all code check-ins. This also implies that all bugs are fixed as soon as they are reported – no accumulating of bug backlogs and associated re-work). The front-end of the process is largely unchanged, and continues to satisfy the requirements of ISO/TL9000. Let’s call this “Agile Stage 2″.
Please not that is not the simple encapsulation of a sprint-based development phase by traditional waterfall. The adoption of continuous integration with automated regression testing of each build, and a demonstrable ship-ready increment at the end of each sprint is a serious step forward on the road to agility. Yes, we still have the overheads associated with the Definition and Launch phases, but these are arguably necessary in any case where you have a large cross-functional organization, engaged in multiple programs, with mature customer organizations that have very formal procurement processes.
Agile Stage 3
Are we there yet? Stage 2 represents major progress, but we still have some fundamentals to tackle. What we are pushing for next is concurrent Planning, Development and Validation, that is, a merging of 3 classical waterfall phases into a single framework. This step requires a broader circle of individuals beyond the boundaries of the engineering function to be fully on-board, and thus requires some fundamental changes in both technical and organizational behavior. One note of caution is worth emphasizing: abandon the “PRD” at your peril! One of the issues constantly raised at sprint retrospectives is a complaint about not having solidly defined user stories at the start of a sprint. This causes the team to make frequent calls back with the product owner for clarifications and more details, which of course adds up to a significant source of delay, the very thing we are trying to eliminate. You cannot replace the waterfall “Planning” phase with a single, time-boxed activity called “Prepare Product Backlog”. The product backlog preparation will be an ongoing process that runs concurrently with sprint execution, and delivers a set of “Sprint-Ready” user stories into the start of each sprint.
Agile Stage 3 could be represented by the following diagram:
Finally, having successfully arrived at something like Stage 3, how do we conform to the requirements of ISO/TL-9000? This will be the subject of the next article: Achieving agility while staying in control, Part 3.