5 common team structures when you scale Kanban

Home » Let’s scale our teams » 5 common team structures when you scale Kanban

When applying Kanban principles beyond a single team you hit a number of organisational design challenges.

The biggest, most contentious challenge is how to organise the teams.

Here are the five most commons patterns when organising your teams.

How do you structure multiple teams when you’re faced with a multiple product landscape using shared data stores, and multiple 3rd party integration points:

1. By work type
   • Support & Maintenance
   • Projects
2. By feature / functional area
   • Registration & Login
   • Search
   • Results Page
   • Transact
3. By architectural layers
   • Front-end
   • Services layer
   • Backend / data
4. By technology skills
   • HTML / Javascript
   • Node.js
   • Java
   • Mongo DB
   • Informix
   • SAP
5. By roles
   • Product Owners
   • Business Analysts
   • Developers
   • Testers
   • Release Engineers

Unfortunately, there’s no specific blueprint for you to download and follow to solve this problem.

That’s because every organisation is different.

But, here’s a bunch a questions that you can ask when wrestling with this challenge:

• Should the shape of your demand tell you how best to organise?
• How effective is your current way of organising your teams? (how do you measure effectiveness?)
• What have we learnt from the past by organising by roles and how did Agile principles make us think differently about this?
• In large scale highly integrated environments, how do you handle specialisms and dependencies (both internal teams and external 3rd parties)?
• If you have truly cross functional co-located teams how do you avoid (or reduce the impact of) code base contention and environment contention to improve release cadence?
• How do you remove prioritisation conflicts at the team level, departmental level, and org level, especially when you may have one of more shared service teams in the mix?
• In a highly complex multi-Kanban organisation, where are your system boundaries?  Where does one system end and another one start?
• Is a blend of component teams and feature teams more appropriate?
• Look out for these signals from Conway’s Law.