Agile / Anforderungsmanagement / Projektmanagement / Software-Entwicklung

Scrum – die Starrheit der Agilität

Scrum: agil, flexibel und doch starr? Die Antwort lautet: Ja, aber… Ich möchte Ihnen mit diesem Blogeintrag diese Starrheit der Agilität veranschaulichen. Dabei setze ich den Fokus auf die Methodik, Rollen und Modalitäten in der Praxis und möchte Ihnen Impulse mitgeben, wenn Sie das nächste Mal vor der Frage stehen: „Scrum oder klassisch?“

bald-eagle-550804_1280_740

„Machen wir es mit Scrum oder klassisch?“

Als Projektleiter und Scrum Master sitze ich oft in Projekt Kick Off Meetings in denen eine wesentliche Entscheidung getroffen wird. Eine Entscheidung, die den gesamten Verlauf des Projekts beeinflusst. Eine Entscheidung, die durchaus auf den Erfolg oder Niederlage eine große Auswirkung hat. Die Entscheidung der geeigneten Vorgehensweise, der geeigneten Methodik oder auf Neudeutsch: für welches Framework entscheiden wir uns? Nach der obligatorischen Vorstellungsrunde kommt dann auch schon die gefürchtete Frage aus der zweiten Reihe: „Machen wir es mit Scrum oder klassisch?“. Viele Teilnehmer wissen, dass diese Frage zwar immer wieder kommt, aber was bedeutet diese Frage eigentlich bzw. welche Auswirkungen kann eine übereilte Antwort haben? Zunächst sollte erwähnt werden, dass die die Frage eigentlich falsch ist. Die Frage sollte eher lauten: „Machen wir innerhalb des Projekts Teilgebiete agil oder alles im klassischen V-Modell?“.

 

Agile Vorgehensweise innerhalb von Projekten

Scrum ist ein agiles Framework, das für die Softwareentwicklung bzw. Produktentwicklung gedacht war und noch immer ist. Scrum ist keine Projektmanagementmethode. Außerdem müssen die Rahmenbedingungen passen und das Unternehmen, das dieses Projekt umsetzt, eine agile Vorgehensweise unterstützen. Leider wird heutzutage Scrum oder Agil – viele Personen sehen darin keinen Unterschied – als Sündenbock für fehlgeschlagene Projekte hergenommen. Oft stimmt es auch, dass genau solche „Scrum Projekte“ scheitern und im Endeffekt hohe Kosten erzeugen und nicht fertig werden. Dies liegt aber nicht an der Methodik oder am Framework. Die Antwort ist viel komplexer. Einige Faktoren können sein: fehlendes Know-How der ausführenden Personen, kein Top Down Support seitens dem Management, die Firmenkultur sieht agil nicht vor, Missinterpretation der Methodik und noch vieles mehr; die Liste ist sehr lange. Es sind Menschen, die involviert sind und mit ihnen steht und fällt der Erfolg bzw. Misserfolg.

„Aber oft scheitert Scrum, weil es zu flexibel ist, keine klaren Ziele vorgibt und auch der Inhalt unklar ist. So kann kein Projekt erfolgreich sein!“. Diese Aussage ist schlichtweg falsch. Nur weil das Framework auf einem A4 Blatt beschrieben werden kann, heißt es noch lange nicht, dass es einfach in der Umsetzung ist.

Jetzt höre ich erneut die Stimme aus der zweiten Reihe: „Aber ich bin doch zertifizierter Scrum Master, ich weiß wie das geht“. Natürlich ist eine Zertifizierung gut, aber ausschließlich ein fundiertes Basiswissen über das agile Manifest und den Methoden bzw. Frameworks zu haben, heißt noch lange nicht ein Scrum Team mit strikt vorgegeben Regeln und eingeschränkter Flexibilität zum Erfolg zu bringen.

washington-80382_1280_740

Scrum & Ich

Auch ich habe nicht als Scrum Master angefangen. Ich komme aus der klassischen Projektleitung und für mich waren damals Use Cases und User Stories auch dasselbe, wobei die User Stories zugegebenermaßen netter formuliert waren. Erst als ich mehr mit einem Scrum Team zu tun hatte, hatte ich die Stärke des Frameworks an sich verstanden. Zu diesem Zeitpunkt wurde ich als IT-Projektleiter punktuell zu den Meetings eingeladen, dennoch war es mir anfänglich schleierhaft wozu all diese Meetings notwendig sind. Zusammensitzen und immer wieder über den Inhalt zu reden und in einer Retrospektive über Geschehenes zu reflektieren? Nein das ist nicht effizient, in dieser Zeit könnte man doch produktiv arbeiten, wir sind doch alle mündige Erwachsene. Übrigens, Sie glauben nicht wie oft ich diesen Satz mittlerweile von unterschiedlichen Hierarchieebenen schon gehört habe. Und genau hier liegt der Denkfehler. Als IT-Projektleiter war ich zwar involviert, aber ich war nicht Teil des Scrum Teams. Dennoch lies mich die Faszination von Scrum nicht los und ich vertiefte mein Wissen in der Materie, sprach mit etlichen Scrum Mastern und Product Ownern und machte mir selbst ein Bild davon.

Nach zwei Jahren IT-Projektleiter und Scrum Master-Vertretung wollte ich letztendlich ein eigenes Scrum Team als Scrum Master begleiten. Ich klärte alle Rahmenbedingungen, holte mir das finale Commitment vom Management und startete mit meinem neuen Scrum Team ab Sprint 0.

Schnell wurde mir klar: Scrum ist ein riesengroßes Puzzle. Fehlt auch nur ein Teil ist es nicht mehr ganz. Und dann kam der gedankliche Wendepunkt. Nach Sprint 3 wurde mir bewusst, dass agil nicht flexibel bedeutet. Eigentlich ist Agilität in diesem Kontext relativ starr. Das Framework an sich ist kaum beweglich, wenn man es konsequent durchzieht und richtig anwendet. Und darin liegt aber die Stärke. Die Belohnung bekommt man in Form von Effizienz, hohe Performance des Teams, Transparenz und hoher Qualität des Produkts.

 

Starre Rollen?

Deshalb sind auch die vorgesehenen Rollen in Scrum eigen und speziell innerhalb des Frameworks aufeinander abgestimmt.

Der Scrum Master ist dafür zuständig, dass die Methodik eingehalten wird. Er trägt die Verantwortung, dass das Team sich an die Spielregeln hält. Er ist Mentor und Psychologe des Teams und hält die schützende Hand über das Team. Einerseits ist er dafür verantwortlich, dass das Team optimal performed, andererseits muss er auch realistisch bleiben und seine Bedenken auch außerhalb des Teams kommunizieren. Um diese Tätigkeiten pflichtbewusst und erfolgreich durchführen zu können, ist es unumgänglich einen Vollzeit Scrum Master für ein Team zu verpflichten.

Der Product Owner hingegen wird vom Scrum Master durch den Prozess geleitet. Ihm wird der Rücken freigehalten, damit er sich inhaltlich vollends auf das Produkt und dessen Entwicklung konzentrieren kann. Dabei wird er vom gesamten Team in den vordefinierten Meetings unterstützt, damit auch die Effektivität hochgehalten wird.

Die restlichen Teammitglieder werden aufgrund des Produkts definiert. Meistens beinhaltet es Frontend- und Backend Entwickler, sowie Tester. Auch diese Teammitglieder haben ihre vordefinierten Rollen. Das Framework sieht zwar vor, dass alle Teammitglieder die Rollen der anderen besetzen können, jedoch ist es in der Praxis kaum möglich.

Auch die Rollen widerspiegeln die Starrheit des Systems: sie sind fix definiert, fernab von agil.

 

Wir wollen aber agil sein; alle sind agil!

Wozu sollten wir Scrum verwenden, wenn es nur starr ist und weit entfernt davon agil zu sein? Auch dieses Missverständnis möchte ich klarstellen. Das agile Manifest stellt den Kunden in den Fokus. Das fertige Produkt soll dem entsprechen, was sich der Kunde vorstellt. Hier geht es nicht um die Agilität respektive Flexibilität des Teams, des Unternehmens oder der Firmenkultur. Agile Methoden wie Scrum, Kanban und andere Frameworks dienen ausschließlich dazu ein Ziel effizienter und effektiver zu erreichen. Ist der Kunde zufrieden wird er weiterhin bei Ihnen einkaufen. Klingt simpel, ist es auch. Die Agilität und Flexibilität sind nur Mittel zum Zweck. Das Endprodukt, das betriebswirtschaftlich natürlich mit einem hohen Gewinn verkauft werden soll, ist DAS was schlussendlich für das Unternehmen zählt, nicht die Methodik.

 

graph-963016_640

Was versteht man jetzt unter starrer Agilität?

Um diese Frage zu verstehen, sehen wir uns am besten den Ablauf einer Scrum Entwicklung an. Gehen wir davon aus, dass zweiwöchentliche Sprints definiert wurden. Innerhalb der zwei Wochen soll es keine Änderungen in den umzusetzenden User Stories geben. Innerhalb der zwei Wochen weiß jedes Teammitglied genau was zu tun ist. Innerhalb der zwei Wochen gibt es ein Scope Commitment, das anhand von User Stories vorher geschätzt und für die eine Implementierung definiert wurde. Diese Stories werden umsetzt, getestet und am Ende des Sprints abgenommen. Diese Punkte sind Fakt. Hierbei ist das Framework auch nicht flexibel. Alle vordefinierten Meetings werden durchgeführt. Daily Stand-Ups finden jeden Tag für 15 Minuten statt, timeboxed, kein Raum für Diskussionen. Metriken, wie zum Beispiel Burn-Up, Burn-Down oder Velocity Charts können jederzeit generiert werden. Die Transparenz ist extrem hoch und wird durch exakte Statistiken untermauert. Dies resultiert aus einer strikten Anwendung des Scrum Frameworks. Offensichtlich ist der korrekte Einsatz von Scrum strikt und fernab von flexibel oder agil. Diese Aussage stimmt nur zum Teil, denn das Regelwerk von Scrum ist starr, die Gestaltungsmöglichkeiten agil.

 

Warum sind die Gestaltungsmöglichkeiten agil?

Die Agilität und Flexibilität widerspiegelt sich in der Gestaltung des Scopes, des Backlogs. Der Backlog ist die Sammelstelle für alle Anforderungen in Form von User Stories. Diese Stories werden durch den Product Owner definiert und gemeinsam mit dem Team geschätzt und besprochen, damit es für die Umsetzung im Sprint dann keine Unklarheiten mehr gibt. Vor dem Sprint können diese sogenannten Backlog Items entfernt, neue hinzugefügt und anders priorisiert werden. Der Product Owner ist sehr flexibel in deren Gestaltung. Die Verantwortung ist sehr groß. In dieser iterativen Phase entsteht das eigentliche Produkt. Doch auch hierbei unterstützt das strikte Framework den Product Owner. Fix definierte Meetings, wie z.B. das Estimation Meeting oder Planning, in dem User Stories vorbereitet und für den übernächsten Sprint geschätzt werden, geben dem Product Owner und dem gesamten Team den Gestaltungsraum für flexible inhaltliche Entscheidungen.

Und genau das sind die agilen Aspekte innerhalb von Scrum. Der Fokus liegt hierbei auf der Vorarbeit, der Verfeinerung und der finalen Zustimmung zu den User Stories. Dies wird fixiert, alle stimmen zu, ohne Ausnahme. Das gesamte Team committet sich zu der Umsetzung im nächsten Sprint. In den kommenden zwei Wochen werden diese Anforderungen umgesetzt, getestet und durch den Product Owner abgenommen.

Die Erfolge werden dann in einem Sprint Review jedem gezeigt, der Interesse an dem Projekt hat; das Review ist mit einer Kinovorstellung zu vergleichen. Das Auditorium lehnt sich zurück und sieht den Output der letzten zwei Wochen, danach wird diskutiert. Dabei wird positives, sowie kritisches Feedback angenommen und notiert.

Darauf folgt dann in der Regel eine teaminterne Retrospektive, in der das Team überlegt was im letzten Sprint gut war, was als verbesserungswürdig angesehen wird und wie diese Verbesserungen als Team durchgeführt werden können. Dieser Termin ist meiner Meinung nach einer der wichtigsten im gesamten Framework, da es den Teamzusammenhalt stärkt, die Performance für die nächsten Sprints verbessert und dem Scrum Master einen Einblick über das Scrum Team und dessen Zusammenhalt gibt. Die Retrospektive ist letztendlich auch der Abschluss des Sprints. Alle offenen Punkte sollten abgeschlossen sein, damit das Team mit frischem Elan in den nächsten Sprint gehen kann.

 

Fazit

An dieser Stelle möchte ich meinen Eintrag mit folgenden Zeilen beenden: Agilität funktioniert sehr gut, wenn sich das Team an starre Regeln und Abläufe hält, die durch das Framework vorgegeben werden. Diese Starrheit unterstützt das gesamte Scrum Team, um Anforderungen agil, flexibel und iterativ zu definieren und umsetzen zu können.

Ich hoffe, dass ich Ihnen einen praktischen Einblick über die Methodik Scrum und den notwendigen Rollen und Modalitäten, sowie die Starrheit der Agilität veranschaulicht habe. Vielleicht behalten Sie die eine oder andere Passage im Kopf, um beim nächsten Mal, wenn die Frage aufkommt: „Machen wir es mit Scrum oder klassisch?“ die für Sie richtige Entscheidung treffen können.

 

Passende Artikel

4 Kommentare

  1. Hallo Christian,

    zuerst gratuliere ich zu deinem fundierten Artikel. Deinen beiden Kernaussage, dass einerseits „Starrheit“ in deinem Sinne und die praxisnahen Einsichten zu den „agilen Gestaltungsmöglichkeiten“ werden in der Mainstream Literatur selten genug derart betont. Ein zwei Anregungen und Gedanken gestatte ich mir hier zu hinterlassen. Wie du weißt geht es in meiner Artikelserie zur Agilität um fundamentale Kritik. Ich bin tief davon überzeugt, dass Kritik der einzige rationale Weg ist, um Methoden, Arbeitsweisen etc. tatsächlich weiterzuentwickeln, oder wenigstens ein optimiertes Pro und Contra Picture zu bekommen. Daher gestatte ich mir die Frage, warum du nicht auch einen Deep Dive genau auf diese Aspekte machtst?

    Viele Grüße
    Roland

    • Christian Eggbauer Christian Eggbauer sagt:

      Hallo Roland,

      danke für dein Interesse an meinem Artikel. Kritik (egal ob positive oder negative) ist immer gut – nur so lernt und verbessert man sich. Ich habe noch viele Ideen und Gedanken in petto, die ich im agilen Umfeld als Blog veröffentlichen will. Deine Idee ein Pro- und Contra-Picture finde ich gut. Ich werde versuchen diese Anregung in den nächsten Artikeln zu verarbeiten.

      lg
      Christian

  2. Martin Lemanski sagt:

    Hi,

    sehr schöner Artikel.

    Ich hab folgendes gelernt: http://martinfowler.com/bliki/ShuHaRi.html
    Im Prinzip beschreiben Sie den Shu Zustand, alles so machen wie es im Handbuch steht.

    In dem Fall aus Team angewendet:
    [quote]
    The idea is that a person passes through three stages of gaining knowledge:

    Shu: In this beginning stage the student follows the teachings of one master precisely. He concentrates on how to do the task, without worrying too much about the underlying theory. If there are multiple variations on how to do the task, he concentrates on just the one way his master teaches him.
    Ha: At this point the student begins to branch out. With the basic practices working he now starts to learn the underlying principles and theory behind the technique. He also starts learning from other masters and integrates that learning into his practice.
    Ri: Now the student isn’t learning from other people, but from his own practice. He creates his own approaches and adapts what he’s learned to his own particular circumstances.
    [/quote]

    Leider erlebe ich immer wieder, dass manche Teams das überspringen und gleich zu Ri gehen, ohne die Grundlagen ausreichend zu können. Da sehe ich immer das großte Problem.

    LG, Martin

    • Christian Eggbauer Christian Eggbauer sagt:

      Hallo Herr Lemanski!

      Danke für ihr Kommentar. Ich sehe es genauso. Die Rahmenbedingungen der Methodik zu verstehen ist relativ simpel. Die Bedeutungen der jeweiligen Rollen, Meetings etc. und deren Zusammenspiel für die funktionierende Gesamtheit wird leider meistens vernachlässigt. Das direkte Springen zum Ri ist natürlich nicht sinnvoll und ich bin davon überzeugt, dass man – bevor man als Scrum Master aufs Feld geht – einen erfahrenen Mentor braucht (oder man wächst aus einem Scrum Team Mitglied zum Scrum Master und nimmt das ganze Scrum Team als Mentor). In beiden Fällen ist es aber notwendig, dass man es korrekt gelehrt bekommt, indem es auch korrekt gelebt wird.

      Lg, Christian E.