Kommen dir diese Situationen bekannt vor?
Vor dem eigentlichen Sprint Planning im Team muss der Product Owner noch weitere Abstimmungsrunden mit anderen Teams drehen, damit die Arbeit für den Sprint geplant werden kann.Im Daily Scrum berichten die Entwickler, dass sie nicht weiterarbeiten können, da die Datenbankspezialistin nicht auf ihre Anfragen reagiert.Im Sprint Review können den Stakeholdern ein Mock-up und der Source-Code des neuen Features präsentiert werden, aber ausprobiert werden kann es nicht, da es nur auf dem Rechner eines Entwicklers lauffähig ist.In der Sprint-Retrospektive wirft das Team einen Blick auf die Cycle-Time und stellt fest, dass sie von Sprint zu Sprint zunimmt.
Dies sind alles Beispiele aus meiner Vergangenheit und sie haben eines gemeinsam. Du hast es bestimmt bereits erraten:
Abhängigkeiten behindern die Arbeit des Scrum Teams.
Abhängigkeiten sind für mich der unsichtbare Feind der Agilität. Deshalb stelle ich mir Abhängigkeiten immer als Spinnennetz vor. Wenn wir nicht aufpassen, verstrickt sich das Team immer mehr in ihm. Es kann sich irgendwann nicht mehr vor- oder zurückbewegen. Bis es ganz gefangen ist.
Damit es deinem Team nicht so ergeht, möchte ich dir drei Arten von Abhängigkeiten vorstellen und Wege präsentieren, wie du sie frühzeitig transparent machen kannst.
Widmen wir uns einer Art nach der anderen:
Architektur: Wenn die Änderung in einem Bereich einen anderen Bereich funktionsunfähig macht
In meiner Java-Vorlesung im Jahr 2008 wurde mir erzählt, dass Continuous Integration (CI) und Continuous Deployment (CD) Standard sind.
Der Professor meinte: „Früher haben die Programmierer den Code ‚ausgecheckt‘, und wenn der Code ausgecheckt war, war er gesperrt, sodass niemand anderes daran arbeiten konnte. Andere Entwickler mussten ihre Arbeit pausieren.“ Dann erklärte er weiter, dass dies seit der Einführung von CI-Praktiken und -Werkzeugen jedoch nicht mehr der Fall sei. Niemand im Unternehmen würde mehr den Code sperren. Stattdessen nähmen die Programmierer ihre Änderungen vor und behöben Konflikte gemeinsam. Konflikte beim „Mergen“ würden durch Tests erkannt. Daher sei ein hoher Grad von Testabdeckung essenziell für die Arbeit von Softwareentwicklern. Die Entwicklung von CI stamme noch aus einer Zeit, als Anwendungen monolithisch gewesen seien. Heute, so der Professor, bestünden Anwendungen aus vielen separaten Komponenten, die einzeln bereitgestellt werden könnten, was zu Continuous Deployment geführt habe. Somit erweitere CD das Konzept der Integration auf mehrere getrennt einsetzbare Komponenten der Software. Dies habe zu dem Problem geführt, dass Entwickler ständig parallel an sich überschneidenden Komponenten der Software arbeiten könnten, was aber zu Abhängigkeiten führe. Abhängigkeiten zwischen Quelldateien und Abhängigkeiten zwischen getrennt einsetzbaren Komponenten. Sich mit Abhängigkeiten herumzuschlagen, werde zum Leidenskampf eines jeden Softwareentwicklers.
Der Professor beendete seinen Vortrag mit der Aussage:
„Heute ist das anders. In jedem Unternehmen werden moderne Entwicklungspraktiken eingesetzt. Dazu gehören Werkzeuge wie Git, Pull-Requests, API-Versionierung und vieles mehr.“
Nach dem Studium begann ich, selbst Software zu entwickeln oder Teams dabei zu unterstützen. Dabei musste ich feststellen, dass der Professor nur die halbe Wahrheit erzählt hatte.
Zum einen gibt es noch viele Softwareprojekte, in denen keine modernen Entwicklungspraktiken verbreitet sind.Zum anderen schützen moderne Entwicklungspraktiken Entwickler nicht vor der „Mergehölle“. In dieser verbringst du einen ganzen Nachmittag damit, Bibliotheken nachzuladen. In der Hoffnung, dass sich irgendwann die Abhängigkeiten in Luft auflösen.
Und das Problem mit Abhängigkeiten in der Software ist noch viel gravierender. Sie entstehen, ohne dass die Entwickler etwas tun. Software altert. Die Qualität von Software lässt im Laufe der Zeit nach. Du erkennst es daran, dass die Software langsamer wird. Was schließlich dazu führt, dass die Software fehlerhaft oder unbrauchbar wird oder ein Upgrade benötigt.
Deshalb hilft es deinem Team, diese Alterung im Blick zu behalten. Du kannst die Verwaltung von Abhängigkeiten zum Thema einer Sprint-Retrospektive machen.
Hilf deinem Team Technik zur Identifizierung, Auflösung und Korrektur von Abhängigkeiten in der Codebasis unserer Anwendung zu entwickeln. Wenn dein Team weiß, wovon es abhängig ist, ist es besser darauf vorbereitet. Ihr könnt die Schwachstellen der Anwendung erkennen. Außerdem versteht ihr, wie sie sich auswirken könnten.
Diese Umsetzung der Techniken sollte Bestandteil der Definition of Done sein.
Neben Architektur-Abhängigkeiten gibt es aber noch eine weitere Quelle:
Fachwissen: Wenn spezifische Expertise oder die Hilfe einer bestimmten Person erforderlich ist
Eigentlich sollte es in einem Scrum Team keine Abhängigkeiten aufgrund fehlenden Fachwissens geben.
Scrum Teams sollten interdisziplinär aufgestellt sein, also sämtliches Fachwissen vereinen, um neue Produktversionen erstellen zu können.
So lautet die Theorie. In der Praxis sind Teams und Unternehmen jedoch häufig noch nicht so weit. Warum es sich lohnt, darauf hinzuarbeiten, soll dir das folgende Beispiel veranschaulichen.
Das Beispiel stammt von Troy Magennis, der es im Jahr 2015 auf der „Agile 2015 Conference“ in Washington präsentierte. Dort verwendete er boolesche Logik, um darzulegen, dass das Entfernen jeder Abhängigkeit die Wahrscheinlichkeit einer pünktlichen Lieferung verdoppelt.
Betrachten wir ein Beispiel: Angenommen, wir benötigen bestimmte Fähigkeiten in dieser Reihenfolge, damit ein neues Feature fertiggestellt werden kann: Programmierung und Test.
Betrachten wir zwei Szenarien:
Alle Fähigkeiten sind im Team vorhanden, jeder Experte steht zur Verfügung. Die Lieferung ist pünktlich fertig.Die Fähigkeit „Test“ fehlt im Team und der Experte steht nicht zur Verfügung, die gesamte Fertigstellung verzögert sich.
Es besteht also eine 50-%ige Wahrscheinlichkeit, termingerecht fertig zu werden. Wenn dein Team auch über die Fähigkeit „Test“ verfügt, besteht eine 100-%ige Wahrscheinlichkeit, termingerecht fertig zu werden. Natürlich ist dieses Beispiel jetzt sehr vereinfacht, aber ich hoffe, du verstehst Troys Punkt.
Sollte dein Team noch nicht interdisziplinär aufgestellt sein, findest du hier eine Methode. Diese Methode hilft dir, die entstehenden Abhängigkeiten transparent zu machen.
Schritt 1: Schreibe alle Rollen auf, die zur Fertigstellung eines Features benötigt werden, etwa:
IT-ProjektleiterDesignerBusiness-AnalystSoftwarearchitektEntwicklerTesterQ&A-ManagerProduct Owner
Schritt 2: Erstelle eine Matrix mit den Rollen als Spalten und Zeilen. Beschrifte die Spalten mit „Rollen, die etwas benötigen“ und die Zeilen mit „Rolle wird benötigt“.
Schritt 3: Fülle gemeinsam mit allen beteiligten Rollen die Matrix aus. Wenn etwa der „Entwickler“ den Input vom „Designer“ benötigt, setze ein Kreuz in der Spalte „Entwickler“ und Zeile „Designer“.
Mit diesem einfachen Vorgehen kannst du Fachwissen-Abhängigkeiten über Teamgrenzen hinweg transparent machen.
Aber es gibt noch eine dritte Quelle von Abhängigkeiten:
Aktivitäten, bei denen erst nach Abschluss weitere Fortschritte möglich sind
Viele Teams nutzen User Stories.
Aber INVESTieren sie auch in gute User Stories?
Was meine ich mit diesem Wortspiel? Die INVEST-Kriterien gehen auf Bill Wake zurück. Es war sein Vorschlag, um die Qualität von User Stories zu beschreiben.
INVEST steht für:
I wie Independent (Unabhängig)N wie Negotiable (Verhandelbar)V wie Valuable (Wertvoll)E wie Estimable (Schätzbar)S wie Small (Klein)T wie Testable (Testbar)
Du möchtest den unsichtbaren Feind der Agilität in deinem Team oder Unternehmen entlarven. Dazu solltest du dir das erste Kriterium zu Herzen nehmen.
Dieses Kriterium hat direkte Auswirkungen auf die Arbeit des Product Owners deines Teams.
Die Auswirkung von abhängigen User Stories wurden in der Arbeit „The Effects of Team Backlog Dependencies on Agile Multiteam Systems: A Graph Theoretical Approach“ von Wissenschaftlern um Alexander Scheerer untersucht. Sie kamen zu dem Schluss: Sollte eine Abhängigkeit zwischen zwei Einträgen im Product-Backlog bestehen, dann reduziert diese die Anzahl der möglichen Kombinationen für die Anordnung des Product-Backlogs um 50 %.
Was bedeutet das für die Arbeit des Product Owners?
Der Scrum Guide schreibt:
„Der Product Owner ist verantwortlich für die Maximierung des Wertes des Produkts, resultierend aus der Arbeit des Scrum Teams.“„Diese Entscheidungen werden durch den Inhalt und die Reihenfolge des Product Backlogs sichtbar.“
Wie kann der Product Owner den Wert des Produkts maximieren? Wie kann er auf eine sich ändernde Marktsituation reagieren? Dies kann unmöglich werden, wenn die Anordnung der Product-Backlog-Einträge durch Abhängigkeiten bereits vorgegeben ist.
Deshalb mein Appell: Der Product Owner sollte das Product-Backlog wertorientiert ordnen können. Dein Team sollte im Refinement daran arbeiten, die Einträge entsprechend zu gestalten. Sie sollten die INVEST-Kriterien erfüllen. Für Scrum in einem einzelnen Team sollten die INVEST-Kriterien ausreichend sein. Wenn mehrere Teams an einem Produkt arbeiten, ist es jedoch hilfreich, die teamübergreifenden Aktivitätsabhängigkeiten weiter transparent zu machen.
Im „Scaled Professional Scrum“-Training nutzen Peter Götz und ich hierfür ein Cross-Team-Refinement-Board.
Hier ein Bild davon:
Auf dem Bild sind drei Teams – „Rider“, „Driver“ und „Backoffice“ – sowie die nächsten drei Sprints dargestellt. Die Teams treffen sich regelmäßig zum teamübergreifenden Refinement. Dabei visualisieren sie die Abhängigkeiten in ihrer Arbeit. Diese Visualisierung geschieht über die Teamgrenzen hinweg.
Diese Aktivität wird als Cross-Team-Refinement bezeichnet.
Peter Götz und ich haben jahrelang in skalierten Umfeldern gearbeitet. Wenn du aus erster Hand Tipps und Praktiken für solche Situationen erfahren möchtest, empfehle ich dir, unser Training zu besuchen.