Why requirements in software development harm collaboration, stunt innovation, and threaten the quality of our products.
“Software development has been steered wrong by the word ‘requirement,’ defined in the dictionary as something mandatory or obligatory. The word carries a connotation of absolutism and permanence – inhibitors to embracing change. And, the word ‘requirement’ is just plain wrong.”
I wish I could take credit for first publishing a quote like this. But it was Kent Beck who actually did in his 2nd edition of Extreme Programming Explained.
Let me see if I can explain why the word “requirement” is just plain wrong.
I’ve been seeing a pattern lately with Agile projects.
It’s not a new pattern. It’s one we’ve all likely seen on more traditional development projects for years.
The story goes a little like this:
A customer needs a software solution to a problem. An Agile team swoops in and in a reasonably short amount of time, and in collaboration with customers and end users, writes a bunch of user stories. Developers then estimate the stories. Together we spread these stories out over time and build a release plan. The customer makes some tough tradeoffs and winnows the release plan down to a set of stories that we all believe can be completed by the release date. The customer cautions “We really need to hit this date… we’ve got a lot of people depending on this software.” The story estimates have been “marked up” – a load factor applied based on historic team velocity. We’re comfortable we can deliver these stories by the release date.
Those of you with a few years experience in software development have some guess about what happens next.