The Scrum framework is not a set of work instructions; instead, the framework is a guide within which teams learn how to work together to deliver value to the organization and discover which complementary practices work best for them. However, some see Scrum as a rulebook and take the guidelines too far. Others consider one or more of the complementary practices as “required”. In this article we will discuss a few of the common missteps that give Scrum a bad name.
Ignoring Incremental Delivery
According to the 2020 Scrum guide, “Scrum employs an iterative, incremental approach to optimize predictability and to control risk.” It sounds simple, and yet, those words “iterative” and “incremental” are so often misunderstood. “Iterative” in this context means frequent delivery. Easy enough to understand. But the word “incremental” is where people so often get tripped up. Incremental means that what is delivered is fully usable.
Think of an iphone. Each time a new upgrade is released, the phone is usable. Each time a software update is released, the phone is still usable. There may be only minor improvements, and yet, the phone itself is still usable. It’s a clear example of incremental delivery, because with each release, the phone is usable and additional value has been provided to the user of the phone.
With Scrum, teams should deliver a usable increment at least once per Sprint. For those who are new to the concept, this can be a significant change. Teams who have been using waterfall may not deliver value more than once per year, so changing their mindset to deliver value at least once a month is a huge change in mindset. It requires a whole new way of approaching work and value delivery. Rather than asking, what can we deliver one year from now, Scrum teams ask themselves, what is the most valuable thing that we can do next, and then they work together as a cross-functional team to deliver it.
Teams who do not fully embrace this concept give Scrum a bad name, because while they may be going through the motions and performing all of the Scrum events, if they are not delivering a valuable, potentially releasable increment at least once per Sprint, then they are not really embracing the mindset underlying Scrum. The result is that such teams are slowing value delivery, increasing risk and they are not really using Scrum at all.
Teams that deliver value incrementally have increased visibility, because at the Sprint Review, stakeholders can see a valuable increment and provide valuable feedback. Teams that deliver value incrementally also maintain a higher ability to change direction, because they do not have a lot of “sunk” cost in the sense that they are not carrying a lot of undone work which needs to be finished before the team can change direction. Teams that deliver value incrementally also reduce risk faster, because if there are integration issues, these are identified at least once per Sprint. Teams that deliver value incrementally also deliver business value sooner, because the Product Owner may decide to release the increment to Production at the end of the Sprint.
Where we’re going, we don’t need a forecast
Back to the Future Part 2. 1989.
According to the 2020 Scrum Guide, “Sprints enable predictability by ensuring inspection and adaptation of progress toward a Product Goal at least every calendar month.”. This means that at least once per Sprint, the Product Owner should forecast progress towards the Product Goal using whatever method is preferred. Examples of methods to forecast future delivery include a roadmap, burn-up chart, cumulative flow diagram or (my personal favorite) a monte carlo diagram which describes the likelihood of delivering a certain amount of work by a particular date.
And yet, so many teams seem to be very dismissive when stakeholders ask for a forecast. The attitude seems to be “we’ll get there when we get there”, which is true enough, but not very useful.
Teams who dismiss requests for a forecast give Scrum a bad name, because while Scrum teams cannot promise a fixed amount of scope by a fixed date at a fixed budget, providing a forecast is necessary in order to set expectations and guide decision-making for the Product Owner.
A forecast is a forecast, like yesterday’s weather forecast, it can always change. Scrum teams who are targeting a fixed date delivery may need to change their budget or scope in order to meet a date. Scrum teams who are targeting a fixed scope delivery may need to change their timeline or budget to deliver the agreed-upon product.
Having a forecast can help the Product Owner to make the right decisions to meet the Product Goal. “We will get there when we get there” is not an option for most businesses. Most businesses have deadlines and goals to meet. Scrum - real Scrum - can help by guiding decision-making using empirical data. Teams using Scrum have greater visibility into their progress and can create more accurate forecasts about future delivery. Using incremental delivery increases predictability, which can result in a more reliable forecast and can increase the likelihood of delivering against Product goals - even goals that are associated with a particular timeline.
Conclusion
Teams who adopt Scrum without incremental delivery or without understanding the need to provide transparency about progress towards the Product Goal give Scrum a bad name because they have not fully embraced a mindset of Agility and Transparency. To learn more about the concepts underlying the Scrum framework, signup for Rebel Scrum’s upcoming Professional Scrum Master course. For those who are newer to Scrum, signup for Rebel Scrum’s upcoming Applying Professional Scrum course and experience what it is like to be part of a Scrum team.