In my previous blog post, I explored how “small batch funds release” can be an enabler for organisations starting their agile journey constrained by a traditional fixed scope, time and cost business case. With this more flexible but also more tightly controlled funding process in place, it is time to turn our attention to navigating the “signed off”, “locked down”, “fixed scope” requirements contained in the Business Requirements Document (BRD) that underpins the business case.
Software developers working in traditional software development shops have been conditioned to expect their work to arrive in the form of requirements documents. Many organisations new to agile have fallen into the trap of transposing hundreds of pages of requirements documentation into thousands of “user stories” in a misguided attempt to provide “agile requirements” to the dev teams. As logical as this may seem to some this is not the answer. I could write write a whole blog series on the flaws in this approach, but some words from +Mary & Tom Poppendieck's latest book The Lean Mindset summarise it well: “A detailed list of requirements is not the starting point for good engineering. The Wright brothers did not start with requirements; they started out with an idea: build a glider and learn to fly it and then add power (and don’t get killed in the process).” So our challenge is clear, we need to make a shift from requirements to ideas.
Some agilists might recommend throwing the requirements document in the bin and starting over with a blank piece of paper. Do not do this! I have been on the receiving end of this approach and it is not much fun. While I am sure it was well intentioned at the time, it was immensely frustrating for the people who had already invested many hours in workshops providing the original requirements, followed by many more hours reviewing reams of documentation. On the other extreme, this does not mean you should try locking the technology team in a room with the BRD and none of the stakeholders that contributed to it. I have seen this done too and it is equally as disastrous.
As BDD expert James Ferguson Smart says, "At the end of the day, business people want the software being built to help them achieve their business goals. If the software is delivered in this regard, the business will consider it a success, even if the scope and the implementation vary considerably from what was originally imagined."
However, in the enterprise context sometimes this won't be enough. Introducing “change control processes” to create a paper-trail for significant scope decisions might feel anti-agile, but if you have a BRD to manage to, odds are you’re attempting to be agile while standing in a waterfall. Why not borrow some waterfall tools, and put them to a higher purpose?
Pretty Agile® and Tribal Unity® are registered trademarks of Pretty Agile Pty Ltd.