Seminar buchen

Kategorie: Wissen

Veröffentlicht am

Definition of Done verständlich erklärt

(c) Bernard Goldbach - Creative Commons

Vor Kurzem hielt ich in einem Workshop ein Smartphone in die Luft und fragte einige Menschen, ob das ein gutes Telefon sei. Viele fanden es gut, manche okay und einer mochte es absolut nicht. Bei der Nachfrage nach Gründen stellten wir schnell fest, dass verschiedene Menschen verschiedene Qualitätsmerkmale betrachten und wichtig finden.

Das ist auch in einem Softwareentwicklungsteam nicht anders – bei der Frage, ob ein Stück entwickelte Software fertig ist, gibt es oft Uneinigkeit und Diskussionen. Woher weiß ich, dass ich fertig bin mit der Entwicklung? Was kann ich von meinen Kollegen erwarten, wenn sie ein Feature umsetzen? Was erwartet mein Product Owner?

Um diese Fragen in einem agilen Team zu beantworten und Klarheit zu schaffen, gibt es in der agilen Welt ein Artefakt mit dem Namen „Definition of Done“. Im Prinzip ist es soetwas ähnliches wie eine sehr spezifische Arbeitsvereinbarung oder selbst auferlegte Regeln, wie man Entwicklungsqualität definiert.

Eine Definition of Done (kurz: DOD) ist die Einigung eines agilen Teams darauf, was getan werden muss, damit ein Feature als fertig angesehen wird.

Man kann sich das als eine Art Kriterienkatalog oder Checkliste vorstellen, die man bei jedem Feature (sprich: User Story) durchgeht und auf Erfüllung überprüft:

  • Habe ich Unit Tests entwickelt?
  • Wurde die Dokumentation erweitert?
  • Sind die Codekonventionen eingehalten?
  • usw.

Definition of Done (DOD)In einem Workshoptermin, den der Agile Coach bzw. ScrumMaster moderiert, wird diese Selbstverpflichtung des Teams als Einigung gemeinsam erarbeitet. In Zukunft ist sie die Basis für Klarheit bei der Frage, ob ein Feature fertig ist und hängt deswegen im Idealfall im Teamraum. Die Verantwortung für die Inhalte und auch die Einhaltung der Vereinbarung liegt ausschließlich beim Team. Ein wachsamer Agile Coach erinnert aber an die festgelegten Elemente zur passenden Gelegenheit.

Übrigens darf man im Laufe des Wachstums eines agilen Teams durchaus erwarten, dass die Definition of Done reift, somit mehr und umfangreichere Qualitätskriterien enthalten sind. Vielleicht ist es damit die erste Checkliste, die organisch wächst.

Veröffentlicht am

Qualitätssicherung in agilen Methoden

Scrum sagt, produziere potenziell auslieferbare Software in jedem Sprint, Kanban hat als Prinzip „Fokussiere Dich auf hohe Qualität„.

Leicht erkennbar ist, dass agile Methoden Anforderungen an die zu produzierende Qualität einer Software treffen. Was bedeutet dies nun in der konkreten Anwendung im Unternehmen?

In der perfekten agilen Welt liefern wir einen kontinuierlichen Fluss von Funktionalitäten aus: Auf der Ebene einer jeden Story ist diese getestet auf ihre Qualität und im Kontext des Gesamtsystems validiert, im Extremfall nicht nur auf den Test- sondern auch auf den Produktivserver verteilt.

Um soetwas tun zu können, müssen wir in der Lage sein, mit geringem Aufwand zu prüfen, ob eine User Story funktioniert und die Erstellung der Story eine Auswirkung auf einen anderen Teil des Systems hatte. Schließlich wollen wir ja keine neuen Defekte hinzufügen, weil neue Funktionen hinzukommen. Mittlerweile gibt es ja eine ganze Hand voll Best Practices in diesem Bereich. Specification By Example, TDD, Integrations- und Unittests oder Konfigurationsmanagementtools sind einige von Ihnen.

Schaffen wir es, den Automatisationsgrad von Tests und Deployment so weit zu bringen, dass es im Sprint möglich ist, die Qualität zu sichern, die wir gerne hätten, haben wir Feedback dann zur Hand, wenn es am wichtigsten ist: Kurz nach der Produktion, wenn Entwickler noch wissen, wo der Defekt zu finden ist oder wie das Feature leicht zu modifizieren ist, damit es das tut, was der Kunde wirklich will. Denn wir wollen Fehler beheben, statt sie zu verwalten.

Abhängig von den Fähigkeiten im Team, den bisher verwendeten Tools, der Testbarkeit des Codes und der eigenen Disziplin ist die Erreichbarkeit solch einer Qualitätskontrolle für das eine Unternehmen eine überschaubare Strecke, für das andere ein Ultramarathon, der schnell als unmöglich schaffbar bezeichnet wird.

Ein befreundeter Agile Coach, der aus Leidenschaft extrem lange Strecken läuft, hat mir einmal erzählt, wie man eine 116km-Strecke angeht:

Viel Training, die Vorstellung des nächsten kleinen Abschnitts statt der ganzen Riesenstrecke im Kopf und: man sollte Lust darauf haben.

Wenn ihr Team sich gerne die Finger schmutzig macht, versuchen Sie es mit kleinen kontinuierlichen Schritten: Erweitern Sie die Definition of Done regelmäßig in der Form, dass mehr Aspekte auf Story- und Sprintebene fertiggestellt werden und weniger je Release. Das wird vielleicht zeitweilig anstrengend sein, aber Schritt für Schritt gelingt so auch der lange Lauf – wenn man darauf Lust hat.

Veröffentlicht am

Selbstorganisation ist ein (wichtiger) alter Hut

Menschliche Systeme wie z.B. Softwareentwicklungsteams organisieren sich selbst ohne jegliches zutun – schon immer. Dieses Selbstorganisation genannte Phänomen ist das natürliche Verhalten aller komplexer Systeme. Die spannende Frage ist dabei jedoch, ob das zu Tage tretende Verhalten gewünscht oder unerwünscht ist.

Viele Jahre lang haben Führungsrkräfte versucht, das Verhalten durch möglichst detaillierte Vorgaben, Anweisungen und Regeln zu beeinflussen – ein Vorgehen, dass den Anleihen des Taylorismus geschuldet zu sein scheint. Das funktionierte mal mit mehr, mal mit weniger Erfolg.

Ein Trick in der Interaktion mit komplexen Systemen ist: Entscheidungen und Verantwortung werden dorthin gegeben, wo die Informationen präziser und kleiner sind. In der Regel ist das eine Delegation weiter „nach unten“. So werden die Entscheidungen besser und auch eher mitgetragen. Rahmenbedingungen helfen dabei, wichtige Entscheidungsaspekte zu berücksichtigen.

Komplexe Systeme haben emergente Eigenschaften: Das Verhalten des Systems kann nicht alleine durch das Verhalten der einzelnen Teile des Systems bestimmt werden. Ein Team ist mehr als die Summe seiner Mitglieder.

Als Konsequenz daraus verwendet man in agilen Vorgehensweisen die Intelligenz der Gruppe an allen wichtigen Stellen: Planung, Schätzungen, Reviews, Retrospektiven. Keine dieser Tätigkeiten kann von einer Person alleine in hoher Qualität geleistet werden, denn dafür sind zu wenige Informationen in der gedanklichen Abbildung jedes Einzelnen. Wer einmal bei einer Planning Poker Sitzung dabei war, kann dies dort leicht erkennen: Abweichende Schätzwerte sind immer in einem unterschiedlichen Wissenstand begründet. Hier wird aus den Einzelinformationen ein Gruppenmodell, dass die Komplexität einer Anforderung besser wiederspiegelt.

Aus dem selben Grund delegiert man – wie oben geschrieben – also auch möglichst viel Kontrolle an die Teams selbst: Sie haben das vollständigste Model zur Verfügung, um ihr eigenes System zu steuern. So steigt die Stabilität des Gesamtsystems Abteilung und Organisation.

Veröffentlicht am

Kontiniuerliche Wertschöpfung

Ein Grundgedanke in agilen Prozessen wie Scrum ist es, in Intervallen potentiell auslieferbare Produkt- oder Projektstände zu erzeugen. Jetzt kann man sich fragen, warum dies ein Vorteil zu anderen Produktionsphilosophien ist?

An jedem Intervallende habe ich die Möglichkeit, mein Produkt meinem Kunden oder Anwender zur Verfügung zu stellen. Damit ist die Zeitspanne, bis ich mit neuen Funktionen am Markt oder beim Kunden bin sehr kurz. Diese Taktung können oft nur wenige Mitbewerber erreichen. Sobald die Anwendung so ausgeliefert ein Mindestmaß an Nutzwert für die Zielgruppe darstellt, kann abgerechnet oder anderweitig monetarisiert werden.

Was bei Großprojekten oft Monate und Jahre dauert, beginnt hier von Anfang an. Darüber hinaus habe ich frühes Feedback meiner Anwender, welches maßgeblich in meine Produktgestaltung einfließen kann und so eine gute langfristig erfolgreiche Positionierung am Markt sichern kann.

Spinnt man den Gedanken der häufigen Auslierferung weiter, kommt man schnell zu der Erkenntnis, dass solche Lieferintervalle bestimmte technische Voraussetzungen haben: Kontinuierliche Integration, automatische Tests und schnell durchführbare Deploymentprozesse. Hat man diesen Reifegrad erreicht, entsteht quasi mit jedem Feature, dass ein Team in einer Iteration abschließt, Wertschöpfung für das Unternehmen. Welche Projekte können das schon behaupten?

In der Realität ist dies für viele Unternehmen ein Weg, der Mut, Ausdauer und Kraft kostet. Und vielleicht liegt gerade hier das Potential, sich vom Mitbewerber abzuheben oder auch als interner Dienstleister überzeugen zu können. Noch sind es wenige Firmen, die so weit gegangen sind und ich bin mir sicher: es werden jedes Jahr mehr werden.

Veröffentlicht am

Die volle Blüte Scrums – Entwicklungsphasen eines Teams richtig unterstützen

Teams von Menschen kann man als komplexe adaptive Systeme betrachten, was auch bedeutet, dass solche Gruppen ständiger Veränderung unterliegen.

Jeder Mensch bringt seine Tagesform ein, seine aktuellen Lebensthemen, seine Erfahrung und viele weitere Faktoren, die das Zusammenleben und Arbeiten beeinflussen. Es gibt verschiedene Modelle zur Gruppenentwicklung, welche diese Komplexität auf ein handhabbares Maß reduzieren.

Kommen Scrum-Teams neu zusammen oder werden in ihrer Zusammensetzung stärker verändert, durchlaufen sie verschiedene Entwicklungsstufen. Als erstes dominieren Unsicherheit, Hoffnungen und Befürchtungen aber auch Vorfreude. Die Teammitglieder kennen sich teilweise oder auch vollständig noch nicht.

Hier bieten sich als ScrumMaster vor allem Aktivitäten an, die Vertrauen aufbauen und ein Kennenlernen ermöglichen:

* Kollaborative Gruppenspiele
* Vorstellen bisheriger Projekt- und Erfahrungshistorie
* Partnerinterviews mit anschließender Gruppenpräsentation
* Wertearbeit von Einzelnen und der Gruppe

Besteht eine grundlegende persönliche und berufliche Basis, können Gemeinsamkeiten und Verbindendes herausgearbeitet werden. Formen der Zusammenarbeit können definiert werden, durch:

* Eine gemeinsame Vision/Mission
* Teamnormen bzw. eine Teamcharta
* Konventionen auf technischer Ebene

In der darauffolgenden Differenzierungsphase bildet sich die informelle Hierarchie eines  Teams heraus. Rollen werden detaillierter ausgeprägt, es klärt sich, wer sich für welche Themen verantwortlich macht und fühlt. Um mit auftretenden Spannungen umgehen zu können, kann ein ScrumMaster diese Aktionen planen:

* Einführung des Teams in Gewaltfreie Kommunikation oder andere Kommunikationsmodelle
* Erarbeiten von Regeln für konstruktives Feedback
* Anwenden von Win-Win-Strategien wie dem Harvard-Modell für Verhandlungen

Darauffolgend kann das Team in die hochproduktive Arbeitsphase gelangen – es steht in der vollen Blüte Scrums.

Durch die gemeinsame Basis, vereinende Ziele und einen wertschätzenden, vertrauensvollen Umgang entsteht eine Atmosphäre, die Kreativität und Fehler zulässt. Dies kann noch weiter gestärkt werden durch:

* Lernen von Kreativitätstechniken
* Verbindende Events (Teamabende, Outdoor-Events)

Die meisten genannten Aktivitäten können im Rahmen einer Retrospektive oder gesonderten Teamentwicklungsworkshops eingebracht werden – abhängig vom Grad der Komplexität des Teams, der Herausforderungen und des Unternehmens.

Schaut man sich im Detail diesen aufwändigen Findungsprozess an, wird sich für viele die Frage nach der Häufigkeit von Teamveränderungen beantworten: Teams sollten so selten wie möglich verändert werden – außer sie funktionieren auch nach intensiver Investition nicht.

Und wie sollten nun Scrum Teams generell zusammengestellt werden? Darauf hat Mike Cohn eine Antwort (bzw. einige Fragen).

Veröffentlicht am

Selbstorganisation passiert (nicht) von alleine

Wer mit agilen Teams oder Methoden in Kontakt kommt, hört manchmal die Aussage, dass Manager nicht mehr benötigt werden, da sich die Teams selbst organisieren sollen. Das ist ein völlig falsches Verständnis von Selbstorganisation.

Der ScrumMaster hat im Scrum Prozess eine laterale Führungsrolle. Das bedeutet, dass er keine disziplinarische Macht hat, jedoch ganz klar eine Führungsaufgabe hat, was auch durch den Begriff des „Servant Leaders“ deutlich wird.

Wieso braucht man diese Rolle? Sind ein Team von Experten nicht von alleine in der Lage durch Selbstorganisation möglichst efffizient Software zu produzieren? Der Haken an selbstorganisierten Systemen ist, dass ohne vorgegebene Rahmenbedingungen absolut beliebige Systemzustände entstehen. Das bedeutet nicht zwangsläufig Chaos, aber auch nicht, dass ein System alleine zu positiver Entwicklung neigt.

Ein System könnte zum Beispiel zu einer lokalen Optimierung neigen. Sagen wir mal, ein Team ist damit beauftragt, intensive Lasttests auf eine im Internet platzierte Serverfarm durchzuführen. Dieses Team wird sich bemühen, die Arbeitsumstände so optimal wie möglich für ihr Vorhaben zu gestalten und im schlechtesten Fall die Netzwerkbandbreite der gesamten Firma konsumieren.

Und auch Manager setzen Rahmenbedingungen für Teams: Sie müssen Menschen zum Beispiel vor Mobbing schützen, gemeinsame Ressourcen wie Platz im Büro, Netzwerkbandbreite, usw. vor zu hoher Inanpruchnahme durch einzelne Teams und Individuen.

Ein „Rahmengeber“ ist also ein elementarer und wichtiger Bestandteil eines selbstorganisierten Teams. Innerhalb dieser Grenzen kann eine positive und sinnvolle Entwicklung eines Teams stattfinden. Hier ist neben dem ScrumMaster auch das Linienmanagement gefragt, diesen Rahmen zu definieren.

Veröffentlicht am

Story Points verständlich erklärt

Bei meiner Recherche im Internet und der gängigen Literatur habe ich gute Beispiele zur Vermittlung des Konzepts von Story Points gesucht.

Bis auf Mike Cohns Erläuterung in seinem Buch „Agile Estimation & Planning“ habe ich wenig leicht verständliches gefunden. Auf die Gefahr hin, dass ich vielleicht einfach eine gute Quelle verpasst habe und das Rad nun neu erfinde, möchte ich meinen Beitrag zu dem Thema zu leisten, um Story Points nochmal auf den Punkt zu bringen:

Storypoints sind eine Einheit, die die Größe einer User Story beschreiben.

Wie ist nun diese Größe definiert? Diese Frage ist nicht pauschal zu beantworten. Es fließen viele Faktoren ein, die von den Individuen abhängen, die diese „Größe“ definieren.

Ein Team könnte eine Größe zum Beispiel so definieren:

* Die Größe einer Story ergibt sich aus ihrer Komplexität. Die Komplexität hängt davon ab, ob und wieoft welche Schichten unseres Architekturmodells durchstoßen werden…

Ein anderes Team vielleicht so:

* Wie komplex sind die Interaktionen zur Umsetzung? Um diese Story umzusetzen müssen wir mehrere Abstimmungs- und Anpassungsrunden zwischen Designer, Interaction Designer und Frontend-Entwickler durchführen…

Wie auch immer ein Team diese Größe definiert, eines ist wichtig dabei: Es geht nicht um die Zeitdauer, die benötigt wird, um die Story umzusetzen, sondern um eine Eigenschaft der „Struktur“ der User Story. Oder gleich um ein ganzes Bündel von diesen Eigenschaften.

Das ist ein wichtiger Unterschied. Das bedeutet, dass die wachsende Erfahrung eines Teams und schnellere Abarbeitung von Stories die Größe einer Story nicht verändert, denn die Eigenschaften der Story haben sich nicht geändert.

Ein erfahrenes Team schafft einfach mehr bzw. größere Stories in der selben Zeit als ein unerfahrenes Team, das beeinflusst die Größe nicht.

Was bedeutet das nun für Schätzungen:

Die Diskussionen darüber, wer eine Story umsetzt, sind nichtig. Ob erfahrener oder unerfahrener Entwickler: Es spielt keine Rolle für die Schätzung einer Story. Das unterstützt cross-funktionale Teams in ihrer Arbeit und macht Schätzungen leichter und schneller. Es müssen nur die Eigenschaften identifiziert werden und ein Vergleich mit schon bearbeiteten oder ähnlichen Stories angestrebt werden, dann hat man die Größe.

Wie kann man nun mit Story Points einen Releaseplan erstellen?

Der Zeitfaktor kommt in Scrum dann durch die Teamgeschwindigkeit in das System. Diese so genannte Velocity ist der Durchschnitt über die Summe aller vom Team erledigten Story Points pro Iteration, also:

V = ø (SUM(Story Points der erfolgreich abgeschlossenen Stories im Sprint))

Wenn ich jetzt für alle Product Backlog Items Story Point Werte schätze, sie in der Reihenfolge durch eine Form von Priorisierung sortiere und weiß, wieviele Storypoints mein Team je Iteration umsetzt (Velocity), kann ich die Aussage treffen, in welcher Iteration ich ein Feature liefern kann.

Während der Arbeit entstehen also gemessene Zeitwerte, die ich dann auf die Größe appliziere. Zeiten schätzen wird daher mit Story Points niemand mehr. Das ist eine gute Konsequenz, wenn man überlegt, wie schwer es ist, so etwas komplexes wie die Entwicklung von Softwarebausteinen durch Zerlegung zeitlich abzuschätzen. Es gibt ziemlich dicke Bücher über nur dieses Thema und eher weniger als mehr Projekte, die gute Schätzungen vorweisen können.

Kleinteilige Diskussionen vermeiden

Ein anderer Aspekt ist der, dass durch die Betrachtung der Charakteristika einer Story vermieden wird, zu tief in die für die Umsetzung notwendigen kleinteiligen Elemente hineinzugehen. Die Merkmale einer Story können auch ohne eine detaillierte Tätigkeitenanalyse identifiziert werden. Das ist bei Aufwandsschätzungen in Tagen häufig anders. Hier werden alle notwendigen Tätigkeiten identifiziert und deren Aufwände aufsummiert.

Einfacher in der Praxis

In der Praxis ist das Thema „Story Points“ interessanterweise einfacher, als es tatsächlich zu erklären ist.

Nimmt man eine Referenzstory und einigt sich darauf, dass diese eine mittlere Größe hat, gibt das Team der Story zum Beispiel die Größe „5“. Andere Stories werden dann mit dieser verglichen und als gleich groß, kleiner oder größer eingestuft. Die Agilisten nehmen dann gerne die nach Mike Cohn angepasste Fibonacci-Reihe und verteilen die Elemente darauf: 1, 2, 3, 5, 8, 13, 20, 40, 100.

Die seltsame Skala dient unter anderem dazu, auszudrücken, dass um so komplexer die Story ist (also umso größer), die Genauigkeit der Schätzung in die Binsen geht.

De facto sollte man mit sehr großen Stories vorsichtig in der Releaseplanung sein, denn es herrscht hier eine hohe Unsicherheit in Bezug auf das korrekte Verständnis des Teams für dieses Story – aber das ist ein anderes Thema.

Update vom 14.09.2018: Mit meinen Kollegen von DasScrumTeam habe ich ein kostenfreies Online-Video-Coaching produziert, das User Stories sehr anschaulich vermittelt.

Veröffentlicht am

Technische User Stories gehören nicht ins Product Backlog

Die agile Gemeinde hat dieses Thema schon öfter diskutiert – mit sehr unterschiedlichen Ansichten. Daher möchte ich diesen Beitrag nutzen, um meine Meinung darzustellen und sie zu begründen. Meine Erfahrung aus der Rolle des Entwicklers fließen in mein Verständnis ebenso ein, wie die wirtschaftliche Betrachtung der Softwareentwicklung.

Das Product Backlog ist ein Ort, an dem der Product Owner eine Bestellung an sein Team aufgeben kann. Häufig finden hier User Stories Verwendung.

Nach Mike Cohn haben User Stories die 3 C’s als Kriterien:

  • Card: Eine Story sollte auf eine Karteikarte passen.
  • Conversation: Eine Story ist keine vollständige Anforderung oder dergleichen. Es ist ein Versprechen über eine Konversation, die während der Planungssitzung und beim Estimation Meeting noch geführt werden soll.
  • Confirmation: Die Definition, wann eine Story erfüllt ist, sollte auf der Rückseite stehen in Form eines User-Acceptance-Tests, damit das Team weiß, welcher Maßstab im Review Meeting angelegt wird.

Würde ein Product Owner bei seinem Team bestellen, dass eine Komponente von Version 1.2 auf Version 1.3 aktualisiert werden soll? Möchte er diese Konversation mit seinem Team führen? Die Frage ist, ob dadurch ein Mehrwert für ihn aus Geschäftssicht entsteht: Braucht er ein Feature der Komponente, dass nur im neuen Release enthalten ist? Sind Fehler behoben, die den Anwender betreffen?

Jetzt wird der erfahrene Entwickler vermutlich auf die technische Schuld hinweisen. Vollkommen zurecht: Wer in größeren Projekten arbeitet, der kennt die Themen der Komponentenaktualisierung, umfangreicher Refactorings und Austausch ganzer Bausteine.

An dieser Stelle gibt es zwei Optionen:

a) Der Product Owner bestellt ein Feature, dass die Aktualisierung bzw. Bearbeitung der technischen Schuld tatsächlich auch beinhaltet. In diesem Fall werden entsprechende Tasks zu der User Story erstellt und wie gewöhnlich bearbeitet.

b) Der Product Owner interessiert sich eigentlich nicht für die notwendigen Tätigkeiten aber jeder gute Entwickler weiß, dass diese Veränderungen gebraucht werden, um das Fortbestehen und die Wartbarkeit der Anwendung zu sichern.

Das Team sollte im Sprint Planning dann entscheiden, wieviel Aufwand es erwartet in Bezug auf die technischen Veränderungen und dementsprechend das Commitment anpassen, dass es dem Product Owner gibt. In den Velocity / Burndown Graphen ist eine Anmerkung des Product Owners sinnvoll, warum eine vermutlich eingeschränkte Velocity nach der Iteration erreicht wird.

Dies ist eine kritische Stelle der Interaktion zwischen dem Team und dem Product Owner, denn dieser muß dem Team vertrauen, dass das Team wirklich nur die notwendigen Arbeiten in einem Rahmen durchführt, der es nachwievor ermöglicht, echten Geschäftswert zu schaffen. Nutzt das Team diese Entscheidungsgewalt als „technischen Freibrief“ aus, sollte der ScrumMaster diesen Konflikt thematisieren und lösen.

Nur ein verantwortlicher Umgang mit Ressourcen und ein Zusammenspiel aus Technik und Business sichern langfristig den Erfolg.

Machtkämpfe zwischen Produktverantwortlichen und Entwicklern oder Architekten haben hier keinen Platz.

Die Abarbeitung der technischen Tasks wird wie gewohnt im Sprint Burndown dargestellt. Hier herrscht also Transparenz für den Product Owner. Die kritische Frage, warum gewisse Tätigkeiten umbedingt erfolgen müssen, darf gestellt werden und sollte vom Team beantwortet werden ohne dabei eine Rechenschaft abzulegen. Das Team entscheidet selber, wie es produziert.

Hier kann es hilfreich sein, wenn der ScrumMaster beiden Seiten hilft, die Belange des jeweils anderen zu verstehen, für Transparenz zu sorgen und einen tragfähigen Kompromiss zu entwickeln. Ein farbliches Hervorheben von Tasks der „technical debt“ könnte eine Option sein, das Verhältnis für alle Transparent zu halten. Kippt das Verhältnis in die falsche Richtung, sollte es thematisiert werden.

Technische Stories gehören also nicht ins Product Backlog. Technische Tasks gehören hingegen zur Arbeit des Teams. Die Balance zu halten, liegt in der Verantwortung aller Beteiligter.

Veröffentlicht am

Shu Ha Ri – Teamentwicklung in Etappen

Jurgen Appelo, den ich dieses Jahr persönlich bei seinem Management 3.0 Seminar in Hamburg kennenlernen durfte, hat eine für mich sehr stimmige Aussage getroffen:

Alle Modelle sind falsch, aber manche sind nützlich.

Ein Modell, dass ich für nützlich halte, ist das Shu Ha Ri – Modell, welches aus dem fernöstlichen Kampfsport stammt und von Lyssa Adkins in ihrem Buch „Coaching Agile Teams“ ausführlich dargestellt wird.

Gerade in einer solch komplexen Domäne, wie der Softwareentwicklung, sind solche Abstraktionen hilfreich, um effektiv mit Gruppen arbeiten zu können und bei Teamentwicklungsprozessen bei der Selbstreflektion zu helfen.

Das Shu Ha Ri – Modell besteht aus drei Stufen:

  • Shu: Jemand, der sich in dieser Ebene bewegt, benötigt klaren Regeln. Ihm fehlt die Erfahrung, Zusammenhänge und Hintergründe bewerten zu können und er folgt den Regeln erstmal in Vertrauen auf seinen Lehrmeister.
  • Ha: Der Lernende beherrscht die grundlegenden Praktiken und Prinzipien. Jetzt entsteht Raum, das Handeln zu reflektieren und ein tieferes Verständnis zu entwickeln, warum das gelernte funktioniert oder was es im Kern ausmacht. Diese Einsichten ermöglichen es, die Regeln zu brechen und neu zu definieren, ohne die dahinterliegenden Wirkprinzipien zu verletzen.
  • Ri: Man selbst ist die Regel. In tiefer Kenntnis der Notwendigkeiten und Mechaniken des Handelns können eigene Regeln erstellt werden, die nichts mehr mit den ursprünglichen Regeln zu tun haben und diese in ihrer Wirksamkeit in Bezug auf die eigene Situation deutlich übertrumpfen.

Man kann dieses Modell auf verschiedene Bereiche eines Teams anwenden, wie auch auf die persönliche Entwicklung in Bezug auf ein Thema.

In welchem Bereich Deines Lebens oder Jobs bist Du Shu, wo Ha und wo Ri?

Veröffentlicht am

Wie Scrum die Softwarequalität erhöht und warum der ScrumMaster selten Quellcode liest

Wenn man Scrum erklärt, biegt bei vielen Beschreibungen irgendwann das magische Projektmanagementviereck um die Ecke. Während bei Projekten generell die vier Eckpfeiler Kosten, Funktionsumfang, Zeit und Qualität zur Disposition stehen, sagt Scrum von sich selbst, das Qualität keine verhandelbare Option ist. Unter Projektdruck ist es nicht ungewöhnlich, dass Refactorings unter den Tisch fallen, Dokumentationen weggelassen und Umbauten vermieden werden. Hier sagt diese agile Methode, dass dies nicht passieren darf, um auch langfristig Wert zu schaffen.

Wer korrekt nach Scrum produziert, baut also keine schlechte Software mehr? So einfach ist es natürlich nicht. Hier lohnt es sich, einmal genauer hinzusehen: Wie kann ein solches Framework technische Qualität sicherstellen? Ist ein ScrumMaster ein getarnter Tester, der heimlich beim Abnahmemeeting für den fachlich Verantwortlichen in den Quelltext schaut, ein Code Review macht und mit einem dezenten Lächeln oder mürrigem Dreinblicken dem Product Owner heimlich mitteilt, wie das Team gearbeitet hat?

Guckt man in die Literatur, so hat der ScrumMaster erstmal die Verantwortung für die Prozessqualität. Von technischen Fähigkeiten oder gar Quellcodelesen steht da nichts. Wie kann also durch eine hohe Prozessqualität eine hohe Softwarequalität erreicht werden? Klare Sache: Die Antwort muss in den Prozessbestandteilen zu finden sein.

Bestandteil 1: Potentiell auslieferbare Produkt- / Projektinkremente
Nach dem Ende einer Iteration (also in der Regel nach zwei oder vier Wochen) hat ein Scrum Team eine potenziell auslieferbare Software produziert. Was bedeutet das? Der Anspruch ist hier: Auf CD brennbar, ausrollbar, verkaufbar… Alles, was die Software betrifft, muss erledigt sein. Der ScrumMaster bestärkt den Product Owner darin, Unfertiges abzulehnen und zur Nacharbeit zu geben.

Die „offensichtliche Ware“ ist also sauber. Wie sieht es nun mit dem Innenleben aus?
Hier hängt es maßgeblich vom Team und seiner Erfahrung ab, inwieweit Refactorings durchgeführt wurden, Quellcode bereinigt ist, Module getestet sind. Um so weniger technisches Qualitätsbewußtsein im Team vorherrscht, umso weniger Qualität wird ein Team liefern.

Ist es Aufgabe vom ScrumMaster, sein Team zu mehr technischer Qualität zu bewegen? Jein.  „Technische Schulden“, versäumte Refactorings, schlechte Architekturen  – sie werden durch Scrum sichtbar. Die Geschwindigkeit des Teams wird zum Beispiel geringer, einfache Features liefern riesige Schätzwerte, der Burndowngraph stagniert, am Iterationsende wird nicht geliefert.

Die Aufgabe des ScrumMasters ist es dann, dem Team zum Erkenntnisgewinn zu verhelfen und es darin zu unterstützen, besser zu werden. Findet das Team dann eine gute technische Lösung und die richtigen Maßnahmen? Wir vertrauen ihm und bitten es um Ideen, verfolgen die Umsetzung.

Bestandteil 2: Regelmäßige Auslieferung
Wer verteilte Systeme, interagierende Komponenten, unterschiedliche Bestandteile konstruiert, muss diese irgendwann integrieren und testen.  Hier können viele Probleme im Detail liegen. Um so häufiger hier eine Integration durchgeführt wird, um so sicherer kann das Team sein: Das läuft in der Praxis.

Bestandteil 3: Kanalisierte Kommunikation
Scrum definiert Kommunikationswege und Besprechungen, bringt Ideen für Artefakte mit, die helfen sollen, Anforderungen zu transportieren. Wenn Entwickler keinen Zugang zu weiteren Informationen einer Problemstellung haben, bleibt ihnen häufig nichts anderes übrig, als Annahmen zu treffen.

Scrum minimiert die Anzahl getroffener Annahmen auf ein Minimum, indem es die Kommunikation zwischen Product Owner und Team forciert. Geht man davon aus, dass intensivere Kommunikation eher zu dem gewünschten Produkt führt als ratende Entwickler, erhöht Scrum auch hier die Qualität.

Unbestandteil:  Automatisiertes Testen, kontinuierliche Integration
Scrum schreibt keine technischen Praktiken vor. Das viele der agilen Praktiken aus Extreme Programming eine sinnvolle Ergänzung sind, ist mittlerweile klar. Aber wer bringt nun dem Team TDD, kontinuierliche Integration, Collective Code Ownership und Buildmanagement bei?

Der ScrumMaster ist hiermit zu Recht in der Regel überfordert. Kann er das wissen vermitteln: Prima. Ansonsten kann zum Beispiel auch ein externer Coach mit einem starken Entwicklungshintergrund dazugezogen werden.

Fazit: Scrum sichert Softwarequalität durch seine Prozesselemente. Wie es dem Innenleben einer Software geht, wird nicht durchleuchtet. Die entstehenden Graphen zum Projektfortschritt spiegeln jedoch diese Qualität wieder. Der Rest ist Vertrauen in die Mannschaft. Wünscht das Team bei gewählten Maßnahmen Unterstützung, gibt es viele Lernarten, wie zum Beispiel die Study Group oder ein externer Coach.