Wednesday, 27 May 2015

How to be Agile With a Fixed Scope Business Case? Part2 - 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 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.

Monday, 4 May 2015

How to be Agile With a Fixed Scope Business Case? Part1 - Small Batch Funds Release

How do you embrace change when your hands are tied by corporate red tape?

Many organisations I work with have existing business cases with fixed scope, time and cost expectations when they first decide to "go agile". The early conversations about "going agile" are generally prompted by either some misstep with a previous project or delivery issues with an inflight project. Agile is the magic answer that is going to radically improve the way Information Technology deliver projects. As the technology teams begin to "embrace change" and deliver "clean code", pressure begins to mount on the business processes that govern the project. Cries of "that's not very agile" are heard at every turn and the tension between the business and technology that had started to relax begins to increase again.

If you’re in middle management, you begin to feel trapped. You don't make the rules. Changing the corporate business case process is beyond your scope of influence. The project's governance board is holding you accountable for delivery of the project exactly as it is laid out in the business case and supporting business requirements document. So how do you escape the locked box and enable true business agility?