„Scrum is a tool to change the world!“ Jeff Sutherland, einer der Begründer von Scrum, hat diesen Satz einmal gesagt und die Kollegen vom Scrum Day haben ihn sich dieses Jahr groß auf ihre Fahnen geschrieben. Eines der „geheimen Mottos“ des diesjährigen Scrum Day 2019 kam aber von einem anderen prominenten Vordenker der Agilen Community: Daniel Mezick.
„Agile, in essence, is about decentralising decision rights. Thus, we should understand Scrum as a specific system of decision rights“ (Daniel Mezick)
Daniel Mezick, der am Rande der Konferenz auch zwei Trainings zu „Open Space Agility“ und zu „Inviting Leadership“ gab, betonte in seiner Keynote ganz zu Beginn des Scrum Days: „Agilität bedeutet im Kern eine Dezentralisierung von Entscheidungsrechten.“ In der Hauptsache beschreibt der Scrum Guide also nicht eine wiederkehrende Abfolge von bestimmten Regelterminen wie Planning, Daily, Review, Retro. Vielmehr ist Scrum ein sehr durchdachtes und ausgeklügeltes Teamarbeits- und Teamkommunikationssystem zur Entwicklung komplexer Produkte, wie etwa Software.
Dem zugrunde liegen drei Rollen – Entwicklungsteam, Scrum Master und Product Owner – zwischen denen kein hierarchisches Gefälle besteht. Entscheidungsrechte liegen dabei nicht, wie in klassischen Strukturen oft üblich, zentral bei einer Person, sondern sind zugunsten der Effektivität auf die verschiedenen Rollen verteilt. Das Entscheidungsrecht über die Priorisierung der fachlichen Anforderungen etwa liegt beim Product Owner, während das Recht die technische Umsetzung der Anforderungen zu planen und die Aufgaben auf die Mitglieder zu verteilen beim Entwicklungsteam liegt.
In seiner Keynote präsentiert Daniel Mezick schließlich einige Antipattern, die dezentrale Entscheidungsrechte nachhaltig untergraben und damit auch Scrum Implementierungen im Unternehmen unterminieren. Zu diesen negativen Handlungsmustern gehören:
Imposition: Menschen und Teams im Unternehmen bestimmte Arbeitssysteme und Prozesse auferlegen, statt sie diese zielorientiert selbst bauen zu lassen
Delegation or dictation: Einzelnen Menschen Aufgaben zuweisen – zum Beispiel in einem Push-System – statt dass Teams gemeinsame Aufgaben selbstorganisiert in der Gruppe bearbeiten
Lack of clear authority: Unklarheit und Intransparenz in den Rollen anstelle klarer und zielorientiert verhandelbarer Aufgaben, Kompetenzen und Verantwortungen.
No clear boundaries: Unklarheit über das Handlungsfeld von Teams, anstelle klarer und zielorientiert verhandelbarer Autonomiegrenzen
Lack of shared signals: fehlende gemeinsame Rituale, Signale, etc.
Closed-door-decisions: Diskussionen und Entscheidungen hinter verschlossenen Türen, anstatt offener Gesprächsrunden – z.B. nach dem „The Right People“ Konzept.
Ad hoc Approach: Ad-hoc-Ansätze, bei denen die betroffenen Menschen nicht einbezogen werden
Siloed Knowledge: Wissen, das sich nur auf einzelne Gruppen im Unternehmen erstreckt – nach dem Motto „Leserechte bekommt nur, wenn es einen triftigen Grund dafür gibt“ – anstelle von unternehmensweit frei zugänglichen Informationen – nach dem Transparenzmotto „Jeder hat Leserechte, außer es gibt triftige Gründe dafür diese Rechte einzuschränken“
Dan Mezicks Fazit: Firmen, die zwar die im Scrum Guide aufgeführten Regelmeetings implementieren, die Entscheidungsrechte aber unberührt lassen – zum Beispiel in dem Sie weiterhin Projektleiter mit den „klassischen“ formalen Entscheidungsrechten ausstatten – arbeiten nicht nach Scrum. In vielen Fällen ‚verschlimmbessern‘ sie sogar ihre Prozesse, frustrieren ihre Mitarbeiter und erzielen weniger statt mehr Produktivität.
„If you don’t want to improve, don‘t implement Scrum!“ (Daniel Mezick)
Warum dezentrale Entscheidungsrechte tatsächlich eine gute Idee sind, illustriert wiederum Jeff Sutherland in seiner Keynote. Das Stichworte lautet „Decision Latency“. Dahinter verbirgt sich u.a. eine Studie der Standish Group, nach der der Erfolg von Softwarevorhaben nachweislich davon abhängt, wieviel Zeit vergeht, bis zu einem ungeklärten Sachverhalt eine Entscheidung gefällt ist. Je länger der Entscheidungsweg umso höher die Wahrscheinlichkeit, dass das Softwarevorhaben scheitert, die Kosten explodieren, Termine nicht gehalten werden können, etc.
Daher ist es auch in der „klassischen“ Softwareentwicklung eine gute Idee, Entscheidungsrechte zu dezentralisieren. Für agile Teams ist dies jedoch essentiell. Da mit jeder Entscheidung immer auch gewisse Risiken verbunden sind – egal ob im agilen oder im „klassischen“ Kontext – arbeiten agile Teams übrigens empirisch und mit kontinuierlicher Verbesserung.
Comments