Ich kann mich noch sehr gut an meinen ersten Arbeitstag erinnern: viele Eindrücke, nette Kollegen – tolles Gefühl. Diesen ersten Tag werde ich aber nie vergessen, weil im Gespräch mit einem Kollegen folgender Satz gefallen ist: “Einfach mal machen.” Kurz, aber dennoch unheimlich stark. Nicht immer nur reden, planen, denken, überlegen sondern einfach mal machen. Getreu diesem Motto möchte ich mithilfe dieses Beitrages die Vor- und Nachteile aufzählen, wenn es darum geht, Papier mit Software zu vergleichen in Bezug auf unser Scrum Taskboard.
(Flur) Transparenz
Sicherlich ein KO-Argument für ein Papier-Taskboard. Eines der wichtigsten Merkmale von Scrum ist die sogenannte Transparenz. Mit Transparenz ist gemeint, dass der Status des Teams schonungslos offengelegt wird, und zwar für jeden, den das interessiert. Wenn also Herr Stromberg seinen Chefsessel verlässt, um seinen Untertanen eine Visite zu gewähren, dann kann er sich auch direkt einen Einblick der aktuellen Lage verschaffen. Wenn Frau Heisterkamp abends zum Putzen kommt, dann kann auch sie sich einen Einblick über die aktuelle Lage verschaffen (ob sie damit was anfangen kann, steht auf einem ganz anderen Blatt). Kurzum, das Team weiß, dass jeder sehen kann, wie gut/schlecht es seine Arbeit erledigt. Das motiviert. Leider verpufft diese Motivation, sobald man den Status nur am eigenen Bildschirm sieht. Denn: die Transparenz ist dann nicht mehr gegeben. Interessierte haben dann keinen Einblick mehr in den Status oder müssen sich erst umständlich einloggen. Große Monitore helfen hier leider nur bedingt: zu klein ist meist die Schrift und zu oft ist der Monitor ausgeschaltet, er könnte ja womöglich Strom verbrauchen.
Papier 1 : Software 0
Flexibilität
Was versteht man unter Flexibilität? Meiner Auffassung nach bedeutet Flexibilität, wie gut/flexibel sich das Tool (unabhängig, ob es auf Papier oder Software basiert) in meinen Workflow integriert. Ein auf Papier basierendes Taskboard ist sehr flexibel, man kann es beliebig gestalten. 4 Meter lang und 1 Meter breit? Kein Problem. Mal schnell eine Spalte hinzufügen für den PO? Kein Problem. Wir brauchen nur ein bisschen Papier, ein bisschen Klebeband und ganz schnell ist das Taskboard an die Wünsche angepasst. Aber ist das Workflow-Flexibilität? Meiner Meinung nach nur bedingt. Kann ich ein Papier-Taskboard mit einem Bug Tracking System kombinieren? Kann ich es automatisch durch das PO Backlog füllen lassen? Kann ich gar einen Build starten? Das sind alles Aspekte, die Software vorbehalten sind. Je nach Tool und Hersteller funktioniert diese Workflow Integration mal besser, mal schlechter. Allgemein gilt: Produkte desselben Herstellers funktionieren (meist) herrvorragend zusammen. Beispiel Atlassian: automatische Integration des Wikis (Confluence) mit dem Ticketing System (JIRA)? Funktioniert wunderbar.
Papier 1 : Software 1
Kosten
Software-Lizenzen, Server und Terminals um Tausende von Euros vs. Paketpapier und Klebeband für zusammen € 4,98 beim Discounter des Vertrauens? Hier muss nicht viel gesagt werden. Ich denke, es ist klar, welche Methode Herr Stromberg bevorzugen wird – jedenfalls kostentechnisch. Klar, gute Post Its kosten gutes Geld (sind es aber auch wert) – aber macht es Sinn, auf diese “laufenden” Kosten zu pochen? Das muss jeder für sich entscheiden, dennoch muss man schon einige Sprints absolviert haben, bis sich diese Kosten leveln. Zur Verteidigung von Software sei gesagt, dass man meist auch mehr erhält als nur ein simples Taskboard (siehe vorherigen Abschnitt).
Papier 2 : Software 1
Teams
Es gibt verschiedene Teamtypen. Teams an einem Standort, verteilte Teams an mehreren Standorten oder über mehrere Etagen im Gebäude. Wann immer die Teams räumlich getrennt sind, hat Software einen entscheidenden Vorteil: Man sieht das Taskboard an jedem Ort, Bildschirm sei Dank. Natürlich kann man an jedem Standort ein Papier-Taskboard aufhängen und dann täglich die Änderungen kommunizieren (zum Beispiel via Telefon, Webcam oder Foto – natürlich braucht man dann wieder jemanden, der das täglich tut. (Vielleicht Frau Heisterkamp?) Aber das erzeugt Overhead, der vermeidbar ist. Verteilte Teams sind derzeit das KO-Kriterium für Software Tools – das wird sich so schnell auch nicht ändern, da Papier bei diesen Teams der limitierende Faktor ist. Ich sage nicht, dass es nicht geht. Es geht. Für manche Teams geht es sogar ganz gut. Dennoch sind meiner Meinung nach verteile Teams mit Software momentan besser beraten.
Papier 2 : Software 2
Training
Software ist mächtig, aber Software ist auch kompliziert. Bis ich einen Task bearbeiten kann, muss ich mich erst einloggen, mich durch das Tool klicken und dann hoffen, dass alles gut geht. In diesem Fall wird die Putzfrau gänzlich ausgeschlossen! Das Problem habe ich nicht bei Papier – dort ist der Prozess sehr einfach: aufstehen, Task verschieben. That’s it. Das Team muss dafür nicht spezielle Trainings absolvieren; jedem Neuling ist das Verfahren innerhalb von Minuten erklärt. Neben dem Zeit- & Kostenfaktor gibt es noch einen dritten: Interaktion.
Papier 3 : Software 2
Interaktion
Physikalische Interaktion verbessert das Lernen des Menschen. Umgemünzt auf Scrum bedeutet dies, dass das Team sich stetig verbessert, wenn es miteinander agiert. Wenn Herr Stromberg mal wieder Kommunikationsbedarf hat, dann kann er herunterkommen, auf das Board zeigen und fragen: “Jungs, wo drückt der Schuh?” Und das Team muss dann diese Frage beantworten können und es im schlimmsten Fall auf den schlechten Kaffee schieben. Das Papier-Taskboard “zwingt” das Team förmlich dazu, miteinander zu kommunizieren, währenddessen es Software ermöglicht, an seinem Arbeitsplatz sitzen zu bleiben. Einzelne Teammitglieder laufen dann Gefahr, isoliert zu werden, was sich negativ auf das gesamte Team auswirkt. Interaktion ist somit ein Muss für Scrum. Achja: Tolle, große TV-LCDs sind nur auf den ersten Blick toll und entpuppen sich schnell als Fehlinvestition. Auch die großen Geräte sind bereits aus mehreren Metern Distanz nicht mehr lesbar (blame the Software…) und bieten keinerlei Eingabemöglichkeit. Es ist daher kein Wunder, dass Teams den Bildschirm gekonnt ignorieren, wenn er keinen wirklichen Zweck erfüllt.
Papier 4 : Software 2
Historie
Was passiert, wenn ich ein Papier-Taskboard habe und der Sprint zu Ende ist? Richtig, die Post Its werden abgenommen und maximal noch in irgendwelche Kartons verstaut. Oder aber durch Frau Heisterkamp fachgerecht entsorgt. Dann noch herausfinden, welche Tasks dann zu welchen Stories gehört haben oder wie sich die Tasks im Laufe des Sprints entwickelt haben? Nada. Oder gar 10 Sprints zurückschauen? Nope, nicht möglich. Hier hat Software einen Vorteil: Herr Stromberg kann sich gemütlich durch die letzten Sprints klicken, ohne sich dafür nennenswert bewegen zu müssen. Alles wird archiviert, kann problemlos später wieder angezeigt werden, man kann sogar Daten exportieren, um sich Diagramme oder Reports erstellen zu lassen. Wie wichtig diese Funktionalität ist, muss jeder für sich selbst beantworten – Fakt ist jedoch: Hier hat Software die Nase vorn.
Papier 4 : Software 3
Usability
Usability ist nur schwer greiflich, daher will ich das in diesem Fall greifbarer gestalten. Mit Usability ist konkret gemeint: Wie gut kann ich mit dem Tool arbeiten? Dazu gehören verschiedene Aspekte, wie zum Beispiel die Verfügbarkeit. Ein Papier-Taskboard ist immer vorhanden. Zugegeben, es kann herunterfallen, wenn es schlecht geklebt ist (dasselbe gilt für Post Its), aber das ist die absolute Ausnahme. Ansonsten hängt das Taskboard bis in alle Ewigkeit. Ein Papier-Taskboard geht nicht mal eben “down”, es fällt nicht aus. Wenn ich Montagmorgen erscheine, dann begrüßt mich das Taskboard mit all seinen knallig farbenden Post Its – es schreit förmlich: “Bearbeite mich!” Jemand, der schon mal Montagmorgen anstatt seines Taskboards auf einen schwarzen Monitor geschaut hat, wird nie wieder ein Software-Taskboard haben wollen, da man als Team darauf angewiesen ist. Erst recht nicht, wenn der Chef mit hochrotem Gesicht auf das Team wartet und brüllt, wieso das Taskboard schon wieder nicht verfügbar ist. Usability ist aber auch Lesbarkeit. Software-Taskboards können natürlich auch auf 100″-Displays oder mittels Beamer dargestellt werden, nur wird hier ein schwerwiegender Aspekt oft vergessen: Die Auflösung skaliert nicht mit zunehmender Größe des Anzeigemediums. Das bedeutet im Klartext, dass selbst der größte Monitor mir nichts bringt, wenn die Taskboard-Software damit nicht umgehen kann. Der Sinn eines solchen Geräts ist einfach verfehlt, wenn man bereits bei einem Meter Abstand nichts mehr erkennen kann oder eben schon nach 10cm – wie es bei Herr Stromberg der Fall ist, dessen Brille eher gen Fernglas geht. Letztendlich steckt in Usability aber auch ease-of-use. Will ich meine Zeit wirklich mit Logins & co verschwenden, wenn ich selbiges mit einem Handgriff am Papier-Taskboard erledigen kann? Wohl eher nicht.
Papier 5 : Software 3
Reporting
Stapelweise Grafiken, am besten in Farbe, noch besser in verschiedenster Ausführung, damit auch ja kein Aspekt verloren geht – diese Stapel liebt Herr Stromberg, denn hinter diesen Stapeln lässt es sich gut verstecken. Spaß beiseite, Reporting ist ein wichtiges Thema für viele Firmen, nicht ohne Grund ist es eines der meistgefragten Features, wenn man den alljährlichen Agile Tool Surveys glauben schenken kann (und das tue ich). Ob man Reporting braucht, ist subjektiv. Klar macht es Sinn, aber mal ehrlich: Wieviele Metriken brauchen wir eigentlich? Wenn es drauf ankommt etwas zu messen, dann geht es bei Scrum doch nur um eins: die Velocity in Kombination mit Hilfe des Burndowncharts zu bestimmen. Scheinbar ist das aber nicht genug, und das ist wohlmöglich auch der Grund, wieso hier Software ganz klar ihre Stärken ausspielt – mit ein paar Klicks mehr oder weniger sind alle möglichen Varianten auf den Bildschirm gezaubert.
Papier 5 : Software 4
Verfügbarkeit
Das leidige Uptime Thema. Sag einem IT-Administrator, dass er dafür zu sorgen hat, dass alle IT-Systeme eine hohe Verfügbarkeit erfüllen müssen und er wird minimal rot anlaufen und explodieren. Wieso? Unter high availability versteht man eine Verfügbarkeit der Systeme von mindestens 99%, eher 99,9% oder gar 99,99%. Gehen wir von dem ersten Beispiel, den 99% aus, dann bedeutet das konkret, dass das System zu 99% über ein Jahr hinweg verfügbar ist. Kann man ausrechnen oder mir glauben, dass das bei 99% immer noch gute 3,5 Tage sind, an denen so ein System nicht verfügbar ist. Und dank Murphy & co wissen wir auch, dass wir nicht einmal eine 3,5 Tage anhaltende Störung haben, sondern ganz viele kleine, die genau dann auftreten, wenn wir das gerade nicht gebrauchen können. Man stelle sich Herr Stromberg vor, der gerade einem wichtigen Kunden zeigen will, wie toll Scrum doch ist, nur um von Error 404 begrüßt zu werden… Bei einem Papier-Taskboard haben wir das Problem nicht, denn das Schlimmste, was passieren kann ist, dass der Kleber nicht hält und das Taskboard runterfällt (alles schon erlebt…) So what? Das Ding hängt in spätestens 3 Minuten wieder. Viel wichtiger ist aber, dass das Team das Problem selbst lösen kann und nicht auf die IT-Admins warten muss.
Papier 6 : Software 4
Fazit
Der Spielstand ist ein Indikator und soll auch nur als solcher verstanden werden. Wie das Ergebnis letztendlich ausfällt, hängt von den eigenen Vorlieben bzw. der Situation ab. Habe ich verteilte Teams und will ich gerne die Integration in meinen Workflow? Dann werde ich wohl nicht um Software herumkommen. Habe ich aber nur ein lokales Team und will ich einfach nur arbeiten, anstatt mich mit Sachen herumzuschlagen, die mich eher bremsen als beschleunigen? Dann ist die altbewährte Papiervariante schon eher das Richtige. Natürlich gibt es noch viel mehr Szenarien als diese beiden genannten, in denen die Entscheidung keine einfache ist. In diesem Fall muss man die Aspekte priorisieren und dann entscheiden.
Pingback: Transparenz und Interaktivität durch ein physisches Scrum-Board