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.

Portfolio Kanban

Take a deep dive into Portfolio Kanban on our  instructor led online course. Take your Kanban game to the next level learning about how Kanban deals with Dependency Management, Risk Management, Portfolio Visualisation, Scheduling and sequencing work across multiple teams at scale, Resource Management and more.

About Ian Carroll

Ian consults, coaches, trains and speaks on all topics related to Lean, Kanban and Agile software development.

Connect with Ian at the following


Leave a Comment

Your email address will not be published. Required fields are marked *

Further information...

The content of this article is just the tip of the iceburg. To dive deeper into any of these case studies or concepts join our 2 day Portfolio Kanban live online course.

Application for a free Agile Coaching session

I would like to speak with an advisor