Wenn die Unternehmen mit Softwarelösungen von On-Premise in die Cloud wechseln, setzen sie sich oft das Ziel, “agiler” zu werden. Dies sollte idealerweise für alles auf einer unternehmensübergreifenden Ebene gelten. Und natürlich überall zur gleichen Zeit.
Die Transformation der Prozesse könnte leicht möglich sein, zumindest in der Theorie. Sie können Scrum-Zeremonien definieren und Menschen neue Rollen zuweisen (wie Scrum Master, Product Owner, Delivery Manager und Scrum Teams).
Sie können Tools wie Jira, Azure ADO und Miro Boards einführen und deren Verwendung zur Pflicht machen. Aber was ist mit den Prozessen, die die Tools miteinander verbinden? Was ist mit der Veränderung der Denkweise, der Verhaltensweisen und der Arbeitsweise der Mitarbeiter? Es ist klar, dass diese Veränderungen nicht reibungslos verlaufen und auch nicht schnell abgeschlossen sein werden. Lassen Sie uns nun untersuchen, warum.
Was ist eine Delivery Transformation Initiative und warum machen Unternehmen sie?
Ein großer Teil der Unternehmen arbeitet heute noch nach dem Wasserfallmodell. Das bedeutet Folgendes:
- Planen Sie zunächst, was Sie als Endergebnis/Produkt erreichen wollen und wie viel es ungefähr kosten kann.
- Beginnen Sie mit der Anforderungserhebung, bei der Sie alle Details des Endprodukts gründlich diskutieren, beanstanden, in Frage stellen, vereinbaren, erneut diskutieren und schließlich bestätigen.
- Schätzen Sie das Ganze und bestätigen Sie die Budgeterwartung.
- Entwerfen Sie die Lösung. Führen Sie mehrere Besprechungen mit den Beteiligten durch. Erstellen Sie verschiedene Dokumente und lassen Sie sie von den Beteiligten prüfen. Bestätigen und genehmigen Sie das endgültige funktionale und technische Design.
- Implementieren Sie die Lösung auf der Grundlage des Entwurfs. In dieser Phase entwickeln Sie das vollständige Endprodukt.
- Treten Sie in die Testphase ein und führen Sie verschiedene Arten von Tests durch: Einheitstests, Systemtests, Funktionstests, Integrationstests, Leistungstests, Regressionstests, Benutzerakzeptanztests und möglicherweise viele mehr (je nach Unternehmenskultur). Dokumentieren Sie alles und lassen Sie es von den Beteiligten überprüfen und genehmigen.
- Stellen Sie die Lösung in der Produktionsumgebung bereit. Dies ist der Zeitpunkt, an dem die Zielbenutzer das endgültige und vollständige Produkt verwenden.
- Planen Sie eine Supportphase ein, in der das Entwicklungsteam mögliche Fehler der Lösung korrigiert.
Dieser ganze Prozess kann einige Monate bis einige Jahre dauern, und wie Sie sehen, werden die Benutzer die Ergebnisse erst am Ende dieses Prozesses sehen. Nach der langen Wartezeit kommt also der Moment der Wahrheit (oder des Scheiterns).
Wenn sich während dieser langen Zeit etwas ändert und das Endprodukt ein wenig anders aussehen soll, ist das eine Situation, die man Änderungsantrag nennt. Der Entwurf muss neu aufgerollt, überarbeitet und erneut genehmigt werden. Dadurch verlängert sich der gesamte Zeitplan um einen weiteren Teil.
Das ist natürlich keineswegs agil. Jede Änderung erfordert einen Neustart des gesamten Vorgangs.
Umstellung auf Agilität
Wie können wir also aus dieser Situation herauskommen und sie in eine agile Situation umwandeln? Die Menschen arbeiten seit vielen Jahren oder sogar Jahrhunderten in der Wasserfallstruktur. Sie haben Rollen und Verantwortlichkeiten, mit denen sie vertraut sind, und wollen den Status quo nicht ändern. Der Hauptgrund dafür ist, dass diese Veränderung letztendlich bedeutet, dass sie einen Teil der Macht verlieren, die sie bis jetzt hatten.
Das ist der Hauptgrund, warum eine solche Veränderung bei den Menschen den stärksten Widerstand hervorruft, den Sie nur hervorrufen können.
#1. Umstrukturierung des Teams
Die erste und relativ einfachste Maßnahme ist die Umstrukturierung der Mitarbeiter in Scrum-Teams. Teilen Sie sie auf der Grundlage der Funktionsbereiche oder einer anderen logischen Aufteilung, die Sinn macht.
Die Aufteilung geht in der Regel reibungslos vonstatten; das Problem beginnt, wenn Sie feststellen, dass die Mitarbeiter noch an die ursprünglichen Strukturen gebunden sind. Selbst wenn sie bereits Teil der neuen Scrum-Teams sind, sind sie es praktisch nicht. Sie arbeiten immer noch in der alten Struktur, weil sie immer noch Aufgaben haben, die nicht mit der Umstrukturierung des Teams beendet wurden (warum auch immer – die Führung kümmert sich nicht darum, was fertiggestellt werden muss, sondern hauptsächlich darum, was angefangen werden muss).
Praktisch gesehen haben Sie also ein Scrum-Team, das kein vollwertiges Scrum-Team ist. Es ist eine Gruppe von Leuten, die jetzt einfach mehr Arbeit zu erledigen hat. Es bleibt nicht so viel Zeit für die Arbeit innerhalb des Scrum-Teams, wie das Management erwartet.
Gleichzeitig wird erwartet, dass die Mitarbeiter sowohl ihre ursprünglichen Aktivitäten als auch diese neue Erwartung innerhalb der Scrum-Teams erfüllen. Es ist ein System, das von Anfang an zum Scheitern verurteilt ist.
#2. Scrum-Zeremonien einplanen
Die Teams anzuweisen, mehrere regelmäßige Besprechungen (Sprint Ceremonies) zu planen, ist einfach zu definieren und zu starten. Zumindest unter der Voraussetzung, dass Ihre Scrum-Teams nicht aus Leuten aus 3 Zeitzonen bestehen (was oft der Fall ist).
Das Problem beginnt, wenn die Mitarbeiter nicht regelmäßig an den Zeremonien teilnehmen. Je nachdem, wer fehlt und wie oft, kann dies zu verschiedenen Problemen führen. Zum Beispiel:
- Wenn die Product Owner nicht an den Planungs- und Verfeinerungszeremonien teilnehmen, hat das Team keine neuen Stories, an denen es arbeiten kann. Oder die Beschreibung der Stories ist so schlecht, dass der Rest des Teams nicht mit der Arbeit daran beginnen kann.
- Wenn Scrum Master bei den Calls fehlen, fehlt dem Team die grundlegende Scrum-Orchestrierung und könnte mit der Zeit verloren gehen.
- Wenn die Teammitglieder des Entwicklungsteams häufig fehlen, können sie sich nicht miteinander synchronisieren und die Kommunikation innerhalb des Teams ist viel schwieriger. Außerdem sind mehr Meetings erforderlich, um den Rückstand aufzuholen, was dem Team noch mehr Zeit raubt.
Letztlich ist es nicht unbedingt die Schuld der Mitarbeiter, dass sie die Zeremonien verpassen. Es ist nur so, dass die Einrichtung es ihnen nicht erlaubt, an den Anrufen teilzunehmen (siehe oben über parallele vorherige Aufgaben).
#3. Die Stabilität des Teams
Sie können ein Scrum-Team mit Struktur und Zeremonien haben, aber wenn dieses Team nicht über einen längeren Zeitraum stabil ist – sagen wir, idealerweise mindestens ein halbes Jahr, ein Jahr Stabilität wäre meine persönliche Mindestanforderung – dann kann sich ein solches Team nicht wirklich weiterentwickeln und verbessern.
Außerdem werden Sie wahrscheinlich nie ein völlig unabhängiges Scrum-Team erreichen, das die Sprints wie gewohnt abwickelt. Und schließlich müssen Sie die Menschen im Team ständig weiterbilden, damit sie die Scrum-Mentalität und die Prozesse verstehen. Das ist ein anstrengendes Problem.
Dieses Problem wird sehr unterschätzt, vor allem von der Unternehmensleitung oder dem Management. Die Teams von Mitarbeitern nur als “Ressourcen” zu bezeichnen und ihre “Auslastung” von Quartal zu Quartal zu planen, ist ein Weg in die Hölle.
#4. Neue Rollen für dieselben Mitarbeiter
Ein weiteres Hindernis, das es zu überwinden gilt, ist die Neuzuweisung bestehender Mitarbeiter zu verschiedenen neuen Rollen. Diejenigen, die zuvor Teams mit ultimativer Befugnis geleitet haben, könnten jetzt beispielsweise Product Owner werden. Dies ist zwar eine starke Position in einem Scrum-Team, kann aber im Vergleich zur bestehenden Struktur als eine schwächere Rolle angesehen werden.
Plötzlich müssen sich die Product Owner mit dem Scrum Master oder den Programmmanagern abstimmen. Sie sind immer noch für den Inhalt verantwortlich, aber nicht mehr so sehr für die Lieferprozesse. Diese Situation erfordert den Verzicht auf einige Verantwortlichkeiten, die die Personen zuvor hatten, und ist daher schwer zu schlucken.
#5. Arbeitsweisen
Dies ist ein interessanter Punkt, den ich immer wieder höre: Wir müssen neue Arbeitsweisen erlernen, um auf dem sich entwickelnden Markt, auf dem Agilität die grundlegende Erwartung ist, relevant zu werden. Aber was genau bedeutet das, diese Arbeitsweisen?
Wenn Sie mich fragen, ist es klar, was das Management damit meint – in kürzerer Zeit (viel) mehr zu erreichen. Nach der Einrichtung der Scrum-Teams wird erwartet, dass jedes Teammitglied plötzlich von Tag zu Tag einige dokumentierte inkrementelle Ergebnisse erzielt. Wenn das nicht der Fall ist, wird sich die Führung fragen, warum der agile Prozess nicht gut funktioniert.
Plötzlich erwartet die Führung, dass jede Stunde zählt und dass die Scrum-Teams im Grunde genommen keine Leerlaufzeiten haben, denn dafür ist in den Scrum-Prozessen wohl kein Platz. Und das ist die Definition von “neuen Arbeitsweisen” aus der Sicht der Führung in Kurzform.
Natürlich beruht diese Erwartung nicht auf einem Realitätscheck. Es ist illusorisch zu erwarten, dass die Menschen im Unternehmen innerhalb desselben Zeitraums mehr arbeiten werden, nur weil sich einige alltägliche Prozesse ändern werden. Ich meine, einige von ihnen könnten es, wenn auch nur eine Minderheit. Aber selbst diese Gruppe wird weiter eingeschränkt, indem man sie mit mehr Aufgaben zur gleichen Zeit überhäuft.
Unterschied zwischen Ziel und Wirklichkeit
Zweifellos ist die Beschreibung des Endziels oft gut und macht viel Sinn. Es geht um die folgenden Grundsätze:
- Stabilisierte Scrum-Teams, die an unabhängigen Backlogs mit klaren KPIs und OKRs arbeiten.
- Product Owner, die solide Roadmaps erstellen und priorisierte Inhalte planen, um sie gegen konkrete Zeitvorgaben zu liefern.
- Definierte Backlog-Inhalte mit relevanten Funktionen, die bereits vor Beginn der Arbeit detailliert sind.
- Zuverlässige Testprozesse, die parallel zur regulären Sprint-Entwicklungsarbeit durchgeführt werden.
- Regelmäßige Freigaben für die Produktion – mindestens einmal pro Monat, idealerweise aber nach jedem abgeschlossenen Sprint.
- Verfolgung von Risiken und Problemen und Kommunikation zwischen den verschiedenen Scrum-Teams im Falle von Abhängigkeiten.
In der Realität kann ich dann feststellen, dass keiner der oben genannten Punkte leicht zu erreichen ist.
- Sie bilden die Scrum-Teams, aber sie ändern sich ständig (von Quartal zu Quartal). Sie investieren Zeit, um den Teams die Scrum-Prozesse beizubringen, und wenn sie schließlich beginnen, diese zu akzeptieren und ihre Arbeitsweise zu ändern, organisieren Sie die Teams für die nächste Periode neu. Roadmaps werden geändert, verschoben oder gestrichen.
- Die Product Owner haben keine wirkliche Ahnung von den Details der Roadmaps und (nur weil sie solche Gewohnheiten schon vorher hatten) werden sie ihre Aufgaben zur Erstellung der Backlog-Inhalte direkt an das Team übertragen. Infolgedessen hat das Team keine Zeit, die Inhalte zu entwickeln, da es zunächst herausfinden muss, was es entwickeln soll.
- Die Testprozesse sind rein manuell und erfordern viele Unterschritte, Genehmigungen und komplizierte Prozesse. Das bedeutet, dass die Tests auf keinen Fall im selben Sprint wie die Entwicklung abgeschlossen werden können.
- Infolgedessen verzögert sich die Freigabe für die Produktion um mehrere Sprints.
- Die Kommunikation zwischen den verschiedenen Scrum-Teams ist chaotisch und ineffektiv, da jedes Team in jedem Sprint eine Vielzahl von Aktivitäten zu bewältigen hat. Tatsächlich neigen die Product Owner dazu, dem Team in jedem Sprint zu viele Inhalte zuzuweisen. Es besteht keine Chance, dass das Team alles schaffen kann, so dass es ständig unter Termindruck steht.
Die Fehler korrigieren
Aus meiner Erfahrung mit einigen agilen Transformationsprojekten möchte ich einige der größten Fehler zusammenfassen, die ich erlebt habe, und einige subjektive Meinungen dazu abgeben, wie man sie überwinden kann.
#1. Die richtigen Verantwortlichkeiten für die richtigen Rollen
Wenn Sie versuchen, die Definition zu verbiegen und die Verantwortlichkeiten anders zu verteilen, als sie nach Scrum/Agile sein sollten, bringen Sie die gesamte Initiative zum Scheitern.
- Die Product Owner sind für den Inhalt und die Pflege des Backlogs verantwortlich. Sie sind für die Backlog-Stories verantwortlich, und wenn die Backlog-Stories nicht gut definiert sind, liegt es an ihnen, Maßnahmen zu ergreifen und das Problem zu beheben. Andererseits sollten sie keinen Einfluss auf die Zuweisung von Scrum-Team-Mitarbeitern oder Entscheidungen über das Projektbudget haben.
- Scrum Master sollten keine Verantwortung für den Inhalt des Backlogs tragen. Sie sind im Team, um die Zeremonien zu orchestrieren und das Team in einer agilen Arbeitsweise zu schulen. Sie sollten keine Sekretärin für Product Owner sein. Im Gegenteil, sie sollen das Entwicklungsteam vor dem Product Owner und externen Stakeholdern schützen.
- Jedem Scrum-Team sollte ein Delivery Lead zugewiesen werden. Diese Person verbindet den PO, den SM und das Entwicklungsteam zu einer funktionierenden Struktur, definiert die Lieferprozesse und löst alle potenziellen Risiken, Probleme oder Konflikte, die das Team haben könnte. Der Delivery Lead ist die richtige Person, um über die Personal- und Budgetfragen des Projekts zu entscheiden. Diese Person ist bestrebt, für das Team ein Umfeld zu schaffen, in dem jeder sein Bestes geben kann.
- Die Aufgabe des Entwicklungsteams ist es, die Stories aus dem Backlog zu entwickeln. Sie können PO bei der Erstellung von Inhalten für einige Storys helfen (vor allem bei denjenigen, die zu technisch sind), aber sie sind nicht für die Erstellung von Inhalten für die Roadmap verantwortlich oder sogar rechenschaftspflichtig.
#2. Stabiles Team
Es ist wichtig, in die agile Ausbildung des Teams zu investieren, und das muss ein schneller Prozess sein. Wenn Sie dieses Wissen alle paar Monate verschwinden lassen, ist das für alle Beteiligten reine Zeitverschwendung.
Die ersten fünf Sprints können Sie als Lernkurve für das Team nutzen, um die grundlegenden Scrum-Aktivitäten kennen zu lernen und zu üben. Sobald diese für das gesamte Team klar sind, kann der kontinuierliche Verbesserungsprozess des Scrum-Teams beginnen. Wenn jedoch die Personen innerhalb des Teams regelmäßig wechseln, werden Sie sich in einer ständigen Schleife von Wissenstransfer und Weiterbildung wiederfinden.
Ein solches Team wird wahrscheinlich nie sein volles Leistungspotenzial erreichen, und das Führungsteam wird sich weiterhin fragen, warum es früher (vor der agilen Transformation) effizienter war als es jetzt scheint.
Bauen Sie also das Team auf, investieren Sie das Wissen, und sobald das Team mit den neuen Prozessen vertraut ist, lassen Sie es einfach so, wie es ist, und entwickeln es weiter. Von hier aus wird der ständige Weg zur Perfektion beginnen.
#3. RACI-Matrix
Es ist eine gute Praxis, die RACI-Matrix (Responsible, Accountable, Consulted, Informed) zwischen allen Teams zu erstellen und zu vereinbaren, kurz bevor die eigentliche Arbeit beginnt. Dies kann möglicherweise eine Menge Verwirrung gleich zu Beginn beseitigen.
Vor allem in der Anfangsphase der Transformationsinitiativen ist dies sehr wichtig. Andernfalls werden die Mitarbeiter anfangen, Fragen darüber zu stellen, wer in welcher Situation was tun sollte, insbesondere in den Fällen, die nicht ausdrücklich in der Kommunikation des Teams angesprochen wurden.
Hier ist ein Beispiel für eine solche RACI-Matrix für einige der Verantwortlichkeiten. Ihr Projekt kann eine andere Matrix haben. Es ist wichtig, die relevanten zu erfassen.
| Aufgabe | Antragsteller | Leiter der Lieferung | Product Owner | Scrum-Meister | Entwicklungsteam |
|---|---|---|---|---|---|
| Sprint-Planungssitzungen | K/I | C | A/I | R | K/I |
| Release-Inkrement liefern | N/A | I | A/I | K/I | R |
| Sprint Überprüfung | K/I | I | R | I | C |
| Sprint Rückblick | I | I | A/I | R | K/I |
| Verfeinern Sie den Backlog | I | A/I | R | A | K/I |
Fazit
Es gäbe noch viel darüber zu schreiben, denn es gibt viele Wege und viele Stellen, an denen die agile Transformation vom Weg abkommen kann. Der Zweck war, auf einige der Probleme hinzuweisen, die sich meiner Meinung nach häufig wiederholen.
Die Initiative selbst ist eine gute Idee. Sie kann jedoch schnell zu einem Albtraum für alle Beteiligten werden, wenn man einige Grundregeln nicht beachtet. Ich habe ein paar davon hervorgehoben, aber benutzen Sie einfach Ihren gesunden Menschenverstand, dann wird alles gut 🙂
Als nächstes sollten Sie sich gute Lernressourcen für die Agile-Zertifizierung ansehen.