I was originally going to call this post, “why I chose Kanban”, then I realized I didn't choose Kanban.
What I chose was Kanban and most of the other “Agile” stuff that I consider good practices and find valuable. There really isn't a good name for this and when people say they are doing Kanban, it really doesn't say much. Hence, I am coining a new phrase (Kanbanand), which I hope will be much more specific than saying I am doing “Agile or Kanban development”, and not quite as specific as saying “I am doing Scrum”.
Agile is pretty vague
There is a major problem in the Agile community today. The problem is “Agile” is too broad and involves a large number of assumptions about what Agile involves. There is not much that defines Agile even though many types of best practices are considered to be Agile.
Which of these best practices are clearly defined in the Agile manifesto or Agile principles?
- Test driven development
- Paired programming
- Daily stand up meetings
- Progress board with swimlanes
- Having a product owner
- Stories or backlog items
- Continuous integration
- Automated testing
The correct answer is none of them. Don't get me wrong here. I am not attacking Agile. I am just saying that when you are saying “I am doing Agile development”, what you're saying means different things to different people, and most people don't even realize what the Agile Manifesto actually says, or what the Principles Behind the Agile Manifesto says. Instead they have this general idea of what Agile is and it may include one, all, or none of the items I listed above. (Actually, I would venture to wager that most people think Scrum and Agile are synonymous.)
Scrum, XP and Kanban
Scrum and XP don't really suffer from the problem that Agile in general does. They are not really vague at all. Actually, to be more accurate, they are not really vague about process at all. Scrum is a little vague about development practices. Either way, both of these processes suffer from a different problem than Agile itself. No one is actually doing them. Well, hardly anyone is.
Lots of people say they are doing Scrum. But what they are actually doing is what is known as Scrumbut. “We are doing Scrum, but… “. And no one that I know of is actually brave enough to claim they are doing XP.
The problem is these processes are just a little too restrictive, a little too prescriptive.
Kanban is out there on the other end of the spectrum. It is sitting closer to Agile. It is the least descriptive. Heck, Kanban doesn't even have to be Agile at all! I am sure most people that are doing Kanban are doing it in an “Agile” way, but there really is nothing about Kanban that says anything more than you have a Kanban board and you limit your Work In Progress (WIP). If you have a whiteboard and you can put a number on that whiteboard, you are doing Kanban!
Enter Kanbanand
Kanbanand is good in the same way that Scrumbut is bad.
The goal of Kanbanand is to be a fully Agile process, adhearing to the Agile Manifesto and the Principles Behind the Agile Manifesto, as well as process that is not as specific as Scrum or XP, but specific enough to be distinct and recognizable. The basic idea of Kanbanand is to take the simple non-prescriptive, open framework of Kanban and formally add some of the best practices that are considered “Agile” as requirements and others as guidelines.
In the spirit of the 80/20 rule. I want someone saying they are doing Kanbanand to be able to convey with just those words, 80% of what their development process looks like.
In my next post I am going to attempt to define what I will call Kanbanand. I will proceed with the goal of making Kanbanand be much of exactly what most Kanban teams are already doing, just formalized in a way that is specific enough that someone doesn't have to know the undocumented features of Agile development to understand it.
If there is enough support around this idea of creating a more formalized version of Kanban that more specifically states the process, and is still Agile, I intend to create a website and community dedicated to this idea. Contact me if you are interested in participating. I think we are at the point where the only thing holding Kanban back is that there isn't a formal enough definition of exactly what it is. I believe once we have a real Kanban process that can be implemented and clearly identified many of the teams and organizations that intially thrived under Scrum, but are now held back by the strict time-boxing, will jump to our side of the fence and embrace the idea of limiting WIP.
