Dieser Beitrag widmet sich beliebten Missverständnissen und überholten Interpretationen agiler Rahmenwerke. Sie beinträchtigen bis heute die Erfolgsgeschichte des "agilen Manifestes" und darauf aufbauende Rahmenwerke und verdienen deshalb entsprechende Aufmerksamkeit. Die Hinweise enthalten Verweise auf Abschnitte im aktuellen "Scrum Guide" von Jeff Sutherland und Ken Schwaber, siehe Link am Ende des Beitrags.
Agile Rahmenwerke machen Führung und Planung obsolet
Die Abschnitte über "Scrum-Theorie" - vgl. "empirische Prozessteuerung", der Abschnitt "Der Product Owner" und "Der Scrum Master" im Scrum Guide und die an diversen Stellen des Guides beschriebenen Planungsaufgaben demonstrieren, daß agile Methoden Planung und Führung nicht dem Zufall und der naiven Hoffnung auf eine sich automatisch einstellende "Selbstorganisation" überlassen. Der wesentliche Unterschied zu älteren Management Rahmenwerken besteht in der konsequenten Förderung der Selbstorganisation und Eigenverantwortung in Bereichen, wo sie eingespielte Teams nach einiger Zeit wie selbstverständlich übernehmen können.
Im agilen Manifest wird zu Recht der Wert "Reagieren auf Veränderung" über den Wert "Befolgen eines Plans" gestellt, ohne das die Bedeutung von Planung in Abrede gestellt wird. Agile Rahmenwerke sind der emprische Prozessverbesserung verpflichtet, die ohne überprüfbare Ziele aus vorangegangener Planung nicht denkbar wäre. Das "Befolgen" eine Planes stellt für sich alleine keinen Wert dar. Zudem lebt die Idee der "kontinuierliche Verbesserung" von der Erkenntniss, dass Planung in der Praxis nach wenigen Minuten überholt ist. Trotzdem ist ein Mindestmaß an Planung erforderlich, z.B. um kurzfristige gemeinsame Ziele festzuhalten (vgl. z.B. "Sprint Vision"), und damit überhaupt eine Abweichung feststellbar ist.
Auch längerfristige Planung, z.B. eine grobe Release-Planung ist bei Vorhaben mit Abhängigkeiten zu anderen Projekten und externen Vorgaben unverzichtbar zur Überprüfung, ob aktuell erkennbaren Trends (z.B. Velocity des Entwicklungsteams) für oder gegen die Einhaltung extern vorgegebener Ziele sprechen.
Scrum funktioniert nur mit prägnanten Anforderungen auf Story Cards, der Rest wird mündlich geklärt
Die Abschnitte "Das Product Backlog" und "Das Sprint Backlog" im Scrum Guide stellen einerseits klar, dass diese Backlogs "als einzige Anforderungsquelle für alle Änderungen am Produkt" zu verstehen sind, und folglich in der geforderten "Beschreibung" einerseits die für den kommenden Sprint aufbereiteten Anforderungen enthalten, wie auch entsprechende Planungsinformationen zur Verfolgung des Fortschrittes.
Während ältere Scrum Guides den "Auftrag zur Konversation über Anforderungen" mehr betonen, wird in der modernen Fassung des Scrum Guides festgelegt, dass die Backlogs Einträge für den kommenden Sprint, und das kurze Sprint Planning sowie der vorangegangene Sprint Review im Team ausreichendes Verständnis für Design und Umsetzung im Sprint bereit stellen müssen.
Der Abschnitt über das "Team" und das "Inkrement" lässt zudem keine Zweifel offen, dass professionelles Arbeiten und marktübliche Qualität erwartet wird, zu der bei komplexen Software-Produkten eine angemessene Dokumentation der Deployment-Artefakte, APIs, Daten und der grafischen Benutzeroberflächen für den Betrieb und die Endbenutzer zählt, soweit diese Information nicht aus dem qualitativ hochwertigen Code ableitbar ist. Ohne ein Mindesmaß an strukturierten Anforderungen zusätzlich zum Code, wird z.B. die Beurteilung von späteren Changerequests durch fachliche Ansprechpartner, das Redesign von Produkten (z.B. Aufteilung) und die Übergabe an ein neues DevOps Team schwierig, wenn das Produkt eine gewisse Komplexität (z.B. > 200 Stories) aufweist.
Scrum funktioniert nur mit Wegwerf-Anforderungen, die am Projektende entsorgt werden
Dieses Missverständis entspringt Wunschdenken und einer Fehlinterpretation des agilen Manifestes, das direkte, persönliche Kommunikation über schriftliche Dokumentation stellt. Alte Versionen des Scrum Guides enthielten zudem Vorschläge zum "Aufräumen" des Produkt-Backlogs.
Der Abschnitt über das "Product Backlog" im aktuellen Scrum Guide stellt klar, dass das Product Backlog ein lebendes Artefakt ist, dass sich mit dem Produkt und dessen Einsatz weiter entwickelt. Für die "einzige Anforderungsquelle für alle Änderungen am Produkt" sind darüber hinaus bereits implementierte Änderungen an Anforderungen auf eine übersichtliche Weise einzuarbeiten, damit der aktuelle Stand des Produktes zur Beschreibung Planung neuer Änderungen erkennbar bleibt.
Der Abschnitt über das "Entwicklerteam" und das "Inkrement" lässt - wie zuvor erwähnt - auch keine Zweifel offen, dass professionelles Arbeiten und marktübliche Qualität erwartet wird, die bei komplexen Software-Produkten eine angemessene Dokumentation der Deployment-Artefakte, APIs, Daten und der grafischen Benutzeroberflächen für den Betrieb und die Endbenutzer umfasst.
Nach jedem Sprint wird ein Produktinkrement veröffentlicht
Wie im Abschnitt „Sprint“ beschrieben, können Veröffentlichungen jederzeit und so oft wie gewünscht durchgeführt werden. Der Product Owner trifft die finale Entscheidung, wann ein Produktinkrement veröffentlicht wird, wobei in der Praxis sowohl Vorschläge des Teams als auch Vorgaben aus einer übergeordneten Releaseplanung berücksichtigt werden.
Agile Softwareentwicklung basiert auf einzeiligen User Stories, mündlicher Abstimmung und hochwertigem Code
202X ist der Glaube an das Märchen von übersichtlichen kleinen Domänen verblasst, für die rasch ein paar kleine, selbsterklärende Microservices geschrieben werden. Moderne Softwareentwicklung ist in der Regel noch komplexer geworden, als vor der Besinnung auf schlanke Methoden und Architekturen. Auch die Komplexität technischer Realisierungen hat sich nach der Abkehr von vepönten "Monolithen" nicht wesentlich geändert, bestenfalls die Bereitschaft, mit unzureichend durchdachter Architektur, unzureichender Fehlerbehandlung und fehlender Dokumentation erste Erfahrungen in der Produktion zu sammeln.
Das Missverständis von der schlanken Softwareentwicklung ohne strukturierte Anforderungen und lästige Design-Arbeit entspringt Wunschdenken und einer Fehlinterpretation des agilen Manifestes, das zu Recht direkte, persönliche Kommunikation über schriftliche Dokumentation stellt. Die Wertschätzung wird so formuliert:
- Individuen und Interaktionen (zählen) mehr als Prozesse und Werkzeuge
- Funktionierende Software (zählen) mehr als umfassende Dokumentation
- Ergänzung: Obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein.
Wenn in komplexen Systemlandschaften mit umfangreichen APIs die Dokumentation der zu berücksichtigenden Komponten unverzichtbar ist, kann die schriftliche/bildliche Dokumentation nicht durch persönliche Kommunikation kompensiert werden. Niemand wird z.B. versuchen, einen Bauplan für ein Smartphone mündlich weiter zu geben. Die gemeinsame Zeit für persönliche Abstimmungen ist ein wesentlicher Erfolgsfaktor, aber sie ist knapp und wertvoll, und kann in diesem Umfeld besser genutzt werden, in dem die verfügbare Dokumentation vor dem Treffen konsultiert wird, und wenn z.B. hilfreiche Diagramme, Glossare usw. auch während der Abstimmung verfügbar sind.
Ein professionelles Team nutzt deshalb bei Bedarf auch verfügbare Informationen aus Tutorials, aus verfügbaren Architektur-Konzepten, Videos, Produktbeschreibungen usw. zur Vorbereitung und raschen Umsetzung der Tasks. Auch die Dokumentation von im Team getroffenen Design- und Architektur-Entscheidungen, die Vorbereitung von Benutzer-Dokumentationen und Workshops sind typische Arbeiten professioneller agiler Teams, wenn komplexe, verteilte Software entwickelt wird. Der aktuelle Scrum Guide und das agile Manifest bieten keine Ausreden, sich davor zu drücken.
Qualitativ hochwertiger Code wird gerne als Ersatz für strukturierte Anforderungen angesehen. Er ist für TesterInnen und fachliche EntscheiderInnen aber nur erkennbar, soweit er in Benutzermasken oder Webservices sichtbar wird. Geschäftslogik, die nicht direkt in Prozessdiagrammen, in Benutzermasken und APIs sichtbar ist, bleibt fachlichen AnsprechpartnerInnen, TesterInnen, Portfolio-ManagerInnen und nachfolgenden DevOps in falsch verstandenen agilen Projekten nach der Implementierung verborgen.
Veraltete Software ohne aktuelle Dokumentation und ohne Verbindung zum aktuellen Stand der Geschäftsprozesse bietet keinen Geschäftswert. Auf Grund der damit verbundenen "technischen Schuld" ist im agilen Umfeld im Zweifelsfall ein negativer Geschäftswert anzunehmen.
Der erwähnte Scrum Guide ist hier verfügbar: