Kanban for software development is a newer kid on the block, at least in the US. Besides being just another word like Scrum that is not commonly understood in the English language, how does it stack up? Both Kanban and Scrum align with the well with the value system described in the Agile Manifesto. And they make an interesting pair.

As much as we love Scrum, even we would have to admit that it’s not perfect.  Nothing is. In fact, a large part of the literature describes workarounds for various deficiencies that Scrum presents to us in certain circumstances.

One of the more commonly noted deficiencies in Scrum is that it plans its work a whole Sprint at a time.  This “batch” planning process is often not agile enough to cope with the actual rate of change of requirements.  In fact, PlaceHolder Stories, discussions of mid-Sprint Re-planning, and discussions of renegotiating the scope of a Sprint are common deficiencies that teams must cope with.

The new kid, called Kanban, which solves some of these deficiencies and presents others, is becoming popular for software development projects.

Altogether, Kanban, Scrum, XP and many other agile methods rely on a task boards and index card like systems to simultaneously decompose and manage the work. What’s new about task boards and index card systems? Index card systems have been around at least since 1925, when the first one was formalized by Dr. Crawford and used later to build NASA rockets. Increasing task orientation is a well understood method for improving team performance and has been well documented since the 1950s. Our goal will be to highlight both Kanban and Scrum and then touch on why we need to reinvent them ourselves so often.

Learning Objectives

• An overview of Kanban
• An overview of Scrum
• Stacking them side by side
• The Power of Index Card Systems and Task Orientation
• Can one reduce or evolve from one to the other?
• Why do we repeat ourselves so often?

A great recent blog post by Vikas Hazrati caught my eye.

The story starts like this …

You have been feeling great. Recently, you met a lot of people in \the software community who knew little about Agile and you felt good telling them on how you are practicing Agile on your new project. You tell them about the wonders it has done to the business value delivered to the client and how your work life balance has improved since you started following Agile methodologies religiously. How you have felt so committed to the project that you are working on a that you have a great team of professionals.

So far so good.

The climax in the story comes on that dreaded Friday evening when the less committed people of the organization, which includes all of your team, are give the pink slip, and of course you are one of them!

You wonder, Why us, Why me, How the hell am I not committed? I thought that after years of developing software the wrong way this is the first time that you have done the things right, then why? The reason is that somehow your organization believes that you are not committed. Neither to the organization nor your work.

This is not a surprising outcome and all to common. Agile has gone mainstream but it will be attacked from many angles.

My Observations

The current systems are thought models, essentially living thought models, changing them is slow and painful.  Like any living thing when it is attacked or challenged it will fight back and lash out in fear, anger, igonorance and for pure simple survival. The people defending the old tired models of thinking are simple acting reasonable from their frame of reference.

Additionally, for big companies to even recognize that they have an incredibly valuable asset in a well formed team is a huge step acknowledge that performing teams are capital assets. With a great team I can deploy it towards a challenging business problem and generate a myriad of ways to thrive. Knowledge is a commodity, it is the ability to do something useful with that knowledge that will distinguish these companies long term. Eliminating your good teams (capital assets) from the business is fiscally irresponsible and it will come back to haunt the organization.

Expect real change to take years. You can do things to dramatically accelerate this change but, you have to be very thoughtful about your approach. It will not rely solely on a rationalized conversation (i.e. 1+1 = 2) people just don’t care when it comes to habits and perceptions driven from an emotional bases. And like it or not we are most often dealing with emotional issues since our rationalizations are anchored by an emotional part of our brain. Intentionally changing behavior is a long haul propositioin and the scrum framework is an means to inspect and adapt a change state into existence.

- Doug

http://3back.com