Kanban vs Scrum, the ultimate fight? Don't think so, here's why:...

Wow, what a week! A BIG post on Kanban by Scrum evangelist @jcoplien litterally put the blogosphere (and twittersphere on fire!).

It is good to have these family fights in the Agile family once in a while. As a life-philosopher once said: "These things gotta happen every five years or so, ten years. Helps to get rid of the bad blood".

But what are the differences between Kanban and Scrum, really? What are they?

Here's my take on the differences:

Kanban innovation

Kanban is, from it's origin a more systematic approach to measuring, visualizing and following up work in a "system" (one team, many teams, a company you name it). Thanks to the work by the Poppendiecks, David Andersson and Don Reinertsen (and others I'm sure) a pretty interesting and innovative economic framework as been put into the software process development lingo. Cost of Delay, Queues, optimize the whole, etc.
This economic framework is, in my view, the major innovation that Kanban proponents bring to the table. This was to be expected as many of the early adopters of Kanban were using Scrum before and felt the need to quantify and analyze some aspects of software development that Scrum did not tackle.

Scrum innovation

Scrum brought to the fore-front of process discussions issues that had never made it to our attention before: Self-organization, people/team dynamics, problem solving within a short cycle with feedback loops in place (Sprint), etc.
The major innovation of Scrum in my view was the introduction of the Socio-technical system of software development as Liker describes it in the Toyota way. Other similar software development processes took some of the ideas that Scrum also took, but shied away from the self-organization at the team level and blocker-removal focus of roles such as the scrum master. Those methods did not last long because the teams felt like puppets instead of adults with the possibility (and responsibility) to produce the best product they could.

Wrap-up

Both Kanban and Scrum brought significant innovations to the software development world. Those are just two types of innovations. There is more coming from the community and instead of focusing only on these two methods (which all of you should experiment with!) we should also look at what else is missing in the software development ecosystem.
My next interest area is "Complex Systems" (Complexity + Systems Thinking) and Management as a profession. I'll be exploring those subjects more and more in the future as a way to complement my use of Kanban *AND* Scrum. I suggest you do the same and find what else is missing in your environment and look for what else is around that could help you complement what you are already using. Here's a suggestion: start with @jurgenappelo's book on Management!

Happy reading, happy learning!

XP2012: The Extreme Challenge

"Agile has crossed the chasm" we hear often. But has it really? In the last few years Agile has gone from being "the cousin in the corner that shouts and screams but no one wants to talk to" to being "the famous cousin who everyones wants to talk to". It was not an easy transition, and to be sure there are still many in the Software industry that call that cousin the "bastard child" of software. Need an example? just take a look at the title of this book.

Agile has turned a corner, there's no doubt about that. However, we have also grown as community, and what was the focus of the last 5 years is also being challenged from within. J.B. Rainsberger described the evolution in a very critical as well as prescient way: the future of Agile is XP (the irony is not lost on many, I'm sure).

JB Rainsberger's keynote "The Extreme Decade: Progress, Pain, Paradox" from Agile Eastern Europe on Vimeo.

XP2012 happens in this context and in itself has a challenge of re-inventing the tired old format of Gurus coming to install the faith on the rest of us. Erik Lundh started a project for XP2012 that deserves some attention as well as exposure. XP2012 will be the first conference in a few years to live up to its name *because* of this challenge!

The XP2012 challenge!

The challenge is to do full cycle from Agilehttp://www.blogger.com/img/blank.gif Planning Game or similar to DoneDone deployed into production at least once in a week.

A set of teams of developers will be invited to attend the conference and effectively develop and release software at the conference in one week or less. They will start and end an iteration during the conference. Random people from the audience will use the software in the technical demos (not the team!) to check that everything is working.

So, if you work in a really good Agile team why not take the challenge? Come to XP2012 to *prove* that you can do Agile Software Development just as it should be done!

Photo credit: sanfora @ flickr

Kanban in a networked process -- Visualise the network!

It seems that the idea of a work-network instead of work-flow is catching on and I'd like to throw a bit more fuel in that fire!

Knowledge work is not linear! This we have learned from the experiences with failed Waterfall projects. There are things we do over and over again, and there are things we do only once in a project. None of those can easily be predicted. Scrum and Kanban are examples of our quest to distill what we do to the bare essential. Only then can we understand and manage our work.

Scrum does this by strictly limiting the work in progress through the concept of time boxes. The idea is: do something that fits a (reasonably) short timebox, and nothing else. Get that done and released before you go on to the next thing.

Kanban does this by strictly obeying Work In Progress (WIP) limits and establishing a Pull system (instead of push as much content as you can into an iteration). Both have pros and cons which I will not discuss here. http://www.blogger.com/img/blank.gif

But most interestingly, both tackle the flow of our work in a linear fashion. Both Scrum and Kanban assume that some work can "flow" orderly to completion. However that is not the case! In knowledge work we have many loops and re-loops in the process that are hard to visualize and follow. Without visualizing those loops we cannot effectively manage our work!

Jurgen Appelo and Allan Shalloway had (what looks like was) an interesting discussion on the non-linearity of work and consequently on the non-linearity of Kanban boards. Check out Jurgen's and Allan's posts on the subject.

Since I've been experimenting with Personal Kanban for 3 months now I'd like to share some of my own experiences.

The picture below depicts my process boards as they evolved (click for larger images). The initial one was simple and linear, and it did not disclose enough information for me.


The second one was much better in highlighting some of the bottlenecks in my process (waiting for my action, waiting for others action, waiting for meeting), but was still too linear to reflect the work in a way that was useful to visualize.


The final Kanban board is actually what I use now and is a slight modification of the second one. As you can see it depicts the networked nature of my work and therefore also helps me set my WIP limits appropriately (for example why not have many things waiting for meetings?).


A conclusion of mine from the above boards is that it is not possible to set WIP limits without understanding the work (for example what "wait" states do you have in your process). On the other hand, trying to follow the WIP limits you have set will help you visualize those "wait" states as a consequence of the search for sustainable WIP limits

How about you? What are your experiences in using Kanban boards or other visualization techniques to uncover the networked nature of our work? Leave a comment below with a link to your post!

Photo credit: sjcockell @ flickr