Scrum/Kanban Series: Scrum Is One of Many Agile Methods

April 16, 2012 — Posted by Al Shalloway

This blog starts out what I'm hoping will be an ongoing, weekly, series of short (written in less than 30 minutes) of blogs on Scrum and Kanban.

Blog update note: After writing this blog it caused some conversation on twitter where I realized this was a fairly important topic. So I have updated this blog and will also turn it into an article.

Scrum and Agile are often used interchangeably, as if they are the same thing. But they aren't. Scrum is a way of doing Agile, but only one of many. Other methods include XP, Kanban, Lean, FDD, Crystal and even just generic Agile. The problem with thinking that Agile is Scrum is that when someone has a success with non-Scrum Agile, Scrum gets the credit and someone else may try to apply Scrum in a place it doesn't work well. Alternatively, when Scrum does work, other may think Scrum is their only choice, when for their situation another method may be better. Finally, when someone tries Scrum and it didn't work, it often makes people think Agile won't work when another method might. These over-generalizations had me think that it'd be useful if I described how Scrum manifests Agile being and doing but how there are other options available. In a world where we know one-size does not fit all, we should know that we have different sizes available.

I will look at two areas of different approaches possible in Agile methods. The first area will comprise of issues or forces that are the essence of Agile. The second are just different approaches to learning and managing that are available to those attempting to be or do Agile. I will list both of these issues first and then go through each one in more detail. My next blog will discuss how to chose a process that will work better for your team.

The essence of Agile:

  • have an effective team structure
  • discover and build value quickly
  • learn fast

Other issues that can be approached differently:

  • Managing requirements
  • Ad hoc or explicit workflows
  • relationship with management
  • using principles or practices or both to get you started
  • How much should you start with
  • Where should one start

Have an effective Team Structure. The ideal is cross-functional teams. Scrum requires this to be most effective, Kanban can use them, but doesn't require them. We believe one should always go for cross-functional teams, but if you can't start with them, you might find a flow-based Kanban model is easier to start with and migrate to cross-functional teams. Of course you can do Scrum without true, cross-functional teams, but then Scrum provides little guidance to help you manage the challenge of this hybrid method. Theories of lean-flow and managing WIP could enhance Scrum here.

Discover and build value quickly. There are two methods of building value quickly: time-boxing or lean-flow. Scrum uses time-boxing. It's easy to get started with. But, it is still a batch system and many of the challenges of batch systems (inherent overhead and the tendency to turn into short push systems) often show up after a few iterations. It also is best with a cross-functional team structure, which as mentioned earlier, may be difficult to start with. Kanban is a lean-flow based pull system. Often easier, and just as often harder, to implement.

Learn Fast. Agile is about learning and adapting quickly. Scrum is geared around learning via three main mechanisms: 1) discovering impediments and removing them, 2) reflecting on a per Sprint basis to see that what the team is building is on target (the demo), 3) reflecting on a per Sprint basis to see how to improve the team's process (the retrospective). Lean based systems take an extended approach. They essentially have these same mechanisms (remove blockages, ensure we are on track with what we are building, improve our process) but extend them with an attitude of continuously improving process. Lean does this by focusing on the flow of work through the value stream. Kanban specifically calls out to attend ito visualizing the workflow, limit work in progress, manage flow, making process policies explicit and improve collaboratively using models and the scientific method.

The biggest difference here is perhaps more emotional and in how things are phrased. Scrum focuses on failing fast and removing impediments. Lean based approaches focus on learning fast and continuously striving to get better. We have seen a pattern of Scrum retrospectives going stale after teams learn how to do Scrum reasonably well. I believe the reason for this is that the teams are so much more effective than they used to be the pain the prompted them into Scrum has gone away, along with some of the motivation for improvement.

Of course, Scrum teams can incorporate this model of learning into Scrum - and we highly recommend that they do so. For more on the learning method underlying Lean and Kanban I highly recommend reading Toyota Kata: Managing People for Improvement, Adaptiveness and Superior Results, by Mike Rother for more.

Managing requirements. Agile grew up using stories to manage requirements. Many teams still start with them. Lean's focus on the value stream has shifted this to focusing on the chunk of business value to be delivered - often called a Minimum Marketable Feature (MMF). The Lean-Startup community has built themselves around this but talk about a Minimum Viable Product (MVP). Scrum appears to slowly be adopting these notions but most still write a lot of stories to begin with and use epics to refer to large stories.

Ad hoc or explicit workflows. Scrum itself does not really discuss this - it would be left to the team to decide how to manage their work in the Sprint. However, many in the Scrum community believe that explicit policies will lead to a mechanistic attitude of following procedures. The underlying notion is that software development is complex and therefore can't be defined. I believe this is a misinterpretation of complexity (see Types of Processes - by Don Reinertsen ) as well as a misinterpretation of what explicit policies are. Explicit policies simply mean the team has discussed their workflow. It is not ad-hoc but rather the result of conversations about how the work should be done. It is easy to change - just talk about it and change it. Explicit policies are not really about the policies themselves, but are a way to ensure that people know what each other is doing - it's a method of improving collaboration.

Agile doesn't say much about this so it is not surprising this is one of the areas where there is a huge variation in how the methods handle it

Relationship to management. Scrum's process is often called a "black-box." While we have visibility as to what goes into the Scrum team and what comes out (i.e., stories to be done and stories completed) how the team does it is not always visible to those outside the team. In fact, how the team does it is often not even clear to those on the team (see 'Ad hoc or explicit workflows.' Hence, management often has little understanding of how the team works. One often hear's that Scrum teams must protect themselves from management. This represents a variation within Scrum itself. Fortunately, the Chicken and Pig story has been abandoned by Scrum (I wrote a blog calling for this in 2007 - Is "Chickend and Pigs" Counter-Productve? ). Scrum itself doesn't really talk about the relationship with management - just that impediments should be removed.

Without any model to include management, it shouldn't be surprising that many Scrum teams simply isolate themselves from it. Their only real power here is the threat of aborting the Sprint. But this is rarely used as it is seen as a CLM (career limiting move). Most managers of Scrum do not have an appreciation for why doing one more thing, working just a little harder in a time of need, won't enable a little more work to be done. Visibility into a team's process, on the other hand, can enable management to see that doing one more thing will actually slow the team down. It was the demonstration of this, btw, that got me very excited about Kanban several years ago.

The end result is that, given no mechanism to effectively deal with management, some Scrum teams isolate themselves from management. "Although Scrum may help teams isolate themselves from dysfunction in the organization (which can lead to limited improvement), it is better for them to help the organization become more functional." Again, incorporating some of Lean/Kanban methods into Scrum can help Scrum teams considerably here and highlights how even within Scrum, there is a lot of variation possible.

Using principles or practices or both to get you started. There are two main schools of thought on how to get things started. One school believes you should start with practices - essentially telling the newbies - do this until you understand. This is a fairly prescriptive approach. It gets things started quickly, but often results in either stagnation when people don't know what they need to do, or challenges that can't be overcome because the practices prescribed are not the right ones for their particular situation (remember, one-size does not fit all). The other school believes that a combination of practices, along with the principles on which those practices are based, is essential. This usually requires a slower start, but results in less turmoil and more sustainability.

How much you should start with. Scrum is a framework. It is usually promoted with a minimalistic attitude - "start with this, add as you need to." The idea sounds fine - people are capable, they'll figure things out. The only problem is that we have seen most teams run into mostly the same problems. We therefore take a different attitude - "start with a bigger set of knowledge and methods to handle challenges that you are almost certainly going to face."

Where should one start. Scrum requires you to start by creating cross-functional teams while also changing roles (product owner, scrum master, team). Kanban suggests you start where you are, learn more about how you are working, discover how to improve it and then improve it. A different attitude. Scrum is a revolutionary change, while Kanban is an evolutionary change. See Kanban - Evolutionary or Revolutionary?

Many of these issues are discussed in The Scrum Clinic and The Kanban Clinic. Our Lean-Agile Project Management course (see current public offerings) provides all of these alternatives so you can see what works for you. Also, see our webinar Team Agility, Scrum, Kanban, XP - The Essence of All Three, from our Lean-Agile at Scale and the Team: The Value Stream Webinar Series.

While the intent of this blog was not to be a comparison between Scrum and Kanban, given that these are currently the two most popular Agile approaches and given that they differ greatly in their approach, doing so illustrates my point that Agile is not just Scrum. BTW: If you want a direct comparison between Kanban and Scrum, look to David Anderson's Thoughts on How Kanban Differs From Scrum and my own The Real Differences between Kanban and Scrum .

Next week I'll write a blog on building your own process by starting with the Agile mindset you believe makes the most sense and then picking from the options above to create a custom-fit approach that will work best within your context. See The Importance of Mindset for more on this.

Hope you enjoyed this. I'll admit this was a little longer than I was going for.

Alan Shalloway, CEO, Net Objectives

Subscribe to our blog Net Objectives Thoughts Blog

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With 45 years of experience, Al is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design. He helps companies transition to Lean and Agile methods enterprise-wide as well teaches courses in these areas.


Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Agile Design and Patterns, Personal Development, Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Guy Beaver
Business and Strategy Development, Executive Management, Management, Operations, DevOps, Planning/Estimation, Change Management, Lean Implementation, Transitioning to Agile, Lean-Agile, Lean, SAFe, Kanban, Scrum
Israel Gat
Business and Strategy Development, DevOps, Lean Implementation, Agile, Lean, Kanban, Scrum
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, SAFe, Kanban
Ken Pugh
Agile Design and Patterns, Software Design, Design Patterns, C++, C#, Java, Technical Writing, TDD, ATDD, Certifications, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Lean, SAFe, Kanban, Kanban Method, Scrum, Scrumban, XP
Marc Danziger
Business and Strategy Development, Change Management, Team Agility, Online Communities, Promotional Initiatives, Sales and Marketing Collateral
Max Guernsey
Analysis and Design Methods, Planning/Estimation, Database Agility, Design Patterns, TDD, TDD Databases, ATDD, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Agile Design and Patterns, Software Design, Design Patterns, Technical Writing, TDD, Coaching, Mentoring, Online Training, Professional Development, Agile
Steve Thomas
Business and Strategy Development, Change Management, Lean Implementation, Team Agility, Transitioning to Agile
Tom Grant
Business and Strategy Development, Executive Management, Management, DevOps, Analyst, Analysis and Design Methods, Planning/Estimation, Innovation Games, Lean Implementation, Agile, Lean-Agile, Lean, Kanban