Scrum or Kanban… it’s not Black or White
It’s been fun the past few months to watch Kanban get some traction out in the community. It seems that my Google Reader is full of agile guys talking about Kanban. If you are David Anderson… this has to bring a little smile to your face. David and a few others have done a great job generating quite a lot of energy around this topic.
If both methods ‘increase visibility’ and ‘build trust’… there has to be something more. In my opinion… the key difference between Kanban and Scrum is that Kanban makes explicit what Scrum leaves implicit.
Let me explain…
Scrum takes the approach that the team is a black box. The business puts requirements in… and after some predetermined amount of time… they get working software out. Within that black box… the team gets to self-organize… they get to self-manage. The business gets to decide what… the team gets to decide how. The processes inside the team are abstracted from the business AND from management.
Kanban takes the approach that the team is a white box. The business puts requirements in… but rather than leave it up to the team to figure out how best to deliver the work… management plays a role in defining the work. There are explicit workflows… work in process limits… and visual controls that track the flow of value through the team. Kanban gives managers a role helping to deliver working software.
One of the earliest agile books I ever read was Mary Poppendieck’s ‘Lean Software Development: An Agile Toolkit”. Not long after that I read David Anderson’s “Agile Management for Software Engineering”. Lean thinking and theory of constraints were just built into the very fabric of how I thought about and managed agile teams. As Kanban started capturing mindshare over the past few months… I found myself wondering what was so new.
We teach Scrum teams not to wait to the end of the iteration to deliver features to the product owner. We want to see linear increase in story completion during the sprint. We talk to each other everyday to identifty and remove impediments. When one team member is struggling to get something delivered… we are encouraged to help them get finished before we start on something new.
Scrum teams should be constantly focused on getting to done. I would argue that there is a bunch of single piece flow thinking up underneath a well run Scrum team. I would suggest that there are some implied work in process limits at play. I would suggest that effective Scrum teams are continuously indentifying and elevating constraints. For some teams… in some environments… it probably makes a ton of sense to make all these implicit controls in Scrum explicit by using a Kanban. Is it necessary in every environment? That’s where I am not totally sold.
Comments (12)
Dennis Stevens
Mike,
Nice post. Excellent perspective. Thanks for the reference.
Karl Scotland on the scrumdevelopment group addressed this distinction when he said "It sounds to me like you are saying 'If your process works then we can call it Scrum, and if you process doesn't work then we can say
its not Scrum'."
One important distinction that I want to make is that the statement "management plays a role in defining the work" is not always correct. It is just that management has visibility into how the team has defined the work. This visibility also allows the organization to use a common view to extend the concept of single unit flow from idea to delivery.
Mike Cottmeyer
I used the phrase 'plays a role in defining the work' very intentionally. I don't think they should totally define the work… but whiteboxing the development team gives management the opportunity to influence the design… and help make corrections if the team needs help.
Kevin E. Schlabach
Mike,
Like the post and agree. I was trained in Agile through Scrum/XP eyes and just recently started to research and understand Lean. Because I come from that alternate training path, this difference was much clearer for me when I first heard about Kanban.
So, the question is… was I exposed to agile in a very constrained (and possibly wrong) fashion, or were you lucky (and unique) to have Lean ingrained in your exposure from the beginning? Which is the more common path (yours vs. mine) in the community at large? Does this answer tell us something we can help grow and improve in the movement at large?
7thpixel
Are you guys following Lean Startup trends as of late?
I really like where this is going by baking in Customer Feedback Loops and using empirical data with Agile + Split A/B tests.
Google Eric Ries Lean Startup and check out the presentations.
Mike Cottmeyer
7thpixel… thanks for the suggestion. I found Eric's blog and was not subscribed. Will check it out.
Mike Cottmeyer
Kevin… Thanks for the comment as always. I don't know if there is a right way or a wrong way to get introduced. Personally… I have a strong desire to understand why I am doing certain things and why they work. To some degree that led me to Lean early.
But… the point remains… regardless of people understanding the relationship between Lean and Agile… the relationship is there. My nagging issue is really the rebranding… the recalibrating of the language… by people that DO know the relationship.
I agree that there are differences. I respect and admire the folks out there beating the drum. The are doing GREAT work. That said… I just hope for great acknowledgement and understanding of WHY things stuff works… why it is the same… BEFORE we start learning something new.
I feel like we are confusing people.
Mike
Hannu Kokko
About visibility and black box/white box: Many agile teams show burndown charts, radiators, task cards in the walls etc at least where I come from. That is visible to EVERYbody including management. They talk to product owner and vice versa, they talk to other teams, scrum of scrums etc. So team is not black box… What Kanban seems to bring to this IN ADDITION is limit on number of things in progress at the same time, which can be a good thing.
So already there seems to be quite a lot of visibility into the team at least in some forms of agile. Scrum is just part of agile (a very good part…), many / most use additional stuff as well.
Kanban Agile discussion in various arenas seems to be confusing,I agree.
I agree (also) on your last comment…
Mike Cottmeyer
I agree that Scrum teams are visible… I hope I didn't imply otherwise.
Scrum says teams are visible… Kanban says teams are visible.
Scrum says teams build trust… Kanban says teams build trust.
As you mentioned… the main mechanism of Kanban seems to be the board with explicit process flows and work in process limits. The board and the limits help identify and clearly show constraints.
By eliminating the constraints… and resisting the urge to create inventory or waste… you improve flow through the team.
So… I was trying to say that Scrum teams have boards, and WIP limits, and elevate constraints… at least they should. It's just that Kanban deals with these explicitly while Scrum leaves it up to the team to decide how… Scrum defines this implicitly using language like get to done and swarm around features.
Am I making any sense ;-) Stayed up too late last night with my kids at the new Harry Potter movie!
Hannu Kokko
You're making sense. Implicit / explicit in this case makes sense.
Even the board is similar partly. to me the WIP limits are the key thing here and would fuse nicely.
To my understanding Kanban has also other stuff but I would say adopting WIPs would do good for most scrum teams.
On the other hand: if you do maintenance / support kind of work where things just continuously flow in you might use WIPs and no timeboxing and priorization just for picking the next thing. Even then you might need to relax strict WIP limit for things outside your control (bugs waiting for 3rd party correction, urgent stuff needed to be fixed immediately)…
Paul
Hi Mike,
Great post. I agree, you could say Kanban = Scrum + WIP limits (mostly). But I think there is something else going on here too. A number of the proponents behind Kanban have been heavily influenced by Lean thinking.
This article by Alan Shalloway sets out the different beliefs between Agile and Lean:
http://tinyurl.com/pysl4f
So much of the implicit stuff in Scrum is left "implicit" on purpose. Why? Well so that the team can improvise on how it gets the work done in an impromptu "self organised" way. In contrast Lean has the idea of "standard work" and a "defined process".
A defined process is a pre-requisite to process improvement in Lean, this is not the case in Agile.
Does this difference matter? Having come to Lean long before Agile, I don't think so as long as you understand "why" there is a difference in emphasis and the context where these differences arose.
Adaptive self organisation is great where there is a great deal of uncertainty and complexity. A defined process is great where things are better understood (like in manufacturing). What makes sense mostly depends on the nature of the work.
I think the book "Artful Making" (Robert Austin, Lee Devin) explains the distinction well labeling the two approaches "artful making" and "industrial making". In software I think we need to apply both, varying our emphasis depending on our context :)
Paul.
Anonymous
This is a neat post. I wonder however if everyone isn't missing the boat on this. Agile, at least in my experience, doesn't work in the textbook manner in which it is described and taught. Why? Because all work efforts inherently involve constraints in the form of management support, political support, leadership skill, contributor skill, cultural limitations etc., …. All of which conspire to make Agile teams feel good and "bonded" but while preventing them from being truly Agile. I would submit that Kanban potentially has similar constraints. Is it possible that Kanban works for some teams because they have established mechanisms which require that those functioning in a management role have objective skill with and insight into the things/people they are managing? And isn't that just good management/leadership….
Mike Cottmeyer
Anonymous,
Totally agree… that is why I am in the camp of people that think you need to arm yourself with as much knowledge as possible and use everything you can to create situationally specific strategies.
Mike