When applying Kanban principles beyond a single team you hit a number of organisational design challenges. I’ve found the biggest, most contentious challenge is how to organise the teams.
Photo courtesy of Dennis Hamilton
Here are some organising principles I’ve come across, i.e. how to structure multiple teams when you’re faced with a multiple product landscape using shared data stores, and multiple 3rd party integration points:
- By work type
- Support & Maintenance
- Projects
- By feature / functional area
- Registration & Login
- Search
- Results Page
- Transact
- By architectural layers
- Front-end
- Services layer
- Backend / data
- By technology skills
- HTML / Javascript
- Node.js
- Java
- Mongo DB
- Informix
- SAP
- By roles
- Product Owners
- Business Analysts
- Developers
- Testers
- Release Engineers
Unfortunately, I have no specific blueprint for you to download and follow to solve this problem. That’s because every organisation is different (no shit Sherlock). But, here’s a bunch a questions that I’m constantly asking when I’m 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?
