Agiles Vorgehen in strategisch wichtigen Projekten und eine effektive Unternehmenssteuerung – passt das zusammen?

Vorurteil 1: Agile Vorgehensweisen sind vor allem aufgrund der vielen Scrum-Meetings zeitaufwändig und nicht effizient.

Meiner Erfahrung nach ist es von entscheidender Bedeutung, vor Projektbeginn mit den Team-Mitgliedern und den Stakeholdern über die regelmäßigen Meetings zu sprechen. Jeder Mitarbeitende wird entweder bereits eigene gute und/oder schlechte Erfahrungen mit den Meetings gemacht haben oder zumindest etwas darüber gehört haben. Im Team sollte deshalb über den Zweck und die Erfahrungen mit Daily-, Review-, Planning- und Retrospektiven-Meetings gesprochen werden. Wichtig ist, dass das Team anschließend gemeinsam einen favorisierten Standard zu Dauer und Turnus festlegt. Entsprechend des agilen Vorgehens kann dieser Standard vom Team jederzeit für die Zukunft angepasst werden. Nach meiner Erfahrung spielt sich das Vorgehen rasch ein und der Nutzen dieser Meetings wird erkannt. Wichtig ist, dass der Scrum Master auf die Einhaltung der gemeinsam festgelegten Regeln achtet.

Sind die Meetings wirklich so zeitaufwändig?

In Bezug auf das tägliche fünfzehnminütige Daily, an dem insbesondere das Entwicklerteam, Product Owner und bei Bedarf auch Stakeholder aus dem Fachbereich teilnehmen, sollte der Scrum Master strikt auf die Einhaltung der Dauer achten. Damit wird die Effizienz im Projekt sichergestellt. Das kurze Daily sorgt für Transparenz über die Aktivitäten und bietet die Möglichkeit, Dinge anzusprechen, die einen stören. Die fünfzehnminütige Timebox für das Daily hindert aber nicht daran, dass für einzelne Teammitglieder relevante Themen (anschließend) gesondert vertieft werden.

Das Review-Meeting am Ende eines jeden Sprints kann ebenfalls effizient in einer festgelegten Dauer (eine bis eineinhalb Stunden reichen in der Regel) durchgeführt werden. Grundsätzlich sollte jeder am Projekt interessierte Mitarbeitende teilnehmen können. Das Entwicklerteam stellt im Rahmen des Reviews die Ergebnisse des vergangenen Sprints vor. Feedback ist möglich und wird auch eingefordert. Am Ende des Review-Meetings wird ein Ausblick auf die Zielsetzung des Product Owners für den nächsten Sprint gegeben; an dieser Stelle können Stakeholder Impulse geben und auch Wünsche für die Priorisierung anbringen.

Das Planning mit Product Owner, Stakeholdern und dem Entwicklungsteam ist zumeist das zeitintensivste Meeting. Bei zweiwöchigen Sprints sollte mit drei Stunden Zeitaufwand gerechnet werden. Es findet am Beginn des Sprints statt. Ziel ist es, die im anstehenden Sprint umzusetzenden User Stories für das Sprint Backlog festzulegen. Je besser die umzusetzenden User Stories fachlich sowie technisch vorbereitet und beschrieben sind, desto schneller läuft das Planning. Aber das Planning bietet auch die Möglichkeit, einzelne Punkte zu verfeinern, Verständnisfragen zu klären und zu große Arbeitspakete auf kleinere aufzuteilen. Die Schätzung der Komplexität der Anforderungen erfolgt gemeinsam im Meeting.

Last but not least trifft sich das agile Team nach dem Sprint zur Sprint Retrospektive. Ziel ist es, gemeinsam nach hilfreichen Änderungen zu suchen, um die Effektivität der Zusammenarbeit zu verbessern. Vor Beginn eines Projekts wird oft das Feedback gegeben, dass die Zeit hierfür eingespart werden könnte, und der Nutzen gering ist. Meiner Erfahrung nach stellt sich aber meist schnell heraus, dass die Retro-Meetings sehr hilfreich sind, und die Mitglieder des Teams begeistert dabei sind.

Fazit: Ist der Zeitaufwand verglichen mit dem Ergebnis der Meetings tatsächlich zu hoch? Als ehemaliger Projekt-Controller empfinde ich den Nutzen in Bezug auf Effizienz und Effektivität in der Projektarbeit als enorm hoch! Dies führt in der Praxis zu einer sehr intensiven Projektarbeit, auch weil sich das Entwicklerteam voll auf die vorher abgestimmten Arbeitspakete konzentrieren kann. Leerlauf im Projekt wird vermieden. Wenn das Team den Arbeitsumfang des Sprints schneller als gedacht umsetzt, kann in Abstimmung mit dem Product Owner für Nachschub gesorgt werden. Diese Vorgehensweise unterstützt die effektive Unternehmenssteuerung enorm! Die Stakeholder – inklusive Geschäftsleitung – haben jederzeit im Austausch untereinander und mit dem Product Owner die Möglichkeit, auf die Priorisierung im Product Backlog Einfluss zu nehmen. Änderungen – etwa aufgrund geänderter Priorisierung – wirken sich aber erst auf zukünftige Sprints aus.

Vorurteil 2: Agiles Vorgehen steht für schlechte Dokumentation und fehlende Transparenz

Woher kommt dieses Vorurteil? Beim traditionellen Vorgehen wird oftmals vor Beginn der Entwicklungsphase ein ausführliches Fachkonzept erstellt, in dem das zu erstellende IT-System mit all seinen Funktionen, Daten, Schnittstellen und Oberflächen detailliert und komplett beschrieben wird. Dies ist ein sehr zeitaufwändiger Prozess, in dem teilweise sehr umfangreiche Dokumente entstehen.

Im Gegensatz dazu gibt der Kunde beim agilen Vorgehen nur einige wenige Basisfunktionalitäten vor und das IT-Projekt startet sofort ohne Verzögerungen. Dies ist vielleicht der Grund dafür, dass Mitarbeitende ohne Kenntnisse über agile Vorgehensweisen denken, dass in agilen Projekten wenig dokumentiert wird.

Dennoch ist Dokumentation auch beim agilen Vorgehen wichtig! Die Anforderungen sind im Rahmen der User Stories genau zu spezifizieren. Hinzu kommt, dass Auftraggeber von agilen Projekten die Dokumentation im Projekt oftmals mit dem Auftragnehmer vertraglich vereinbaren. Wichtig ist in diesem Kontext, dass die Dokumentation effizient organisiert wird. Die praktische Erfahrung zeigt, dass hierfür direkt zu Beginn Standards vorgestellt, im Team abgestimmt und festgelegt werden sollten. Während des Projekts achten insbesondere der Scrum Master und der Auftraggeber auf Einhaltung der Vorgaben.

Wie ist die Dokumentation ohne größeren Aufwand möglich? Kann damit sogar Zeit eingespart werden?

Dokumentation des Projekts

Die Ergebnisse relevanter Abstimmungsrunden und Architekturentscheidungen werden in Form von Ergebnisprotokollen dokumentiert. Dies erfolgt immer an der gleichen Stelle und im gleichen Format. Besonders effizient ist dies beispielsweise im Confluence möglich – es müssen keine Dokumente an sich regelmäßig ändernde Verteilerkreise verschickt werden.

Für die Abstimmung grundsätzlicher Entscheidungen (Prozesse, Tools, Methoden) werden in der Regel PowerPoint-Dokumente erstellt. Die Ablage erfolgt ebenfalls im Confluence. Die tatsächliche Entscheidung ist dem Protokoll zu entnehmen.

Sämtliche Anforderungen und Aufgaben werden immer nur an einer Stelle dokumentiert. So beispielsweise in Jira – einer Webanwendung zum Aufgaben-, Anforderungs- und Fehlermanagement.

Dokumentation der Software

Für die Entwicklung des Codes sowie die Dokumentation im Code selbst, sollten allgemeingültige Standards vereinbart werden (zum Beispiel Clean Code).

Unterstützende Übersichten werden mit Dokumentationswerkzeugen (etwa Draw.io) erstellt.

Fazit zur Dokumentation

Ja, auch beim agilen Vorgehen wird dokumentiert! Wichtig ist, dass ein Sachverhalt immer nur an einer Stelle dokumentiert wird. Dies spart Zeit, und widersprüchliche Information werden vermieden. Mit dieser Art der Dokumentation wird für Transparenz gesorgt und Zeit eingespart.

Zusammenfassung

Die hohe Akzeptanz agiler Vorgehensweisen hat seine guten Gründe! Durch die verständlichen agilen Methoden wird mit Unterstützung des Scrum Masters für Effizienz im Projekt gesorgt. Erfreulich ist auch die hohe Motivation im agilen Team durch die offene Kommunikation und kurze Entscheidungswege. Aktuell bin ich in einem IT-Projekt als Scrum Proxy Product Owner und Projektkoordinator tätig. Aus diesem Blickwinkel heraus kann ich eine hohe Effektivität des Vorgehens bestätigen, da nicht sofort die hundertprozentige Lösung angestrebt wird. Stattdessen werden Schritt für Schritt einzelne Bausteine und/oder Funktionen umgesetzt, die sich an den Anforderungen des Unternehmens ausrichten.