How to be Agile With a Fixed Scope Business Case? Part2 – Business Benefits over Business Requirements
May 27th, 2015
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.
Now coming back to the BRD; the trick is to think of it as a head start rather than a ball and chain. Find the middle ground. Include the people who provided the original requirements in the impact mapping sessions and use the existing requirements as a starting point for the conversation. Of course there is a risk that the impact mapping workshops uncover new ideas/features that weren’t included in the original documentation or, perhaps even worse, requirements that cannot be mapped to the business case benefits. As the intergalactic hitchhikers say – DON’T PANIC! Remember that change control process we talked about in part 1 of this blog post? What if you used change control to discuss the deltas? i.e. scope that is no longer relevant as it does not map to the benefits and scope that should be added in order to achieve the benefits. “Embrace change” and shape the delivery scope so that it aligns with the intended benefits.
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?