Die ewige Krux: Papier vs. Software im agilen Umfeld

Auf den XPDays 2011, der deutschen Konferenz für agile Methoden, habe ich am 17.11.2011 eine Fishbowl-Diskussion zum Thema „Agile Entwicklung mit Softwareunterstützung – ein Widerspruch?“ moderiert. Auf Basis der Meinungen der Diskutanten und weiterer Gespräche vor Ort möchte ich mich dieser Thematik noch einmal ausführlicher widmen und meine Standpunkt wiedergeben.

Papier im agilen Prozess

Ist Papier überhaupt ein ernstzunehmendes und professionelles Tool? Dieser Frage ging Stefan Roock in einem Vortrag auf der W-Jax Konferenz 2011 nach. Jedenfalls hat sich meine persönliche Auffassung zur Nutzung von Papier als Hilfsmittel für Planung, Brainstormings und jegliche Form von Meetings durch die Beschäftigung mit Scrum und agilen Methoden wesentlich geändert. War ich vorher darum bemüht, stets sämtliche Informationen digital zu erfassen, werden nun zu jeder Gelegenheit Klebezettel gezückt und die Wände „gepflastert“. Digital sind nur noch die Fotos, die man von den Ergebnissen macht.

Grundsätzlich sind die Argumente für das Werkzeug Papier im agilen Prozess ja auch überzeugend. Zusammengefasst:

  • Papier ist stets sichtbar.
  • Papier fördert die Zusammenarbeit.
  • Papier ist einfach anpassbar, Prozesse lassen sich schneller verändern.
  • Papier ist ein visuelles und haptisches Erlebnis, es spricht mehrere Sinne an.
  • Papier ist übersichtlicher, auf dem Task-Board geht so schnell nichts verloren.
  • Die Nutzung von Papier erfordert keinen Einarbeitungsaufwand, die Nutzungshürden sind niedrig.

Grundlage: Agilität verstehen und leben

Keine Frage: Ein Task-Board mit Zetteln ist unschlagbar. Immer wieder erfahre ich allerdings – zuletzt im Rahmen der erwähnten Fishbowl-Diskussion –, dass gerade unerfahrene Teams von Anfang an auf Tools setzen wollen. Oft hört man den Satz: „Wir wollen in der Software-Entwicklung agiler werden. Welches Tool können wir nutzen?“ In diesem Zusammenhang wird häufig auch eine ganze Reihe von Ausreden bemüht, warum ein analoges Board vermeintlich nicht funktionieren kann und weshalb es einer Software bedarf:

  • Unser Team ist verteilt, wir sitzen nicht alle am selben Standort.
  • Unsere Kunden erwarten eine minutiöse Abrechnung, weshalb die gesamte Arbeit digital erfasst werden muss.
  • Wir müssen jegliche Kommunikation dokumentieren.
  • Wir haben keinen Platz für ein Board.

Letzteres habe ich tatsächlich von einem Team zu hören bekommen, das ich gecoacht habe, und aus diesem Grund ist jenem Team die weitere Einführung agiler Methoden bis heute nicht gelungen – man sucht noch nach einer Software, die alle Anforderungen abdeckt …

Lösungen für all diese vermeintlichen Probleme finden sich im agilen Manifest, der Grundlage, die alle agilen Methoden gemeinsam haben. Der zentrale Leitsatz lautet:

„Individuals and interactions over processes and tools.“

In eigenen Worten: Am wichtigsten sind die beteiligten Personen und ihre Kommunikation untereinander. Wir müssen also miteinander sprechen und gemeinsam Probleme unserer aktuellen Zusammenarbeit erkennen und Lösungen erarbeiten. Das Beispiel verteiltes Team ist definitiv eine solche Herausforderung. Aber dieses Problem wird durch eine Software nicht gelöst, sondern höchstens überdeckt. Und genau das ist meines Erachtens der zentrale Kritikpunkt an der Software-Nutzung im agilen Prozess:

Viele Teams neigen dazu, Probleme durch die Einführung einer Software lösen zu wollen, statt die tatsächlichen Ursachen des Problems anzugehen und dafür Alternativen zu finden.

Können sich verteilte Teams nicht z.B. per Video-Chat verabreden, um das Board gemeinsam zu organisieren? Oder noch sinnvoller: Können nicht Feature-Teams pro Standort definiert werden, die gemeinsam vor Ort an einer dedizierten Aufgabe sitzen? Es obliegt jedenfalls dem Team selbst, praktikable Lösungen zu finden und auszuprobieren („Inspect & Adapt“).

Die Rolle von Tools im agilen Prozess

Je stärker ein Team die agilen Prinzipien verinnerlicht hat, desto eher kann es einschätzen, ob in bestimmten Bereichen Software-Unterstützung hilfreich ist und wo Probleme bestehen, die es anderweitig lösen muss. Der Weg bis ins vierte Stadium des Teambildungsprozesses (Performing: In dieser Phase hat das Team sich so eingespielt, dass es sich stark auf die Umsetzung seiner Aufgaben konzentrieren kann und das Höchstmaß an Produktivität erreicht) ist lang und steckt voller Hindernisse und Rückschläge. Es ist nötig, die eigenen Vorgehensweisen ständig zu hinterfragen und zu analysieren. In seinem Artikel Scrum in der Praxis: Ein Team startet durch hat Manuel Kummerländer ausführlich beschrieben, welche Herausforderungen die Etablierung von Scrum bergen kann.

Sinnvolle Einsatzgebiete für Tools im agilen Prozess gibt es sicher. Es seien z.B. Testunterstützung (Dokumentation von Testfällen), Bug-Tracking, Anfragebearbeitung oder Support genannt. Auch die Backlog-Pflege kann – je nach Präferenz des Product Owners – mit einer Software unterstützt werden. Ob das jeweils sinnvoll ist, hängt vom individuellen Teamkontext ab.

Nicht hilfreich sind dagegen digitale Board-Lösungen. Sie sind in jedem Fall unübersichtlicher und verhindern oft die Absprache und Kollaboration zwischen den Teammitgliedern. Ein Daily Standup-Meeting vor dem Monitor wird immer länger dauern als vor einem Papier-Board. Auch die in Scrum üblichen Sprint-Planning-Meetings sollte man meines Erachtens nicht am Monitor verbringen. So wird im Twentyfeet-Team bei //SEIBERT/MEDIA der Backlog zwar in JIRA gepflegt. Steht eine Sprint-Planung an, druckt der Product Owner die Tickets jedoch aus (ScrumCards-Plugin), die Ausdrucke landen am Board.

Fazit

Meiner Auffassung nach spielt die Unsicherheit im Hinblick auf die sinnvolle Anwendung agiler Methoden eine wichtige Rolle. Dadurch, dass man an Software-Hilfsmitteln festhält, um vermeintliche Probleme in den Griff zu bekommen, tritt der agile Prozess und seine richtige Anwendung in den Hintergrund. Das ist der falsche Ansatz. Sinnvoller ist stattdessen, zuerst den agilen Prozess einzuführen und kontinuierlich zu optimieren und anschließend gegebenenfalls diejenigen Bereiche zu evaluieren, in denen Software unterstützen kann. Hier sind auch weiterhin Aufklärungsarbeit und Hilfestellung für Agile-Neueinsteiger nötig.

Weiterführende Informationen

Haben Sie Fragen zu agilen Vorgehensweisen in der Software-Entwicklung? Möchten Sie Agilität in Ihrem Unternehmen einführen? Bei //SEIBERT/MEDIA ist “Agile” in Projekten an der Tagesordnung. Mit mehreren Zehntausend Stunden Projekterfahrung in internen und externen Projekten mit agilen Entwicklungsmethoden gehört //SEIBERT/MEDIA zu den erfahrenen und großen Anbietern für Scrum in Deutschland. Gerne helfen wir Ihnen bei der Etablierung agiler Prinzipien und Verfahren – sprechen Sie uns einfach unverbindlich an. Ausführliche Informationen zu unseren Agile-Dienstleistungen finden Sie in unserem Agile-Orientierungsangebot mit Leistungsbeschreibungen und Beispielkalkulationen.

Welche Vorteile bietet mir als Kunde ein Scrum-Projekt?
Agile vs. Wasserfall-Modell: Was die Forschung sagt
Die Scrum-Meetings und ihre Bedeutung
Agile Projekte und Scrum in der Praxis: Elemente, Nutzen, Tools, Hürden
Scrum in der Praxis: Ein Team startet durch