Scrum And Strategy

Posted by Mukund Srinivasan on Dec 15, 2009

Sections

Process & Practices

Topics

Agile ,

Agile Techniques ,

Agile in the Enterprise

Tags

Scrum

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:

1. Modification of ship date (earlier) based on sufficient aggregated value or perhaps opportunistic deals.
2. 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.
3. 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:

1. False precision of estimates.
2. Change in business conditions causes detailed plans/designs to be reprioritized.
3. Uncertainty is typically ignored and not visible until late in the project.

Traditional planning/strategy issues

1. Focuses on tasks (requirements doc, design doc, test plan) rather than customer value.
2. Activities are not independent and dependency tracking is very complex.
3. 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!

1. Back to top

   In essence, our fault!

   by Dave Hitchman

   If I read you right, you are suggesting that Scrum is great for delivering the correct product at the correct time (my feelings as well) but that we sell it on the basis of its short term functions - flexibility, short term deliveries, motivation from immediate deadlines etc. and fail to mention that the delivery team is focussed on delivering - in a flexible manner - what is required, while the business and product owner (especially these) manage the strategy covering the long term direction the development is taking?

   Reply

2. Back to top

   Good topic, but...

   by Gary McCants

   I like and support the premise of your article. However, I'm left feeling hungry for more meat. May I offer some thoughts? While I agree Scrum address the specifics of execution, when executed with skill it also provides a vacuum for things to do, and I feel Scrum and our Community has some scattered answers to filling this vacuum. (BTW, a vacuum is critical to change imho, and agile coaches need to be meteorologists that understand low and high pressure systems, but I digress...) For example, Scrum calls out for the Product Backlog. If one follows the ideas of Cohn and others on Release Planning, then you get at least part of the answers for longer-term planning.
   
   But I propose there's more. If one considers that in an enterprise of any size you might have more than one Product Owner and Product Backlog, and that the concepts of Themes can be harvested from just focusing on one Product Backlog, and finally that there is some merit in the idea of One True Metric, then we have a model for longer-term thinking that can affect many Product Backlogs, and thereby many Scrum teams, and serves to compliment tactics with Strategy.

   Reply

3. Back to top

   Agile Estimating and Planning (the book)

   by Dandik M

   It seams to me as if this grate book "Agile Estimating and Planning" can provide a lot of value on this question. At least I do not see anything here that would not be covered in it.
   
   Though there sure is one good point in the article. Good understanding of agile planning principles is a must for any agile methodology be it lean, scrum, XP or whatever combination of them. Without it a lot of agile practices might seem to be pointless or have no reason.

   Reply

4. Back to top

   Double edge sword

   by Prasad P

   In a distributed context, non perspective and self managing nature of scrum is really challenging. We may have to plan for common practices on both project management and engineering

   Reply

5. Back to top

   In scrum - are we missing the bigger picture?

   by Udayan Banerjee

   setandbma.wordpress.com/2009/06/18/why-am-i-unc...

   Reply

• Older >