Kanban is team structure agnostic.
Kanban is team-structure neutral, which means that it can work with any typical team structure. However the creation of a cross-functional team is one of the first process improvements most organizations make to remove bottlenecks. Cross-functional teams reduce the amount of partially done work that has to wait for a specialist or has to be transferred to another team to be completed. This is important because delayed work results in delayed feedback, delayed feedback increases the potential for rework.
One of major benefits of implementing a Kanban approach is to reduce cycle time between beginning work on a feature and getting feedback. Faster cycle times reduce the possibility of changed minds, feature drift or scope creep and external events intervening to delay delivery. In the Daily Process Thoughts, Kanban: Getting Started, I advised you to begin your implementation of Kanban by mapping your process and then using that process unchanged with a Kanban approach. Executing the process provides performance data and visually alerts the team to real bottlenecks rather than anticipated bottlenecks. When mapping the process, it would be easy to decide to immediately implement a cross-functional team, and then guess at the composition of skills and capabilities that would be required. The problem is that it is very easy to be wrong. Just check out the Freakonomics Podcast’s The Folly of Prediction episode, which strongly suggests that humans are poor predictors of the future. Wait until you have data. To create a cross-functional team use actual performance data your team generates. As the team attacks the bottlenecks it will be much easier to determine the skills or capabilities the team needs to improve the flow the work towards completion.
In a perfect world we would be able to compose a self-contained cross-functional team that would be able to perfectly meet the needs of current projects. We could then easily imagine how a team could evolve and grow to meet the needs of future projects. We can imagine these scenarios because they can and do happen more and more often. However years of specialization and architecture choices sometimes make creating self-contained cross-functional teams difficult. For example, it would be cost prohibitive for an organization to have a highly specialized security architect on each team. They wouldn’t have a lot to do on every project and are expensive. Each team will need to make compromises, however the core team should be composed to make it as cross functional as possible, rather than perfectly cross functional.
Kanban may well be team structure neutral, however in the long run, working effectively and efficiently tends to be biased towards self-contained cross-functional teams. Do not try to predict what the composition of the skills and capabilities of the team should be. Execute your Kanban approach and let data and your eyes provide the feedback needed to develop the best team structure possible.
September 15, 2013 at 4:00 am
Sorry, one other thing I meant to ask. Several people use Kanban interchangeably with Kanban Method, even though most non-LKU Kanban experts consider them as different. This is analogous to the Agile not the same as Scrum even though many CSTs use them interchangeably. Did you mean Kanban in general or the Kanban method?
September 15, 2013 at 3:47 pm
In this set of comments I was thinking in general rather than the Kanban Method specifically. I also see a word Kanban being used to mean more than one thing.
September 15, 2013 at 4:09 am
The odd wording of my prior comment is due to the fact that wordpress through away my first comment when i had to reset my password. I’ll recreate it.
I agree that Kanban can be used with or without teams, That is one of it’s great assets. I guess you could call that team neutral – but I don’t think that’s a good idea. The fact is, virtually all places benefit from having teams. This is not prediction, it’s patterns. And, of course, you never force fit anything. One should always look at the value stream, see where you are and then suggest changes. The irony is that the Kanban Method (not sure that’s what you mean when you are saying Kanban – hence my first question) suggests the first thing you should always do is manage work in process (WIP). Most non-LKU Kanbaners I know suggest there are often other things to do after seeing where you are and setting up a kanban system.
I have seen many almost cross-functional teams doing Kanban not try to create teams because they hear it is orthogonal and focusing on WIP induces framework myopia.
The interested reader should check out these blogs of mine
( on http://www.netobjectives.com/blogs/all ):
Why You Should Be Concerned When a Consultant Says “That’s Orthogonal” (to be clear I don’t hear you saying this)
A Tale of Two Kanbans… or Three
Cross-Functional Teams Eliminate Waste and Manifest Lean
Creating Teams When It Does Not Seem Possible
Attending to Teams is Important
Extending the Kanban Method
Framework Myopia
September 15, 2013 at 3:57 pm
Thanks for the comment Alan. I agree that while the framework is team structure neutral the world is not. I believe that before making decisions on team structure that we first should seek to understand (pardon my paraphrasing Stephen Covey) the specific environment with observation and data and then act.
Thanks for pointing our your blog, it one of those that I highly recommend.
September 28, 2013 at 11:57 pm
[…] Kanban and Team Structure I suggested that Kanban is team structure neutral. The same argument can be made for kanban-y […]
February 10, 2014 at 6:59 pm
[…] has an expectation of bounded, well-formed teams. Scrum teams are cross-functional with members playing many roles depending on the need. Teams are also expected to be […]