“Wir fokussieren uns nicht mehr vorrangig auf ein Produkt, sondern sind häufig viel zu sehr davon getrieben, Berichte, Präsentationen oder Statusreports abzuliefern. Wir befinden uns eher im Dokumentengeschäft"1. Zu dieser Erkenntnis kommt Jörk nach vielen Jahren Erfahrung im Management als auch als Berater. Sicher fällt Ihnen hier der Grundsatz des agilen Manifests ein: “Funktionierendes Produkt vor Dokumentation”2. Doch was bedeutet das?
Lean Agil als 180º Kehrtwende: Dokumentieren wir gar nichts mehr?
Doch. Natürlich werden auch in der agilen Welt Dokumentationen benötigt. Denken Sie nur an Produkte, die einer Zulassungspflicht unterliegen. Doch gilt es zu unterscheiden, welche Reports einen wirklichen Mehrwert erzeugen und notwendig sind und welche erstellt werden, um internen Prozessen und Abläufen á la “das haben wir schon immer so gemacht” Rechnung zu tragen. Letztere gilt es so weit wie möglich zu eliminieren und dennoch Stakeholder sowie Führungskräfte außerhalb des agilen Teams mitzunehmen als auch die Kunden-/Marktanforderungen zu erfüllen.
Agil und Lean gehen Hand in Hand: Reduzieren Sie Verschwendung, um schneller zu werden
Der erste Schritt in einem Veränderungsprozess ist das Schaffen von Bewusstsein. Das gilt in beide Richtungen: in Ihrem Arbeitsablauf als auch im Entwicklungsprozess selbst. Jede unnötige Aufgabe, die während des laufenden Projektes bearbeitet wird, behindert die Zielerreichung. Eine agile Arbeitsweise, schnelle Ergebnisse und das Einhalten der Sprint Commitments funktionieren nur, wenn jeder Einzelne fokussiert am gemeinsamen Ziel arbeiten kann. Dafür muss Verschwendung so weit wie möglich eliminiert werden.
Werden Sie sich selbst bewusst, wie viel Zeit Sie z.B. in der Rolle als Product Owner in Statusberichte und Dokumente investieren. Eine gut geeignete Methode ist das Führen eines Tagebuchs. Schreiben Sie über einen gewissen Zeitraum jede Tätigkeit inklusive Zeitangabe auf, die Sie während Ihres Arbeitstags beschäftigt. Das mag nach zusätzlichem Aufwand klingen, ist aber eine einfach umsetzbare Möglichkeit, Transparenz herzustellen. Beispiele aus unserer Projekterfahrung zeigen, dass Verantwortliche im mittleren Management bis zu 90% ihres regulären Arbeitstages mit Reporting verbringen! Hinterfragen Sie gleichzeitig kritisch, welche technischen Dokumentationen während der Produktentwicklung von Ihrem Development Team wirklich notwendig sind. Im Fokus des Projekts steht der Kundennutzen und dieser gilt als Maßstab, um das Sinnvolle von der Verschwendung zu trennen.
Der Weg der goldenen Mitte: So viel wie nötig aber so wenig wie möglich
Ein Statusreport mit den wesentlichen Informationen als Entscheidungsgrundlage für Verantwortliche außerhalb des Teams kann notwendig sein, wenn die Informationen innerhalb der regelmäßigen Review Meetings nicht ausreichend oder nicht jedem zugänglich sind. Dokumente, die der späteren Anwendersicherheit Nutzen tragen oder für Zulassungsverfahren notwendig sind, müssen selbstverständlich vorhanden sein. Doch sollten Sie bei allen Dokumentationen, deren direkten Geschäftsnutzen Sie nicht erkennen, die kritische Gegenfrage nach dem “Warum?” stellen und klar auf die Konsequenzen hinweisen: Wenn wir dieser Forderung nachkommen und dafür x Stunden einplanen, müssen wir die Umsetzung des produktentwickelnden Aufgabenpakets y auf einen späteren Zeitpunkt verschieben. Die Funktionalität des Produktes bzw. Produktinkrements zu jedem Sprintende fällt entsprechend geringer aus. Die Entscheidung wird in den meisten Fällen zugunsten der Produktentwicklung ausfallen.
Seien Sie Agil: Probieren Sie es aus
Wie bei jedem Change Prozess werden Sie mit Widerstand rechnen müssen. Häufig fällt es Menschen schwer, von gewohnten Strukturen abzulassen und Unsicherheit zu akzeptieren. Hier können Sie die Vorteile des agilen Arbeitens nutzen. Laden Sie auch Verantwortliche außerhalb Ihres direkten Stakeholderkreises dazu ein, an Daily Stand-up’s oder den Review Meetings teilzunehmen und sich direkt über den Fortschritt des Projekts und die Tätigkeiten ihrer Mitarbeiter zu informieren. Reduzieren Sie dafür Reportings auf das notwendige Minimum. Schlagen Sie einen Testzeitraum vor und bewerten Sie im Anschluss gemeinsam mit den beteiligten Personen die Ergebnisse. Welche Erfolge konnte das Team durch die gewonnene Zeit erzielen? Welche erwarteten Risiken haben sich relativiert bzw. als falsch herausgestellt? Wie viel Zeit haben Sie umliegenden Funktionen außerhalb des agilen Teams gespart und wie wurde der Informationsfluss empfunden? Welche Verbesserungsideen gibt es?
Ähnlich können Sie mit technischen Dokumentationen umgehen. Durch die iterative Arbeitsweise und das regelmäßige Feedback können Sie zum einen den Zeitpunkt der Dokumentation genauer bestimmen und diese konkret einplanen. Gehen Sie zum anderen mit den entsprechenden Stakeholdern in die Diskussion und stellen Sie Gegebenes in Frage. Was ist wirklich notwendig? Denn häufig fehlt die gemeinsame Kommunikation über ein konkretes Thema, obwohl eine Zusammenarbeit als selbstverständlich angenommen wird. Gehen Sie das Risiko ein und streichen Sie, was als verzichtbar erachtet wird. Im Ernstfall können Sie es in einem der nächsten Sprints wieder einbauen. Meist stellt sich die Entscheidung allerdings als richtig heraus. Das Risiko ist demnach überschaubar. Probieren Sie es aus!
Lesen Sie mehr zum Thema Change Prozess in unseren Artikeln "Change Management - Warum die Planung der Implementierung die halbe Miete ist" und "Change Management: Fünf Phasen der Veränderung".
1) Dr. Jörk Hebenstreit, Geschäftsführender Gesellschafter AGILEUS Consulting GmbH & Co. KG
2) Agiles Manifest, leicht gekürzt und modifiziert
Kommentar schreiben