InfoQ published a good interview last week, Can You Scale Kanban?, with Klaus Leopold; one of the founding members of the Lean Kanban University.
One of my fellow ScrumMasters at Macmillan, Rosie Curran, and I were very lucky to see him in December at the Holtzbrinck Agile Day in Hamburg with the a very similar talk: Lean and Agile at Scale. He talks about using Kanban’s inherent principles and practices to look at scaling issues; to find ways to improve your processes across teams and departments; and to raise coordination levels between teams.
One quote really struck me:
“If all teams use agile, you don’t get an agile organisation… you get a lot of teams doing agile”
The whole talk was very good and so I dug around and found a video of the same talk from Lean Kanban Central Europe 2014:
Watch it if you have time, I think it’s well worth 40 minutes.
He runs through some of the misconceptions about scaling agility to create an agile organisation:
- Misconception 1: All teams have to use agile methods: Organisations are living social systems, the interactions between teams are important in creating agility, teams being agile units without coordination won’t increase the value the system produces as a whole.
- Misconception 2: You only need to follow the method: If you apply another’s solution to your problem don’t be surprised if it doesn’t work. You need a tailored solution for your system, built to solve your problems.
- Misconception 3: Agile doesn’t need all that management: We in fact need better “active managers” to manage agile systems. People who understand what exactly we want to improve.
Then he goes through some examples of what this might end up looking like in practice and how some “scaling patterns” might be applied as part of a solution, as long as you know what exactly you want to try and achieve by using them.
I think a lot of his points are applicable with any agile methodology: it’s important to apply [ Agile | Scrum | Kanban ] principles at each level in the organization rather than trying to apply a cookie cutter “solution” to solve everything. This is why each of the teams in my department does things a bit differently, even though we’re all following the Scrum framework.
One of the markers for me between a good talk and a great one is when I can immediately see things I want to apply. This talk hammered home that it’s coordination between dependant teams that we need to concentrate on right now in order to make our work scale, as opposed to frameworks, or practices within individual teams. We need to make sure the right pieces are ready at the right time.
We’re just starting to look at projects spread between 3 or 4 teams with additional dependencies on further teams. It’s not the biggest scaling problem in the world, but a few key practices will hopefully help us improve. A few things we’re trying to start are:
- Additional cross team stand ups
- Joint Sprint Reviews to make it easier for core stakeholders to see how everything fits together and is progressing
- Maybe also additional retrospectives between all the parties involved, every month or 6 weeks…
I’m not sure if we will need anything like WIP limits and buffers between teams, but with these practices in place we are more likely to find out if we do need them. I’m sure we’ll learn more together as we go, but inspiration like this is a good start.