Category: Kanban

Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question

originally posted July 2017. Co-written by Jim Sutton and Al Shalloway

Abstract: This blog suggests that instead of looking at whether we should choose between Scrum and Kanban, we can see Scrum and Kanban as process patterns and benefit from the best of both.

Scrum and Kanban are often presented as “solutions” for developing software within an organization. Yet every real organization combines unique histories, personalities, and individual skills and beliefs. Even the best off-the-shelf “solutions” require variations to fit the context of the real organization to which they are being applied. If the adopted approach is not designed for these variations, the results will be less than hoped for.

Continue reading “Why If You’re Asking “Should I Use Scrum or Kanban?” You’re Asking the Wrong Question”

Why We Need a New Meaning / Name for Kanban

Originally written July 2013.

What Is Kanban?

When Kanban first came out for software development, it was not the Kanban Method. It was A Kanban System for Software Engineering. It was a system for managing flow in software development and maintenance teams. It was developed over a few years by several different people at Microsoft and Corbis. It was essentially what I have sometimes referred to as “Team Kanban” and is actually what most folks mean by Kanban. David Anderson’s book, Kanban: Successful Evolutionary Change for Your Technology Business, introduced the Kanban method, a way of effecting evolutionary improvement. In many ways the Kanban Method is little more than Lean Kaizen with a particular starting approach and with some additional, sometimes useful, practices (e.g., service level agreements). I tried sorting this out a couple of years ago with my article Demystifying Kanban and several webinars on that theme that Kanban is an overloaded term meaning all of the following:

  • A signal card and usually referred to as “small k Kanban”
  • A team management method using Kanban to manage flow and usually referred to as capital K Kanban. This is essentially the original Kanban system for software engineering which I will refer to from this point on as Kanban Software Development
  • A thought process
  • A transition, or education, method (the Kanban Method)

While I have been troubled about this for years, even suggesting years back that we needed to come up with different terms for different things, I thought it mostly was an annoyance, but not dangerous. Recent insights and events has had me shift my thinking here.

It is quite clear that a number of Kanban consultants, particularly those in Lean Kanban University, are attempting to usurp the term to mean that Kanban is the Kanban Method and that any use of Kanban other than the Kanban Method is a “shallow implementation of Kanban.” I am not trying to draw any aspersions to their motivations for this. I am certain they feel they are doing what is in everyone’s best interest, as the Scrum folks did when they blurred the terms Scrum and Agile. But I do not agree that equating Kanban (in the sense of the original Kanban) with the Kanban Method is beneficial for most in the industry.

Kanban and Lean

I have long felt that Kanban (both software development and method) is a subset of Lean Software Development. Our industry will forever be indebted to David Anderson, Jim Benson, Corey Ladas, Darren Davis, and others who brought Kanban into existence. Kanban software development opened ways of doing Agile software development to companies for which cross-functional teams were either impossible or prohibitive or who couldn’t otherwise make the jump to Scrum.

Putting Lean-Kanban practices into Scrum is not the same as being Lean

It’s nice to see the Scrum community finally accepting the importance of Lean and Kanban. But putting Lean/Kanban practices into Scrum does not make Scrum the same as Lean.

Perhaps the biggest different between the two is where our attention is when we have to remove an impediment. In Scrum our attention is “how do we remove the impediment by being faithful to Scrum’s practices.” In Lean, there is no attachment to any practice. Instead we ask “how do we remove the impediment by attending to Lean principles?”

In Scrum’s case, the assumption is that the team will figure out how to alleviate this impediment. But the best solution may not include having a stable team. For example, when multiple teams are working on a common codebase it may be best to dynamically form a feature team to work together (think of this as spontaneous mobbing).

This is a practice that I first used over a decade ago when test platforms were highly constrained. Immediately worked well and adoption was simple. The 7 teams that worked together to do this were following Scrum (with difficulty) before shifting to this model. Afterwards, they were no longer doing Scrum. We had to think in a Lean way to get to a Lean solution.

Walking my Talk – Integrating our On-the-Job Online Master Class With our Onsite Class

I’ve been espousing (a nice word for rant) about the need for scaled learning methods and how 2-day classes have low retention. I’ve decided to integrate our On-the-Job Online Advanced Scrum Master / Kanban Coaching workshop with our Team-Agility Coach (our integration of Scrum/Kanban workshop.

Our online workshop is normally $595 but when you take our Scrum/Kanban master course we’ll include that for $200 a person. This means that our 2 day workshop followed by our 3 month program is $10,400 for 12 people ($500 for each additional person).

The onsite aspect of this integrates Scrum and Kanban. The three month program has me work with participants helping them apply what they’ve learned, as well as advanced topics of Agile, with their teams.

Please message me if you’re interested.

A metaphor for team agility – GPS systems

Using a predetermined set of roles, events, artifacts and rules is like having a GPS that just gives you the directions without the map. If you get lost or you can’t make a turn or you miss it you are lost.

Being given a map with alternatives to get there provides not only options that work for you but provide a way of getting back on track when you get lost. In the complex world of software development it is even more likely you’ll need this ability.

Many people require a given set path. But have it include where you are and have it provide you with a reset option when you get lost. This is what Lean-based team Agile does. Scrum doesn’t even try because you are out of Scrum by this time. Scrum proponents just call this Scrumbut and go on to the next team. This doesn’t mean you can’t use Scrum, it just means that when you do Scrum you should do it within the context of Lean.

The Differences Between Scrum and Kanban

Looking at differences between Scrum and Kanban can help us see which will work better for us.

1) Scrum requires planning the sprint ahead. You can plan in Kanban but it’s not necessary and normally isn’t done.

2) Scrum requires cross-functional teams, a good thing to have. Kanban doesn’t but this often misses the opportunity for team structure improvement.

3) Scrum requires starting with its roles, practices, events & artifacts. Kanban allows you to start where you are & provides a transition model for improvement.

4) Scrum improves by removing impediments. Kanban improves by focusing on shortening cycle time.

Teams that don’t like to be told what to do may resist Scrum. Kanban requires more discipline from the team than Scrum.

Factors to consider when deciding which to use:

* culture – including resistance to being told what to do and attachment to roles

* nature of work being done (plannable?)

* ability to create cross-functional teams

Note that executives can better relate to Kanban’s focus on flow. Combined with its insistence on visibility, executives can better understand the importance of managing workload.

In few cases is one clearly superior to the other. Taking a blend of the two often makes sense. Doing this is not difficult. 

Why I Believe My Advanced SM/Kanban On-the-job Online workshop is my biggest contribution to Agile

Given I’ve written 5 books, delivered 100s of courses/talks/ webinars, influenced Scrum, Kanban & SAFe, that’s a big statement. I think it’s true because I hope its introduction of proven methods of training/coaching developed at Harvard will prompt the Agile industry to improve current methods which I believe are outdated and one of the biggest impediments to the widespread adoption of effective Agile.

Consider:
• Common training formats are ineffective and expensive. Intensive 2-4 day workshops have been shown to be the least effective method of conveying skills. These also incur the cost of lost days and possibly travel to take. Flipped classroom methods are both more effective and much less costly to deliver and incorporate follow up coaching
• Content. Being effective requires both Scrum and Kanban. Each are selective views of Lean, which is now recognized as a critical component of Agile beyond a team.
• Lack of a support system. There are patterns of challenge and solution which should be provided to students so they get assistance in solving problems on their own

Bottom line – this method can increase the effectiveness and content of a course while dramatically reducing real cost

You can learn more about this course here.  Take the overview box (mostly black) for a 28 minute overview of the class that explains both content and format.

The Magic of Scrum, The Magic of Kanban – Why You Need Both

A development team working in harmony is a beautiful thing. Every two weeks they get together to decide what they are going to do over the next sprint, and then they proceed to do it. Daily retros keep them on track. Guided by a product owner the team incrementally builds their product increment. A demonstration at the end of the sprint produces value and important feedback to make sure they are going in the right direction. They get better each week with retros. Magic.

Getting to this may be a challenge, however. Well formed teams may not exist and it may be unclear how to make them happen when some people are needed by many teams. Also, the culture of an organization may be such that reorganization is not an easy move.

Another type of magic is possible, however. That’s when people make agreements to get any started work completed as soon as possible and not to start work if it will slow down more important work. They make all of their work visible to each other so they can work as a team even if they aren’t dedicated to it. They continuously improve with small changes. Also magic.

Any company that has more than a few teams can find magic in both approaches, but often only approach is magic for a particular team

Why Agile Coaches Need to Know Both Scrum and Kanban

-AMAZONPOLLY-ONLYWORDS-START-

-AMAZONPOLLY-ONLYWORDS-END-

Scrum and Kanban are the two most popular Agile team-level methods available. While the difference between them is mostly thought to be sprint-based or flow-based, that is just one way in which they differ. Other significant differences include how to start, how to improve, and how people should be organized. They are based on different theories of how to manage software development work and whether you need to change your roles. And this creates other differences such include the amount of discipline to use them and the cultures in which they fit. Continue reading “Why Agile Coaches Need to Know Both Scrum and Kanban”

The Dark Cycle of Scrum and How To Avoid It

1) management tells teams to do Scrum

2) they try but can’t. A common challenge is they don’t know how to break down big epics into small stories (which is often not taught in initial scrum training)

Continue reading “The Dark Cycle of Scrum and How To Avoid It”