September SPIN – Agility and Requirements Management
Advanced Technology Systems Corporation (ATSC) brought in Ken Clyne to speak to SPIN on Agility and Requirements Management. Ken spoke with a Scottish accent and was easy to listen to for an hour and a half. Ken drove in from Columbus after a flight from D.C., and ATSC also flew in Rob Kowalski, their territory manager, from Chicago. Yvonne Nabors, an ATSC Cincinnati-based process engineer and PMP also attended. The ATSC folks were great to talk with and did a solid job providing some meaty content for the presentation. It’s obvious that Ken knows his stuff.
I also had an opportunity to talk with Patrick Mergler of Ethicon Endo-Surgery. They’re doing a lot of interesting work and delivering with globally distributed teams.
Ken approached agility as a pragmatist, which I think is a healthy perspective. Dogmatism and skepticism don’t generally provide a useful platform for progress. And the bottom line is that agility doesn’t replace all the other good stuff, especially the people. So Ken describes himself as an agile-ist and a people-ist.
We all know that defects caught in production are 100 to 200x more costly to fix than those found during requirements. Perhaps a more telling statistic is that 41% of software errors are requirements errors due to lack of user input and changing requirements.
Yet adding detail to requirements costs money and potentially constrains implementation, not to mention that it is impossible to know all the requirements up front and nobody reads them anyway. More detail can lead to a false impression of precision, which is key to their uselessness as an up-front process. For instance, if I tell you it takes me 67 minutes to drive from Columbus to Cincinnati and then I show up in 70 minutes, I’m a liar and you’ll never believe me again. If I tell you it takes me a bit over an hour and I show up in 70 minutes, well then I’m a man of my word. The precise requirement was not an accurate representation of the reality.
Ken highlighted a set of Standish Group statistics (highlighted in this Fowler post – look at the Build Only The Features You Need section) that say 20% of a product’s features are regularly used and that 64% of a product’s features are rarely or never used. Perhaps this 64% represents the greatest cost in a project.
In the agile world, requirements emerge through conversation. Objective acceptance criteria (a euphemism for “detail”) is pushed to testing. If you give a developer a test then he’ll know when he’s “done”. Decisions continue to be deferred until the maximum amount of information is known. For instance, Toyota did not set out to create a hybrid car with the Prius. Instead, they started with the concept of creating a vehicle that got 47.5 miles per gallon. As time passed and decisions were deferred, the cost of hybrid technology came down and understanding of how to reach the 47.5mpg goal became clear, then the hybrid concept became a viable solution – late in the process.
Consider cooking an omelet. You could order a western omelet off the menu where the cook follows a recipie (written requirements), but if you changed your mind on the green peppers you’re out of luck. You’re gonna get green peppers. Compare this with an omelet station at the hotel buffet. At the omelet station you (the stakeholder) are in a conversation with the cook (the developer). If you decide that you don’t want green peppers as the cook reaches for them, you can stop him. If he already put green peppers in and you decide you don’t want them, the cook can toss out the half-cooked omelet before spending any more time or wasting any more ingredients. In any case, it’s fresh and it’s exactly what you needed at the minimum cost. One of the benefits of agile projects is that they fail much faster and your stakeholder will know quickly if spending the money is a bad investment.
Requirements in the agile world are user stories – a written description of a conversation. To ensure complete and accurate implementation of a story, provide a test. That way the developer will know when the feature is complete. Ken suggested a couple of great books about user stories including Mike Cohn’s User Stories Applied and Rachel Davies The Power of Stories (PDF).
As an aside, Ken also recommended Cohn’s Agile Estimating and Planning 
The greater the separation between the stakeholder and the team, the greater the dependency on the written word. Obviously, co-located teams are the most successful agile teams. A number of tools exist to help distributed teams on agile projects.
The principles of agile teams include continuous delivery, welcome changing requirements, the business works with the development team daily, and simplicity – where success is measured by the amount of work not done, because it didn’t have to be.
Finally, Ken recommended Mary Poppendieck’s Lean Software Development 
Kishore, thanks for another great meeting!
- Andy