Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

//

Agile Skaliert – Teil 1

1.2.2014 | 5 Minuten Lesezeit

Vor 19 Jahren wurde Scrum als neuer Entwicklungsprozess von Ken Schwaber und Jeff Sutherland auf der OOPSLA (Object-Oriented Programming, Systems, Languages & Applications) vorgestellt. Gleichzeitig erschien auch die erste Beschreibung des „Scrum Development Process“. 6 Jahre später folgte das agile Manifest, das mit seinen 4 Werten und 12 Prinzipien die Grundlage für eine andere Art und Weise der Zusammenarbeit innerhalb von Firmen und auch darüber hinaus legte.

Agile Vorgehensweisen sind mittlerweile im Mainstream angekommen; die Phase der „Early Adopters“ haben wir hinter uns gelassen und immer größere Unternehmen wollen von den Vorteilen dieser Art der Zusammenarbeit profitieren. Nicht zuletzt, weil der Marktdruck mit immer kürzeren Innovationszyklen ein dazu passendes Vorgehen unabkömmlich macht, um am Markt bestehen zu können. Als populärster Vertreter eines agilen Vorgehens wird dabei häufig Scrum eingesetzt.

Doch die Einführung von agilen Vorgehensweisen (z.B. Scrum) in großen Organisationen stellt diese vor völlig anderen Herausforderungen als dies noch beim Etablieren in kleinen Teams der Fall war. Dazu gehören beispielsweise:

  • Wie wird die Unternehmensidee (Vision) auf kleine, in Sprints umsetzbare Inkremente herunter gebrochen?
  • Wie behält das Unternehmen trotz der Umsetzung von sehr kleinteiligen Artefakten das große Ganze im Auge?
  • Wie kann eine notwendige Kommunikation zwischen den Kollegen zum richtigen Zeitpunkt sichergestellt werden? Wie vermeidet man zu viel unnötige Kommunikation?
  • Müssen bisherige Strukturen, Hierarchien und Rollen berücksichtigt werden? Wenn ja, wie?

Glücklicherweise können bereits einige Hilfestellungen zu diesem komplexen Thema gefunden werden:

  1. Ken Schwaber selbst hat (natürlich) dazu seine Ansichten veröffentlicht: „The Enterprise And Scrum
  2. Von Dean Leffingwell stammt das aktuell viel diskutierte „Scaled Agile Framework
  3. Craig Larman und Bas Vodde haben sich bereits vor einigen Jahren ihre Gedanken dazu gemacht: „Scaling Agile Development“
  4. Der Erfahrungsbericht von Henrik Kniberg, wie Agile bei Spotify gelebt wird

Dies ist der 1. Teil einer Blogserie in der ich einen Überblick über diese Ideen und Vorgehensweisen gebe sowie die Vor- und Nachteile, die aus meiner Sicht damit jeweils einhergehen.

Ken Schwaber: „The Enterprise And Scrum“

Als Miterfinder von Scrum verfolgt Ken Schwaber einen sehr puristischen Ansatz beim Skalieren von Scrum in großen Unternehmen. Alle Rollen, Meetings und Artefakte von Scrum werden beibehalten. Übergreifende Abhängigkeiten der Teams und auch über Abteilungen hinweg werden über Backlogs gesteuert. Dies geht über das bekannte Product Backlog hinaus zu Backlogs zur Steuerung der Arbeit von den an der Transition beauftragten Teams, dem Produktmanagement und weiteren notwendigen Abteilungen. Als Hilfsmittel für jegliche Planungsaktivitäten werden auf jeder Ebene (Sprint, Release, Produkt, etc.) des Unternehmens jeweils Burndown-Charts genutzt.

Schwaber legt sehr viel Wert darauf, dass die Werte von Scrum auch bei großen Unternehmen nicht verfälscht werden. Weitere Rollen als die bekannten Scrum-Rollen sind nicht vorgesehen und seines Erachtens auch nicht notwendig. Er warnt davor, bei der Nutzung von Scrum bisherige Management-Rollen beizubehalten oder „Extra Manager“ sogar einzuführen. Alte hierarchische Strukturen lassen sich nicht mit der Nutzung von Scrum vereinbaren.

Ein Auszug aus seinem Buch dazu:

„I visited several Wingtip, Inc. teams at their Sprint Planning Meetings. Strangely, their managers were in attendance. The team members sat in silence, while the managers investigated the work, asked questions of the team members, committed the team to the Sprint goal, and then broke down and assigned the work. No self-management occurred. The productivity and joy of teamwork was forgone.
I investigated and found that 18 first- and second-level managers were still unassigned.“

Scrum Teams organisieren sich selbst und benötigen niemanden, der die Aufgaben vorgibt die zu erledigen sind. Stattdessen benötigen sie Ziele. Die Scrum Teams organisieren sich dann ihr Product Backlog selbst um diese Ziele zu erreichen. Ob diese Ziele erreicht wurden wird (spätestens) im Sprint Review überprüft. Aufbauend auf dieser Inspektion von erreichten Ergebnissen können dann auch notwendige Anpassungen vorgenommen werden. (Prinzip von „Inspect and Adapt“ in Verbindung des „Fail Fast“.)

Die Strategie von Schwaber für eine Skalierung sieht vor, dass der Start mit Scrum mit einem Team erfolgt. Wenn neue Scrum Teams hinzugefügt werden, soll ein Teammitglied des bisherigen Teams (d.h. in der Abbildung aus 1) in die neuen Teams (1.1 bis 1.3) wandern. Das bisherige Scrum Team wird nun zum Integration Scrum Team und ist für die erfolgreiche Integration der Arbeit der anderen Teams in ein qualitativ hochwertiges Produkt verantwortlich. Dazu entwirft das Integration Scrum Team eine tragfähige Architektur, die Coding-Standards und verantwortet weitere notwendige Dinge die natürlich jeweils von dem Produkt abhängig sind.

Bei weiterem Wachstum der Organisation kann eine Skalierung von Scrum mit weiteren Ebenen so aussehen:

Zu beachten ist dabei, dass das Produkt mit fortschreitender Skalierung in immer feinere Ebenen (Product – Function – Activity – Task) auf die Scrum-Teams herunter gebrochen wird.

Zusammenfassung

Schwaber verwendet alle Methoden und Artefakte von Scrum auch bei der Skalierung innerhalb von großen Organisationen. Es werden keine zusätzlichen Rollen oder Artefakte eingeführt. Stattdessen setzt er sehr stark auf die Selbstorganisation der Teams und der Vorgabe von Leitplanken, in dem jedes Team und jeder Einzelne einen sehr großen Handlungsspielraum hat, um die tägliche Arbeit zur Erreichung des Ziels (Produktvision, etc.) zu Planen und zu Organisieren.

Beim Skalieren von Scrum verwendet Schwaber ein initiales Scrum-Team, welches quasi als Keimzelle für einen Ausbau mit weiteren Teams dient.

Auch wenn es Schwaber explizit nicht nennt: Eine Reflektion über das Vorgehen und ggf. Adaption der Zusammenarbeit ist notwendig. Dazu dienen natürlich die Retrospektiven die zu diesem Zweck auch teamübergreifend stattfinden.

Bewertung

Der sehr gradlinige Ansatz von Schwaber beim Skalieren von Scrum ist für alle „Scrum-Puristen“ sicherlich sehr reizvoll. Große Unternehmen werden aber ein Problem damit bekommen, die sehr rigide Vorgehensweise 1:1 umzusetzen. Da Schwaber sehr wenige explizite Vorgaben macht und auf die Selbstorganisation der verantwortlichen Teams setzt, muss eine Skalierung von Mitarbeitern mit sehr viel Scrum-Erfahrung begeleitet werden.

Schwaber zerteilt das Produkt in mehrere Ebenen um den Entwicklungsteams die Möglichkeit zu geben die Product Backlog Items selbstorganisiert und eigenverantwortlich umzusetzen. Auch bei skalierten Scrum soll ein Scrum-Team selbständig die Product Backlog Items umsetzen können (Feature-Teams). Dieser Ansatz stößt meines Erachtens bei großen Produkten irgendwann an seine Grenze da ein Scrum-Team mit 7-9 Personen nicht mehr nicht mehr das notwendige Knowhow besitzen kann.

Ich möchte mich gerne zu Euren Erfahrungen bei dem Einsatz von Scrum in großen Unternehmen austauschen. Welche Probleme traten beim Umdenken von „Command & Control“ hin zu (mehr) Selbstorganisation und Verantwortung auf? Wie wurden die jeweiligen Abhängigkeiten der Teams untereinander festgehalten und geplant? Welche Probleme traten bei der Verbindung zu anderen Teams die nicht Scrum nutzen auf und wie wurden diese gelöst?

Kommentare Willkommen!

Dies war Teil 1 der Serie „Skalieren von agilen Vorgehen“ mit den Ideen von Ken Schwaber. Im zweiten Teil wenden wir uns dem derzeit sehr bekannten „Scaled Agile Framework“ (SAFe) von den Erfindern des Rational Unified Process (RUP) zu.

Beitrag teilen

Gefällt mir

0

//

Weitere Artikel in diesem Themenbereich

Entdecke spannende weiterführende Themen und lass dich von der codecentric Welt inspirieren.

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.