Technische Schulden spielerisch verstehen

Technische Schulden sind bewusste oder versehentliche Schwächen im Code, die durch mangelnde Kommunikation, Qualifikation oder übereilte Veröffentlichung entstehen und bei ausbleibendem Refactoring konstant anwachsen. So ist die Wichtigkeit des Thema nicht nur für Außenstehende, sondern auch für ein Softwareteam teilweise schwer greifbar. In meinem Blog Beitrag habe ich meinen Impuls Vortrag veröffentlicht, in dem ich mich damit beschäftigt habe, wie der richtige Umgang mit technischen Schulden sein kann. Um aber überhaupt das Verständnis für diese Problematik zu schaffen, bietet es sich an dies spielerisch erlebbar zu machen.

Bisher habe ich dafür gerne die Scrumble Simulation auf den Tisch gebracht, da dort das Thema technische Schulden sehr gut integriert ist. Allerdings ist die Simulation nicht remote spielbar. Daher hat es mich sehr gefreut, dass ich dem Buch “Agile Games – Das Spielebuch für agile Trainer, Coaches und Scrum Master” eine remotefähige Simulation gefunden habe, um sich das Thema technische Schulden spielerisch anzunähern und auch die Auswirkungen auf das Produkt und Lieferzeiten erleben zu können.

Vorbereitung

Pro Team (4-6 Personen) ein gut gemischtes Kartendeck von 1-100 sowie Dubletten von 1-30 und ein Spielfeld mit 15 Karten breit und 2 Karten breit. Dies entspricht 3 DINA 4 Blättern. Remote kann du dies mit Hilfe eines Whiteboards umsetzten. Ansonsten sind die Kartendecks von The Mind und The Game gut geeignet (wem das Zusammenstellen nicht zu umständlich ist).

Ablauf

Ziel des Spiels ist es, möglichst schnell ein absolut fehlerfreies Produkt zu bauen. Das Produkt ist ein fehlerfrei sortierter Kartenstapel mit den Karten von 1 bis 100 (ohne Dubletten). Jede einzelne Karte stellt eine Funktionalität (Feature bzw. User Story) dar. Die Funktionalitäten bauen technisch aufeinander auf, sodass das Produkt nur funktioniert, wenn es keine Fehler gibt.

Insgesamt werden 2 Runden mit jeweils vier Phasen der software-basierten Produktentwicklung gespielt: Development, Deployment, Debugging, Release. Dabei besteht jedes Team aus folgenden Rollen:

• 2-3 Entwicklern
• 1 Qualitätsmanager
• 1 Zeitnehmer (Scrum Master)
• 1 Kunde (Product Owner)

Der Kunde kann bei zu wenig Teilnehmern auch vom Moderator übernommen werden.

Runde 1

Generelle Regel in dieser Runde: Jede Karte, die einmal im Spielfeld liegt, darf nicht mehr bewegt werden. Ziel ist es, möglichst schnell Features zu entwickeln, und es gibt keine Zeit, existierende Features zu bewegen oder den Code anzufassen. Es dürfen nur Personen, die in der jeweiligen Phase arbeiten, Karten berühren.

Phase 1 – Development

Aufgabe für das Entwicklungsteam in dieser Phase ist es, die Features möglichst schnell zu produzieren. Dazu zieht das Entwicklerteam immer eine Karte vom Kartenstapel und legt sie offen auf das Spielfeld. Jede gelegte Karte symbolisiert ein entwickeltes Feature. Dabei dürfen die Karten nur auf dem Spielfeld (Produktionsumgebung) abgelegt werden. Dubletten (doppelter Code) werden rausgeworfen und außerhalb des Spielfeldes abgelegt. Wenn alle Karten des Kartenstapel gespielt sind, endet die erste Phase. Der Zeitnehmer notiert die gestoppte Zeit von dieser Phase.

Phase 2 – Deployment

Einer der Entwickler deployed anschließend das Produkt, in dem er Karte für Karte nimmt und zu einem aufsteigend sortierten Kartendeck stapelt. Die Karte mit der Nummer 1 markiert den Beginn und die Karte 100 das Ende. Dabei darf er Dubletten entsorgen (neben das Spielfeld legen). Der Zeitnehmer notiert auch wieder hier die Zeit, wenn die Karte 100 an obersten Stelle liegt.

Phase 3 – Debugging

Der Deployer übergibt das sortierte Kartendeck an den Qualitätsmanager. Dieser kontrolliert das Produkt, entfernt die Dubletten und sortiert das Deck ggf. um. Dabei muss jeder Fehler (falsch sortierte Karte oder Dublette) gezählt werden, Der Zeitnehmer notiert auch hier wieder die gestoppte Zeit von dieser Phase.

Phase 4 – Release

In der letzten Phase wird released. Der Kunde bzw. Product Owner bekommt das fertige Produkt (einen aufsteigend sortierten Kartenstapel ohne Dubletten) in die Hand überreicht. Er überprüft den Kartenstapel erneut. Auch hier wird jeder Fehler notiert.

Runde 2

Generelle Regel in dieser Runde: Der Ablauf der vier Phasen sind identisch, mit einem Unterschied: Es ist nun erlaubt, Karten auf dem Spielfeld beliebig zu verschieben, also Code und Features auch nach der Entwicklung nochmal anzufassen. Weiterhin gilt die Regel, dass nur die Personen, die in der jeweiligen Phase arbeiten, Karten berühren dürfen.

Learning: Obwohl in der zweiten Runde mehr Karten (Code) mehrmals angefasst werden musste, läuft dieser Durchgang insgesamt effizienter und am Ende mit weniger Fehler ab. Vergleicht hierzu am besten die notierten Ergebnisse (Zeit und Anzahl Fehler ) der Runde miteinander.

Debriefing

Die folgenden Fragen können dich beim Debriefing unterstützen;

• Wie habt ihr die Rollenteilung wahrgenommen?
• Welcher Unterschied habt ihr in eurer Arbeitsweise im Vergleich der jeweiligen Runde festgestellt?
• Welche Auswirkungen hatte die unterschiedliche Arbeitsweise auf da Produkt? Die Auswertung der gemessenen Ergebnisse der Runde können dabei hilfreich sein.
• Was ist das Optimum aus Arbeitszeit und Fehlern?