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.

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?

Reflektion des 3. Treffen der Scrum Usergroup Rhein-Neckar

Das 3. Treffen der Scrum Usergroup Rhein-Neckar stand ganz unter dem Zeichen „Agile Games“. Als Ziel für unser Treffen hatten wir uns den Austausch über solche „Spiele“ gesetzt, die zur Vermittlung agiler Werte und Prinzipien geeignet sind. Auch Teambuilding-Spiele generell haben wir mit dazugenommen.

Jeder Teilnehmer hatte die ihm bekannten Spiele vorgestellt. Es kam eine stattliche Liste zusammen:

  • Marshmallow Challenge
  • X/Y Game
  • Planning Poker
  • Magic Estimation
  • 60 Schritte Spiel
  • Ballpoint Game
  • Name Game von Hendrik Knieberg
  • Kanban Game of Ones
  • NASA Übung
  • Fearless Journey

Die NASA Übung haben wir uns dann in der Gruppe vorgenommen. Bei diesem Spiel geht es darum, zu zeigen, dass Teamarbeit bessere Ergebnisse liefert als Einzelarbeit. Besonders auch mit mehreren Teams schön, um ein wenig Wettbewerb und Vergleich zu bieten.

Freundlicherweise konnten wir die Räume der marken mehrwert – brand added value AG in Heidelberg für unser Treffen nutzen und einen Einblick in die Produktion des softwaregetriebenen Geschäftsmodells der Firma erhalten.

Das Spiel Fearless Journey haben wir für den 4. Scrumtisch Rhein-Neckar geplant. Wer Interesse daran hat, wie man jemanden für einen Change-Prozess neue Ideen mitgeben kann, ist herzlich eingeladen und jeder der mehr über Scrum erfahren möchte oder bereits viel Erfahrung hat natürlich ebenfalls.

In kleiner Runde endete der Abend dann mit einem agilen Feierabendbier bei spannenden Gesprächen mit schönen Einblicken in die Scrum-Praxis.

Für unser nächstes Treffen: Welche Spiele fehlen noch? Wer kennt noch spannende Lernerfahrungen im Agile Game Format?

Testgetriebene Entwicklung lernen

Viele Unternehmen, die sich im agilen Ökosystem bewegen, arbeiten mit entsprechenden unterstützenden Engineering Practices. Eine davon ist die testgetriebene Entwicklung.

Im Rahmen der Study Group können Mitarbeiter sich gemeinsam weiterbilden und zu gewünschten Themen auch projektübergreifend austauschen. Nach der Abstimmung beim Kickoff, hat sich die Gruppe für eine Vertiefung in testgetriebener Entwicklung (TDD) entschieden.

Ich habe eine kurze definierte Agenda vorbereitet, um der Gruppe viel Raum zu geben, Inhalte und Quellen zu identifizieren. Sehr erkenntnisreich war ein Scaling Dance zum Thema „Wieviel Kenntnisse sind zum Thema bereits vorhanden?“ und „Wieweit möchten wir überhaupt bei dem Thema kommen?“. Es entstand so schnell ein Bild davon, wo die Gruppe steht und bis wo die Entwicklung reichen soll.

Ausgehend von dieser Erwartungshaltung haben wir mit verdeckter Stichwortabfrage und anschließender Priorisierung den folgenden Weg beschlossen:

  • Gemeinsames Lesen von Roy Osheroves Buch „The Art of Unit Testing
  • Zum Sinn von Unit Tests Blogdiskussion von Golo Roden und Ralf Westphal (Beitrag 1, Beitrag 2, Beitrag 3)
  • Einen Überblick über TDD und BDD Frameworks zusammenstellen
  • Ein oder mehrere Coding Dojos veranstalten mit dem angelesenen Wissen

Die Gruppe hat noch deutlich mehr Ideen gesammelt, die zur Vertiefung danach weiter verfolgt werden können. Von Fachartikeln über die Einladung anderer erfahrener Entwickler waren noch weitere schöne Ideen dabei.

An dieser Stelle interessiert mich natürlich: Was sind Eure wertvollsten Ressourcen, um TDD zu lernen?

Agile goes Europe

While participating at a team development seminar provided by boris gloger in Munich I had the chance to join the just founded Munich Agile & Lean Network group. The idea of an agile and lean network with an european focus was spreaded by Jurgen Appelo who I met at his great Management 3.0 seminar in Hamburg earlier this year. As I am half dutch I appreciate his experience and connection to the community in the Netherlands pushing forward some new ideas for the agile community and so I decided to support his initiative and join this meeting.

At least 15 people met yesterday at a bar in Munich to find out in which ways we can interact and contribute to this network. Ilker, Christian and Wolfgang hosted the session and opened up a world café based on three items:

  • Connect Global
  • Stay Local
  • Call to action

So we discussed which elements were great to share with other european agile communities and how our local engagement could look like. The hosts will deliver and forward our content to our german ambassdor who will take Germanys contribution to the XP Days 2011 in Madrid.

To give a sneak peak on some ideas which I favored most:

  • Agile Couchsurfing
  • European ScrumMaster Exchange
  • Connecting to local communities of practice

I am looking forward to other countries and cities contributions. If you want to participate have a look at Jurgens blog for detailed information.

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.

COVID-19 AktionMoment noch, spare 150,- €* bei Newsletter-Anmeldung

Wir unterstützen Dich + Deine Firma mit unseren Scrum-Zertifizierungskursen, um erfolgreich auf Veränderungen zu reagieren.

Melde Dich jetzt für den Agile Growth® Newsletter an + erhalte sofort Deinen Rabattcode über 150,- Euro für Deine nächste Online- oder Präsenz-Seminarbuchung. 

* gültig bei Seminar-Teilnahme im Jahr 2021, kombinierbar mit Frühbucher-Rabatt für Präsenz- und Online-Seminare.