012017

Foto: 贝莉儿 NG

Werkzeuge

Benjamin Wasner

Responding to change over following a plan – Agilität als Einstellung und Scrum als Methode

Gelernt habe ich Theologie und ich bin als Berater und Coach im agilen Kontext bei einem (softwarelastigen) Maschinenbauer tätig. Was das eine mit dem anderen zu tun hat? Alles und nichts: In meinem Beruf spielt Gott keine Rolle, aber ich begleite Menschen dabei, (in ihrem Arbeitskontext) selbstwirksam zu werden und als Subjekte in komplexen Kontexten wertvolle Beiträge zu einem größeren Ganzen zu leisten. Im folgenden Artikel möchte ich aus meiner Sicht die wesentlichen Elemente dessen erläutern, was eine agile Arbeitsweise ausmacht und dies einmal am Beispiel der konkreten Methode Scrum ausbuchstabieren.

Das Wort Scrum („Gedränge“) stammt aus dem Rugby. Scrum als Framework (https://de.wikipedia.org/wiki/Framework) bezeichnet heute eine Methodologie für die agile Entwicklung von Produkten, insbesondere Software. Die Wurzeln von Scrum reichen beispielsweise zum TPS (Toyota Production System) und weiteren Vorläufern zurück, deshalb trifft die Engführung auf Software eigentlich von Beginn an nicht zu. Das Modell konnte dort zwar seine Bekanntheit erlangen, aber seine Anwendung ist längst nicht mehr nur im Softwarebereich üblich und sinnvoll.

Ein prägnanter Blick auf das Wesen und – wie ich finde – auch das Menschen- und Weltbild der Agilität in knappen Sätzen ist im “Agile Manifesto” von 2001 enthalten:

“We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.”1

Wenn wir umgangssprachlich von Agilität sprechen, dann meinen wir damit körperliche und geistige Wendigkeit. Agilität insbesondere im Kontext von menschlicher Kooperation bezieht sich meines Erachtens genau auf die letztgenannte, geistige Wendigkeit. Im Jargon heißt das Ganze dann “agiles Mindset”, also das existentielle Fürwahrhalten (vgl. „Glaube“) bestimmter Prinzipien und Praktiken, wie wir ein Problem in einem bestimmten Umfeld zu einem gewissen Zweck erkennen, analysieren und lösen können, bzw. wie wir einen Berg von Problemen in lösbare und sinnvolle Teile zerbrechen.

Agil planen heißt, die Dinge nicht vom Ende her zu planen, sondern auf ein Ende hin.

In diesem Sinne prägen bestimmte Fragestellungen eine agile Arbeitsweise: Um eine Fährte, einen Entwurf zu bewerten, fragen wir “is it good enough for now?”. Agil planen heißt, die Dinge nicht vom Ende her zu planen, sondern auf ein Ende hin. Planen lässt sich in komplexen Umfeldern ja fast nur “auf Sicht”, alles andere kann man vorbereiten, aber nicht planen. Dieses Ende ist als eine Vision zu denken, die wir jeweils für den Moment durchbuchstabieren, denn weder ist die Zukunft vorhersag-, noch exakt, durch vollständige Kontrolle der Umweltbedingungen, präzise und zielgerichtet gestaltbar. Natürlich gibt es Umfelder, deren geringere Komplexität mit gewissen Erfahrungswerten besser beherrschbar ist, wobei auch hier selten 100 % alles nach Plan verläuft (“nicht nach Plan” bedeutet dabei nicht, dass das Vorhaben ohne Erfolg bleibt!). Die Frage, ob es etwas für den Moment ausreichend sei, hilft uns diszipliniert Entscheidungen jeweils nach gegenwärtigem Wissensstand und mit der minimal “lebensfähigen” Konkretisierung zu fällen. Daneben ist diese Frage auch für den jeweils umzusetzenden Umfang entscheidend. Hier fällt mir das Schlagwort “clean up as you go” ein: Welche Maßnahmen können für ein kleineres Inkrement gesetzt werden, um bestmögliche Qualität, d.h. möglichst wenig Korrekturen in der Zukunft vornehmen zu müssen.

Auf der Suche nach der Wurzel (root cause) eines Sachverhalts gibt uns die Frage “why?” wertvolle Hinweise. Gleichzeitig ist dies auch der Kern der erwähnten Vision. Warum tun wir, was wir gerade tun? Die Vision ist deshalb entscheidend, weil in einer nicht kontrollierbaren Umwelt nur dann produktiv auf eine Veränderung reagiert werden kann, wenn das „wozu“ unseres Tuns transparent ist, also konkrete Entscheidungen und konkretisierte Handlungen mit einem übergeordneten Ziel in Beziehung gesetzt werden.

Ist alles so eingerichtet, dass Fehler möglichst früh erkannt werden?

Kritisch ließe sich einwenden, ob hier nicht die Gefahr einer Verzettelung gegeben sei. Natürlich sind kurzfristige Entscheidungen nicht so langfristig thttp://agilemanifesto.org/iso/de/manifesto.htmlransparent wie ein großer Plan, aber sie haben einen entscheidenden Vorteil: Durch kleinteilige, auf ein größeres Ganzes ausgerichtete Entscheidungen, die möglichst schon in einer minimalen Umsetzung lebensfähig sind, entsteht schnell Fläche, gegen die strukturiert und regelmäßig Feedback eingeholt werden kann. Fehler zu machen ist unvermeidlich, es geht schlicht darum, sie möglichst früh möglichst sichtbar zu machen. Ein Fehler ist eine Abweichung zwischen einem erwarteten und einem tatsächlichen Verhalten bei einem bestimmten Vorgehen, d.h. auch “das haben wir uns anders vorgestellt” ist ein Hinweis auf einen Fehler, einen Bug. In diesem Sinne ist “do you fail fast?” die letzte Fragestellung: Ist alles so eingerichtet, dass Fehler möglichst früh erkannt werden? Werden Fehler, möglichst ohne größere Umbauten, früh bereinigt, werden keine technischen Schulden aufgenommen, d.h. die Kosten des Umbaus und etwaiger späterer Korrekturen sinken oder entfallen.

Auf dem Weg zur Erfüllung einer Vision treffen wir auf Probleme, oder positiver “Herausforderungen”, also Ereignisse, die wir nicht ignorieren können. Probleme werden durch Agilität nicht weniger anspruchsvoll, aber mittels eingangs entfalteten Fragestellungen werden Probleme zerbrochen in lösbare Pakete mit inhärenter Erfolgskontrolle, die qualitativ gut umgesetzt werden. So nähert sich das Verhalten des angestrebten Produkts durch enge Zyklen der Inspektion und Adaptierung schrittweise (“iterativ”) dem gewünschten an. Möglich wird dies durch schrittweises Zusammenfügen (“inkrementell”) von Einzelteilen zu einem jeweils lebensfähigen Ganzen, das jeweils mit jedem Inkrement verifiziert und ggf. korrigiert wird.

Probleme werden durch Agilität nicht weniger anspruchsvoll, aber mittels eingangs entfalteten Fragestellungen werden Probleme zerbrochen in lösbare Pakete mit inhärenter Erfolgskontrolle, die qualitativ gut umgesetzt werden.

Die hier von mir hier skizzierte Dualität zwischen sogenannten “klassischen Projektmanagement” und dem hier insbesondere dargestellten agilen Ansatz ist eine künstliche. In der Praxis werden häufig Mischformen und Ansätze beider Welten zu finden sein, je nach Anforderung. Im beruflichen Kontext kenne ich die Fragestellung “ist dieses Vorgehen oder jenes agil oder gar agiler als ein anderes” sehr gut. Solche Fragen wirklich abschließend zu beantworten, wäre ein klares Anti-Pattern (also ein Ansatz, der schon von Beginn an am Problem vorbeizielt), da jede spezifische Situation einer spezifischen Antwort bedarf, die aus einem breiten Werkzeugkasten auszuwählen ist. Was jetzt und hier das richtige ist, kann man durchaus im Voraus verbindlich festzulegen versuchen, aber Menschen finden Umwege. Scrum (Agilität allgemein) gleicht, ernst genommen, einer öffentlichen Grünfläche, bei der man auf die Anlage von Wegen von vornherein verzichtet. Die Normierung, d.h. dass Anlegen gepflasterter Wege erfolgt genau dann, wenn durch die Trampelpfade ausreichend sichtbar wird, welche Wege tatsächlich von realen Fußgängern in Anspruch genommen werden.

Nach diesen Gedanken lässt sich agiles Arbeiten als wie folgt zusammenfassen: Der Plan deckt nie alles ab, was passieren kann, manchmal rechnet der Plan nicht mit Chancen (aber auch Problemen), die sich ergeben können. Deshalb ist es besser, kleine “Häppchen” mit hoher Qualität zu bauen und rasch zu liefern, die gegen einen klaren Anwendungsfall getestet werden können: Funktioniert es, generieren wir die nächste Idee, funktioniert es nicht, ändern wir es, bis es funktioniert. Fortschritt wird durch funktionierende Produkte gemessen, die Unsicherheit wird schrittweise reduziert. Wenn man strikt einem Plan folgt, bekommt man in der Zukunft, was man in der Vergangenheit geplant hat, wenn man einem Leitstern folgt und diszipliniert, aber mutig und kreativ Entscheidungen in dessen Geist fällt, bekommt man mit signifikant höherer Wahrscheinlichkeit am Ende das, was man auch braucht.

Ganz knapp:
1. Verkürze die Distanz zwischen Problem und Problemlösern.
2. Ersetze Druck durch Sog und Kontrolle durch Vertrauen.
3. Mache kleine Schritte und bewerte diese ehrlich.
4. Korrigiere Fehler, sobald sie erkannt wurden.

Das Scrum-Framework in Grundzügen2

Rollen

Scrum basiert auf dem Dreiklang „Transparenz – Inspektion – Adaption“ und auf drei Rollen, die miteinander arbeiten, um über bestimmte Rituale / Aktivitäten iterativ bestimmte Artefakte inkrementell zu generieren. Auf Deutsch: Es gibt festgelegte Aktivitäten (d.h. Termine), die jeweils in einer Timebox stattfinden. Diese Zeitvorgabe wird sehr ernst genommen. Jeder soll Verantwortung für die optimale Nutzung der Timebox übernehmen, d.h. die im jeweiligen Kontext relevantesten Informationen priorisiert zum Besten geben.

Wenn man strikt einem Plan folgt, bekommt man in der Zukunft, was man in der Vergangenheit geplant hat, wenn man einem Leitstern folgt bekommt man mit signifikant höherer Wahrscheinlichkeit am Ende das, was man auch braucht.

Die Termine dienen entweder dem Zweck, Transparenz herzustellen, also für den Moment einen einheitlichen Wissensstand herstellen, dem Zweck, die so sichtbar gewordenen Informationen zu bewerten oder dem Zweck aufgrund dieser Informationen Veränderungen zu initiieren. Ergebnisse der Termine fließen entweder in Produkt oder Arbeitsweise ein und werden als Artefakt fixiert. An den Terminen sind verschiedene Rollen beteiligt, dies sind im im Einzelnen:

Product Owner

Die erste Rolle ist der Product Owner (=PO), also die Person, die für den geschäftlichen Wert (und damit die Ausgestaltung) eines Produktes verantwortlich ist, die er von verschiedenen Stakeholdern erhebt und harmonisiert. Im Hintergrund kann hier durchaus ein Team agieren, welches ihr oder ihm zuarbeitet, nach außen soll jedoch eine Person accountable sein, d.h. über Einträge und Änderungen am Product Backlog (= Summe aller bereits bekannten oder geahnten Forderungen an ein zu erstellendes Produkt) verantwortlich und rechenschaftspflichtig sein.

Mitglied des Entwicklungsteams

Die zweite Rolle ist die des Mitgliedes des Entwicklungsteams, das für die Umsetzung responsible ist, das Team soll sich selbst organisieren, interdisziplinär / cross-functional aufgestellt sein, also über alle Fähigkeiten verfügen, die zur Erstellung eines Produktinkrements nötig sind. Ungeachtet ggf. einzelnen Teammitgliedern zugeschriebener Domänen obliegt dem ganzen Team die Verantwortung für die erfolgreiche Lieferung von Produktinkrementen.

Um die optimale Teamgröße zu bestimmen, kann man folgende Übung zur Hand nehmen: Mit Pinnadeln repräsentiert man auf einer Pinnwand die beteiligten Personen und verbindet diese mit Linien, beginnend mit zwei Personen. Nach und nach nimmt man eine weitere Person (= Nadel) hinzu und ergänzt die Linien. Ab einer gewissen Personenzahl kippt „viele Linien“, deren Zahl man aber noch einfach erkennen kann gegenüber „Wirrwarr unbestimmter Zahl“. Jede dieser Linien steht für eine Kommunikationslinie, die im Team stattfinden wird. Da Scrum auf eigenständige, sich selbst stabilisierende und wo nötig verändernde Einheiten setzt, ist das genau der Punkt, an dem Kommunikation eher unübersichtlich zu werden droht.

Scrum Master

Die dritte Rolle ist die des sogenannten Scrum Masters, also einer Person, die die wesentlichen Aspekte von Scrum, die Vor- und Nachteile gut kennt und einerseits als Prozessverantworlicher zu sehen ist, aber vor allem als Moderator und Coach im Team, bzw. in Richtung der Stakeholder agiert und für die akute Problemlösung während einer Iteration verantwortlich ist.

Scrum setzt auf eine Kultur, die Veränderungen und Fehler als wertvoll und unvermeidlich wahrnimmt und versucht diese frühzeitig zu erkennen und produktiv zu gestalten.

Der (=PO) hat eine Vision, welche groben Linien das Produkt erfüllen soll und formuliert daraus so genannte Epics, die jeweils einen Teilaspekt auf abstrakte Art beschreiben. Elemente dieser Epics (= Ein Epos ist eine Abfolge von Geschichten) werden nach ihrer Wichtigkeit herausgelöst und in Stories (= Eine Story beschreibt letztendlich das Erleben eines tatsächlichen Anwenders oder einer Anwenderin mit dem Produkt) formuliert. Diese bilden das durch den (=PO) zu priorisierende Product Backlog. Im Idealfall sagt die Story dann nur aus, was geschehen soll, aber trifft keine Festlegungen zum wie, da technische Details so spät als möglich festgelegt werden sollten, damit die Passung zur vorgefundenen Situation möglichst hoch ist.

User Stories

Die User Stories werden häufig aus der Sicht eines konkreten Anwenders (einer “persona”) zur Erfüllung eines konkreten Zieles formuliert:

“As a _________________ I want to _________________, so that _________________.”

Diese Fassung ist zwar nicht in Stein gemeißelt, sorgt aber dafür, dass einzelne Anforderungen (und nichts anderes ist die User Story) der sogenannten INVEST-Regel folgen:
Independent (ohne inhärente Abhängigkeiten zu anderen Items des Product Backlogs),
Negotiable (Raum für Veränderung und Verhandlung bis das Item eingeplant wird), Valuable (stellt Wert für die Stakeholder dar),
Estimable (es muss möglich sein, den relativen Aufwand für die Umsetzung zu bestimmen),
Small (es muss mit einem gewissen Maß an Sicherheit möglich sein, die Anforderung umzusetzen, d.h. begründete Zweifel müssen ausgeräumt sein) und
Testable (alle Informationen die für einen Funktionstest erforderlich sind, müssen enthalten sein).

Die konkrete Anwendung dieser Regel, bzw. die Vereinbarung eines Modus, wann eine Story „good enough“ ist, erfolgt zwischen Team und PO und wird als „Definition of Ready“ bezeichnet. Aufgabe des POs ist es dann, seine Anforderungen dem Team vorzustellen, so dass diese den relativen Aufwand einer Story bewerten können. Dieses Schätzen geschieht in der Regel anhand von abstrakten Bewertungen, beispielsweise Story Points (einer Fibonacci-Folge), durch die Teammitglieder. Es gibt verschiedene Arten, der Bewertung und verschiedene Modi hier zu einem Konsens zu kommen: Eine verbreitete ist das verdeckte Abstimmen mit Spielkarten. Dabei gibt es teamspezifische Faustregeln, ab welcher Übereinstimmung ein Wert als gegeben angenommen wird. Bei einem bestimmten Maß an Abweichung erhalten die differierenden Teammitglieder die Gelegenheit, Stellung dazu zu nehmen, warum sie den Aufwand geringer oder größer als die Mehrheit einschätzen. Je nach Team wird dann ein zweites Mal votiert oder eine einvernehmliche Lösung verhandelt. Damit sollen Stories ganzheitlich beleuchtet werden und „vernachlässigte“ Aspekte eine Stimme bekommen. Das Ergebnis wird an der Story vermerkt und gibt so nach und nach Aufschluss darüber, wie teuer ein Gesamtpaket werden wird.

Sprints

Der Umsetzungszeitraum heißt Sprint und dauert oft 10 Werktage. Aus vergangenen Sprints kennt das Team seine Velocity, d.h. die ungefähr in diesem Zeitraum bearbeitbare Menge an Story Points. Anhand dieses Erfahrungswerten wird dann die entsprechende Arbeitsmenge vom Team vom Stapel abgehoben. Diese Menge heißt dann Sprint Backlog und das Team legt sich auf diese auch fest, d.h. gibt ein sogenanntes Commitment ab. Der Deal ist, dass innerhalb des Sprints möglichst unterbrechungsfrei gearbeitet und zum Abschluss geliefert werden kann. Die technische Konkretisierung der ausgewählten Stories erfolgt ebenfalls im Team. Durch die Invest-Regel sind Stories, die noch zu keinem Sprint zugeordnet wurden grundsätzlich noch verhandelbar. Ungeachtet dessen lässt sich aus einer Velocity und bereits geschätzten Stories eine Dauer bis zur Fertigstellung im Rahmen eines Forecasts angeben.

Es ist üblich geworden, dass Sprints nicht nur eine Ansammlung von Stories darstellen, sondern auch der Sprint an sich ein benennbares Ziel hat, damit wird ein einzelner Sprint zu einer Art Sub-Projekt mit klarer Zielsetzung, an der sich das Team zusätzlich orientieren kann. Während des Sprints trifft sich das Team einmal täglich, um sich gegenseitig zu informieren. In diesem Daily Scrum beantwortet jede/r diese Fragen:

Was habe ich seit dem letzten Daily getan, um unser gemeinsames Ziel zu erreichen?
Was habe ich mir bis zum nächsten Daily dafür vorgenommen?
Welche Hindernisse sehe ich im Moment, unsere Ziele zu erreichen?

Eine gute Timebox für ein Team von 5 Personen ist ca. eine Viertelstunde. In dieser Zeit sollten alle für alle relevanten Informationen geflossen sein und Aufhängepunkte für die spezifische Vertiefung in Kleingruppen erkannt werden. Hier ist es insbesondere Verantwortung des Scrum Masters Probleme, sogenannte Impediments, mitzunehmen und in Richtung einer Lösung zu entwickeln.

Die Bearbeitung der Stories erfolgt dann ungeregelt im Team. Für die qualitätsorientierte Bearbeitung und insbesondere die Fertigstellung einer Story gibt es analog zur „Definition of Ready“ die Vereinbarung „Definition of Done“, die man nach ihrem Umfang als ein „Bauen, verpacken, die Werkstatt aufräumen“ beschreiben könnte, d.h. auch hier liegt Augenmerk darauf, keine Schulden aufzunehmen, sondern „das Ding“ so vollständig wie möglich zu erledigen. Ein Merksatz dazu, insbesondere aus der entfernt verwandten Welt des Kanban: „Stop to start, start to finish.“ (Nicht alles gleichzeitig bearbeiten, lieber eines ordentlich machen.)

Neben dem inhaltlichen Ziel des Sprints gibt es auch ein funktionales: Theoretisch auslieferbare Funktionalität bereitzustellen, auch wenn diese möglicherweise nicht tatsächlich sofort ausgeliefert wird. Aus diesem Grund setzt das Team die Stories so um, dass etwas funktionierendes, d.h. auch „zeigbares“ entsteht: „It is not done until you can demo it.“

Um komplexe Kontexte zu bewältigen sollen Team interdisziplinär aufgestellt sein.

Die Ergebnisse (das Produktinkrement) werden vom Team als Teamleistung am Ende des Sprints öffentlich vorgestellt. Dazu ist das Ritual „Sprint Review“ vorgesehen, einerseits haben die Stakeholder, insbesondere der PO so die Möglichkeit, Fragen und Feedback direkt und in kleinen Zyklen beim Team zu platzieren, bzw. haben auch die Aufgabe die betroffenen Funktionen formal abzunehmen. Im Ergebnis zeigt sich, wie gut die Anforderung geschrieben waren, wie genau sie umgesetzt werden konnten und es entstehen zugleich Ideen für neue Stories oder die Anpassung bestehender, um den Pfad zum höchsten Wert zu finden. Idealerweise hat „Wert“ erst im zweiten Schritt ein Währungskennzeichen und beschreibt in erster Linie den Grad der Unterstützung, den eine bestimmte Funktion einem User zukommen lässt.

In einem weniger öffentlichen Rahmen wird dann im Team die Zusammenarbeit während des Sprints evaluiert, diese Aktivität heißt Retrospektive und dient der Weiterentwicklung und Stabilisierung der Zusammenarbeit im Team und mit den Stakeholdern. Zugleich kann hier Raum sein, technische Aspekte zu diskutieren, dies lässt sich in der Praxis ohnehin nicht wirklich trennen. Retrospektiven dienen vor allem dazu, die Prozessqualität durch Adaption zu verbessern, indem alle Eindrücke und Informationen des Teams verbalisiert und besprochen werden, d.h. das implizite Wissen des Teams regelmäßig wirklich genutzt wird, um Dinge besser tun zu können. Eine Art Methodenkiste für Retrospektiven kann ich besonders empfehlen (https://plans-for-retrospectives.com), man bekommt hier einen sehr guten Eindruck von der Vielfalt der Themenstellung.

Und nach dem Sprint ist vor dem Sprint: Wir beginnen wieder bei der Auswahl der für den kommenden Sprint umzusetzenden Stories. Wurden diese schon zuvor festgelegt, werden sie überprüft und mit den Ergebnissen von Review & Retrospektive kontrastiert. Entsprechend können im Sprint Backlog nun andere oder anders geschnittene Elemente sein.

Fazit:

  • Scrum setzt auf eine Kultur, die Veränderungen und Fehler als wertvoll und unvermeidlich wahrnimmt und versucht diese frühzeitig zu erkennen und produktiv zu gestalten.
  • Scrum definiert Schnittstellen (Rituale), in denen klar definierte Rollen Fortschritte bewerten und jeweils für einen verantwortbaren Zeitraum neue Ziele stecken, lässt die Einzelnen bei der Umsetzung aber frei agieren, dies ermöglicht eine hoch agile Suche nach optimalen Lösungen.
  • Um komplexe Kontexte zu bewältigen sollen Team interdisziplinär aufgestellt sein

Lässt man einmal außer Acht, dass die Sprache von Scrum sehr stark vom Softwaredenken geprägt ist, zeigt sich, dass die beschriebenen Vorgehensweisen leicht auf andere Kontexte zu übertragen sind, in denen Lösungen für komplexe Probleme gefordert werden.

  1. Übersetzung: Manifest für Agile Softwareentwicklung. Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir diese Werte zu schätzen gelernt: Individuen und Interaktionen mehr als Prozesse und Werkzeuge
    Funktionierende Software mehr als umfassende Dokumentation Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung Reagieren auf Veränderung mehr als das Befolgen eines Plans

    Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. (http://agilemanifesto.org/iso/de/manifesto.html)

  2. Beschrieben im Scrum Guide: vgl. https://www.scrumguides.org/docs/scrumguide/v1/Scrum-Guide-DE.pdf