Scrum and Kanban stronger together

I don't quite get what the point is here, they have different uses for different teams. As coaches we shouldn't be allied to any particular process, and should be able to discuss/coach on multiple ways to ensure the team learn so they can choose for themselves (so you should be coaching them multiple practices). I know people get hung up on Scrum (in general, obviously here there is a bias), we need to change that.

I totally agree. I think teams lose out when they say "we're a (insert name here) team. We don't do (insert other name here)." That may stop them from looking at what else they could add to make improvements.

Great article Steve. I agree both communities should learn from each other by fostering collaboration. It will only make our profession better at the end.

Collaborate and learn from each other: Sure. A must. (EOF)
Create hybrids: Beware! IHMO there's a fundamental difference between Scrum and Kanban that makes blending them at least a high risk game (Footnote: initially I wrote "virtually impossible"). Scrums primary constraint and constitutive approach to manage work is (quite rigid) time-boxing. Kanbans primary constraint and constitutive approach to manage work is (quite rigid) use of explicit WiP-Limits - along with an absence of time-boxes or any other time-bound constraint (the Kanban cadences are not constraints).
A better understanding of 'signals' that help to decide which approach to use would be beneficial - especially if a whole Org is on a transition: Which parts of the Org should use/start with what method, on which level (Task, Feature, Product, Portfolio - vertical relation)? How to manage a switchover from one to the other in the value stream (horizontal relation) - if such a switchover makes sense at all? How do metrics look like in such a case?
Basically, I see plenty of options as well as questions in a organizational context. I hardly see any value in picking some ideas and/or practices from here and others from there to create a hybrid, which is then to be used by whatever organizational unit. Both methods have "conceptual integrity" just as they are - and that has to be preserved. There's still enough room to explore how they can complement each other - but each as a whole.

Thanks for the comment.

I'm also not a fan of hybrids.

The different parts of Scrum complement each other, so my recommendation to people is to try all them and not to pick-and-choose. The framework is quite light-weight (more on that in the next post), so this often isn't as burdensome as people think.

In my talks with Daniel, the key practices of Kanban are the same. Complementary and very light weight.

I like your term "conceptual integrity," I'd like to borrow that.

The idea that we're going to challenge is that the two "constraints" can't co-exist in some fashion.

Can Scrum benefit from more granular work in progress limits and can Kanban benefit from Scrum's time boxes (I just picked two of the practices).

Stay tuned.

Interesting point of view. Would like to read more on this topic.

Steve, I'm really sorry, but I cannot lend you that term ... Because I shamelessly stole it from "The Mythical Man-Month" (Brooks, 1975, various places, especially Chapter 4). :-)

Nevertheless, I believe this term best describes an often overlooked issue in a world full of mashups.

Good initiative Steve.

Often the teams who transition to Agile from a traditional SDLC model, they start with Scrum. Over couple releases that mature in Scrum practices and learn the game. During the prcoess they get better at requirements management and uniform story sizing, provided they have been learning all the while during their Scrum journey. At an inflection point, they can transition to Kanban - which is more of a flow based model. When the teams have established good release cadence, have sufficient backlog in fron of them, they can look forward to optimize cycle time and throughput and that's where the Kanban helps them. Again, when they transition to Kanban they do not necessarily define WIP limits at the begininning, they do so after some experimentation (I'm sure we all are familar with the penny game - to learn how the batch size affects the throughput). I was very fotunate enough to get Kanabn training from Mr. Daniel Vacanti :-)

Thanks for your comment.

When you say the "transition to Kanban", what did that look like?

What did that team add from Kanban?
What did that team take away from Scrum?

In relation to those two questions.

Why didn't that team start out with those Kanban practices they added later?
Why did that team stop getting value from the Scrum practices the abandoned?

Hi Steve,

Thanks for your response questions, and an opportunity to converse.
The teams who took to Kanban had matured in engineering practices and estimation practices in Scrum. Besides they were at a point where they were able to visualize the end to end flow and moving to Kanban helped.
Management had taken conscious decision that once we reach a certain maturity level (People, Process and Technology) we'd move to Kanban to realize the benefits that a flow based model offers.
Hope this answers your latter quesitons as well.

Thanks
Hiren

Sounds like your teams were able to see a lot of benefits from their move. Congratulations!

Did they stop using any of the Scrum practices?

For me, what matters is agile, and Scrum and Kanban are both part of the agile family. This means I'm not in a Scrum or Kanban Camp. I find that agile frameworks and practices often complement each other. XP practices make Scrum better, and Kanban can add lean concepts like optimizing flow time, removing waste and limiting WIP to Scrum.
In most teams I apply Scrum, sometimes adding WIP limits (for teams that struggle with too much WIP) or cycle time metrics. For teams that work on a lot of ad hoc stuff, I usually prefer Kanban. In one occasion, a team kept changing from Scrum to Kanban and back because there were times when ad hoc work dominated the backlog and other times when work could be planned in Sprints.

Thanks for the comment. I like hearing about teams that go back and forth based on their circumstances.

As they go back and forth, what do they change? What do they drop and what do they add?

No, they didn't . Though some of their practices like planning, review - they are truncated. But they still are organized as scrum teams and most of them are completely self-managed.

Typically, when moving from Scrum to Kanban, teams keep retrospectives, refinement and daily scrums. When moving from Kanban to Scrum, they sometimes add WIP limits and cycle time measurements.

In scaled agile environment I often have the majority of teams using Scrum and a few (eg component teams with external dependencies and ready teams) using Kanban. In those situations a Kanban team may also take part in the Sprint Review and show what they have accomplished.

That's great, thanks for your comments.

That's great insight, thanks for sharing.

Thank you, Steve. First for attempting to remove barriers and promote conversation through knowledge share and Openness. Second for actively participating in discussion through these comments; it is a valuable, rare, and valued thing! I look forward to seeing the resulting work.

Thanks Alan.

The second post in the series is due his Wednesday. Stay tuned!

Hey Steve,

I've been sitting with this tab open for a month, trying to decide what to say. I felt like it was time to close the tab by providing my thoughts. To be clear, I'm speaking about The Kanban Method when I use the word kanban and I believe that is what this article is talking about when it says Kanban and Scrum are stronger together.

Let me start out stating that I believe that teams and organizations need to be better at addressing customer demand. That pressure is what drives organizations and teams to adopt a 'process' that they think will help. We would call those processes Scrum and Kanban and that is probably the first point of failure. It is unfortunate that these processes are seen as incompatible and I applaud your decision to try and change that thinking. It isn't the practices that are incompatible, but the religions that sprout up around the organizations that evangelize the processes.

Part of me is disappointed with the misconceptions of what kanban is and how it can be applied as demonstrated by the comments. Going through some of the the comments, I see...

@disqus_hnVGJVEEah:disqus ... the requirements needed to transition to kanban.

Anyone can begin transitioning to kanban at any time because of the lack of prescription of "the one" kanban approach. Kanban has a natural and specific mindset that accommodates the current state and an evolutionary path to maturity, of which we are all at different points in our journey. Honestly, transitioning to kanban is as simple as changing the label we use describe our mindset and values.

@brunobaketari:disqus Create hybrids: Beware! --and-- along with an absence of time-boxes or any other time-bound constraint (the Kanban cadences are not constraints).

The problem with this statement is that any approach that is open to adding/removing practices as their value to the team changes will create a hybrid solution. Kanban by it's very nature creates hybrid solutions as teams take tactical practices from anywhere they choose to enhance they way they deliver value to their customers. The kanban value system openly embraces the concept of taking practices from anywhere that might improve your team/organizations ability to deliver value to customers. It has to accept all practices with respect.

Regarding cadences not being constraints, I would posit that a Replenishment meeting with a cadence of 2 weeks is exactly the same kind of time-bound constraint as a Sprint Planning meeting that happens every 2 weeks. Practically, they are equivalent constraints.

@disqus_ZVj0o42RTa:disqus I don't quite get what the point is here, they have different uses for different teams.

This seems to be a reinforcement of the myth that Kanban is for <type a=""> teams and <type b=""> teams shouldn't use it. Which is a myth.

Final Thoughts...

After reading your article, and the comments, it makes me wonder why people think that a team couldn't implement a fully "Scrum" set of practices and processes and name it Kanban. It is 100% possible to do that. I don't know that the opposite is true, in that a team would fully implement a kanban system and call it Scrum. Kanban allows for far more variation than the Scrum guide does.

I guess in the long run, we are trying to foster collaboration and enhance the strength of our professions by bringing these two communities together, which I think is very noble and the right thing to do. What I would like to see though is a properly educated discussion about where and how they (Kanban and Scrum) are different (or not) so that people can make decisions from how to describe what they are doing.

Thank you and Dan for stepping forward and taking on this challenge.

Hey Dave, thanks for your well thought out comment. I think you identify a lot of ideas that I share. Please stay tuned. I would love your feedback on the next two posts (A Scrum primer for Kanban teams and a Kanban primer for Scrum teams).

One idea I'd love to hear your thoughts on (maybe in the later posts) is if you can truly transition to a Kanban system as easily as you described. I'm stealing some of Daniel's thunder here, but limiting WIP can be revolutionary for some orgs and if you're not limiting WIP, you're not implementing a Kanban system.

First of all, I spoke of transitioning to The Kanban Method as being very easy. I didn't discuss the implementation of a virtual kanban system as easy, although in truth, most Scrum teams are already using a virtual kanban system.

Dan and I have had great conversations about WIP limits. Last time might have been in Germany over cocktails, but it was a great conversation.

There are many ways to limit WIP. I, and probably Dan too, would actually probably prefer to call it an optimal WIP policy, but if we are speaking only about limiting WIP, there are different kinds of policies along the maturity curve that we can use to limit WIP, all with different pros and cons that are discovered as we go. We choose which of those policies to start with based on organization emotional resistance and education/experience, all the while understanding that we are using this first policy as a starting point and we expect it to change, sometime frequently, as information about team workflow evolves.

Some possible policies include...

A Sprint backlog is a WIP limiting policy.
A policy of not starting anything new until your current work is done, is a WIP limit.
Stating everyone can work on 2 things at a time is a WIP limit policy.
A visual token indicating there is capacity to pull is the visualization of a WIP limit policy.
Keeping a flow efficiency number high is a WIP limiting policy.
Canonically, a number at the top of a column on a kanban board is a visualization of an explicit WIP limit policy.

The problem with WIP policies (and this certainly applies to many Scrum teams I've seen) is that there is usually no penalty for breaking the policy. It is an indicator of bad behaviour if the team violates a WIP limit, but it isn't a law and we acknowledge that sometimes we have to violate our WIP limits due to unforeseen events.

So while I speak about limiting WIP, I don't necessarily write a # on the kanban board until the team discovers the problem with the # not being on the board, then we decide what to do about it. If I recall correctly, Dan always puts a # on the board, but makes it high enough that there should be no emotional resistance to it, and then he starts talking about lowering it. I think both approaches have merit.

About 'no WIP limit == no kanban system', generally speaking, I'd state that you have an immature virtual kanban system if you don't have pull-based work scheduling mechanics in play to manage the flow of work. This is subtly different than saying if your not limiting WIP, you're not implementing kanban.

Steve, I did reply, but it seems to be currently stuck as in a disqus spam queue. I don't know what their SLE is on that queue. :(

I read your reply. Weird that I got an email notification, but it didn't get publicly posted. #GoodThingsComeToThoseThatWait.

I think joining Scrum and Kanban like http://kanbantool.com/kanba... is a great idea. In my company this hybrid's used by several IT teams and it works quite well, in the shorther as well as longer projects (while longer ones were problematic when using Scrum only). So I do support promoting the idea.

This is a great news Steve. I have read that news of scrum with DevOps and now Scrum and Kaban and I think this is the need of the hour to respect whatever make sense and value addition in the quality software delivery. From my experience I have seen that scrum teams moved to Kanban to reap the benefits of WIP limits and managing the flow to maximize the throughput. Similarly some of the kanban teams have moved to Scrum framework to reap the benefit of time boxing and scrum events. I have also seen the way teams calling themselves as Kanban and ScrumKan based on where there inclined. Definitely I think there is a lot to understand and implement way forward for producing better software to the customers. Looing forward to understand and contribute this concept further.

I too have seen teams move from one to the other. What I'm hoping is that when they move, they take all other stuff with them :). You don't need to give up anything from one to do the other.

Yes Steve, agreed and it make sense. As long as we complement the practices and enhance the value, all set to go.

Hello Steve! It seems that this topic has been abandoned. Or is the material available elsewhere?

We announced an formal initiative almost two years ago.

If you search for Kanban on our resources page, there's more there.

https://www.scrum.org/resou...

Hi Steve, could you please let us know when you expect to release the following topics?

ScrumBan or KanScrum? It’s Neither: How the Two Really Should Work Together
- The two set of practices are not mutually exclusive. We’ll examine how they’re complementary.

Hobson’s Choice: Scrum or Kanban?
- Must you choose one or the other? Should anyone ever have to make that type of decision?

Hi,

Sorry, these posts got away from me.

No immediate plans to publish these. I would encourage you to check out blog posts from other PSTs to see if someone else covered these topics.