Comments on LeadingAgile: Scrum or Kanban... it's not Black or White

Anonymous, Totally agree... that is why I am in t...

2009-09-09T13:52:57.907-04:00

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

This is a neat post. I wonder however if everyone ...

2009-09-09T13:46:27.793-04:00

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....

Hi Mike, Great post. I agree, you could say Kanba...

2009-07-16T07:44:20.946-04:00

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.

You're making sense. Implicit / explicit in this c...

2009-07-15T10:17:40.676-04:00

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)...

I agree that Scrum teams are visible... I hope I d...

2009-07-15T09:20:37.938-04:00

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!

About visibility and black box/white box: Many agi...

2009-07-15T04:43:45.019-04:00

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...

Kevin... Thanks for the comment as always. I don'...

2009-07-14T14:31:00.908-04:00

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

7thpixel... thanks for the suggestion. I found Er...

2009-07-14T14:27:30.421-04:00

7thpixel... thanks for the suggestion. I found Eric's blog and was not subscribed. Will check it out.

Are you guys following Lean Startup trends as of l...

2009-07-14T11:16:53.908-04:00

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, Like the post and agree. I was trained in ...

2009-07-13T12:26:10.031-04:00

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?

I used the phrase 'plays a role in defining the wo...

2009-07-13T10:35:05.884-04:00

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.

Mike, Nice post. Excellent perspective. Thanks fo...

2009-07-13T10:30:17.359-04:00

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.