Agile Transformation – eine märchenhafte Reise?

Bei der agilen Transformation dominieren bisher „Insellösungen“ für einzelne Teams oder Abteilungen. Berühren agile Prozesse jedoch benachbarte Teile des Unternehmens, die nach wie vor auf klassisches Projektmanagement setzen, steigt die Komplexität. Dies betrifft vor allem große Unternehmen.

Anbieter zum Thema

MicroConsult Microelectronics Consulting & Training GmbH

Axivion GmbH

Parasoft® Deutschland GmbH

Unternehmen, die ihre IT-Abteilung vollständig auf agile Methoden umstellen wollen, wissen zunächst einmal noch nicht, wohin die Reise wirklich geht und was sie mit sich bringt. Vor allem, wenn wir davon sprechen, dass Agilität auch wirklich zu hundert Prozent gedacht wird – von Anfang bis Ende der Wertschöpfungskette.

Kurz gesagt: Alle sind derzeit auf der Suche nach dem „heiligen Gral“ der agilen Transformation. Jedes Unternehmen muss dabei vier Stufen meistern, die ich im Folgenden darstellen möchte: Den „Aufbruch ins Ungewisse“, den „Märchenwald“, den „dunklen Turm“ und schließlich das Finden des heiligen Grals selbst. Wer am Ende erfolgreich sein will, kann von anderen lernen, wie die Reise am einfachsten ist.

Die Reise beginnt, wo Routinen überholt sind

Wie in den meisten Märchen beginnen Transformationen in Unternehmen im Alltäglichen: Der Held (in unserem Fall kann es das gehobene Management sein, aber auch der „einfache“ Abteilungsleiter oder Mitarbeiter) lebt sein gewohntes Leben in seinem gewohnten Umfeld. Eines Tages aber tritt eine Veränderung auf. Ein Bote kommt von weither geritten und proklamiert: „Agile! Lean Management! Digital Transformation!“

Es ist klar, dass das gewohnte Leben unter diesen Bedingungen nicht weitergehen kann. Unser Held ist zunächst ratlos: Was tun in dieser Situation? Er hat jedoch gehört, dass es jenseits des Märchenwalds und des dunklen Turms ein Heilmittel gibt: Den heiligen Gral!

Wie dem Held in diesem Beispiel geht es im Grunde genommen allen Unternehmen derzeit. Sie sind mit der Notwendigkeit einer grundlegenden und dauerhaften Veränderung konfrontiert: Der Digitalisierung aller Unternehmensbereiche, vom Einkauf über die Produktion bis hin zu Vertrieb und Kundenservice.

Mit der Schnelligkeit des Wandels lässt sich nur Schritt halten, wenn die IT konsequent auf agile Methoden umgestellt wird. Um diese Erkenntnis aus der Rede des BMW-CIOs Klaus Straub bei der diesjährigen BMW IT-Messe wiederzugeben: Eine Digitalisierungsstrategie wird nur dann funktionieren, wenn die IT agil wird – und zwar zu hundert Prozent. Bis dorthin ist es jedoch ein weiter Weg. Wer den Wandel anpacken will, muss sich daher zunächst in den „Märchenwald“ begeben, wo einige schwerwiegende Irrtümer über das Thema der Agilität lauern.

Fünf Mythen über Agilität und ihr wahrer Kern

Die „Schlagwortisierung“ des Begriffs Agilität hat es mit sich gebracht, dass auch in Kontexten außerhalb des Projektmanagements von ihm gesprochen wird. Hierdurch sind einige Missverständnisse zur Funktionsweise und der zu erwartenden Resultaten agiler Methoden entstanden.

Diese Irrtümer müssen – obwohl sie oftmals einen wahren Kern besitzen – ausgeräumt werden, bevor es weitergehen kann. Auch im Märchen muss der Held zunächst die Mythen prüfen, welche über den heiligen Gral kursieren, und schließlich Wahrheit und Dichtung voneinander trennen – erst dann wird die Zielrichtung der weiteren Reise wirklich klar.

Hier die populärsten Irrtümer über Agilität und welche realistische Erwartung sich ihnen entgegenhalten lässt:

1. „Agilität ist schneller“

In dieser Pauschalität geäußert ist diese Aussage falsch. Denn der Softwareentwickler in einem agilen Projekt schreibt seine hundert Zeilen Code weder schneller noch langsamer als sein Kollege, der nach dem Wasserfall-Modell arbeitet. Nimmt man jedoch eine übergeordnete Perspektive ein, bringt Agilität natürlich den Vorteil einer niedrigen Zeitspanne für die Marktreifung eines Produkts („time to market“).

Da inkrementell entwickelt wird, stehen Teilsegmente und -funktionen der Software früher zur Verfügung. Zeit lässt sich durchaus bei den Korrekturschleifen einsparen. Schließlich erfolgt beim agilen Vorgehen das Debugging immer kleinschrittig, wodurch Folgefehler vermieden werden können. Zudem sinkt das Risiko, dass Softwareprojekt komplett am Bedarf vorbei entwickelt wird. Ein solcher „Worst Case“ kostet sehr viel Zeit – und Nerven.

2. „Agilität ist billiger“

Analog zum Zeitfaktor gestaltet sich das Argument bei den Kosten. Der Softwareentwickler kostet im agilen Projekt nicht weniger als im klassischen. Ganz im Gegenteil: Personal, das auf Agilität zertifiziert ist, hat oftmals sogar einen höheren Stundensatz. Dies ist wiederum auch deshalb der Fall, weil es sich um eine Investition für spätere Effizienzgewinne handelt: Das engere Zusammenspiel zwischen Software-Design und -Implementierung schafft einen Hebel für tatsächliche Einsparungen.

3. „Agilität ist doch bloß Kaffeklatsch am Scrum Board“

Wer sich neu mit agiler Softwareentwicklung befasst, mag von der Meetingkultur überrascht sein. Tatsächlich werden im agilen Modell quantitativ scheinbar mehr Meetings einberufen als in klassischen Projekten zumeist üblich. Über die Länge und die Produktivität der Meetings sagt dies jedoch noch rein gar nichts aus! Das Daily sollte – zumindest nach Scrum-Lehrbuch – nie länger als fünfzehn Minuten dauern. Und ob die Teilnehmer vorbereitet ins Meeting gehen und dort ergebnisorientiert miteinander kommunizieren, hängt in erster Linie von Führung und entsprechender Selbstdisziplin ab. Und von beidem braucht es auch in der agilen Welt eine Menge.

4. „Agilität kennt keine Planung“

Oftmals entsteht gerade beim fachfremden Publikum der Eindruck, Agilität sei eine Art „geplante Anarchie“. In diesem Fall wurde aber einfach nur der Grundsatz „Reagieren auf Veränderung mehr als das Befolgen eines Plans“ aus dem Manifest für Agile Softwareentwicklung falsch interpretiert. „Mehr als“ bedeutet nämlich nicht „statt“.

Planung ist nach wie vor unabdingbar. Besonders auch, wenn es darum geht, an eine Abteilung oder auch einen Kunden auszuliefern, der mit klassischen Methoden der Projektentwicklung arbeitet und dementsprechend auf die richtige Dokumentation angewiesen ist. Da im klassischen Projektkontext jedoch stark an einmal gemachten Plänen festgehalten wird, man diese jedoch auf Grund von Erkenntnissen, die man zur Projektlaufzeit gewinnt, ändern können sollte sei dies im agilen Kontext eben nur nochmals besonders betont.

5. „Bei Agilität entfällt die Dokumentation“

Dieser Irrtum beruht ebenfalls auf einer Fehlinterpretation des Manifests für Agile Softwareentwicklung. Dort heißt es nämlich: „Funktionierende Software mehr als umfassende Dokumentation“. Sicher ist es sinnvoll, sich mehr auf das Funktionieren einer Software zu fokussieren als auf eine umfängliche Dokumentation ihres Nichtfunktionierens! Allerdings entbindet dies nicht von der Pflicht, trotzdem noch sauber zu dokumentieren.

Besonders die „Definition of done“ ist ein besonders wichtiges Mittel, um die Schnittstelle zwischen Entwicklung und Auslieferung sauber abzubilden. Bei Übergaben, Teamänderungen aber auch unter Wartungsaspekten ist die Dokumentation eine sehr wichtige Ressource, um das Projekt weiterzuführen.

Wer diese Missverständnisse beiseite geräumt hat, ist zumindest schon einmal im Bilde, was die Zielrichtung angeht. Nun ist er in der Lage, die nächste, noch gefährlichere Etappe zu beschreiten: Den „dunklen Turm“.

(ID:45087481)