Scrum oder nicht Scrum – ist das hier die Frage?

Die Projektwelt ist im Umbruch. Allenthalben heißt es: macht ihr noch Wasserfall oder seid ihr schon agile?

Viele Unternehmen versuchen, dem aktuellen Trend zu folgen. Und stoßen dabei schnell an ihre Grenzen. Denn: agiles Projektvorgehen ist mehr als drei Rollen, vier Events und fünf Artefakte.

Voraussetzung für ein erfolgreiches agiles Projekt sind im Wesentlichen zwei Faktoren: eine passende Organisationsstruktur und die entsprechende Unternehmens- und Projektkultur.

Agile Projekte in klassischen Organisationsstrukturen – ein Fehler in der Matrix?

Agiles Projektvorgehen schafft die Möglichkeit, schnell und flexibel auf Veränderungen zu reagieren. Doch ein solches Vorgehen wird nur dann wirksam, wenn die Organisationsstruktur des Unternehmens eine schnelle und flexible Reaktion auf Änderungen zulässt. In technischen und produzierenden Innovationsbetrieben ist agiles Vorgehen daher häufig nicht nur auf Projektebene sondern auch in der Organisationsentwicklung selbst (Stichwort: Effectuation) anzutreffen.

Gleiches gilt auch für junge Unternehmen und Startups, die sich meist schon allein auf Grund der zur Verfügung stehenden Ressourcen zu Beginn sehr agil entwickeln.

Bei klassischen Linienorganisationen ist die Einführung agiler Projekttechniken erfahrungsgemäß einfacher, wenn es sich um divisionale Organisationsstrukturen handelt, da hier innerhalb der einzelnen Divisionen interdisziplinäre Zusammenarbeit bereits etabliert ist. Funktionale Linienorganisationen – insbesondere mit breiter Leitungsspanne und großer Gliederungstiefe – scheitern meist an den langen und komplexen Entscheidungs- und Kommunikationswegen.

Matrixorganisationen hingegen sind häufig bereits projektorientiert ausgerichtet, was den Schwenk zum agilen Vorgehen erleichtern kann.

Agile Unternehmens- und Projektkultur versus Zuckerbrot und Peitsche

Wer erfolgreich agile Projekte durchführen möchte, muss für Gleichberechtigung im Projektteam sorgen. Dazu gehört auch die Verzielung des gemeinsamen Teamerfolges. Individuelle projektbezogene Ziele sind hierbei kontraproduktiv. Denn sie fördern in der Regel das Konkurrenzdenken und hemmen somit den Prozess der kollektiven Selbstorganisation.

Sehr hilfreich ist es auch zu verstehen, dass Projektarbeit – insbesondere in agilen Projekten – kein Nebenjob ist. Ein Projektteam muss zusammenwachsen dürfen, um den Zustand der schöpferischen Leidenschaft, den sogenannten Arbeits-Flows zu erreichen. Um in den Flow zu kommen gibt es einfache Voraussetzungen: klare Ziele, eine realistische Aufgabe, die Möglichkeit, sich voll auf diese Aufgabe konzentrieren zu können und direktes Feedback. Es bedarf also der vollen Konzentration auf die Aufgaben und den Austausch mit dem direkten Umfeld. Ständige Unterbrechungen durch parallellaufende Linientätigkeiten verhindern das vehement.

Und noch eins: agiles Vorgehen bedeutet auch Fehler sind erlaubt, denn sie dienen der kontinuierlichen Verbesserung!

Für Organisationen mit einer Unternehmenskultur, bei der im Falle eines Fehlers die Frage nach dem „Wer?“ noch vor der Frage nach dem „Wodurch?“ steht, könnte der Versuch eines agilen Projektvorgehens zum Aha-Erlebnis werden. Die Entwicklung zu „wie beim nächsten Mal nicht mehr?“ stellt hier eine ganz besondere Herausforderung dar.

Ganz oder gar nicht: die Wahrheit zwischen Theorie und Praxis

Auch wenn die eingeschworene Scrum-Community um Ken Schwaber und Jeff Sutherland „ein bißchen Scrum“ als nicht sinnvoll beschreibt, ist die Realität bekannter Maßen nicht immer nur schwarz und weiß. Nicht jedes Unternehmen kann von jetzt auf gleich die strikten Scrum-Regeln 1:1 übernehmen, nicht in allen Unternehmen bietet sich die perfekt geeignete Organisationsstruktur.

Natürlich erzielt man die optimalen Erfolge, wenn man in einem idealen Unternehmen unter den idealen Voraussetzungen die optimalen Prinzipien des agilen Manifestes umsetzen kann. Die Realität gibt das aber in der Regel nicht her. Das Ergebnis sind scheiternde Projekte mit frustrierten Projektteams und unzufriedenen Stakeholdern. Und der Rückzug zum kausalen Wasserfallmodell.

50 shades of agile: agiles Vorgehen in Farbe

Aller Anfang ist schwer. Ich wage mich jetzt mal für einen Scrum Master vergleichsweise weit aus dem Fenster und sage: probieren geht über studieren!

Auf dem Weg zum kompletten agilen Vorgehen ist es meiner Meinung – und Erfahrung – nach vollends legitim, sich der ganzen Sache zu nähern, in dem man sich die eine oder andere agile Technik herauspickt. Denn irgendwie muss man ja mal anfangen. Vielleicht ist es zu Beginn nur mal die Einführung täglicher Standups zum regelmäßigen Austausch im Projektteam oder eines Review Meetings mit einigen Stakeholdern anstelle der klassischen Ergebnis-Präsentation des Projektleiters vor dem Auftraggeber oder Lenkungsausschuss. Vielleicht ist es auch möglich, die einzelnen Aufgabenpakte eines Projektes in thematisch abgeschlossene Pakete zu packen und diese auf einzelne Iterationen zu planen – selbst wenn innerhalb der Iterationen anfangs noch in Mini-Wasserfällen gearbeitet wird. Die Möglichkeiten sind da zahlreich.

Einige Grundsätze sollten aber bei aller flexiblen Auslegung von Scrum & Co. dringend berücksichtigt werden:

Klein aber fein: überschaubare, konstante Teams

Die Idee hinter agilem Projektvorgehen ist die der Selbstorganisation des Projektteams zur Erreichung eines gemeinsamen Zieles und Erfolges. Quasi die kollektive Verantwortung. Das erfordert ein überschaubares, interdisziplinäres Team und vor allem Konstanz in der Teambesetzung. Denn agile Teams brauchen Zeit und die Chance, sich aufeinander einzuschwingen. Hierzu gehören insbesondere der Aufbau von Vertrauen ineinander sowie die Gelegenheit, Stärken und Schwächen der einzelnen Team-Mitglieder zu identifizieren und durch gegenseitige Unterstützung gemeinsam ausgleichen zu lernen. Ständige Mitglieder-Fluktuation verhindert eine kontinuierliche Verbesserung der Team-Performance und somit die erwartete Steigerung der Leistung innerhalb der einzelnen Iterationen (=Velocity).

Weniger ist mehr: Dokumentation vs. Bürokratie

Großes Prinzip im agilen Vorgehen: nur so viel Dokumentation wie nötig. Vermeiden Sie unnötige Bürokratie. Auch die Anzahl der Projekt-Tools und Systeme sollte so klein wie möglich gehalten werden. Viele agile Projekte kranken daran, dass die Geschwindigkeit, die durch das agile Vorgehen aufgenommen wird durch redundante Dokumentation in zu vielen Systemen mit zu vielen Schnittstellen wieder ausgebremst wird.

Wer agile will, muss agile wollen

Wichtig für agiles Projektvorgehen sind hohe Transparenz, kurze Entscheidungswege und Kompetenzen im Team. Dies erfordert die Einbindung aller Stakeholder und klare Worte statt bunter Beruhigungs-Folien.

Entscheidend ist dabei auch die regelmäßige Reflexion des Teamvorgehens: Optimierungspotentiale müssen gemeinsam identifiziert und analysiert werden, damit sich das Team weiterentwickeln kann – zum Wohle der Team-Mitglieder und des Projektes.

Auch wenn der Weg am Anfang holprig ist: der Versuch, agiles Projektvorgehen im eigenen Unternehmen einzuführen kann sich durchaus lohnen. Gerade in komplexen (IT-)Projekten in unserer heutigen Zeit, in der auf regulatorische Anforderungen, Marktsituationen, organisatorische Veränderungen und Kundenverhalten schnell reagiert werden muss, bietet agiles Vorgehen die notwendige Flexibilität. Man muss sich nur damit beginnen.