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.
reminds me of Lean priciple of “identifing and eliminating waste”. Waiting for specifications to be ready upfront is an important source of waste.
That is absolutely correct Oana. I created a blog post back in February about eliminating waste. I didn’t mention this particular waste, but several others. I am a STRONG believer in the power of the lean principles in guiding agile practices. Almost all of my courses start with those principles!
– Bob –
Well I tell you what. I wish I’d read this post fifteen months ago when we were just starting out with Scrum. We got the whole concept wrong, and ended up having thrashing arguments with the P.O. about the requirements being changed, wrong, and added.
It was a long and drawn-out battle for me to convince everyone that requirements are not the ‘starting block’ of the sprint, they’re the finish line. (or somesuch)
Nice succinct, to the point post, Bob.
There are times when I see that the customer/PO isn’t even ready with what you call, “Get the requirements good enough to start moving forward”.
They just have a concept in their head and due to multiple dysfunctions (unavailability of a PO, BA, QA and architects pulled in multiple directions).
We can react to this situation where we start collaborating and help the customer start defining the requirements and start building simultaneously.
I am currently in a situation with a customer and reading this post inspires me to jump in and start collaborative: discover, define and deliver cycle.