Scrum and Strategy
Usually when people are asked to differentiate between a Scrum workflow and a ‘traditional process’ driven execution of projects, the easiest answer is that you plan to the finest extent possible in the latter approach before beginning execution, whereas in the former, you plan just enough to get started and refine it as you go along. The slightly more elaborate answer that comes to mind is this – in Scrum, your depth of planning is progressively less granular, the farther you look in time. In other words, the immediate sprint is planned in extreme detail, you have a rough idea of what to accomplish over the next 3-sprints, and beyond that it’s a hazy timeline. Great – it makes a lot of sense, doesn’t it? But look beyond just the engineering, and you see there’re lots of other factors to running a business – forecast, product strategy, execution of the committed strategy – as in laying out a rough timeline of how the accomplishments would line up and add to the planned revenue targets. If Scrum is all about short term, how then do the strategy folks work in such an ecosystem? More importantly, how does it help business leaders make and live up to important commitments? Good questions, but there aren’t easy enough answers. However, make no mistake, strategy is every bit as important as execution itself because it is the guiding light that leads the way for a business to navigate a dark tunnel. Never was it as important to have a good strategy, as has the current market conditions necessitated it to be. Doesn’t all this make strategy and Scrum look like the two poles of a magnet, or even further – the two extremes of the planet?
Planning in Scrum – demystified
One of the common misconceptions of Scrum is that you don’t have an idea of when the release cycle is going to be complete, and when the final product (encompassing all of the agreed-upon features) is ready to be shipped. This is the argument that the most ardent of the supporters of the non-Agile processes have to say, about Scrum. In reality, this couldn’t be the farther from the truth. Scrum, having the definitive quality of non-prescribing nature, quashes this with the very attribute of not being prescriptive. Scrum, does not even remotely, suggest that you refrain from long term planning. In fact the long term planning is essential to give the business stakeholders a rough idea of whether the project on hand is feasible to the long term goals, or not. The traditional business tools like capital investment analysis, break-even analysis, etc. become all the more relevant in Scrum because it helps determine the value of not just the overall product but also the sum of its parts – the specific features that make up the product. This in turn helps the product owners determine, and get, maximum value from an investment into the project. In summary, all the Scrum approach suggests, is to have a high level objective in mind, and refine the plan to the level of granularity needed in the short term. So that, if there needs to be a change in direction or course correction needed, it is not only less painful but it also gives the business better control over the reaction to change.
Holistic, yet Logical
Scrum, to put in business lingo, is about “value driven” execution. To compare two courses of action : if some action were to provide a higher value, or return on investment, in comparison to another action then Scrum is all for the former, provided it aligns with your long term objectives and ties in with the business stakeholder needs. All of these thoughts can be explained better in a pictorial form that I was exposed to, when I attended the CSM certification.
Most of this is self explanatory, but here’s also a verbal summary of the key points:
- The whole premise of traditional processes, be it Waterfall or any variant of it, is to deliver solid and significant value after a period of time. The Y-axis in the above diagram shows the value in $, and the X-axis denotes the time. A quick glance at the above chart shows that Agile process is all about delivering some insignificant value at any instant of time, by doing a little bit of everything (the key) right from the beginning, and show measurable progress to stakeholders. Whilst the traditional process delivered a significant chunk of value *after* a period of time, the Agile process is about small, incremental progress over the same time interval.Essentially, the focus of this chart is to point out how the business aspect of a project is closely tied in with the scrum workflow of executing on prioritized stories.
In short, the focus is on how Scrum puts the business in control. The highest value stories get developed first thus providing the business the most opportunity:
- Modification of ship date (earlier) based on sufficient aggregated value or perhaps opportunistic deals.
- Tradeoffs of lesser functionality vs. date late in the release plan that allow dates to be met with little to no impact on revenue attainment.
- Tradeoffs of lesser functionality vs. emergent higher priority stories that provide more sales opportunities sooner.
By adopting the Scrum approach, we circumvent the issues that are typically common with highly granular long-term plans:
- False precision of estimates.
- Change in business conditions causes detailed plans/designs to be reprioritized.
- Uncertainty is typically ignored and not visible until late in the project.
Traditional planning/strategy issues
- Focuses on tasks (requirements doc, design doc, test plan) rather than customer value.
- Activities are not independent and dependency tracking is very complex.
- Lateness is passed down the schedule.
Tying the dots together
It might seem, to the casual reader, how the first and the second parts of the above section correlate. This is where looking at the strategy in holistic sense helps tie the dots together – strategy, to put in very simple terms, is about looking at the future in a theoretical sense. In some ways, Scrum and Agile, in their very premise are against looking too far ahead. The sense of building strategy not as a theoretical concept, but on solid foundations laid by the business benefits of the Scrum framework is the core to this philosophy. In other words, a monument’s architecture hinges as much on the strength of its foundation, as it does on its ability to visually please, by its exterior façade. In the same way, Scrum’s tenets are the foundation to a solid strategy.
We started off listing some of the commonly perceived notions of Scrum, and then described how Scrum looked like a misfit when it came to strategy, and moving on logically from there we tried to connect the pieces of the puzzle together. As a summary, I hope this article helps address some of the less familiar and much less talked about nature of Scrum. More importantly, execution and strategy are like the two eyes – Scrum addresses the specifics of execution, while strategy in the Agile ecosystem is a less cared-for brother, however no less important. As long as we, as Scrum practitioners, are aware of the subtle intricacies of the role of strategy within the Scrum framework, then we are doing ourselves justice. As an ending note, let us remember that Agile is non-prescriptive, and given the bounds of freedom the flexibility to improve the process leaves the ball in our court!