Kanban is team structure agnostic.

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.