Strategy – defined principles prescribing actions that will (hopefully) help us arrive at a future, aspirational state – is important. Really important. But we often ignore the big picture when running projects. It is too easy to forget that strategy and the execution of that strategy form an ecosystem in which the death of one will inevitably lead to the demise of the other. So how does a “short-term” Agile delivery mechanism such as “Scrum” help in contributing towards against a “long-term” strategy? Well, on its own it doesn’t. Indeed, we could imagine a situation where the team, continually delivering against product owner requirements but with no awareness of the wider environment, actually travels in the opposite direction to organisational goals. Without an overarching strategy it is nigh on impossible to know whether iterative delivery is pointing in the right direction, so we need to find a way to ensure that our Scrum activities and corporate objectives are aligned. But how best to do this? Classic project methodologies insist that the only way to exercise control is via detailed plans. However, this merely presents the illusion of control. Documenting (in great detail) things that most likely won’t come to pass is, when you come to think about it, a pretty futile endeavour. Indeed, all of the “traditional” project managers that I’ve ever met spend at least a day a week (often in secret) massaging their plan to fit reality or, in the case of status reports, massaging reality to fit the plan. Such “planagement” is a real waste of effort as there is no way that we can describe daily activities with any level of precision beyond more than a month or two. As Samuel Goldwyn once opined:
“Never predict anything – especially the future”.
In Agile, we’re generally happy folk who don’t worry too much about the future. We know it’s going to happen, we just elect not to worry about it.
So, “how on earth can we hope to implement any kind of strategy when using a framework such as Scrum?” I hear you think. By concentrating on the short-term while keeping an eye on the long game, that’s how. The upcoming 2-4 week iteration represents the limit to our detailed planning ability so, in place of detailed longer-term plans, we make the pretty major, and often divisive, decision at the outset to accept estimates for long-term plans. This is the antithesis of classic project management thinking: surely without a plan there is no project? But every plan ever made represents merely a possible version of the future, so they inherently veer towards being wrong. Indeed, the only way you can guarantee precision is by spending a lot of time either continually changing your detailed plans, or by forcing scheduled activities to happen whether they are required or not. At a previous financial services client I witnessed one of the senior project managers insist that a two-week UAT session, involving a dozen people from around the world, must go ahead, even though the system had been pulled and would never be used! This ensured that the plan was accurate, sure, but who did this benefit?
The only way to ensure that technical delivery is able to support business agility (i.e. changing requirements) is to set up a way of working that not only aligns and directs individual teams’ activities but which also allows us to rapidly change course when required. Following the Agile tenet of “simplicity”, or “maximising the amount of work not done”, I’ve found the easiest way to achieve this is to merely create and maintain a simple overview “helicopter plan” to describe the game plan.
This statement of intent, showing high-level deliverables against best-guess time estimates formulated by the team, is then used as a roadmap that describes our chosen strategic end-point, helping us to keep on a track defined by our customers/sponsor while baking in the capability to painlessly change direction if strategy should change. When coders at the online directory company Yelp discovered that people actively wanted to write reviews of businesses, they changed the way their website was structured so that this functionality was foremost. This is a pretty big change that would have prompted (in Monty Python parlance) a “magnificent display of non-inertia” for traditional project teams. For an Agile team, however, it would merely represent business as usual, with the next Sprint reflecting the new outcome and the helicopter plan being quickly updated to show the new goals.
Successful implementation of strategy is impossible without successful on-the-ground campaigns. But we must ensure that the sum of those campaigns adds up to the strategic goal. Agile can provide an operational structure to help us succeed, but only if we don’t take our eye off the end-game!