Inspect and Adapt

November 20th, 2011

The whole Scrum vs Kanban thing

I'm pretty bad at twitter. I am terrible at getting my thoughts across as intended in 144 characters and the more I try sometimes the worse it gets. So I am writing this as a response to the twitter debate that ensued after Jim Coplien's latest post. My first view upon reading this was that, considering Jim's normally controversy-inviting style, it was well-written and aligned with a number of things I have been thinking about recently. However, it left me incredibly conflicted primarily because I want to be someone who is being positive and constructive to everything that is trying to help make organisations more successful through agility. This is why Jean Tabakas "Community of Thinkers" post resonated with me. I do feel an urgent need to honestly and openly debate where we are though and how we, as a wider agile community, can use our learning to move forward. Set based design is a great approach and I believe experimenting with various methods and approaches is one of the ways we are doing this. However, in my view, we need to critique these approaches to work out how we can synthesise; I don't feel just blindly non-contesting everything is a healthy approach. At the moment I don't feel we are able to do this without starting an 'x versus y' debate and defensiveness all around.

So here are my views at the moment. Please read them with the following context:

1. I try to view things objectively but fail as my views are highly coloured by my attraction to Scrum
2. I fear saying anything these days because irreconcilable conflict seems to be an almost inevitable result

My views on kanban

Let me get these down first before I talk about my hopes. If I was to condense and sum up my views on kanban it would be:

I don't see the point.

I want to see the point and I can kind of rationalise its worth if I try but it doesn't feel right. It's probably just my experience but I see kanban implementations fall into 2 camps - either operations/maintenance environments (or other such reactive/fire-fighting scenarios) or basically Scrum without the difficult (and effective) bits. I would probably list my concerns as:

1. The lack of emphasis on getting things "done" in a time box
2. No protection of the time box that allows the team to focus
3. The lack of a focus on a cross-functional, self-organising team
4. The lack of an explicit servant-leader
5. In terms of continual improvement and organisational transformation, I don't see kanban teams making the necessary changes without the pressures of Scrum.
6. The lack of a big picture in product development caused by a lack of an institutionalised planning session for a time box.

In support of kanban

Now if I was to rebut my own arguments above, I would say there is nothing in kanban that stops me from doing any of those things as they are all optional add-ons to a basic 4-step state of mind. All kanban asks for is to:

1. Visualise the workflow
2. Manage the workflow through limiting work in progress
3. Establish a cadence (or multiple cadences) and
4. Improve the process.

There is no process or framework apart from the one that you have; if you have time boxes, you can continue with them. Also, if you want to have a ScrumMaster role, you can have one. I like the fact that kanban emphasises visibility of the whole system and getting work through that system. Many Scrum teams don't really get stuff truly "done" in their first couple of sprints anyway so I would tell myself to not get too worried about that part :-)

In the workplace, however, I have seen kanban actually move teams away from agility (as I see it) and more into a waterfall approach, setting up their boards with multiple "in-process" states rather than just "in progress" as I would expect to see on a Scrum team board. Also because of its more evolutionary approach I see organisations taking a much slower and passive approach to change. I admit I am impatient and want to push for aggressive, revolutionary change. I'm a believer that if we, as an organisation, are not going to succeed with an agile change I would rather know quickly. My concern is that, with kanban, either we won't get there because it's too softly softly or (worse in my opinion) we won't find out until it's too late. I understand the argument that just by taking our time we increase our chances of success but I'm not convinced by it.

If we take away the concern that some people are pushing kanban simply to make a name and a niche for themselves, a lot of people truly believe in this and it has worked (I can see how that is possible - I can see how waterfall could work in some circumstances as well) so I don't discount it. Personally I can't see any examples of product development where I would recommend kanban over Scrum because, in my (admittedly biased) world view, Scrum done properly is better than kanban done properly. In fact, Scrum done properly makes kanban unnecessary. Having said that, Karl Scotland sagely commented that both kanban and Scrum are failure modes, unless you have achieved perfection and mastered complexity. Obviously we are not there yet so what I really, truly want is for us as a wider agile community to have the courage to critique our options without fear of damaging a brand. This is what is sadly lacking in my view.

Category:

Agile / Scrum

Tags:

Agile / Community / Conflict / Kanban / Scrum / Timeboxing

Tweet ShareThis

3 comments | view comments | add comment