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 scrum.org 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 scrum.org 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.

How we decide at it-agile

Context

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 http://en.wikipedia.org/wiki/Consent) 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.

Acknowledgements

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

Agilität, Skalierung und Kundenbegeisterung

In vielen Fällen reicht es heute nicht mehr aus, mit nur einem kleinen agilen Team an einem Produkt zu arbeiten. Dann müssen mehrere Teams gemeinsam arbeiten. Für die Koordination wurden Frameworks/Methoden wie SAF oder DAD vorgeschlagen. Jetzt gibt es einen weiteren Vorschlag: man braucht gar kein zusätzliches Framework zur Skalierung. Stattdessen sollte man sich an den agilen Prinzipien orientieren und seinen eigenen Weg finden. Zusätzliche Praktiken zur Koordination werden situativ verwendet, wenn sie helfen, die Prinzipien besser umzusetzen. Eine Gruppe von agilen Experten (inkl. meiner Wenigkeit) hat diese Prinzipien zusammengeschrieben und unter http://scaledprinciples.org veröffentlicht. Wer die Prinzipien unterstützt, kann sich dort auch als “Unterstützer” aufführen lassen. Die Skalierungsprinzipien sind in diese Bereiche gruppiert:

  • Begeisterte Kunden
  • Zufriedene produktive Mitarbeiter
  • Globale Optimierung
  • Unterstützende Führung
  • Kontinuierliche Verbesserung

Markus Gärtner hat die Prinzipien zu globaler Optimierung in seinem Blog detaillierter beschrieben und kommentiert. Die Prinzipien zu zufriedenen produktiven Mitarbeitern hat Andreas Schliep detaillierter beschrieben und kommentiert. Ich möchte hier die Prinzipien rund um begeisterte Kunden etwas genauer betrachten:

Begeisterte Kunden sind der Garant für jedes Unternehmen, langfristig zu wachsen. Die Aufgabe der Produktentwicklung ist es, die Grundlage für dieses Wachstum zu schaffen.

Ich meine, dass für Unternehmen der Kundennutzen im Fokus stehen sollte und nicht das Geld. Ich bin (wie viele andere auch) davon überzeugt, dass begeisterte Kunden ein sehr verlässlicher Indikator für den langfristigen finanziellen Erfolg des Unternehmens sind. Ein starker finanzieller Fokus führt hingegen meist zu unzufriedenen Kunden (Qualität von Produkt und Service wird reduziert, um Kosten zu sparen) und damit langfristig zu finanziellen Einbußen. In diesem Kontext waren uns zwei Prinzipien wichtig:

  1. Definiere, was Wert bedeutet schafft
  2. Produziere kleine, lieferbare Inkremente

Definiere, was Wert bedeutet und schafft

Das gemeinsame Verständnis über die wertschöpfenden Elemente muss gerade in einer skalierten Produktorganisation bei allen Mitarbeitern vorhanden sein. Leitbilder helfen dabei, die strategischen Ziele zu erreichen. Ein klares Wertverständnis gibt gemeinsame Orientierung.

Bei der Entwicklung mit nur einem Team ist dieses Prinzip relativ leicht umgesetzt. Das Team arbeitet im direkten Kontakt mit der Business-Seite (Product Owner, Anwender, Kunden) und baut darüber sehr schnell ein Verständnis darüber auf, was die Kundenbedürfnisse sind und wie das entwickelte Produkt diese Bedürfnisse befriedigt. Dadurch steigt die Verbundenheit des Teams mit den Kunden, den Kundenbedürfnissen und dem Produkt. In der Folge bringt das Team selbst Ideen dazu ein, wie die Kunden durch aktuelle Technologien begeistert werden können. Bessere Produkte, begeisterte Kunden und nicht zuletzt zufriedenere Mitarbeiter sind die Folge. In skalierten Umfeldern besteht die Gefahr, dass zusätzliche Hierarchien für die Koordination der Teams eingeführt werden, die die Teams wieder stärker von den Kunden und der Wertschöpfung entfernen. Auch in skalierten Umfeldern sollte jedes Teammitglied wissen, ob und wie das Gesamtprodukt die Kunden begeistert und was der Beitrag des eigenen Teams dazu ist.

Produziere kleine, lieferbare Inkremente

Inkremente bauen aufeinander auf und beinhalten stets den Nutzen und die Funktionalität der vorherigen Inkremente. Daher eignen sie sich ausgezeichnet zur Herstellung und Messung von Mehrwert. Ein lieferbares Inkrement eines Produktes hat somit qualitativ alle Eigenschaften, die man zur Auslieferung braucht, wobei die Produktorganisation Stück für Stück die fehlenden funktionalen und nicht-funktionalen Eigenschaften ergänzt. Im Idealfall kann der Wert eines Inkrements sofort in Nutzen für den Kunden umgesetzt werden. Doch auch wenn das nicht möglich ist, bieten kleine, lieferbare Inkremente die Basis für die kontinuierliche Verbesserung des Produkts, sie minimieren Risiken und reduzieren Komplexität.

Scrum fordert auslieferbare Produktinkremente nach jedem Sprint – es darf keine offenen Restarbeiten an den Funktionalität dieses Inkrements geben. Dadurch werden Risiken effektiv minimiert und es entsteht Transparenz über die reale Leistungsfähigkeit des Teams. Außerdem können Produktinkremente bei Bedarf sofort durch Kunden benutzt werden. Die Time-2-Market reduziert sich. Dadurch wird Feedback aus dem Produktivbetrieb früher generiert und die Wertschöpfung durch das Produkt beginnt früher. In skalierten Umfeldern ist es deutlich anspruchsvoller, lieferbare Produktinkremente zum Sprintende fertig zu stellen. Schließlich müssen dafür die Beiträge aller Teams noch während des Sprints integriert werden. Trotzdem sollte man dieses Ziel auch in skalierten Umfeldern verfolgen. Risikominimierung ist schließlich in skalierten Umfeldern noch wichtiger als für ein einzelnes  Team (der potenzielle Schaden in einem Großprojekt ist einfach deutlich größer). Ich finde hier ein Toyota-Motto hilfreich: “Wenn etwas schwierig ist, mache es häufiger!” Dann wirst Du nämlich lernen, wie es einfacher gehen kann.

Buchtipp: “Software in 30 Tagen”

Die beiden Scrum-“Erfinder” Ken Schwaber und Jeff Sutherland haben 2012 ihr erstes gemeinsames Buch mit dem Titel “Software in 30 Days” veröffentlicht. Ich habe das Buch ins Deutsche übertragen. Es trägt – wenig überraschend – den Titel “Software in 30 Tagen“. Das Buch richtet sich an Manager und will diese von Scrum überzeugen.

Holger Koschek hat bereits eine ausführliche Besprechung des Buches in seinem Blog veröffentlicht. Holger bemängelt Schwächen in der Übersetzung. Ich freue mich über konkrete Verbesserungsvorschläge für eine eventuelle zweite Auflage der deutschen Ausgabe: Einfach E-Mail an: stefan.roock AT it-agile.de (Oder: wer mir das Buch mit entsprechenden Annotationen zusendet, bekommt von mir ein frisches Exemplar zurück).

Ich möchte über Holgers Buch-Beschreibung hinaus auf ein paar Punkte hinweisen, die mir beim Übersetzen durch den Kopf gingen:

  1. Das Buch führt eine Reihe von interessanten Fallbeispielen an. So kann man z.B. lernen, wie es für Adobe möglich und sehr effektiv war, auch in einem Multi-Team-Setting in jedem Sprint vollständig integrierte auslieferbare Produktinkremente herzustellen.
  2. In den Fallbeispielen sind die Product Owner immer hochrangige Manager und nicht umgeschulte Business-Analysten, die zu vorgegebenen Features die Details aufschreiben. Ich habe über die Besetzung der Product-Owner-Rolle hier gebloggt.
  3. Die Sprints in den Fallbeispielen sind relativ lang (eher Monatssprint als 2-Wochen-Sprints). Das harmoniert meiner Meinung nach sehr gut mit der Besetzung der Product Owner-Rolle durch Top-Manager. Auch über die Sprint-Länge habe ich an anderer Stelle gebloggt.
  4. Zu den langen Sprints passt die Sichtweise auf Sprints als Investitionseinheit. Jeder Sprint soll einen positiven ROI (Return on Investment) haben und wenn der Product Owner nach dem ersten Sprint des Projekt beendet, soll er trotzdem ein Produkt haben, das er einsetzen kann und dessen Wert die Kosten des Sprints übersteigen.
  5. Wie Holger bereits schreibt, zieht sich das Thema empirisches Management als roter Faden durch das Buch. Ich denke, dass dem Aspekt des empirischen Managements in der Praxis immer noch zuwenig Aufmerksamkeit gewidmet wird. Eine Kurzeinführung in empirische Prozesskontrolle findet sich z.B. hier. Was das für die Scrum-Meetings bedeutet, habe ich in einem Blog-Post beschrieben.
  6. Im zweiten Teil des Buches geht es um verschiedene “Implementierungsweiten” von Scrum: Scrum auf Projektebene (Scrum PRN), Einrichtung einer dauerhaften Organisationseinheit zur Durchführung von Scrum-Projekten (Scrum Software Studio), Scrum für das ganze Unternehmen (Enterprise Scrum).
  7. Und zum Abschluss gibt es Hinweise, wie Scrum mit Scrum eingeführt werden kann.

Der erste Teil des Buches ist meiner Meinung nach eine für Manager verständliche Einführung in Scrum. Der zweite Teil des Buches kann auch für erfahrene Praktiker die eine oder andere Inspiration liefern.

Shades of Scrum: Empirical Management Meetings

Ken Schwaber defines empirical process control (aka empirical management) as one of the pillars of Scrum. Empirical management means to recognize what is (reality) and to base decisions on facts. Empirical managements needs:

  • Transparency (we need to be able to see the facts and should not rely on things that aren’t provable)
  • Inspection (we have to evaluate and interpret the transparent facts)
  • Adaptation (we modify the plan according to the inspection)

The Sprint Review, the Sprint Retrospective and the Daily Scrum are empirical management meetings in Scrum. In the Sprint Retrospective for example we first create transparency about the way we work (the Gather Data phase) then we inspect what we have found (the Generate Insights phase) and then we adapt the way we work (the Decide What To Do phase).

Applying these three steps of empirical management to the Daily Scrum and Sprint Review meetings often is an interesting exercise since a lot of “Scrum” teams miss adaptation and sometimes even inspection. And it gets worse when teams use additional meetings like a Scrum of Scrums where there are no “by-the-book-checklists” around on how to do them. So they just pollute the meeting we status reports and don’t inspect and adapt.

When looking at a meeting I suggest discussing if it is an empirical management meeting. If it is I would design the meeting backwards with the end in mind. Who should adapt what? When we know that we can easily find out how to inspect and finally what transparency we need.

So here is my “checklist” for the design of an empirical management meeting:

  1. Define what you want to adapt in what way. (Adaptation)
  2. Find out what you need to learn in order to be able to adapt. (Inspection)
  3. Find out what you need transparency about to do the inspection. (Transparency)

If you want to adapt the release plan as the result of the Sprint Review we need to inspect velocity during the Sprint Review and would therefore check what features where implemented and count story points. If we want to adapt the Product Backlog with new ideas that would improve the product we would probably have customers at the Sprint Review and gather feedback and ideas from them.

Team Based Rewards

When companies switch to team based approaches like Scrum individual performance appraisals become more or less meaningless. A team is more than the sum of its parts (team members). Trying to measure the individual contribution to the team’s success as an team-outsider is hardly possible and will harm the team dynamic seriously.

There are some alternatives around. One that comes to mind quickly is team based rewards. The reward is not given to individuals but to teams. To distribution of the reward among the team members can be done in several ways. Things I have seen:

  1. The reward is distributed according to a predefined formula that may take the formal position in the company into account. (The senior developers gets a greater share than the junior).
  2. Everybody gets the same share (and this distribution is clear beforehand).
  3. The team determines the shares.

Option 1 conforms the formal hierarchy and that may hinder self-organization and high-performance. But it may be a first step to migrate from individual performance appraisals to team rewards.

Option 2 is very easy and I have seen it several times. I have never seen dysfunctions in the team caused by this approach.

Option 3 has the best chance to come to a fair distribution of the reward. The challenge is to moderate the discussion within the team. (Remember that most people think they perform over average, see illusory superioty). I know of two simulations where the team came to a consensus. But in these cases the whole thing might change when it would become reality. And I know of one case where it was actually done. The team always found the “compromise” that everybody would get the same share. And after that everybody was pissed off for 3 months since that thought this distribution would be unfair.

Therefore I would aim for option 2 or even better: Dismiss rewards completely. Extrinsic motivation isn’t very useful when it comes to knowledge work (see Dan Pinks Surprising truth about motivation).

Rare specialists in Scrum

One of the questions that occur again and again in trainings and coachings circels around rare specialists. Perhaps a company has five specialists for a special topic and all in all 80 developers. With Scrum they would end up with roughly ten teams. What should the company do regarding the specialists? Two options come to mind very quickly:

  1. Each specialist could work for two teams.
  2. The specialists could form their own team that acts as a service provider for the other teams.

While both options may work I like to highlight a third option:

Figure out which are the five important teams, put the specialists full-time in these teams and let the other five teams to their own devices. The first reaction often is: “No, no, no. That is a really dumb idea.” But what would be the consequences? The most important projects/teams would move forward very fast and the less important projects would move forward slowly.

The two options mentioned in the beginning would lead to all teams moving with average speed (if you manage to bring flow to the workload of the specialists).

What would be the more valuable approach for your company?

What to expect from slack time

Several well known companies have slack time models of different shapes and sizes. 3M and Google are famous for their 20% model (engineers work 20% of thair time – e.g. every friday – on a self-chosen project). My former colleague Bernd Schiffer wrote a small blog post series about slack.

Recently an InfoQ article re-opened the discussion with interesting insights into Googles 20% slack model. It seems that at Google most employees don’t use their slack (self-chosen or management prohibited it).

That made me think of two slack models I have experienced first-hand – one at it-agile (every employee had 30 days slack per year) and one at a client (every developer had a contingent of something about 12 days per year using the Goldcard model). In my point of view both models failed to deliver what was expected: business relevant innovation. And I think I know the reason.

Imagine the typical developer working according to the prioritization of a Product Owner. Now we grant the developer 10 days per year slack time. He can use the day for whatever he wants to do. The developer thinks: “What should I do with my slack time? Hm. I can do, whatever I want. Let’s see, there is this new cool programming language. I will have a look at it.”

The effect is a technological focus of the slack time. In such a setting you can expect that developers know more new technologies. And that is fine if this has a relevant impact on your business.

But most of my clients primarily need business innovation. While knowing the newest technologies is important for a lot of business innovations it is not enough. You need to know customers’ problems and needs as well.

Google has an advantage here: Google develops products for consumers like me and you. Therefore the engineers might be potential customers of Google products and a now their own problems and needs. Ergo: developers were able to develop e.g. Google Chrome or GMail in their slack time.

But in most companies the developers aren’t potential customers of their own products. I think that a slack model has to have certain constraints to generate business innovation. One might be that the slack time has to be with and at clients (perhaps something like the sunglass iPad development at Nordstrom may be the result).

What di you think? What are your experiences with slack time models?

How cross-functional should my Team be?

In a Lean/Agile world teams should be cross-functional. Period.
Or maybe it’s not that easy? What does cross-functionality actually mean? And is it true that the more cross-functional, the better?

Bild

I wrote an article together with my brother Arne Roock adressing these questions. The article is published in the current edition of the “Agile Review” by it-agile. The article is available as PDF for download. (There is also a german version of the article).