Warum Agilität weitaus mehr ist als eine Sache für die Teamebene

Enterprise Agility
Kommentare

Was können Unternehmen tun, um ihre Wettbewerbsfähigkeit zu erhalten, wenn die alten Rezepte nicht mehr wie gewünscht greifen? Sie können Handlungsroutinen verändern. Doch was so einfach klingt, kann zu einer Aufgabe werden, die Sisyphos in die Kündigung getrieben hätte. Enterprise Agility heißt ein neuer Ansatz, der die Herausforderung annimmt, indem er die agilen Prinzipien von der Team- auf die Produkt- und Portfolioebene überträgt.

Das Ziel besteht darin, Produktivität und Innovationsfähigkeit zu erhöhen, auch in komplexen Umgebungen. Dabei ist Enterprise Agility kein dediziertes Vorgehensmodell, es ist ein Framework, das eine Geisteshaltung bestärkt, die Gewohnheiten kritisch hinterfragt und gezielt zu verändern sucht. Ein kurzer Überblick darüber, wo und warum Enterprise Agility ansetzt – und welche Voraussetzungen für den Erfolg entscheidend sind.

Enterprise Agility ist, kurz gesagt, eine Einstellung, die Handlungsroutinen und die Art der Arbeitsteilung verändern soll – und das über mehrere Unternehmensebenen hinweg. Im ersten Moment klingt das vielleicht nicht spektakulär. Tatsächlich ist es eine tiefgreifende Forderung. Denn häufig wird Agilität primär als Option für die Teamebene, noch genauer: für Entwicklerteams, thematisiert. Das ist sie auch, jedoch keineswegs ausschließlich. Agilität verändert Routinen und Organisationsstrukturen, um den Nutzen für den Kunden zu steigern, die Produktivität und Lieferfähigkeit mit definierter Qualität zu erhöhen und wesentlich flexibler reagieren zu können. Das sind Ziele, die für das ganze Unternehmen gelten. Umgekehrt kann Agilität nur in begrenztem Maße Vorteile bringen, wenn ihr Einsatzgebiet stark begrenzt bleibt.

Die klassische Handlungsroutine, auf deren Änderung der Ansatz der Enterprise Agility abzielt, besteht in der organisatorischen Gewohnheit einer ausgefeilten Planung der angestrebten Marktinnovation und einer der Planung deutlich nachgelagerten Entwicklung. Warum, oder besser gesagt wann, sollte sich ein Unternehmen nun darum bemühen, diese Routine zu ändern, die doch offenbar seit Jahren funktioniert? Weil es eine Situation gibt, in der sie nicht mehr funktioniert. Dann nämlich, wenn das neue Produkt nach langer Planung auf einen Markt kommt, der an diesem Produkt kein Interesse mehr hat. Eine Marktinnovation muss drei Kriterien erfüllen: Sie muss erschwinglich sein, sie muss funktionstüchtig sein und vor allem muss sie etwas sein, das die Kunden haben wollen, und zwar unbedingt. Die beiden ersten Kriterien können erfüllt sein, aber was nützt das, wenn der entscheidende Punkt des „Ich will das haben“ nicht zutrifft?

Die Gefahr, diesen entscheidenden Punkt nicht zu erfüllen, ist der klassischen Vorgehensweise immanent. Dagegen helfen Methoden wie Arbeitsteilung und Spezialisierung alleine nicht. Denn sie ändern nichts am grundsätzlichen plangetriebenen Ansatz: Zunächst werden die Anforderungen – der Scope – definiert, und dann analysiert, in welcher Zeit und mit welchem Budget er umgesetzt werden kann. Das Ergebnis und die zu leistende Arbeit stehen von Anfang an fest, sie werden exakt geplant und dieser Plan dann befolgt, der Scope ist in Stein gemeißelt. Es gibt Produktsparten, die mit diesem Ansatz gut fahren. In der Entwicklung softwarebasierter Innovationen in einem komplexen Markt- und Technologieumfeld ist jedoch Skepsis angebracht. Denn die Diskrepanz zwischen starren Handlungsroutinen auf der einen Seite und einem extrem wandlungsfreudigen Markt auf der anderen bleibt bestehen. Damit ist die Frage beantwortet, für wen und warum Enterprise Agility interessant ist: Allen voran ist sie interessant für diejenige Abteilung, die softwarebasierte Innovationen entwickelt. Denn die Existenz dieser Abteilung hängt davon ab, wirkliche Marktinnovationen hervorzubringen. Nicht einmal und nicht zufällig, sondern immer wieder. Noch nicht beantwortet ist, was sich ändern muss, um agiler zu werden, und wie es sich ändern sollte. Die Unterscheidung zwischen Was und Wie ist mehr als eine Frage von akademischer Natur. Tatsächlich steht das Wie erst an dritter Stelle nach dem Warum und Was. Entscheidend ist zunächst, was Agilität ändert.

Kurz gesagt: Der agile Ansatz verspricht keine bessere Methode, die Zukunft vorherzusagen. Monatelanges Design im Voraus kann immer noch in einer Menge Konzepte und Grafiken enden, die am Ende irgendwo verstauben. Deshalb dreht Enterprise Agility das beschriebene Dreieck aus Scope, Budget und Zeit sozusagen um. Anstelle des detaillierten Plans, der langen Konzepte und bunten Grafiken tritt die Frage nach dem Hauptnutzen, den das neue Produkt haben soll. Der Nutzen hängt seinerseits von bestimmten Merkmalen ab, die – als einzige – sofort umgesetzt werden. Dazu wird innerhalb eines vorgegebenen Rahmens an Zeit und Budget eine Pilotversion des angepeilten Produkts gebaut und von Testkunden genutzt und bewertet. Ob und welche Features dann als Nächstes auf die Anforderungsliste kommen, hängt allein von diesen Kundenrückmeldungen ab. Die Pilotversion muss kein fertiges Produkt sein, es kann sich auch um ein Teilstück handeln, das aber auf jeden Fall mindestens eine fertige und einsetzbare Funktionalität hat. Außerdem muss dieses (Teil-)Produkt bereits harten Qualitätskriterien standhalten. Agilität basiert auf dem Prinzip Transparenz – Inspektion – Adaption. Das in jeder Iteration gelieferte Produktinkrement ist die objektiv beurteilbare Instanz, die Transparenz schafft – und damit die Grundlage des agilen Prozesses. Statt klassisch plangetrieben vorzugehen, setzt der agile Ansatz eine nutzengetriebene Vorgehensweise um.

Auf der nächsten Seite beschäftigen wir uns ausführlich mit der agilen Organisation der Teams.

Agile Day auf der International PHP Conference

International PHP Conference 2014

Noch mehr Wissenswertes rund um das Thema Agile Methoden bietet der Agile Day auf der IPC.

Vom 1. bis zum 4. Juni findet in Berlin parallel zur International PHP Conference 2014 die webinale 2014 statt. In über 80 Vorträgen und Keynotes sowie in sechs Workshops erfahren Webenthusiasten alles, was man für den Erfolg im Web benötigt. Und das Beste daran: Besucher der IPC haben freien Zugang zu allen Sessions der webinale!

[ header = Seite 2: Agile Organisation ]

Agile Organisation

Iterativ zu arbeiten, anstatt sehr viel Zeit und Aufwand auf Analyse und Design zu verwenden, ändert auch die Rolle des Managements. Innerhalb der agilen Transition – der Umwandlung in ein agiles Unternehmen – verschlanken sich die Hierarchien, während die Führungsspanne in der Linie wächst. In klassischen Projekten gibt es einen Teamleiter, der nicht eine, sondern gleich vier Rollen hat. Denn er oder sie soll vier Aufträge adressieren: Mitarbeiterentwicklung, Kundennutzen, Produktivität und Qualität. Auf eine komplexe Herausforderung mit einer noch komplexeren Planung zu begegnen, führt meist zur Überforderung. Deshalb wendet der agile Ansatz das Prinzip der Spezialisierung auf diese Rolle an und teilt sie auf: Während die Qualität und Lieferfähigkeit Sache des Entwicklerteams ist, gibt es im mittleren Management neben den typischen Führungsaufgaben neue Rollen: die des Verantwortlichen für den Kundennutzen und für die Produktivität.

Innerhalb der agilen Organisation erhält jeder einzelne Auftrag (Mitarbeiterentwicklung, Kundennutzen, Produktivität und Qualität) damit seine eigenen Verantwortlichen und seine eigenen Aufgaben (Abb. 1).

Abb. 1: Agile Organisation mit den einzelnen Streams Mitarbeiterentwicklung, Kundennutzen, Produktivität, Qualität

Auf der Teamebene gibt es also einen Verantwortlichen für die Linienführung der Teams, der ca. drei bis fünf Teams betreut, pro Team gibt es die Entwickler, einen Product Owner und den Scrum Master. Neu im Vergleich zum Scrum auf Teamebene sind die zusätzlichen Rollen als Area Product Owner, Area Scrum Master und, verantwortlich für die Qualität, der Area Architect. Diese Area-Rollen haben für Scrum Master und Architekten ihrerseits keine Hierarchie, sie bilden eine Gemeinschaft mit gleicher Praxis.

Warum nun diese zusätzlichen Rollen? Weil bei Enterprise Agility ein Change-Team Veränderungen nicht monatelang plant, in Konzepte schreibt und in Grafiken darstellt. Wie gesagt, auch der agile Ansatz liefert kein Rezept, um die Zukunft vorherzusagen. Er versucht es gar nicht. Stattdessen geht das agile Team inkrementell vor, sei es um ein Produkt zu entwickeln oder sei es, um eine agile Transition einzuleiten. Die Zukunft wird Schritt für Schritt erkundet und auf Basis des Gelernten gestaltet. Kleine Änderungsschritte werden nach und nach realisiert, sofort getestet und konsequent an die reale Bedürfnislage angepasst. Daraus entsteht ein vom Nutzen getriebenes Vorgehen.

Trotzdem arbeitet die oberste Ebene, wie die Abbildung zeigt, weiterhin plangetrieben. Wie passt das zusammen? Das Topmanagement ist der Hauptmotivator für die Einleitung der agilen Transition. Es ist das Management, das analysiert, welche Herausforderungen intern wie extern die eigene Wettbewerbsfähigkeit bedrohen, und entsprechende strategische Ziele ableitet, um gegenzusteuern.

Diese strategischen Ziele werden idealerweise aus Sicht der Kunden des Unternehmens formuliert und erklären den eigenen Mitarbeitern das Warum und Was der Veränderung. Sie bilden die Kernstrategie und sind als solche festgelegt. Was das Management nicht vorgibt, ist das Wie, d. h. die Art und Weise, wie die einzelnen Abteilungen diese Ziele verwirklichen. Anstelle einer Anweisung steht an erster Stelle die Frage nach jenen Funktionalitäten, die realisiert sein müssen, um den erwünschten Nutzen zu erzielen. Spätestens hier wird deutlich, dass es mit abstrakten Anforderungen im Stil von „Wir wollen besser werden“ nicht getan ist. Genauso wenig reicht eine oberflächliche Analyse. Ein Beispiel: Ein exportorientiertes Unternehmen erleidet Einbußen und macht dafür ungünstige Wechselkurse verantwortlich. „Verbesserung des Wechselkurses“ ist jedoch für die Produktion kein erreichbares Ziel. „Billiger produzieren“ klingt wie eine Lösung, ist es aber vielleicht nicht. Denn möglicherweise resultieren zusätzliche Verluste aus einem Nachfragerückgang aufgrund schlechter Qualität. Weitere Sparmaßnahmen in der Produktion könnten diesen Effekt noch verschärfen. Hier wäre also ein Ansatzpunkt, die häufigsten Qualitätsmängel zu analysieren und ihre Ursachen zu beheben, selbst wenn das neue Kosten verursacht. Weil „Wir wollen bessere Qualität erzeugen“ auch nur eine abstrakte Forderung ist, könnte das Management vorschlagen, die Produktion komplett umzustellen.

Die Manager auf Divisionsebene formulieren die Anforderungen in Epics um – in große, zentrale Aufgaben, die dann immer weiter hinuntergebrochen werden in User Stories und schließlich in Sprints. Anders gesagt hat jeder Area Product Owner, jeder Area Scrum Master und jeder Area Architect sein eigenes Backlog, seine eigene Liste mit iterativ zu lösenden Aufgaben. Genau das Gleiche gilt für die entsprechenden Rollen pro Team.

Die klassische Infrastruktur der Personalführung bleibt, wie sie ist. Die anderen Einheiten und Ebenen stellen sich demnach entsprechend der agilen Struktur auf. Denn für die agile Transition gibt es kein „Eine Größe für alle“-Rezept und keinen Standardprozess, mit dem ein Unternehmen agil werden kann, genauso wenig wie Scrum bei einzelnen Produkten die Zukunft vorhersagen kann. Weil das unmöglich scheint, ändert Scrum auf der Teamebene die Arbeitsweise und Organisation. Genau das Gleiche passiert bei Enterprise Agility auf den übergeordneten Unternehmensebenen: Mit der beratenden Unterstützung ausgebildeter Engagement-Manager stellt ein Unternehmen ein Change-Team auf, das in festgelegten zeitlichen Etappen bestimmte Änderungen realisiert. Je nach Rückmeldung aller betroffenen Bereiche folgen die nächsten Änderungen. Diese neue Organisation spiegelt die beschriebene Matrix aus den Kernaufträgen Mitarbeiterentwicklung, Kundennutzen, Produktivität und Qualität und den Unternehmensebenen wider. Jeder Kernauftrag entwickelt sein eigenes, spezifisches Backlog und setzt es nach den Regeln von Scrum iterativ und inkrementell in definierter Qualität um. Kein radikales „Ab heute ist alles anders“, sondern eine schrittweise, transparent dokumentierte Änderung. Anders gesagt: Eine Änderung, die dank der kleinen Etappen flexibel genug ist, um sich jederzeit an das anzupassen, was im Umfeld passiert. Das ist agil. Und ein ganz großer Vorteil im Hinblick auf die Wettbewerbsfähigkeit.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Meinungen zu diesem Beitrag

X
- Gib Deinen Standort ein -
- or -