How to be Agile With a Fixed Scope Business Case? Part 2 - Business Benefits over Business Requirements

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 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.

 

In the spirit of focusing on ideas whilst staying grounded in commercial realities, I advocate moving the spotlight from the individual line items contained in the BRD to the business benefits embedded in the project's business case.  With your business benefits in hand, you still need to get to features that are deliverable by an agile team in a number of weeks.  What’s more, you want to move mindset from “progress against scope items” to “progress against projected benefits”, so you want those features to have measurable benefits.  Readers of my blog probably won't be surprised to hear that my preferred approach is to use Gojko Adzic's Impact Mapping. Taking one business benefit at a time, create an impact map for each. The measurable business benefit becomes the S.M.A.R.T. “goal” and through the process of impact mapping you can discover the features (the “deliverables”) that are likely to change the behaviour of the people who contribute to the “goal”. As Jeff Patton says “at the end of the day, your job isn’t to get the requirements right—your job is to change the world.” By using Impact Mapping to identify features, you will be forced to consider how each deliverable contributes to the benefits baked into your business case.

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?