Kanban

Recently, I attended a webinar by Net Objectives titled "De-mystifying Kanban." It was a very well done presentation discussing the basic principles and practices of a Agile software development variant called Kanban.  They did a good job relating Kanban to the Agile software development practice of Scrum and also to the more general practices of Lean. There was a good discussion on how to use Lean's value stream analysis to organize the flow of the work.  This post is not intended to be a full review of Kanban or the presentation. This opening paragraph is to set the context for a couple of points I would like to discuss.

Most of Kanban fits in the tactical organizational space.  As in most Agile software practices Kanban emphasizes breaking software development into small distinct chunks usually expressed as a story and progressing them through various steps of development such as design, coding,  unit testing, integration, etc. depending on what makes sense for the particular particular organization.

The Agile software development systems tend to emphasize cross training so that most everyone in the team can execute in all steps of development. Emphasizing predominately a team of generalists. There are some specialists for certain activities, such as database or build specialists, but the emphasis is on generalizing the roles so that any team member can, for the most part, pickup any story at any point in its development or even work in pairs in a fast paced  test driven development pair programing model, switching back and forth between the tester and coder roles.

This emphasis on generalizing of roles in Agile software development seems to me to be different from the emphasis I see in Holacracy of differentiating  and separating roles to focused onto an individual. While this seems to be Holacracy"s emphasis, Holacracy works very well with teams focusing on role generalization in their operational activities.  There are a number of examples of Agile teams using Holacracy very successfully.

Back to the webinar, I heard many times the phrase "Kanban opens up the opportunity to have a conversation" on defining policies, roles, relationships, etc. It was always left at "having a conversation." No idea as how to structure the conversation.  This is where the Governance practices of Holacracy really shine. The purpose, inputs, outputs, and meeting practices are very well structured and defined in Holacracy. This leads to very clear results and a clear way forward from these "conversations".  Leaving the conversations undefined in Kanban, still leaves a lot of room for stalemates, politics, unclear definitions and directions, unproductive meetings.

I feel that Kanban has very strong operational characteristics for work that can be structured in such a way to effectively use it.  Kanban should be well understood by many organizations as it can be surprising how often it can be useful. But it is not sufficient in itself, Kanban needs the governance practices offered in Holacracy to develop clarity for the Kanban practices to be as effective as possible.