Category: Scrum Vs 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”

Framework Tunnel Vision

Originally posts August 2013.

Disclaimer: I could have named this framework/method/process tunnel vision, but that seems a bit redundant. So don’t infer I mean to pick on any Agile approach that is a framework over one that is called a method or a process. I am just using the word framework generically. For the purposes of shortness, whenever I use “framework” in this blog, pretend I’ve said “framework/method/process/…”.

Continue reading “Framework Tunnel Vision”

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.

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. 

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 biggest difference between Scrum, XP and Kanban

People often conflate Scrum with Agile. But Scrum is not the same as Agile. Agile is considered by many to be a set of values, principles and way of being. Scrum is a framework consisting of roles, rules, artifacts and events. It is designed for teams to add those practices needed in order to become Agile.

XP is quite different. Continue reading “The biggest difference between Scrum, XP and Kanban”