"Are you in a hurry or may I use my electronic organizer?" (Hast Du es eilig oder kann ich meinen elektronischen Organizer benutzen?) So oder so ähnlich heißt ein Artikel, den ich vor 15 Jahren gelesen habe. Er hat den etwas eigenartigen Aspekt elektronischer Organizer untersucht, dass sie oft eher Hindernis als Hilfsmittel sind. Und dieses Problem ist nicht beschränkt auf elektronische Organizer. Es tritt immer wieder auf, wenn wir versuchen, Dinge zu "elektrifzieren". Ein Stück weit ist das auch dem oben genannten Scrum Master auf die Füße gefallen. Auf den ersten Blick scheint es vollkommen logisch: Für das Sprint Burndown muss man täglich die Reststunden der einzelnen Aufgaben summieren und daraus ein Diagramm erstellen. Diese Aufgabe schreit geradezu nach Excel. Damit kann man ganz bequem die Restaufwände je Aufgabe eintragen und dann dafür sorgen, dass Excel die Summe automatisch ausrechnet und ein schickes Diagramm generiert. Das druckt man dann aus und hängt es auf.

So logisch dieses Vorgehen auf den ersten Blick erscheint, so problematisch ist es. Beginnen wir mit dem Ende: das ausgedruckte Diagramm. Wenn es auf DIN A4 ausgedruckt wird, ist es schlicht viel zu klein. Ich muss mich direkt vor das Diagramm stellen, um es lesen zu können. Also muss ich mir die Information aktiv holen. Die Versuchung ist groß, diese Information nicht abzuholen, wenn sie unangenehm ist (z. B. weil das Sprintziel gefährdet ist). Wäre das Burndown hingegen so groß wie ein Flipchartblatt, könnte ich die Informationen auch von Weitem gut erkennen – sogar direkt von meinem Arbeitsplatz aus. Ich werde also die ganze Zeit über mit dem Burndown konfrontiert und kann mich vor diesen Informationen nicht drücken. Und am einfachsten bekommen wir ein Sprint Burndown auf Flipchartgröße, indem wir es von Hand auf ein Flipchart zeichnen. Das kann man als gemeinsame Aktion im Rahmen des Daily Scrum machen. Ein paar Entwickler zählen schnell die Restaufwände zusammen und ein anderer zeichnet den neuen Datenpunkt in das Diagramm ein. Wem das Addieren der Restaufwände im Kopf zu aufwändig ist, kann in Betracht ziehen, einfach nur die Resttätigkeiten zu zählen. Wird das Diagramm dadurch wirklich deutlich ungenauer?

Neben der Größe des Burndowns entsteht so ein weiterer Vorteil: Alle Teammitglieder nehmen an der Erstellung des Burndowns teil und sehen, wie es sich jeden Tag ein Stück weiterentwickelt. Damit wird explizit, dass das Burndown direkt etwas mit dem Team zu tun hat, und das Fortschreiben macht die Dynamik des Projektfortschritts erfahrbar.

Und diese Prinzipien finden sich nicht nur beim Sprint Burndown. Ein anderes prominentes Beispiel ist das Taskboard: Hier werden physikalische Zettel mit Aufgaben an der Wand vom Team im Rahmen des Daily Scrum aktualisiert und entsprechend des Projektzustands verschoben. Aber unser Geschäft ist doch die Softwareentwicklung! Warum sollen ausgerechnet wir auf Technologie verzichten? Ist das nicht vollkommen verquer? Nein, es ist vollkommen logisch. Die genannten Beispiele haben mit der Kommunikation in einem kleinen Team zu tun, das innovative Lösungen erarbeitet. Software spielt seine Stärken hingegen vor allem dort aus, wo Abläufe sinnvoll standardisiert werden können. Und das ist in innovativen Kontexten häufig nicht so einfach möglich.

Natürlich sind Softwarelösungen nicht generell unsinnig. Neben der Effizienzsteigerung in standardisierbaren Abläufen sind sie dann sinnvoll, wenn sie Beschränkungen (Constraints) beseitigen. Das ist z. B. der Fall, wenn sie uns erlauben, Dinge an neuen Orten oder zu neuen Zeiten zu tun. Können wir beispielsweise nicht alle in einem Büro arbeiten – weil z. B. ein Teil des Teams in Indien sitzt – sind Excel Burndown und elektronisches Taskboard durchaus sinnvoll anwendbar.

Wann immer eine Softwarelösung für die Unterstützung in Softwareprojekten diskutiert wird, sollten wir uns fragen, ob die Lösung relevante Beschränkungen beseitigt. Welche Beschränkung wird beseitigt, wenn wir unsere Anforderungen in einen Issue Tracker eintragen, statt sie auf Karten an die Wand zu hängen? Welche Beschränkung beseitigt ein automatisch generiertes Excel-Diagramm etc.? Und wenn wir eine Beschränkung benennen können (wie in unserem Beispiel mit dem Teilteam in Indien), sollten wir mit dieser Erkenntnis immer auch prüfen, ob nicht eine einfachere Lösung dieselbe Beschränkung beseitigen kann. Vielleicht wäre es in unserem Beispiel sinnvoller, ein physikalisches Taskboard an einem Standort zu haben und es per Webcam den anderen Standorten zur Verfügung zu stellen?

Wenn Sie noch weitere Beispiele für einfache softwarefreie Lösungen haben, schreiben Sie mir an stefan.roock[at]it-agile.de.

P.S.: Das Konzept der Beschränkungen ist übrigens nicht von mir. Es findet sich z. B. in "Marktorientierte Innovation" von Clayton M. Christensen und Michael E. Raynor sowie in "Subject to Change" von Peter Merholz, Todd Wilkens, Brandon Schauer und David Verba.