Standardisieren von Aufgaben in Entwicklungsteams

Standards oder Kreativität?

Matthias Bohlen

© Shutterstock / Tashatuvango

Softwareentwicklung ist nicht Fertigung, das wissen wir. Es geht ums Finden von Rezepten – nicht ums Kochen nach Rezept. Teams verwenden daher gerne Taskzettel auf einem Board, das in generische Spalten wie „To-Do, Doing, Done“ eingeteilt ist. Das lässt ihnen die kreative Freiheit, die sie brauchen. Doch müssen wirklich bei jeder Story, die umzusetzen ist, die Tasks neu erfunden werden? Dadurch entgehen den Entwicklungsteams Selbstreflexion und Optimierungsmöglichkeiten. Mit dem richtigen Maß an Standardisierung geht das besser!

Die Mitglieder eines Entwicklungsteams, das starke Kundennachfrage spürt, haben viel zu tun. Damit bei der vielen Arbeit der Überblick nicht verlorengeht, verwenden sie in der Regel eine Wand mit Post-its oder Karteikarten oder ein elektronisches Taskboard-System. Ob nun physische oder elektronische „Wand“ – für jede Aufgabe, die zu tun ist, heften die Leute einen Zettel daran, den sie durch Spalten hindurchziehen.

Generisches Board, spezifische Zettel

Bei vielen Scrum-Teams, die ich in meiner Coachingtätigkeit beobachten durfte, heißen die Spalten an der Wand „Backlog, Doing, Verifying, Done“ oder etwas Entsprechendes (Abb. 1). Auf den Zetteln steht dann, was zu tun ist, z. B. „UI-Wireframes malen“, „Code entwickeln“, „Akzeptanztests schreiben“, „Abnahmetest mit dem PO machen“ usw. Manchmal steht sogar ganz genau darauf, welche Komponente betroffen ist, z. B. „Tabelle X anpassen“ oder „Reverse Proxy konfigurieren“. Für das, was auf den Zetteln stehen darf oder muss, gibt es meist keine Festlegung.

Damit das Team noch weiß, welche Taskzettel zu welcher User Story (oder sonstigem „Item of Customer Value“) gehören, teilen die Leute das Board in Zeilen ein und hängen einen großen Story-Zettel an den Anfang einer Zeile. So ist klar, dass alle Tasks in dieser Zeile zu jener Story gehören.

Gute Teams geben sich selbst eine „Definition of Done“, das bedeutet: Was verstehen wir unter „fertig“? Was muss also sichergestellt sein, wenn alle Zettel zu einer bestimmten Story die letzte Spalte erreicht haben? Typische Kriterien dafür sind: Oberflächen mit den Benutzern abgestimmt, Code geschrieben, Tests laufen auf dem Build-Server einwandfrei durch, der PO hat genickt usw. Eine „große DoD“ gilt in der Regel am Ende des Boards.

So weit verbreitet dieses Verfahren auch ist: Ich finde, das Ganze hat zu viele Nachteile, und wir können das mit einem anderen Vorgehen deutlich besser machen!

bohlen_kreativ_1

Abb. 1: Generisches Taskboard

Was ist das Problem?

Ein solches generisches Board mit spezifischen Zetteln hat verschiedene Nachteile:

Punkt 1: Es erzeugt Verschwendung. Über 60 Prozent der Zettel, die für eine Story geschrieben werden, sind identisch mit denen zur vorigen Story. Wir müssen immer wieder UI-Wireframes machen und mit den Nutzern abstimmen, wir müssen die Domänenmodelle erweitern, Code schreiben, auf Akzeptanz testen und viele andere solche Standardtätigkeiten mehr. Es lohnt sich gar nicht, dafür Zettel zu machen, denn sie sind bei jeder Story gleich.

Punkt 2: Solch ein Board verlangsamt das Lernen des Teams, weil der teameigene Prozess vor lauter Taskzetteln nicht sichtbar wird. Das Team sieht nicht explizit, dass eine Story einen bestimmten Flow durchläuft, z. B. Verstehen (Analysieren), Kriterien für die Akzeptanz aufstellen, Entwickeln, gegen die aufgestellten Kriterien prüfen, produktiv setzen, fertig. Dieser Flow wird gar nicht sichtbar, denn er ist auf viele kleine Zettel verteilt. Wenn nun in einem der Schritte dieses Flows (z. B. beim Akzeptanzkriterien aufstellen oder bei der Produktivsetzung) regelmäßig ein Problem auftritt, erkennt man als Teammitglied erst relativ spät, dass dahinter eine Gesetzmäßigkeit steckt. Meistens geht einem das Licht erst nach dem dritten Mal auf, und vor allem nicht sofort, sondern erst in der Retrospektive.

Punkt 3: Engpässe in den Prozessschritten werden versteckt. Das Team sieht nur, dass ein Taskzettel sich lange nicht bewegt hat, doch es wird längere Zeit nicht offensichtlich, dass es immer dieselbe Art von Zetteln ist, die sich nicht bewegt. Erst nach einigen Wochen merkt das Team: „Moment mal, immer wenn es um UI-Abstimmungen geht, dauert das ewig, verglichen mit den anderen Tätigkeiten, die wir so haben. Das liegt daran, dass wir uns den UI-Spezialisten mit drei Teams teilen müssen“.

Punkt 4: Der Fortschritt einer Story im Flow der Tätigkeiten ist aus solch einem generischen Board nicht ablesbar. Ist die Story noch weit vorn im Flow, z. B. beim Verstehen oder Akzeptanzkriterien definieren oder ist sie schon weiter hinten, kurz vor der Produktivsetzung? Man kann das nicht mit einem Blick erkennen, sondern muss ganz genau lesen, was auf den Zetteln steht, die zu dieser Story an der Wand hängen.

Punkt 5: Die „Fertig“-Kriterien aus der DoD werden erst am Ende geprüft, wenn die Story auf „Done“ gehen soll. Ist irgendein Kriterium nicht erfüllt, das zu einem Arbeitsschritt gehört, der weit vorn im Flow liegt (z. B. Akzeptanzkriterien definieren), muss man noch einmal ganz zurück und diese Tätigkeit nachholen. Dadurch erzeugt man nochmals Aufwand, weil spätere Schritte im Flow (z. B. Code schreiben und Akzeptanz testen) dann ebenfalls noch einmal angefasst werden müssen. Das hätte man am besten ein paar Tage früher geprüft, als das Team noch mitten in der Arbeit an der Story steckte.

Spezifisches Board

Das können wir wesentlich besser machen! Aus den Standardtätigkeiten des Teams macht man am besten Spalten auf dem Board und schreibt gar keine Zettel mehr dafür. Man hängt die Story dann nicht mehr an den linken Rand des Boards, sondern man lässt den Story-Zettel von links nach rechts durch die Standardspalten laufen, z. B. Verstehen, UI abstimmen, Akzeptanzkriterien festlegen, Entwickeln, Akzeptanz prüfen, produktiv setzen und fertig. Falls nun irgendetwas für die Story getan werden muss, das nicht diesen Standardtätigkeiten entspricht, hängt das Team zusätzlich kleinere, andersfarbige Zettel dazu, die den Story-Zettel ergänzen. Das Ganze sieht dann aus wie in Abbildung 2.

bohlen_kreativ_2

Abb. 2: Spezifisches Taskboard

Diese Art von Board erledigt sofort die Probleme 1 und 2. Aufwand für Zettelschreiberei wird eingespart, und der Flow der Tätigkeiten wird sichtbar. Probleme, die in einem bestimmten Schritt auftreten, passieren ab jetzt immer an derselben Stelle auf dem Board. Das Ortsgedächtnis in den Köpfen der Teammitglieder erkennt: „Oh, an dieser Stelle stoppen die Stories jedes Mal, also kann doch da irgendwas nicht stimmen!“. Der Lerneffekt entsteht noch am selben Tag, nicht erst in der Retrospektive. Korrekturmaßnahmen kann das Team also sofort einleiten.

Auch Punkt 3 (Engpässe bei bestimmten Tätigkeiten) wird auf solch einem Board schneller offensichtlich. „Aha, unsere Entwickler sind richtig schnell, und beim Produktivsetzen im Betrieb stauen sich jede Menge Stories auf“. Oder „Nanu, wir haben als Entwickler plötzlich keine gut genug aufbereiteten Stories mehr, die wir sofort umsetzen können, da muss doch in der Spalte vorher … ach so, unsere Anforderungsanalystin ist ja im Urlaub!“.

Punkt 4 ist für den Product Owner und seine Stakeholder, die ab und zu vorbeikommen, jetzt auch viel einfacher gelöst: Man kann den Fortschritt einer Story einfach anhand der Position des Story-Zettels erkennen: Je weiter rechts sie hängt, umso früher wird die Story fertig sein. Auch die Zahl der Zettel auf dem Board ist deutlich kleiner, man erkennt wesentlich besser, wie der aktuelle Stand ist.

Punkt 5, das Prüfen der DoD, wird stark abgekürzt: Es gibt keine große DoD mehr, die am Ende des Boards gelten muss, sondern es gibt kleine DoDs für jede Spalte des Boards. Beispiele:

  • Definition von „verstanden“
  • Definition von „UI abgestimmt“
  • Definition von „Akzeptanz festgelegt“
  • Definition von „entwickelt“
  • Definition von „geprüft“
  • Definition von „produktiv“

und so weiter. Diese kleinen DoDs lassen sich meist in ein, zwei Sätzen beschreiben, die man als Untertitelzettel unter den Namen der Spalte hängt, damit sie jederzeit präsent sind.

Man kann das zu einem kleinen, sehr schnell funktionierenden Peer-Review-Ritual ausbauen: Wenn ein Teammitglied einen Story-Zettel in einer Spalte um 90° dreht und dadurch senkrecht hängt, heißt das: „Ich habe die Tätigkeit, die im Namen der Spalte steht, abgeschlossen. Jemand anders kann ihn gegen die DoD der Spalte prüfen, in die nächste Spalte ziehen und dort bearbeiten.“ Hierbei ist wichtig, die Anzahl der Zettel pro Spalte (Work in Progress) zu limitieren, damit sich die Spalte nicht aus lauter Faulheit mit senkrecht hängenden Zetteln füllt.

Apropos Work-in-Progress-Limits: Immer wenn jemand einen Zettel in eine Spalte ziehen möchte, deren WIP-Limit schon erreicht ist, sollte er stoppen und die Teamkollegen bitten, ihm zu helfen, zuerst Platz zu schaffen. Man findet sich zu 2 bis 3 Leuten zusammen, analysiert kurz, warum sich der Stau von Zetteln gebildet hat, behebt ihn und macht dann erst weiter. Das nennt man auch „einen Qualitätszirkel bilden“. Solche Qualitätszirkel reagieren wesentlich schneller als eine Retrospektive. In der „Retro“ hat man dann deutlich mehr Zeit für strategische Themen, die für längerfristige Verbesserungen sorgen sollen. Diese würde man im Qualitätszirkel, der eher taktisch orientiert ist, im Regelfall noch nicht sehen. Beides ergänzt sich hervorragend.

Hindernisse

Wenn dieses Verfahren so viele Vorteile hat, warum nutzen wir es dann nicht sofort und immer? Es treten bei der Umsetzung einige Hindernisse auf, die viele Teams davon abhalten, das konsequent durchzuziehen. Einige davon möchte ich hier nennen.

Hindernis 1: Die Spalten auf einem Board liegen linear nebeneinander und beschreiben einen Flow. Manchmal sind die Tätigkeiten aber nicht linear anzuordnen. Auch für eine noch nicht komplett verstandene (analysierte) Story könnte man schon UI-Wireframes erstellen oder erste Akzeptanzkriterien festlegen. Das Team würde sich dann fragen: Na, wohin hänge ich denn nun den Story-Zettel? In welcher Haupttätigkeit sind wir denn nun?

Meist liegt es daran, dass entweder die Spalten nicht alltagsgerecht modelliert sind oder dass die Stories zu inhaltsreich sind. Das Team sollte in diesem Fall prüfen, ob die Spalten wirklich dem Teamalltag entsprechen und sie an den tatsächlichen Flow anpassen. Ein Team, das ich kürzlich coachte, fand beispielsweise heraus, dass bei ihnen Modellieren nicht vor Programmieren kommt, sondern gleichzeitig in sehr kurzen Zyklen von wenigen Stunden stattfindet. Deshalb lohnte es sich nicht, zwei Spalten dafür zu machen, sondern nur eine. Das Team sah auch, dass die Stories sehr lange in „Akzeptanzkriterien definieren“ und in „Akzeptanz testen“ hingen, was sie zu dem Schluss brachte, dass die Stories zu viel Inhalt auf einmal hatten und besser aufgeteilt werden mussten. Eine Erkenntnis, die sie mit Einzelzettel pro Task erst viel später gehabt hätten.

Hindernis 2: Elektronische Tools wie z. B. Jira lassen eine Änderung der Spalten nicht schnell genug zu. Meist wird ein echter Toolexperte dafür gebraucht, vor allem dann, wenn mehrere Teams mit demselben Workflow arbeiten. Versucht ein Team, den Experten dazu zu bringen, den Workflow im Tool so zu ändern, dass er für dieses Team passt, wird das Tool in der Regel fragen: „Moment mal, was soll ich mit den Tickets machen, die den anderen Teams gehören? Soll ich sie in neue Spalten verschieben? Wenn ja, in welche?“. Diese Frage allein hält Teams davon ab, überhaupt eine solche Änderung zu versuchen.

Abhilfe dafür wäre: Ein Workflow pro Team konfigurieren – keine geteilten Workflows mehr! Besser jedem Team das Recht auf seinen eigenen Workflow geben als durch übertriebene Standardisierung einen Workflow zu schaffen, der für niemanden so richtig passt und der alle Teams verlangsamt und konfus macht.

Hindernis 3: Ein Board mit spezifischen Spalten muss wirklich dem Team gehören. Ein Team muss ein Interesse daran haben, diese Spalten festzulegen und öfters an den tatsächlichen Alltag anzupassen. Wenn die Teammitglieder keinen Spaß am Denken in Systemen und Prozessen haben oder darin keinen genügend großen Vorteil für ihre Arbeit sehen, wird es immer an einem „Prozesshansel“ hängen bleiben, der sich darum zu kümmern hat (bei Scrum wäre das der Scrum Master). Solch einer wird das Team ständig an die Einhaltung der Richtlinien für das Board erinnern müssen, was einfach keinen Spaß macht und deshalb nach einiger Zeit unterbleibt. Noch schlimmer wird’s, wenn nicht das Team das Board definiert, sondern der Prozesshansel. Dann identifizieren sich die Teammitglieder erst recht nicht damit, und das Board wird veralten. High-Performance-Teams mit solch einem Board gibt es eben nicht umsonst: Alle müssen daran mitarbeiten.

Ausblick

Apropos High-Performance-Teams: Teams, die aktiv auf den eigenen Prozess achten, gewinnen nach einiger Zeit richtig Spaß daran, sich zu optimieren. Sie möchten eben auch mal am System anstatt immer nur im System arbeiten. Sie erstellen zum Beispiel kurze How-Tos, die beschreiben, wie eine der Standardtätigkeiten funktioniert. Solch ein How-To kann man einem neuen Teammitglied in die Hand drücken und ihm kurz zeigen, was das live bedeutet. Das neue Mitglied wird dann wesentlich schneller produktiv. Auch für alte Hasen ist ein kurzer Blick ins How-To nützlich, wenn es sich um Tätigkeiten handelt, die diese Person nur selten durchführt.

Spezifische Boards, explizite Spalten, WIP-Limits, How-Tos … all das sind Möglichkeiten zur Prozessverbesserung, um besser zu skalieren, wenn die Firma wächst. Zusammen mit entsprechenden Verbesserungen in der Architektur und in der Organisation werden solche Firmen unschlagbar.

Aufmacherbild: Standards Concept via Shutterstock / Urheberrecht: Tashatuvango

Verwandte Themen:

Geschrieben von
Matthias Bohlen
Matthias Bohlen
Matthias Bohlen arbeitet als Experte für effektive Produktentwicklung. Teams engagieren ihn als Coach in vielen Projekten, um Prozesse, Architektur und Organisation für sich selbst zu finden und aufzustellen. Matthias Bohlen hilft aktuell auch Teams, die gerade die Startup-Phase verlassen und zu einer erfolgreichen Company skalieren. Er hat für Sie zu dem Thema weiteres Material zusammengestellt, das Sie unter http://scaletonextlevel.com finden können.
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu: