oder: Culture > Process, culture eats process for breakfast

Dieser Blog ist der Beginn einer Serie, in der die verschiedenen Probleme und Ansätze der Skalierung agiler Methoden beleuchtet wird.

Henrik Kniberg hat auf dem Scrum Gathering in Paris eine sehr inspirierende Keynote (hier die Slides): er berichtete über die Erfolgsgeschichte von Spotify.

Spotifiy ist einer der wichtigen Musik-Streaming Provider und Henrik Kniberg ist einer der profiliertesten Scrum Trainer.

Henrik hat die Erfolgsgeschichte von Spotify mit verschiedenen anderen Erfahrungen in Beziehung gesetzt, bei denen jeweils riesige Geldbeträge „verbrannt“ wurden und hat einige überraschende Entscheidungen von Spotify aufgezeigt.

Zunächst zum Skalierungsmodell: Die Belegschaft von Spotify wächst jährlich um 100 Prozent pro Jahr und es sind zur Zeit mehr als 1000 Personen in 28 Ländern. Die übliche Reaktion von Firmen in dieser Situation ist die, dass man einen Teil der agilen Praktiken zurückfährt und versucht, den Overhead durch traditionelles Management zu reduzieren.

Diesen Trend zeigen auch verbreitete Skalierungsframeworks, die in der agilen Scene zur Zeit heiss diskutiert werden wie SAFe (Scaled Agile Delivery von Dean Leffingwell)  und DAD (Disciplined Agile Delivery  von Scott Ambler). Über diese beiden Frameworks in Kürze mehr.

Das ist erst einmal eine natürliche Reaktion: das Risiko ist hoch und man zieht sich auf „bewährtes“, d.h. auf vertrautes Territorium zurück.

Kniberg und Spotify kommen auf eine völlig andere – und wie ich denke, eine wesentlich überzeugendere – Lösung: sie stellen zunächst die Frage, was die Probleme beim Wachstum verursacht und kommen zu den Themen

• Abhängigkeit zwischen Teams
• Prozeduren fangen an im Weg zu stehen
• Lernen und die Arbeit in der Organisation verbinden
• Leadership und Kultur, die enablen, nicht begrenzen

Abhängigkeit und Autonomie

Ein aktiv verfolgtes Ziel ist die Reduzierung von Handovers (Übergaben) und gegenseitigem Warten. Dafür wurden Praktiken entwickelt, bei denen sich

• Team-Autonomie: ein Team hat eine sehr hohe Gestaltungsfreiheit für seine Arbeit. Abhängigkeiten (z.B. Über die Codebasis) schränken diese Autonomie drastisch ein. Anstatt an der Autonomieschraube zu drehen, reduziert man aktiv die Abhängigkeiten.
• Open Source Prinzip: ein Team darf Code eines anderen Teams kopieren und verändern, wenn es ein Feature nicht rechtzeitig von diesem bekommt
• Nur die notwendige Standardisierung: zum Beispiel hat die herausgestellt, dass das Versionsverwaltungstool GIT ganz gut funktioniert, es wird also von „den meisten“ Teams verwendet.

Prozeduren stehen im Weg

Bei der Einführung von Scrum werde ich öfter gefragt, welche Teile von Scrum man einsetzen muss. Meine Antwort ist da normalerweise: alle. Die Teile, die Schmerzen verursachen, decken auch bisherige organisatorische und technische Defizite und Schwächen auf. Wenn die Teams erfolgreich mit Scrum sind, können sie durchaus darüber hinauswachsen. So gehen die Scrum-Prozesse zum Teil in weiter entwickelten Praktiken auf.

Teams werden autonome „Squads“, die sich in „Tribes“ (departments) zusammenfassen. Personen mit gleichen Aufgaben, z.B. Tester, organisieren sich quer dazu in „Guilds“ (communities of practice).

Alles hat das übergreifende Ziel, Abhängigkeiten zu verringern ohne die Zielrichtung zu reduzieren.

Lernen und zielgreichtetes Arbeiten

Die Guilds, Tribes und Squads helfen nicht nur beim unabhängigen Arbeiten, sondern auch beim „alignment“ (alignment enables autonomy) – diese Idee steht im Gegensatz zu den oben genannten Skalierungsansätzen.

Leadership

Voraussetzung für diese Art des selbstbestimmten kreativen Arbeitens ist ein starkes Augenmerk auf eine Kultur, die diese unterstützt und verstärkt. So versteht das Top-Management seine Hauptaufgabe darin, die richtigen Fragen in die Organisation einzubringen.

Die Guilds veranstalten regelmäßige „Un-Konferenzen“, und in den Squads sind Verhaltensweise wie Blaming und Mangel an Respekt vor den Kollegen streng verpönt.

Und die Software?!

Es stellt sich die Frage, wie weit diese Art der Organisation effizient und effektiv ist. Eine Gemeinsamkeit mit anderen Methoden fällt auf: es wird ebenfalls das Modell eines Release Trains verwendet, aber mit sehr wenig Overhead realisiert: Jedes Feature in der Codebasis, das noch nicht fertig ist, kann mit einem „Feature-Toggle“ stillgelegt werden. Es behindert also nicht, dass der Release rechtzeitig ausgeliefert wird. Daher auch das Bild vom Release-Train: der Zug fährt pünktlich ab – Du bist rechtzeitig da oder nicht.