Kolumne: DevOps Stories

DevOps Stories: Ein Plädoyer für physische Informationsvisualisierung

Konstantin Diener

Agilität, Management 3.0, New Work oder DevOps – all diese Bewegungen verändern die Art und Weise, wie Softwareentwicklung organisiert wird. Wenn man ihren Denkmustern und Ideen konsequent folgt, beeinflussen sie stark die Kultur des Unternehmens. Über solche Kulturveränderungen berichtet die Kolumne DevOps Stories. Heute hat sich Lukas mit seinem Kumpel Arne in seinem Lieblingsrestaurant getroffen. Es dauert nicht lange, bis ihr Gespräch beim Essen auf die Arbeit kommt.

  • Arne: „Was benutzt ihr eigentlich für ein Tool, um eure User Stories und Tasks zu verwalten?
  • Lukas: „Wie meinst du das?
  • Arne: „Verwendet ihr Jira, Trello oder Ähnliches?
  • Lukas: „Nein, wir schreiben unsere User Stories auf DIN-A5-Vordrucke und befestigen sie mit Magneten an der Wand. Die Tasks schreiben wir auf Post-its.
  • Arne: „Das würde bei uns gar nicht gehen!
  • Lukas: „Warum?
  • Arne: „Wir haben z. T. so viele Tickets in einer Swimlane, dass unsere Wand dafür nicht hoch genug wäre. Wie du weißt, entwickeln wir Software für Kunden – und der Kunde muss die Stories abnehmen. Da sammelt sich meist einiges an.
  • Lukas: „Wir stehen morgens beim Standup vor dem Board und besprechen die Stories und Tasks, indem wir draufzeigen.
  • Arne: „Das machen wir am Monitor.
  • Lukas: „Seht ihr bei so vielen Tickets denn alles, oder könnt ihr – wenn ihr alles seht – die Tickets dann noch lesen?
  • Arne: „Nee, dafür hat einer die Maus und scrollt an die passende Stelle. Ein anderes Team hat einen großen Flatscreen in seinem Büro. Da muss aber auch jedes Mal jemand scrollen.
  • Lukas: „Das stelle ich mir umständlich vor. Kommt es nie vor, dass versehentlich zwei Teammitglieder mit demselben Task anfangen?
  • Arne: „Das stimmt schon. Wir haben es immer wieder, dass zwei Kollegen am selben Thema arbeiten. Unser Scrum Master meinte, unsere Standups müssten einfach exakter werden, um das zu vermeiden. Wir rufen meist in den Raum rein, wenn wir mit einem Task beginnen. Ich vergesse es aber immer wieder. Wo legt ihr denn Zusatzinfos zu einer Story ab – so wie Absprachen mit dem Kunden?
  • Lukas: „Wenn irgendetwas wichtig ist, aber nicht auf dem Vordruck Platz findet, kleben wir Post-its an das DIN-A5-Blatt oder schreiben hinten was drauf.
  • Arne: „Passt da alles drauf?
  • Lukas: „Das Problem hatten wir noch nie. Ruben, unser Scrum Master, würde vermutlich sagen: ‚Wenn es nicht auf die Karte passt, ist es eh zu groß, um es zu begreifen‘. Ich weiß, dass ein anderes Team Zusatzinfos in Jira pflegt. Die haben als führendes Medium aber trotzdem ein großes Board in ihrem Büro. Auf den Karten stehen die Ticketnummern.
  • Arne: „Spannend! Und das in einer IT-Firma …
Abb. 1: Lukas und Arne unterhalten sich beim Abendessen

Abb. 1: Lukas und Arne unterhalten sich beim Abendessen

Arbeit visualisieren, um sie zu „begreifen“

Arne und Lukas arbeiten in ihren Teams beide mit (Task-)Boards – wie alle agilen Teams, die ich kenne. Jedes Scrum-Buch hat mindestens einen Abschnitt zum Aufbau und der Verwendung eines Scrum Boards. Das ist insofern bemerkenswert, als im Scrum Guide das Wort Board nicht ein einziges Mal auftaucht. In Kanban spielt das Board hingegen eine zentrale Rolle. Es dient dazu, den Fluss der Arbeit zu visualisieren [1], Probleme und Engpässe zu erkennen und zu beheben. Die Visualisierung hilft dem menschlichen Gehirn, Muster und Anomalien zu erkennen und die Arbeit im wahrsten Sinne des Wortes besser zu begreifen. Im Buch „Personal Kanban“ [2] wird die Geschichte einer Frau erzählt, die von ihrer Arbeit erdrückt zu werden droht. Sie kann erst wieder klar denken, als sie sich alle Aufgaben von der Seele geschrieben hat, die ihr im Moment einfallen. Vorher sieht sie einfach nur einen unüberwindbaren Berg an Arbeit vor sich. Durch die Visualisierung wird die Arbeit für sie greifbar, sie kann mit der Priorisierung und Umsetzung beginnen.

Die Teams von Arne und Lukas verwenden also Boards, um einen Überblick über ihre Arbeit zu bekommen, sie zu strukturieren und zu priorisieren.

Information Radiators entlasten das Team

Es gibt allerdings einen maßgeblichen Unterschied. Lukas‘ Team verwendet ein großes Whiteboard mit (bunten) Klebezetteln, um die Arbeit zu visualisieren. Wer schon einmal ein physisches Board dieser Art gesehen hat, weiß, dass es automatisch Aufmerksamkeit bei den Personen im Raum erzeugt. Gibt es eine besonders hohe Anzahl roter Klebezettel? Ballen sich alle User Stories in einer bestimmten Swimlane (z. B. durch ein übervolles Backlog oder aufgestaute Reviews)? Alistair Cockburn spricht in diesem Zusammenhang von „Information Radiators“, die die Informationen wie alte Heizungsradiatoren förmlich ausstrahlen [3].

Auch Arnes Team verwendet ein Board. Dieses elektronische Board ist nicht im Raum präsent und strahlt nicht einfach Informationen aus. Um es sich anzusehen, müssen Arne und seine Kollegen sich explizit im Tool anmelden. Boards dieser Art sind in der Regel das, was Marcus Hammarberg und Joakim Sunden als „Information Refrigerators“ bezeichnen [4] und die folgenden Implikationen mit sich bringt:

  • Ich muss wissen, dass es in dem Tool eine potenziell interessante Information gibt.
  • Ich muss wissen, wo ich nachsehen muss.
  • Ich muss in der Lage und berechtigt sein, das Tool zu benutzen.

Insgesamt kann man sagen, dass es definitiv aufwendiger ist, sich eine Information aus dem Tool zu besorgen, als eben auf einem physischen Board nachzusehen. Möchte jemand aus Arnes Team wissen, woran die Kollegen gerade arbeiten, scheut er diesen Aufwand möglicherweise und fragt die Kollegen lieber (Störung bei der Entwicklung). Ein Externer hat vermutlich keinen Zugriff auf das Tool und muss Arne und seine Kollegen immer nach den Infos fragen, die er braucht. Das Ziel von Information Radiators ist, dass das Team nicht mit Fragen gelöchert wird, sondern sich jeder selbst informieren kann.

Ein Information Radiator muss eine Mindestgröße haben, um wertvoll zu sein

Ein anderes Team in Arnes Firma hat dieses Problem erkannt und mit einem Monitor versucht, sein elektronisches Tool in einen Information Radiator zu verwandeln. Dieser Ansatz kann funktionieren, wenn man eine wichtige Eigenschaft von Information Radiators beachtet: die Größe. Das Whiteboard strahlt deshalb Informationen aus, weil man es schlicht nicht übersehen kann. In vielen Fällen sind Monitore aber zu klein, um denselben Effekt zu erzielen. Dass das Board eine ausreichende Größe hat, ist noch aus einem anderen Grund wichtig. Der komplette Umfang relevanter Arbeit sollte auf einen Blick sichtbar sein, sonst sehen wir wieder nur einen Teil, und die Visualisierung unterstützt uns nicht mehr so gut beim Begreifen. Arnes Team kann die Informationen im Standup zum Teil gar nicht lesen und muss scrollen.

DevOpsCon Istio Cheat Sheet

Free: BRAND NEW DevOps Istio Cheat Sheet

Ever felt like service mesh chaos is taking over? Then our brand new Istio cheat sheet is the right one for you! DevOpsCon speaker Michael Hofmann has summarized Istio’s most important commands and functions. Download FOR FREE now & sort out your microservices architecture!

Viele Teams sehen es als Vorteil an, dass ein elektronisches Tool Statistiken und Kennzahlen automatisch berechnen und visualisieren kann. Das Team muss sich nicht mit dem Zeichnen des Burndown-Graphen plagen, er wird direkt im Tool berechnet. Dieser Graph wird jeden Tag ausgedruckt und in den Teamraum gehängt. Die Ausdrucke sind aber in der Regel viel zu klein, um als Information Radiator zu dienen [5].

Physische Boards fördern Interaktion, Nachdenken und Experimente

Am Beispiel des Burndown-Graphen kann man sehen, dass durch den Einsatz eines Tools noch ein wichtiger Aspekt verloren geht: die Interaktion. Streng genommen hat jeder von Arnes Kollegen sein eigenes Board auf seinem Rechner, das auf die Rechner der anderen synchronisiert wird. Niemand im Team bekommt mit, wenn Arne mit seinem Board interagiert. Wenn Arne aufsteht und am physischen Board einen Task in „in Bearbeitung“ zieht, bekommt das Team das mit und kann darauf reagieren („Ich hatte doch im Standup gesagt, dass ich den Task bearbeite“).

Diese Interaktion führt nicht selten dazu, dass das Team einen Schritt zurücktritt und über seinen Prozess nachdenkt. Unterstützt wird dieses Nachdenken durch die physischen Limitierungen des Boards. Arne sagt, dass eine Swimlane bei ihnen so voll ist, dass sie an keine Wand passen würde. In einem elektronischen Tool ist das kein Problem. Deshalb wird das Team viel seltener darüber nachdenken, ob es denn wirklich sinnvoll ist, so viele Work Items zu haben, die auf ein Review warten. Sobald das Team Klebezettel auf den Teppich klebt, tritt normalerweise dieser Denkprozess ein.

Abb. 2: Die Restriktionen des physischen Boards laden zum Nachdenken ein

Abb. 2: Die Restriktionen des physischen Boards laden zum Nachdenken ein

In Kanban dient die Visualisierung dem Zweck, den Ablauf der Arbeit kontinuierlich zu verbessern. Diese Veränderung ist mit einem physischen Board in der Regel sehr viel einfacher möglich („Lass uns mal die Tickets nach xyz gruppieren!“, „Komm wir probieren mal eine weitere Swimlane aus!“). Wenn etwas einfacher ist, tun wir es häufiger. Physische Boards wirken also als Katalysator für Experimente am Prozess.

Das ist auch der Grund, weshalb wir uns selbst in der IT-Branche nicht schämen müssen, physische Boards zu verwenden – worauf Arne am Ende des Dialogs anspielt. Softwaresysteme spielen ihre Stärken bei standardisierbaren Prozessen aus, Boards unterstützen einen kreativen Prozess und Kommunikation [4].

Oft hilft ein Miteinander von physischen und elektronischen Boards

Elektronische Tools kommen zugegebenermaßen in diesem Artikel nicht gut weg, obwohl sie durchaus ihre Berechtigung haben. Ich erlebe allzu oft, dass aufgrund der vermeintlichen Vorteile ein solches Tool eingesetzt wird, ohne dass sich das Team der Aspekte bewusst ist, die es mit dieser Entscheidung verliert. Bei der nächsten Entscheidung lohnt es sich, auf diese Aspekte zu achten. Für ein verteiltes Team kann es z. B. auch sinnvoll sein, regelmäßig Fotos eines physischen Boards auszutauschen oder eine Webcam einzusetzen.

Arne möchte die Stärken der beiden Alternativen kombinieren, ähnlich wie es ein anderes Team in Lukas̕ Firma tut. Er wird mit einem physischen Board zur Visualisierung und Koordination der Arbeit experimentieren und auf den Klebezetteln die Ticketnummern des elektronischen Tools vermerken, in dem die große Menge an Zusatzinformationen steht.

Geschrieben von
Konstantin Diener
Konstantin Diener
Konstantin Diener ist CTO bei cosee. Sein aktueller Interessenschwerpunkt liegt auf selbstorganisierten Teams, agiler Unternehmensführung, Management 3.0 und agiler Produktentwicklung. Daneben entwickelt er noch leidenschaftlich gerne selbst Software. Twitter: @onkelkodi
Kommentare

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
4000
  Subscribe  
Benachrichtige mich zu: