Agile Scaling Cycle: from SCaLeD principles to practices

The SCaLeD principles ( were well received and gained many supporters. Of course a set of principles is not sufficient to be successful in projects – specific practices (depending on context) need to be used.

When we defined the SCaLeD principles we knew that practices would be needed and that we didn’t want to define another blueprint. So we accepted the gap for the moment.

Later I did a CSM class together with Peter Beck where the participants collected scaling practices. While the participants brainstormed we thought about how to structure the results and came up with the Agile Scaling Cycle (the name came into being during a presentation about scaling I did some weeks later).

The Agile Scaling Cycle is a simple three step cycle. It starts with “reduce dependencies”. Autonomous teams are a cornerstone of agile. Therefore we reduce dependencies between teams as much as possible.

Then we start to work and in the second step of the Agile Scaling Cycle the teams have to coordinate the remaining dependencies.

During the work problems (often pointing at organizational dysfunctions) will occur. These feed the third step of the Agile Scaling Cycle: develop the organization. After that we should have more options to reduce dependencies so we start over again with the first step “reduce dependencies”.

Agile Scaling Cycle.001

We have gathered lots of practices for reducing dependencies during the last decade:

Agile Scaling Cycle.002

And we gathered lots of coordination practices as well:

Agile Scaling Cycle.003

For developing the organization we often work with a transition team:

Agile Scaling Cycle.004

July 13, 2014 at 1:23 pm 2 comments

Coordinating teams with Scrum of Scrums

When multiple teams are interdependent (typically because they develop the same product), Scrum of Scrums is a common coordination practice within Sprints. Here are some tips to make it an effective meeting:

  1. During Sprint Planning identify the features that need contributions from several teams during the upcoming Sprint (e.g. with a dependency matrix).
  2. Focus the Scrum of Scrums meeting around these dependencies. (And dismiss the Scrum of Scrums if there are no relevant dependencies – which is actually a good thing.)
  3. Let the teams with dependencies send one or two delegates to the Scrum of Scrums. The delegates are developers – not the Product Owners and not the Scrum Masters. Delegates may be the same during the Sprint or teams may choose to rotate the delegates.
  4. Find an appropriate periodicity for the Scrum of Scrums. Sometimes a daily Scrum of Scrums is what the teams need, sometimes one or two Scrum of Scrums per week are sufficient. The teams should decide during the Sprint Planning.
  5. Timebox the Scrum of Scrums to 15 minutes if it is done on a daily base (weekly Scrum of Scrums may have longer timeboxes).
  6. Visualize the state of the features with dependencies during the Scrum of Scrums (e.g. with a dependency matrix).
  7. Let one of the team Scrum Masters moderate the Scrum of Scrums.
  8. Discuss three questions (similar to the one used in the Daily Scrum):
    1. What did my team achieve since the last Scrum of Scrums regarding the features with dependencies?
    2. What impediments occurred in my team regarding the features with dependencies?
    3. What do the teams plan to do until the next Scrum of Scrums regarding the features with dependencies?

Also consider alternatives to the central Scrum of Scrums meeting, e.g.:

  • Teams may visit the regular Daily Scrums of other teams if they have a dependency.
  • Teams may visit each other on demand. This is especially suitable in open office settings that encourage communication and cooperation between teams.
  • Teams may form task forces for the features with dependencies. Scrum of Scrums may be established per task force. Over the time of several Sprints patterns regarding the task force members may become visible. These are often good starting points for reorganizing team structures to improve team autonomy.
  • The ideal of the Scrum team is the autonomous team without dependencies. Although a dependency free situation won’t be achievable we strive for reducing dependencies. If we are successful the teams don’t need any coordination meetings during the Sprint.


May 27, 2014 at 10:56 am Leave a comment

ASMM: Agile Scaling Maturity Model

During a presentation of our approach to scaling agile I constructed „Stefans Agile Scaling Maturity Model“ (SASMM, not trademarked) in an ad-hoc fashion: The number of scaling practices you don’t need. It was a joke but I think there might be something behind the curtain.

Let’s start with the Agile Scaling Cycle: We start with reducing dependencies between teams and with the outside context. Then we do some work and need to coordinate the remaining dependencies. During this work we generate insights and detect organizational impediments. These direct us during the further development of the company. The evolved structures and processes of the company give us additional options for reducing dependencies and we start a new loop through the Agile Scaling Cycle. The whole cycle is driven by the agile scaling principles (which are just the agile/lean principles reformulated for scaling; see


The trick here is to reduce dependencies to the point where coordination becomes dead simple. When we went through the Agile Scaling Cycle several times the company should be more mature, teams should be less dependent and in consequence we need very few coordination practices. Therefore the first formula to compute the scaling maturity on a scale from 0 to 10 (the higher the score more mature) could be:

ScalingMaturityLevel = 10/NumberOfCoordinationPractices

Of course some coordination practices are more agile than others. A dependency matrix is less agile than a shared Sprint Review. So we could weight the practices by the additional weight they put on the process. But that would be another blogpost and in the end I’m not convinced that maturity models are valuable.

April 9, 2014 at 10:28 am Leave a comment

Use what works, ditch the rest?

„Use what works, ditch the rest!“ is something that I have heard over and over again regarding Agile. On one hand it sounds logical, one the other hand it feels somehow wrong. And for a long time I didn’t really understand why I felt that way.

In a recent Twitter conversation around that theme Dave Snowden wrote, „if you don’t know why it worked you end up being fooled.“ That statement helped me to understand my gut feeling better.

I think the really important part of „Use what works, ditch the rest!“ is your definition of „works“. Let’s be more precise: Scrum wasn’t made to „work“ in your environment. It is designed to make the organizational dysfunctions visible, so that you can remove them. In that way you shouldn’t expect Scrum to “work”. And if you ditch Scrum since it doesn’t “work”, you ditch an opportunity to evolve the company.

Sidenote: It doesn’t matter if you use Kanban instead of Scrum. Slack time generated by WiP limits doesn’t “work” in most companies either.

Don’t get me wrong: I do not propose cargo-cult dogmatism. In alignment with Dave Snowden you should have experienced agile practitioners on board who know why Scrum and Kanban are designed the way they are and help you understand why something does or doesn’t work in your context. Then you really learn and get the opportunity to improve.

In conclusion the „Use what works, ditch the rest!“ is OK for me, when the definition of „works“ is that our problems become visible so that we can attack them.

March 26, 2014 at 8:05 pm 1 comment

Scrum: Just following the hype?

From time I meet people who say that their management introduced Scrum just because it is a hype. Honestly I doubt that. I have introduced Scrum and other agile approaches since 2000 into various companies and I have spoken to dozens (if not hundreds) of managers. And every manager was able to explain why he wanted Scrum/agile. Sometimes expectations were excessive but I have never met a manager who didn’t know why he wanted Scrum and just followed the hype blindly.

I think the misconception of the employees is caused by a communication fail. As George Bernard Shaw said:

The single biggest problem in communication is the illusion that it has taken place.

The managers know why they want Scrum and normally they even have communicated it:

  • once
  • in an email
  • hidden between a lot of other stuff

And that is just not enough to make a real change happen. Even if employees have read the message there is a lot of doubt:

  • Does the manager really know what Scrum is?
  • Would he really do what is necessary?
  • Was the message just ad-hoc and now there is another most-important thing?

Therefore managers should

  • communicate the intended change (together with the “why”) personally and face-2-face
  • renew the message continuously
  • model the wanted behavior themselves


February 26, 2014 at 12:15 pm Leave a comment

Agile Skalierung: eine Kollage

In diesem Blogpost versuche ich mal eine Sammlung der verschiedenen Sichtweisen auf das Thema agile Skalierung (also der Organisation von agiler Entwicklung, wenn mehr als ein Team notwendig ist).

Scaled Agile Framework™ (SAFe)

Das Methodenframework SAFe von Dean Leffingwell erfährt im Moment viel Beachtung und ist höchst umstritten:

Die deutschsprachigen SAFe-Protagonisten, mit denen ich selbst gesprochen haben, stimmen der o.g. Kritik interessanterweise im Wesentlichen zu. Sie argumentieren aber, dass SAFe trotzdem ein erster Schritt hin zu ein ganz klein wenig mehr Agilität sein kann, dass man SAFe sowieso nicht so implementieren würde, wie es beschrieben ist und dass man direkt nach der Implementierung damit anfangen müsste, es sofort zu ändern (überspitzt: wieder zu demontieren).

Ein SAFe-Trainer meinte, er sähe die größte Gefahr von SAFe darin, dass viele SAFe-Trainer und Coaches Agilität nicht verstanden hätten und daher keinen sinnvollen Einsatz von SAFe sicherstellen könnten. Wer sich tatsächlich für SAFe entscheidet, sollte also viel Aufwand darin stecken, den agilen Erfahrungshintergrund der Trainer/Coaches intensiv zu durchleuchten (das gilt natürlich generell für die Auswahl von Coaches/Trainern). (Vielleicht sollte man sogar prinzipiell immer jemanden mit an Board holen, der SAFe für Unsinn hält :-)

Disziplined Agile Delivery (DAD)

DAD von Scott Ambler hat lange nicht die Aufmerksamkeit wie SAFe erreicht. Das erklärt vielleicht auch, warum es deutlich weniger Kritik dazu gibt.

Large Scale Scrum (LeSS)

LeSS von Craig Larman und Bas Vodde ist eigentlich gar keine echte eigene Methode, weil schlicht das Scrum-Framework für die Skalierung interpretiert wird.

Agility Path

Agility Path von liefert im Gegensatz zu SAFe, DAD und LeSS keine Struktur für skalierte Agilität, sondern definiert den Prozess, wie man zu dieser Struktur kommt. Ähnlich wie SAFe und DAD ist es direkt kommerzialisiert.

Auch bei Agility Path könnte man diagnostizieren “im Westen nichts Neues”. Das, was Agility Path ausmacht, haben Ken Schwaber und andere agile Praktiker schon vor Jahren beschrieben. Man begleitet die Einführung und Ausbreitung von agil kontinuierlich und setzt dafür ebenfalls Inspect&Adapt ein (häufig bildet man ein Transitionsteam dafür).

Enterprise Transition Framework™ (ETF)

Das ETF von Agile42 scheint mir im Grunde fast identisch mit Agility Path zu sein. Vielleicht ist einer der Gründe für die Existenz, dass Agile42 die Scrum-Zertifizierungen der Scrum Alliance anbietet und ein Gegenpol zu Agility Path von der Konkurrenz-Zertifizierungsorganisation schaffen wollte.

We don’t need no new methods

Und dann gibt es noch die Gruppe derjenigen, die meinen, dass man für agile Skalierung keine neuen Methoden braucht und schon gar keine mit Trademarks. Die Prinzipien, die wir für die agile Skalierung brauchen, kennen wir bereits seit Jahren. Die Praktiken für die Skalierung sollten schrittweise passend zum Unternehmen gefunden werden. Inspirieren sollte man sich bei der Suche nach geeigneten Praktiken von der Praxis (z.B. bei anderen Unternehmen) und nicht von Methoden. (Dieser Gruppe gehöre ich selbst an).

Was fehlt?

Wenn Ihr noch Ressourcen kennt, die das Bild vervollständigen, hinterlasst mir einen Kommentar zu diesem Artikel. Ich werde den Artikel dann ergänzen.

February 14, 2014 at 10:58 am Leave a comment

How we decide at it-agile


At it-agile each employee (with some minor exceptions due to probation period) is a shareholder with the same shares. These sum up to more than 60% of the company. The result is a special power cycle: The CEOs have formal power over the employees (and may lay off people). On the other hand the employees may instruct the CEOs or even replace them with somebody else. This setting forced us to search for appropriate decision mechanisms. On our quest we tried several approaches. An obvious one is democratic decision. Funny enough this worked fine for a while but it turned out that it didn’t scale for us when we exceeded an employee number of 15 to 20 (now we are 30 something). This blog post describes the current way we decide at it-agile.

Current State

When it comes to decisions, I think we value some principles:

  • The decision mechanism should be appropriate (especially regarding impact for other employees and reversibility) for the decision at hand.
  • Consensus is nice but often not necessary (it is often too costly to create consensus with 30 people) but it is important to have a high commitment of the employees on the decision.
  • Decisions should be reversible (there are very few exceptions where it is not feasible or possible to ensure reversibility).
  • Therefore wrong decisions aren’t that bad. We may learn that the decision was wrong or suboptimal and then create a better decision soon.
  • Decision making should be decentralized.
  • Relevant perspectives should be respected when making a decision.

Currently we use these decision mechanisms:

  • When a decision impacts only you, you may decide yourself directly. (For example we have very few very simple guidelines (“simple rules”) for travel expenses and you are empowered to decide for yourself according to these guidelines – and you publish the travel expenses for your colleagues).
  • When a decision impacts only your team, you may decide with your team. Here you should use the decision mechanism that is established within your team (often teams use Konsent).
  • When a decision impacts other colleagues we try Konsent (with thumb voting). When we are not able to make a decision within 10 minutes we choose a “decider” who has to consult his colleagues and then decides (consultative individual decision, in german it is called “konsultativer Einzelentscheid”). For choosing a decider we ask for proposals and rationale. If there are several proposals for the same decision we choose in Konsent. It turned out that choosing the decider that way is fast and effective for us.

Consultative Individual Decisions

The consultative individual decision making process has these steps:

  1. Identify a needed decision and choose an appropriate decider with Konsent.
  2. The decider consults an appropriate set of people (within and/or outside his team/company).
  3. The decider decides based on the perspectives he gathered.
  4. The decision is published within the company (at it-agile the decider publishes whom he consulted, which perspectives were relevant and what his decision is).
  5. All other colleagues accept the decision and practice forgiveness.
  6. We all together learn from this decision making process and improve for the next decision.

At the moment we identify necessary decisions and appropriate deciders during our monthly Company Sprint switchovers. When it becomes clear that a decision is needed and we are not able to decide as a group (of 30 people) within a few minutes we select a decider. The decider then has a timebox until the next Sprint turnover to decide. We add a task to the Company Task Board so that we remember to review the decision.

How we got here

In our nine years history we tried nearly every decision-making mechanism we could find. In the beginning a lot of the decisions were made by the CEO. Since we wanted to be a participative company we tried to move more and more decisions to the employees. That worked fine in the beginning. People started to decide for themselves. Bigger issues were discussed and decisions were made with majority decisions at our company tuning days.

When we grew beyond 20-25 people the discussions and decisions at the tuning days became more and more dull and slow. We invested a lot of time and energy and often didn’t come to consensus. We tried majority decisions. Still we had a lot of time-consuming discussions and when the decision had only a narrow majority we slipped into a bad mood. The narrow majority didn’t want to force something onto a big minority. And when we had a narrow majority decision the large minority questioned the decision shortly after the decision again and again.

We knew how to apply Konsent (see for a smaller number of people (team size). But we haven’t found out until now how to run it efficiently with 30 people.

We had a decision crisis for months and since we didn’t know any other alternative we switched back to central CEO decisions for important aspects. That allowed us to make decisions again but still wasn’t what we were aiming for: a participative company.

And then we had a workshop with Niels Pfläging where he explained the Beta Codex model. We recognized that we followed the Beta Codex principles without knowing it but that our central decision model didn’t fit into the picture. After discussing the problem with Niels he proposed Consultative Individual Decisions. At first the concept sounded a bit weird. Would we empower an arbitrary employee to decide about an investment of 100.000 EUR? But since we already had a history of doing weird things (like introducing teams without having a clue how that concept could be applied in a coaching context like ours) we decided to give it a try.

We designed an experiment with 4 decisions: three of the decisions were proposed by the CEOs and one was added by the employees during the Sprint switchover where we started the experiment. We formulated our thesis (“consultative individual decisions” increase the number of options heard before deciding and increase the commitment on decisions) and set a timebox (due to Christmas and New Year we set it to two months).

After the two months we reviewed the decisions at the company Sprint turnover. Three decisions were made. One decision wasn’t made. We had learned that the decision was too big and the time was too early. We then decided to delay the decision for 2 months (when we would know more about the topic). And we learned that it is valid if a decider makes a decision that doesn’t match exactly his mission.

Our evaluation showed that the overwhelming majority of people thought that consultative individual decisions lead to an increased number of options heard and higher commitment. Some people thought the quality was as before and nobody thought it was worse than before. Consequently we added consultative individual decisions to our repertoire of decision-making mechanisms. And we applied it immediately:

We had a CEO decision that we would only hire employees living in Hamburg (to increase personal contact between employees). During the retrospective of the Company Sprint switchover that decision was questioned by a working group. The group proposed another approach. We checked if we could get Konsent for that proposal. Within a few minutes it turned out that we couldn’t. Therefore made it a consultative individual decision and chose a decider.


Thanks to my colleagues Ilja Preuß, Christian Dähn and Manuel Küblböck for their feedback and input for this article.

February 13, 2014 at 9:05 pm 3 comments

Older Posts


Get every new post delivered to your Inbox.

Join 188 other followers