Kanban is NakedThe Kanban method does not specify the use of teams because Kanban does not provide, nor require, any specific organizational structure (people & processes). Still, Kanban requires some structure to start with. As such, you cannot just “run” Kanban, you need something, some existing structure or organization to support it. You could say that Kanban comes naked and gets dressed in whatever structure you are currently using.
This nakedness is actually Kanban's greatest strength: it enables Kanban to transform what you currently have (team, organization, value-stream) into something better, fitter to your context and challenges. The recipe really is: you start with what you have right now, you apply Kanban and you evolve into what you must to succeed. A more prescriptive model (say, Scrum) would not allow for smooth evolution as it would require a good deal of revolution (with the problems of "non-stickyness" that come with it).
Some groups tell me "Kanban is not a process? But we need a process! We've worked ad-hoc for ages, we have nothing!". Well, this is actually never really the case! There is always some (informal) structures and some implicit and natural processes; else they would not have delivered anything, ever. The first step to apply Kanban in these cases is to unearth these structures and make them visible.
Teams are the way we do ThingsNow, what is the most common organizational structure used in today’s software development companies? Based on my experience as a consultant in Sweden (so perhaps this only really applies to Scandinavia), I see: project teams, application management teams, product teams, technology teams, system teams, program management teams, steering groups, etc. So, for me it seems that the concept of team is rather strong. Actually, teams seems to be the way we do things, anything. Of course the definition of team differs widely, even within the same company. Sometime we call them “groups” or “units” but it really is the same thing: individuals working and learning together with the goal to create some value
"Kanban Teams"This means that if you want to evolve (starting from where you are) your current organization into something fitter using Kanban as a change management tool, you will most probably end-up helping teams. Teams that use Kanban. As an extension, you get “Kanban teams”.
A Proto-Form of Kanban?What would a highly valuable Kanban implementation look like? The highest Return on Investment should come from having a Kanban system that spans whole value-streams, end-to-end, from “concept to cash”. This gives you opportunities to tweak the whole stream to predictably deliver value faster with higher quality in a sustainable way. Products get released early and deliver more value. You win.
With that in mind, being stuck at the team-level may not be optimal for the whole as most of the organizations seldom organize their people according to their value-streams. Enterprises still tend to organize themselves to optimize resources utilization over flow. So, except for few extremely successful organizations (like Spotify), teams are often responsible for parts of each-others value-streams. Note that Kanban makes this issue very visible as you will notice that teams tend to block each-others.
Consequently, Kanban Teams may be Proto-Kanban implementations, that is to say implementations that are in transition towards an ideal, end-to-end Kanban systems or "True Kanban". Not because Kanban Teams are inherently bad, but because teams are usually not built right.
Evolution goes via Kanban TeamsSo, is a Kanban Team a Proto-Kanban? It all depends on how you have structured your organization (optimize resource utilization or optimize work flow). But I believe that if your organization uses teams, Kanban Teams are a necessary step to make your organization evolve.
If that is true, then we need a way to make the Proto-Kanban teams evolve towards true Kanban. How do you do that? That will be the subject of another blog post...
Now, if you would, I have some teams to attend to.