Agile Skaliert – Teil 1

4 Kommentare

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.

Schwaber_Example_Activity-Level

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

Schwaber_Enterprise_Work

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.

 

Artikel von Steffen Thols

Agilität

Agiles Projektmanagement – Ein Antagonismus?

Agile Management

Agile Skaliert – Teil 2

Weitere Inhalte zu Agile Management

Agile Management

Unbequeme Wahrheiten

Agile Management

Planlos agil

Kommentare

  • Thomas Jaspers

    Ein großes Problem (auch aus eigener Erfahrung in einem sehr großen Scrum-Projekt) ist es, am Ende des Tages wirklich Features-Teams zu etablieren. Insbesondere wenn es vorher klassiche Strukturen gab, die sich eigentlich immer entlang der Produktgrenzen bewegen. Eine andere Frage ist es ob das – ab einer gewissen Komplexität der Anwendung – wirklich immer sinnvoll möglich ist.

    Oft wird man dann wohl doch eher bei Produkt-Teams landen, die auf Teile der Anwendung spezialisiert sind. Damit verliert man natürlich ein Stück weit die Möglichkeit zur „Skalierung“, was man ja ggf. durch geschickte Planung (Product Backlog) ausgleichen kann.

    Insgesamt ein spannendes Thema, ich bin schon gespannt auf die weiteren Teile und ob ich Lösungsansätze zu unseren damaligen Problemen erkennen kann. Zu sagen es gibt nur noch die Scrum-Rollen ist natürlich immer leicht daher gesagt aber ggf. auch „ein wenig“ realitätsfern ;).

    • Steffen Thols

      3. Februar 2014 von Steffen Thols

      Hi Thomas!
      Danke für den Kommentar; das Problem sehe ich genau so.
      Das Mantra aller Agilisten „Feature-Teams vor Komponenten-Teams“ ist natürlich berechtigt und im Sinne einer Verantwortungsübernahme über das Ergebnis, nämlich ein komplettes Produkt statt „nur“ die Datenbank-Schicht oder „nur“ die UI, sinnvoll und notwendig. Aber irgendwann ist, wie Du schon schreibst, das Produkt derartig groß und komplex, dass die Feature-Teams nicht mehr ohne weiteres möglich sind. Entweder warten die Entwicklungsteams dann ständig auf Zulieferungen von anderen Teams und kommen mit dem Planen und Verfolgen der (externen) Abhängigkeiten nicht hinterher; ein Committment für ein Feature wird dann im Sprint Planning schwierig.
      Oder man muss das Produkt in möglichst für sich autark entwickelbare Blöcke zerlegen. Dies macht dann aber i.d.R. eine neue Organisationsstruktur notwendig, was wiederum andere Probleme mit sich bringt…

  • Matthias

    3. Februar 2014 von Matthias

    Ein guter Beitrag! Vielen Dank dafür! Mir fällt dazu ein dass es großen Unternehmen auch immer schwer fällt ihre Hierarchien aufzugeben nicht zuletzt weil die Ebenen ihre Position als gefährdet sehen. Das spiegelt sich dann in den Leinen wieder, die den scrum Team Mitgliedern oft regelrecht angelegt werden.

  • Olaf Stichtenoth

    Ich halte es für relativ kritisch, scrum als Dogma zu sehen, dass man nicht verändern sollte. Es ist sicherlich sinnvoll scrum erst mal „clean“ einzuführen um die Vorgehensweise zu verstehen. Aber gerade in der Skalierung trifft man ja immer auf neue relevante Probleme. Dabei würde ich nicht empfehlen sich an die Manifeste oder Methodiken zu klammern, sondern durchaus kreativ (und gerne auch agil) nach Lösungen zu suchen.

Kommentieren

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.