How do you decide which agile approaches to take out of the agile toolbox when it comes to creating an agile organization?
I look at every team and every level for itself. This is the only way to find out which agile approach makes sense for which team and at which level.
And you can’t just take a Scaled Agile framework like that?
In practice, you have to take a close look at what a team needs. An agile organization uses different frameworks in different places because the work of the teams is different. Larger frameworks have long since ceased to be frameworks in the sense of “do it exactly like this”. They are a set of frameworks that have to be assembled like puzzle pieces specifically for an organization. This is called tailoring.
Isn’t agility then arbitrary like “agile but”?
No, the puzzle pieces – I would rather speak of patterns – should be done as they are described. Such a puzzle piece is e.g. Scrum or Kanban. I shouldn’t be fiddling around here. But the selection of the right pieces of the puzzle, and the combination of these into an agile organization, can only be solved on a case-by-case basis.
And where do you start?
I start with the teams because they are the basic building blocks of every organization. You don’t get an agile organization without agile teams.
And what kind of questions do you ask at the team level?
At the team level, I basically see two patterns: either I have a team that handles larger tasks that also take some time. An example would be a team developing a product. The other possibility is a team that provides a service and has small requests rather than longer-term, larger requirements. In the former case Scrum is probably a good approach, in the latter I would rather choose Kanban.
And what if a team does both, i.e. develops something and also handles service requests?
Then I can combine both. That’s Scrumban. But this also means that you have all the rules of Scrum and all the rules of Kanban. Not a little bit of either.
And if I use Scrum, what do I do if the team has multiple products?
Scrum too. Then there are requirements for several products in the product backlog.
Do all teams have to use the same framework when working together?
No, the agile frameworks are all compatible with each other. One team can do Scrum, the other Kanban, and still they can work on the same product.
Let’s move on to coordination between teams. How do you start when you’re looking for a “configuration”?
My first question goes to the artifact “product”. I ask whether the team is creating a joint product or not. If the answer is “yes”, then we can write down: there is a common goal, a common definition of done, a common product backlog, a common product backlog refinement, and a product owner. The questions for a service are similar, but often the terms are somewhat different. The product is the service, the quality definition is the Service Level Agreement, and the product owner is often called Service Request Manager. If necessary, we also have a Service Development Backlog if we need to further develop the service.
And if the answer is no, if there is no common product?
Then the teams can work independently of each other. This is actually the best case. In order to coordinate which topics the teams work on and how much capacity or budget they have, you can use a Portfolio Kanban. But you shouldn’t do any more than that. Independent teams are the fastest.
And if there is a common product, what happens next?
The next question then goes to the artifact “Increment”. I ask whether the teams can only deploy together, or whether each team can deploy independently. If they can only deploy together, then I note: common increment, common sprint review and common planning. If the teams can deliver independently, then I don’t need these common events. Of course it would be easier if every team can deploy and deliver independently. This can be achieved through architectural work and shared code ownership.
And if there is no common deployment?
That’s actually great because the teams are then more independent. But even without a joint deployment, the teams may still have to work together during the sprint. Then I ask if people “just walk up to each other and talk” or if they want to use a “Scrum of Scrums“. Depending on what the teams decide, I’ll write one of both down. If necessary, common planning can also help, or an occasional common retrospective. If the teams want this, I’ll put it on my configuration list. By the way, this synchronization is typical for service teams, which often have a “morning meeting” (aka Daily Scrum) or a common “queue replenishment” (aka planning).
And what about the cadence?
I don’t ask that. If there are common events, then I always write down “common rhythm“, aka cadence. Otherwise I get in the devil’s kitchen organizing the events.
How much common rhythm must there be?
This depends on the need for coordination and the frequency with which requirements change. If I have very big requirements, on which a team works more than 2 weeks, then the teams can pull themselves these big requirements every 3-6 sprints (we call this multiple of sprints a stage). If I only have small requirements, and these change frequently, then teams probably need to plan each sprint together.
Does everything have to be in the common product backlog?
No, it is possible that one team reserves e.g. 50% of the capacity for direct requests and the other 50% for a common product backlog.
Does each team need a Product Owner, or is there a PO for everyone?
You can do both. The product backlog refinement is work in which the team and the product owner collaborate. There are multiple ways you can do this: e.g. a PO and teams, a Chief PO and team PO, a PO and team representative. The option you choose depends on the skills and time that the PO and the teams have. But all options can work. It is important that refinement is understood as cooperation and not as team versus PO.
And all the other questions, like distributed teams, or team members in two teams?
These are all good questions. But these are impediments for me, no matter which approach I take. I have to solve these impediments anyway, so they do not determine the configuration of my agile organization.
And the management?
That’s a team, too. Team for me has something to do with cooperation and pulling on a strand, teams exist at all levels.
And what about larger organizations or the next levels?
The next level is the same as the first. I think of the divisions simply as teams, and simply ask myself the questions about the cooperation of the teams again – recursively, so to speak.
And that’s it? That’s the whole truth?
Nope, that’s not the whole truth, you only find the truth with many years of actually doing it and “finetuning”. But it’s a good start. And it’s better than coming along with “Everything is Scrum” or “We use SAFe” or “SAFe is stupid, we use LeSS”. Or “We apply the Spotify model”. This one- hammer-idea isn’t so good, and coming with three SML hammers isn’t much better. Unfortunately, it takes a whole toolbox, asking what the team needs and gut instinct.
What if I want to read something myself now?
Then I would deliberately look at two frameworks that seem to be very different at first – and then have a lot of similarity. I think when you see the similarities in these two frameworks, you are halfway there.
