While Scrum emerged from software development, the underlying patterns have been useful in managing complex work in any industry and context.
Peter and Richard are often asked: “Why do you guys like Scrum so much? It seems like a lot of meetings, and I see a lot of teams struggling with it. But you recommend it for a lot of situations, and it seems like you’ve thought a lot about it.”
In this episode, they explain why Scrum works when it works and why it’s still their favorite approach for product development, including outside of software development.
Related Episodes
Effective Sprint Planning
How To Have a More Effective Daily Scrum Tomorrow
Effective Sprint Reviews
Two Key Moves for Better Sprint Retrospectives
Learn More About Scrum
Certified Scrum Product Owner Workshop (virtual, instructor-led)
Certified ScrumMaster Workshop (virtual, instructor-led)
Agile & Scrum Crash Course (online, self-guided)
Episode Transcription
Richard Lawrence
A question we often get: “Why do you guys like Scrum so much? It seems like a lot of meetings, and I see a lot of teams struggling with it. But you recommend it for a lot of situations, and it seems like you’ve thought a lot about it.”
Well, it turns out that Scrum is a really nice, minimal framework for addressing human collaboration in the presence of complexity in a lot of different contexts. That’s why we recommend it so much. So, let’s look at why each part of Scrum works. As we do, notice that there’s some nuance to how we approach each part of Scrum to make it work well. This, I think, is why many teams go through the motions but don’t get all the benefits we’re talking about. In future episodes, we’ll go deeper into how you can fine-tune your Scrum events to make them work really well for you.
Peter Green
We like Scrum because when work has some complexity to it–things don’t always go the way we plan– it makes sense to break the work into small chunks. Splitting big efforts into smaller slices gives us at least three benefits: First, we can deliver value sooner, second, we learn faster, and third, we have natural break points where we can pivot more frequently. So what do we mean by small? Somewhere between a week and a month. Those are natural human cadences to divide the work.
In Scrum, those small cycles of work are called “Sprints,” and like many Scrum terms, it’s not the greatest label in hindsight, since those short cycles should be sustainable. Runners don’t sprint for a long time. But the core idea is solid.
When the work is complex, each Sprint is really like a dual-loop experiment. The first loop is an experiment on our hypothesis about what we should build. The second loop is an experiment on our hypothesis of the best way for this team to build things.
Now, if we are going to divide the work up into those short cycles, and we are collaborating with our team on those dual experiments, the four Scrum Events; Sprint Planning, Daily Scrum, Sprint Review, and Sprint Retrospective, become natural, logical choices, so much so that we’ve often seen teams that aren’t using Scrum reinvent those four meetings, maybe by some other name.
Richard
Sprint Planning is where a team figures out, “What are we going to focus on creating together in this next sprint?” And, by implication, “What are we not going to focus on?” That second part is a big deal for a lot of teams who find themselves overwhelmed and in reactive mode all the time.
An effective Sprint Planning meeting depends on a few things: Number one, a good product backlog; one of the artifacts in Scrum. The simplest Sprint Planning meeting is just pulling a slice off the top of the product backlog to focus on in the sprint. I worked on one team that was able to do this in 10 minutes for a 2 week sprint because we’d spent a few hours , a little bit every day, in every sprint, incrementally refining and getting familiar with the top of the backlog, so it was really clean and well-understood. A good backlog also ensures thatwhatever we’re choosing to focus on in the Sprint actually is the most important thing we could do. This is the number one way to maximize the value a team creates.
Number two, an effective Sprint Planning meeting depends on an accurate awareness of the team’s actual capacity for the upcoming sprint. Teams get the best results when they manage their workload well. A team with too little work gets bored and doesn’t deliver as much value as they could. A team with too much work gets burned out, demotivated, has no space to learn and grow, and ultimately tends not to finish what they start in each sprint, which has many negative consequences. Overcommitting, by the way, is much more common than under committing. So, it’s critical to have a sense of what can actually get done in a sprint. Note that, in the complex domain, the best way to get an accurate sense of capacity for a team, is to work overtime on small backlog items and get them done frequently, not to try to plan everything in more detail.
Number three, an effective Sprint Planning meeting depends on good facilitation and focus. This, of course, is true of any meeting; but Sprint Planning easily can go off the rails because of the temptation to deep-dive into every backlog item in a way that doesn’t really help a team answer that core question, “What are we going to focus on creating together in this next sprint?” We’ll share more on facilitating Sprint Planning in a later episode—be sure to subscribe so you get notified when that one comes out.
Now, on to the Daily Scrum: As a team works on the items they’ve pulled into the Sprint, if the work is complex, their understanding of the work will evolve while they are doing it, what we call “emergence.” Complex work can’t be fully planned during Sprint Planning. The Daily Scrum is a quick check-in every day where the team plans how they will collaborate to make an impact that day– how they’ll collaborate to make progress toward that shared commitment for the sprint. It allows the team to address whatever emerged or changed the previous day and figure out who will work together that day to move the work forward. Think of the Daily Scrum as the planning session for the day, not a status update meeting. By the way, that team I mentioned with the 10-minute Sprint Planning…we immediately did a Daily Scrum after Sprint Planning was done. Sprint Planning got us a Sprint Backlog, what we were going to focus on in the next Sprint. Then the first Daily Scrum got us a plan for how we were going to attack the first day of the Sprint.
Peter
Since the Sprint is a dual loop experiment, we finish the Sprint by closing out on those two loops. The Sprint Review closes the loop on the question “are we building the right thing?” The Sprint Review is typically the only Scrum Event where external stakeholders are invited, since we’re likely pretty biased about whether we’re building the right thing. Those stakeholders could be internal to the business, but there’s also a real benefit to inviting actual customers, the people for whom we’re doing the work, into the Sprint Review to get the most valuable impact. Good Sprint Reviews accomplish three goals related to what we delivered: prove it, celebrate it, and learn from it. “Prove it” builds trust with the business: we said we’d do a thing, we did it, now we’re showing you what we did. “Celebrate it” builds motivation on the team, allowing stakeholders and others to share what they appreciate about the team’s efforts and the impact they’re having on the business. “Learn from it” allows us to acknowledge uncertainty in what we’re building, treating the Sprint as an experiment that we can and should learn from. The Sprint Retrospective closes the second loop: are we using the best approach for our team? It is a concrete way to do Agile Principle 12, from the Agile Manifesto, which states “at regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.” Every once in a while, a Sprint Retrospective results in a really major change going forward, but most of the time, retrospectives result in small improvements. Those small improvements add up over time, though. If you think of making a 1% improvement every week or two, that adds up to massive improvement over months and years.
Richard
While Scrum may have its own kind of odd words for these events, as Peter said, they’re really just coordination points any successful team needs. They need to figure out what they’re going to work on together and typically do that over multiple time horizons: some kind of big picture, and daily. They need to review what they’ve done and reason about it together. And they need some mechanism to improve how they work.
So far, we’ve talked about the four Scrum Events as something that’s happening with a Scrum team collectively, and that’s true. But there are some responsibilities in these events and in the work of a team overall that are unique and demanding and can benefit from having people who focus on them. Scrum has roles for this.
Peter
For example, creating and maintaining a product backlog is a lot of work, from engaging with customers and doing customer research to creating business cases and modeling value to slicing and refining backlog items to fit nicely in a Sprint. Scrum, therefore, calls this responsibility out as one that should probably have its own role, ideally with someone dedicated to it full-time. This role is called the Product Owner.
Similarly, facilitating the Scrum Events and helping the team become more and more effective is a distinct responsibility with different demands than working on the product backlog or working directly on the product itself. Scrum recommends giving that a full-time person as well, and calls that role the ScrumMaster.
Richard
Everyone else on a Scrum team is, in Scrum terms, a developer. Which, we admit, is kind of confusing because “developer” these days, usually implies “programmer.” But, in Scrum, it’s just “product developer,” anyone, regardless of specialty, who works on creating the product. Sometimes, we refer to that subset of the whole Scrum team as “the development team.” Because there are some things they do collectively like pulling work into a sprint from the product backlog. Scrum has some advice about how to compose a development team. It should be cross-functional, meaning it has all the skills required to complete the increments of the product represented on the product backlog. And it should be dedicated, meaning team members work only on this team instead of being multi-tasked across multiple teams. This totally makes sense in the complex domain. When we don’t know what’s going to emerge during development, it’s important to have a whole team collaborating closely together to respond to that emergence. A team can’t do that when they’re missing key skills on the team or when people are only part-time and unpredictably available.
Peter
So, we like Scrum because it taps into some core human principles about work. When the work is complex, we benefit from doing it in short cycles. There are natural conversations to have about planning and reviewing the work of those short cycles. We are more focused and effective when we make clear decisions about how to focus our time during those cycles. And the team benefits from clear roles and responsibilities. Scrum provides a time tested, natural set of practices that do all of those things pretty well. While scrum emerged from software development, the underlying patterns have been useful in managing complex work in every industry and context.
Last updated