Warum ‘Agile’ zugleich einfach und komplex ist

Wer würde widersprechen, dass die vier Grundsätze des Agile Manifesto –

1. Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge
2. Funktionsfähige Software ist wichtiger umfassende Dokumentation
3. Zusammenarbeit mit dem Auftraggeber ist wichtiger als Vertragsverhandlungen
4. Anpassung an Änderungen ist wichtiger als einem Plan zu folgen,

der Anwendung des gesunden Menschenverstands auf ernsthafte Probleme entsprungen sind? Und wer würde widersprechen, dass die Anwendung dieser Prinzipien geeignet sein könnte eine Vielzahl von Organisationsproblem zu lösen, die der Komplexität des menschlichen Miteinanders in Unternehmen entspringen?

Es gibt eine ganze Reihe guter Gründe „Agile“ als Methodologie einzusetzen. Hierzu gehören unter anderem:

• Eine niedrige Produktivität des Unternehmens
• Eine schlechte Stimmung in den Teams
• Das Unternehmen hat Schwierigkeiten, im „war for talent“ erfahrene Mitarbeiter zu gewinnen
• Beschränkungen im Entwicklungsbudget
• Der Wettbewerb legt ein hohes Innovationstempo vor, dem bisher verwendete Methoden nicht mehr gewachsen sind.

Eine prinzipielle Entscheidung für den Einsatz agiler Vorgehensweisen zu treffen, ist daher relativ einfach – nicht umsonst gilt „Agile“ als das aktuelle Management-Buzzword Nr. 1. Die hierzu notwendigen Maßnahmen jedoch, um eine Organisation auf die neue Methode auszurichten, werden oftmals in Dauer und Umfang komplett unterschätzt. Jede Organisation hat ihre eigenen dysfunktionalen Merkmale und Lösungen müssen daher massgeschneidert sein, was in der Euphorie des Entscheidungsprozesses – „Agile“ werde alle Probleme lösen – gern übersehen wird.

Muster des Scheiterns Agilen Methoden

Ich habe meine Softwareprojekte der vergangenen Jahre aus Sicht des Produktmanagers bzw. Agile Coachs/Scrum Master auf organisationsübergreifende Muster des Scheiterns hin analysiert und folgende vier Ebenen identifizieren können:

Muster des Scheiterns auf Organisationsebene:

• Es gibt keine (Produkt-)Vision oder um es mit Lewis Carroll zu formulieren: If you don’t know where you are going, any road will get you there.
• Der Trugschluss, dass man wisse, was man bauen müsse. Es bedürfe keiner Experimente, um Produkte zu entdecken; dass höhere Management könne das Produkt-Backlog allein definieren.
• Ein (gefühlter) Kontrollverlust auf der Managementebene führt zu Mikromanagement – wer möchte seinen Bonus und ggf. die Karriere schon einer Horde von Hoodie tragenden Clubmate-Trinkern anvertrauen?
• Die Organisation ist nicht transparent in Hinblick auf Vision und Strategie aufgestellt. Was in Folge die Teams daran hindert sich selbst zu organisieren, da sie im Dunkeln gehalten werden.
• Es gibt keine Kultur des Scheitern – besser noch: Keine Kultur des Lernens durch Hinfallen und Wiederaufstehen. Die Teammitglieder fürchten negative Konsequenzen und spielen daher auf sicher.
• Da die Organisation als Ganzes nicht auf einen experimentellen „Build-Test-Learn“-Modus eingestellt ist, bewegen sich Abteilungen daher mit unterschiedlichen Geschwindigkeiten. Die resultierende Reibung absorbiert „agile“ Gewinne einer Abteilung/Gruppe in den meisten Fällen wieder.
• Das höhere Management unterstützt agile Prozesse nicht ausdrücklich, z.B. durch Teilnahme an Veranstaltungen wie einer Sprint-Demo, obwohl es eine Vorbildfunktion für die gesamte Organisation hat.
• Das höhere Management beharrt auf den bekannten Reportingstrukturen und -inhalten anstatt sich den agilen Prozessen anzupassen.
• Die Organisation verhindert das Sichtbarmachen der eigenen Dysfunktionen und eliminiert damit einen der wesentlichen Vorzüge agiler Prozesse. („When you put problem in a computer, box hide answer. Problem must be visible!“ Hideshi Yokoi,der frühere Präsident des Toyota Production System Support Centers in Erlanger, Kentucky, USA.)
• Das Produktmanagement wird nicht als Domainexpert und Problemlöser innerhalb der Organisation verstanden, sondern als diejenige Entität, die Anforderungen in Funktionen, Buttons und Links umsetzt. (Gern auch „Jira-Monkeys“ genannt.)
• Silodenken auf Abteilungsebene führt dazu, dass das Produktmanagement nicht von Anfang an mit einbezogen wird. Typischerweise tendieren Abteilungen in größeren Organisationen zu lokalen Optimierungen, z.B. durch Anreize bzw. Boni und persönliche Agenden gesteuert, die wiederum nicht mit der Unternehmensvision oder –strategie in Einklang stehen.
• Kernaufgaben des Produktmanagements werden von anderen Abteilungen wahrgenommen, z.B. Tracking, Analytics oder A/B-Tests.

Muster des Scheiterns auf Teamebene:

• Ein Entwicklungsteam besteht aus zu vielen Junior-Entwicklern. Diese neigen dazu, eine bestimmte Form des Mikromanagements durch fachliche Autoritäten als Teil ihres Trainings zu schätzen. Sie haben zudem in der Regel nur wenig Erfahrung mit agilen Methoden und können Prozesse wie z.B. Scrum nur bedingt unterstützen. Im Besonderen vermögen sie kaum „Nein“ zu sagen, was dem Ergebnis abträglich ist.
• Ein zu hoher Anteil von Entwickler hat eine Open Source-Mentalität: Diskussionen erfolgen dann ggf. nicht offen im Team – z.B. während einer Grooming-Session –, sondern u.U. in einem Pull Request wie bei einem verteilten Team.
• Teams sind zu klein und daher nicht cross-funktional. Beispiel: Ein Team arbeitet nur am Frontend und kann selbst keine Arbeiten im Backend vornehmen. Dies führt zu unnötige Abhängigkeiten von den (Backend-) Teams und beeinträchtigt die Produktivität – das Team ist langsamer als nötig.
• Die nötigen Positionen für agile Prozesse werden nicht geschaffen oder müssen von anderen Rollen mit übernommen werden. Beispiel: Der Product Owner muss gleichzeitig als Scrum Master fungieren, was dem Prozess in der Regel nicht gut bekommt.
• Teammitglieder lehnen agile Prozesse offen ab, da sich in ihrer Komfortzone wohl fühlen. Sie lehnen die Übernahme von Verantwortung für den Betrag des Teams zum Unternehmenserfolg ab.
• Ein „Team“ kooperiert nicht als Team, sondern bildet eine Gruppe: Der Norming, storming, forming, performing-Zyklus wird nie durchlaufen.
• Teammitglieder verabschieden sich innerlich von agilen Methoden, weil sie diese für einen der vielen Managementtrends halten, die nach einiger Zeit so oder so wie abebben.
• Das Pseudo-Agile-Phänomen: Teams folgen den „agilen Regeln“ buchstabentreu ohne zu verstehen, warum diese existieren. Sie verwechseln ein Rahmenwerk wie Scrum, welches an die jeweiligen Organisation angepasst werden muss, mit einer fest definierten Methode. Die Folge in diesem Fall kann der „Peak-Scrum“-Effekt sein: Scrum liefert keine besseren Ergebnisse als der zuvor angewendete Prozess. Schlimmer noch: Motivation und Produktivität werden schlechter – der Enthusiasmus des Trainings in der neuen Methode verflüchtigt sich im Alltag schnell.
• Teammitglieder werden kurzfristig neuen Aufgaben oder Teams zugewiesen, so dass das Team nur erschwert lernt, als Einheit zu leisten.

Muster des Scheiterns auf Prozessebene:

• Agile Prozesse werden entweder ignoriert oder verbogen, wann immer es opportun erscheint. In der Regel wird dies vom Management initiiert, z.B. um „besondere Projekt“ termingerecht fertig stellen zu können.
• Aus agile Prozessen und Rollen werden bestimmte wesentliche Elemente entfernt. Zum Beispiel wird der Scrum Product Owner zu einem Projektmanager gemacht, indem man diesem die Verantwortung für das Product Backlog entzieht und die Priorisierung von Aufgaben einer anderen Entität auf Managementebene zuweist. Diese Form von „Scrum“ ist übrigens ein ziemlich brauchbare neue Version der Wasserfallmethode.
• Abteilungen bzw. andere Stakeholder umgehen das Produktmanagement, um für sie wichtige Änderungen zu realisieren, und werden vom höheren Management belobigt, weil sie „Initiative“ gezeigt hätten.
• Die Organisation verwendet nicht genügend (Kommunikations-) Anstrengungen darauf um unter allen Beteiligten ein gemeinsames Verständnis darüber zu schaffen, warum was in welcher Reihenfolge gebaut werden soll.

Muster des Scheiterns auf Büro- und Einrichtungsebene:

• Die Arbeitsumgebung bietet nicht ausreichend Möglichkeiten zur formellen und – wichtiger – informellen Kommunikation wie z.B. Teeküchen, Sofaecken oder Besprechungsräume. (Gern wird hierzu Einschätzung, dass Meetings in nichtagilen Organisationen oftmals wenig nützlich seien, 1:1 auf agile Meetings übertragen. Der Erfolg agiler Methoden basiert jedoch stark auf Transparenz und einem „shared understanding“ unter allen Beteiligten: „Erst reden, dann coden.“)
• Es gibt zu wenig Whiteboards aller Größen. Genau genommen müsste die Abwesenheit von Whiteboards an allen passenden Wände thematisiert werden und deren Verfügbarkeit.
• Das Büro ist agilen Arbeitsweisen nicht förderlich. Es sollte hell und offen, aber dennoch kein Großraumbüro sein. Große, unstrukturierte Flächen werden schnell laut, insbesondere wenn mehrere Teams gleichzeitig an Boards arbeiten oder Standups haben.

Zusammenfassung:

Meine drei wichtigsten abstrakten Erkenntnisse der letzten Jahre im Zusammenhang mit der Einführung agiler Methoden auf Organisationsebene sind folgende:

1. Eine agile Abteilung kann nicht isoliert in einer nicht-agilen Organisation erfolgreich sein. Die gesamte Organisation muss sich „agilisieren“, um von der Methode profitieren zu können.
2. Diese „Agilisierung“ setzt wiederum voraus, dass sich in den meisten Fällen die Unternehmenskultur ändern muss.
3. Und im Mittelpunkt dieser Änderung steht die Annahme einer Kultur des Lernens, die das Scheitern nicht bestraft, sondern Experiment und Neugierde belohnt.

Wer nicht bereit ist, diesen mühseligen Weg auf sich zu nehmen und von vielen liebgewonnen Riten und Traditionen der Unternehmenswelt Abschied zu nehmen, der sollte sich „Agile“ nicht auf die Fahne schreiben. „Agile“ funktioniert nur, wenn das Management bereit ist, Hand an die DNA des Unternehmens zu legen. In allen anderen Fällen ist es oftmals nur eine Vergeudung von Ressourcen.

Passend zum Thema: “Tipps zur Vertragsgestaltung bei Agilen Softwareprojekten”

Zum Autor
Stefan Wolpers arbeitet als Agile Coach und Produktmanager in Berlin. Er bloggt unter Age Of Product und twittert unter @StefanW. Ansonsten ist er in der LinkedIn-Gruppe “Agile Clinic – Best Practices For Agile Change” zu finden.

Foto: scrum agile from Shutterstock