Agile antipattern: Waiting for all the requirements before starting
Time for a short blog entry (I tend to be way too verbose!). I often see teams trying to make sure they have all of the requirements for their projects before they start doing any substantive work on the project. Unfortunately, this often leads to long delays at the front of the process which in turn causes the rest of the process to be squeezed. The Nokia Test for Agility underscores this point by having one of the questions be about specification. See this blog entry to learn more about the Nokia test and look particularly at bullet #3.
Remember a few things when you are tempted to get all of the requirements up front:
- Requirements WILL change. In courses I teach the average percentage of requirements which change is 50%.
- Requirements WILL be dropped. We almost always think we can get more done than is possible (or even desirable in many cases). It seems the average percentage of dropped requirements is 25%.
- New requirements WILL come up during development. This too seems to average about 25%.
When you take all 3 of these things together you quickly realize you are fighting a losing battle by trying to “get the requirements right” up front. Get the requirements good enough to start moving forward. Once work starts requirements can change, be dropped or new ones can come up easily if you truly embrace the agile principle to inspect and adapt. Keep looking for what will make the product better, not necessarily what a requirements list says from a few months ago. This isn’t up to the developers themselves, but the product owners and others who maintain the backlog. Build GREAT products by adapting to changing conditions. EMBRACE change as a good thing, not as an impediment.
Until next time I’m Making Agile A Reality® by focusing on emerging requirements over time, not trying (in vain) to get them perfect up front.