7 Stolpersteine beim „agil sein“ im ITSM

Wenn Sie sich eine agile Arbeitsumgebung als Ziel setzen, gibt es leider kein Drehbuch, an das Sie sich halten können. Es gibt allerdings Fachleute, die beim Übergang unterstützen. Steven Happee ist einer davon. Er hat schon eine Vielzahl Unternehmen bei deren Übergang zu einer agilen Arbeitsumgebung gecoached. Heute erzählt er Ihnen, welche Stolperfallen Sie vermeiden sollten.

Steven Happees Weg zum „agil sein“

In den neunziger Jahren hat Steven Happee in einem kleinen, interdisziplinären Team Software entwickelt. Die Methode, die genutzt wurde, würde heutzutage als agil gelten. Dabei hat er seine Leidenschaft für das „agil sein“ entdeckt.

Heute, zwanzig Jahre später, hilft er Organisationen dabei agiler und lernorientierter zu werden. Er setzt seine vielfältige Erfahrung als Product Owner, Scrum-Meister, Entwickler und Manager ein, um aufschlussreiche Experimente durchzuführen. Steven Happee stellt uns die seiner Erfahrung nach sieben häufigsten Stolperfallen beim Übergang zum „agil sein“ vor.

1. Übergang zum „agil sein“ wird nur nach dem Top-down-Verfahren betrachtet

Der Übergang zum „agil sein“ kann nach zwei Prinzipien erfolgen: Top-down oder Bottom-up. Das Bottom-up Prinzip bedeutet, dass das Team, beispielsweise eine IT-Abteilung, die Initiative zu einer agileren Arbeitsweise ergreift.

Beim Top-down Prinzip hingegen kommt der Impuls vom Vorgesetzten, CEO oder CIO. Das Ziel ist, einen Großteil des Betriebs oder sogar die ganze Organisation agiler zu machen. Das Top-down Prinzip ist noch relativ neu. „Agil sein“ hat sich in den letzten Jahren zu einem angesagten Thema entwickelt. Immer mehr CEOs und CIOs beschäftigen sich damit.

Das Bottom-up Prinzip ist aber normalerweise erfolgreicher. Insbesondere in Teams der IT-Branche, wo das Konzept des „agil seins“ ursprünglich herkommt, ist dies gut zu beobachten. Ein Teammitglied möchte gerne mit dem „agil sein“ experimentieren, sein Vorgesetzter ist begeistert und es wird ein Scrum-Team gebildet. Sollte dieses Team gut performen, könnten weitere Teams folgen. Bald wird das ganze Unternehmen neugierig.

Am besten funktioniert ein Prinzip, bei dem Bottom-up und Top-down kombiniert werden: ein Team beginnt initiativ, agiler zu arbeiten und sucht sich einen Befürworter aus der Unternehmensleitung.

2. Wasserfallmodell für den Übergang zum „agil sein“ nutzen

Viele Leute waren vor zehn Jahren noch der Meinung, dass Prince2 benötigt wird, um „agil“ zu arbeiten. Zuerst wird ein Design erstellt, dieses wird dann Schritt-für-Schritt umsetzt, Meilensteine entwickelt, etc. Aber das ist ein Widerspruch.

Glücklicherweise sind heutzutage die meisten davon überzeugt, dass ein Übergang zum „agil sein“ auch eine agile Herangehensweise erfordert. Der Übergang zum „agil sein“ ist schließlich ein komplexes Projekt. Es wird anders zusammen gearbeitet, die Denkweise ändert sich und es werden andere Werkzeuge eingesetzt. Bestenfalls erfolgt dieser Übergang schrittweise mit einem interdisziplinären Team und einem Change Backlog.

3. Zu streng beim Umgang mit agilen Techniken

Agile Frameworks wie Scrum bieten Techniken, um eine agile Denkweise auf den Arbeitsalltag zu übertragen. Diese Techniken wie zum Beispiel Backlogs und Retros sind für jedermann gut erkennbar. Sie stellen aber nur die Spitze des Eisbergs dar, den sichtbaren Teil einer agilen Arbeitsweise. Diese Techniken basieren auf bestimmten Annahmen, wie Arbeit organisiert werden soll. Sie leiten sich von Prinzipien aus dem Manifest für agile Softwareentwicklung oder Modern Agile ab.

Manche Leute tendieren dazu, sich sehr streng an diese Techniken zu halten, obwohl Sie die dahinterstehenden Prinzipien nicht verstehen. Das kann zu Spannungen führen. Manche Techniken eignen sich eventuell auch nicht für Ihre Organisation. Es wäre unklug, ihnen blind zu folgen. Letztendlich kommt es aber auf die Werte des „agil seins“ an und nicht auf die Techniken. Deshalb ist es sinnvoll, die dahinterstehenden Prinzipien zu erklären, wenn jemand agil sein möchte. Damit er etwas hat, auf das er sich stützen kann.

4. Bestehende Techniken zu schnell abwandeln

Selbstverständlich müssen Sie agile Techniken an Ihre eigenen Bedürfnisse anpassen – aber nicht sofort. Die agile Szene bezieht sich oft auf etwas namens ShuHaRi, eine japanische Kampfkunst. Diese eignet sich etwas in drei Phasen an. Es wird damit begonnen, dass Sie sich eine bereits bestehende Technik bis ins kleinste Detail verinnerlichen (Shu). Sind die Regeln internalisiert, können Sie eigene Variationen in die Technik einbinden (Ha), bis Sie schließlich das „Ri-“erreichen: Sie benötigen keine Regeln oder Techniken mehr, sondern handelt mit intuitiver Kompetenz.

Ich bekomme oft mit, dass Teams Abwandlungen vorhandener Techniken einsetzen oder einzelne Elemente aus anderen Frameworks entlehnen. Dafür höre ich verschiedene Rechtfertigungen: „Die Theorie ist mir bekannt. Aber ich weiß genau, dass das für uns nicht funktionieren würde“ oder „Wir experimentieren gerne. Deswegen kombinieren wir verschiedene Techniken“. Klar, experimentieren ist gut, aber zunächst einmal bedarf es einer stabilen Grundlage. Schauen Sie sich für sechs bis zwölf Monate in der Praxis an, wie eine bestehende Methode funktioniert. Wie funktionieren Sprints? Was ist eine gute Retro? Was bedeutet für uns “Nutzen für den Kunden”? Nur wenn Sie eine stabile Grundlage haben, können Sie anfangen, zu variieren.

5. „Agil sein“ und projektbasiertes Arbeiten im gleichen Team

Agile und projektbasierte Arbeitsweisen haben fundamental unterschiedliche Ausgangspunkte. Auf der „agil sein“ Seite gibt es gleichbleibende Teams. Die Teammitglieder kennen die Stärken der jeweils anderen und entwickeln sich zusammen weiter. Sie geben also die Arbeit an die Teams. Bei projektbasierter Arbeit haben Sie Arbeit und stellen temporär ein Team dafür zusammen – Sie bringen also die Teams zur Arbeit. Diese beiden Varianten sind nicht miteinander kombinierbar.

6. Stellen Sie sich den Übergang zum „agil sein“ wie eine IT-Party vor

Oftmals ist die Vorstellung, was sich durch agiles Arbeiten überhaupt bewirken lässt, beschränkt. „Agil sein“ ist nicht auf das IT Scrum-Team beschränkt. Der Übergang zum „agil sein“ ist vielmehr ein Kulturwandel. Er betrifft sämtliche Prozesse und Menschen in Ihrer Organisation, von der Finanz- bis zur HR-Abteilung. Was ändert sich in der Rolle der Teamleitung, wenn Teams sich selbst managen? Wie werden Mitarbeiter in Scrum-Teams bewertet? Passen Jahresbudgets und Scrum-Teams zueinander? In den meisten Fällen möchten immer mehr Teams innerhalb der Organisation agiler arbeiten.

Je früher Sie verstehen, dass der Übergang zum „agil sein“ die ganze Organisation betrifft, umso leichter wird er. Deshalb betrachten viele Manager das „agil sein“ als Chance, einen Kulturwandel herbeizuführen. Es kann zum Beispiel kundenorientierter gearbeitet werden oder die Eigenverantwortung der Mitarbeiter wächst. In vielen Fällen haben Vorgesetzte bereits einige Methoden ausprobiert, um die Unternehmenskultur zu ändern. Bei agilen Techniken sind Änderungen wie größere Kundenorientierung oder mehr Eigenverantwortung eher das Nebenprodukt und nicht das Primärziel.

7. Zu früh den nächsten Schritt wagen

In der agilen Szene gibt es schon einige Erfahrung im agilen arbeiten auf Teamebene. Aber wenn das Team erstmal zusammengestellt und eingearbeitet ist, wie kann das Ganze dann auf zwei oder sogar drei Teams erweitert werden? Oder zwanzig? Und wie funktioniert „agil sein“ für Abteilungen wie den Vertrieb oder HR? Das ist eine harte Nuss, an der die agile Szene im Moment noch arbeitet.

Es gibt verschiedene Frameworks, um agile Teams zu vergrößern, wie das Spotify-Modell, SAFe (Scaling Agile Framework) und LeSS (Large Scale Scrum). Der wichtigste Schluss daraus: Wenn Sie nicht unbedingt den nächsten Schritt machen müssen, sollten Sie es lassen. Testen Sie, ob Sie Ihre Teams unabhängig voneinander arbeiten lassen können. Denken Sie gar nicht erst darüber nach, Frameworks zu skalieren, solange sie noch andere Optionen haben. Manche Organisationen lassen sich von der ersten Euphoriewelle mitreißen. Sie wollen von jetzt auf gleich den gesamten Betrieb auf “agil” umstellen. Lassen Sie das. Sie müssen nicht an Problemen herumschrauben, die nicht existieren.

Sie möchten mehr über Agile Servicemanagement erfahren?

In unserem E-Book finden Sie alles Wissenswerte zum Thema agiles Servicemanagement. Sie erfahren, wie „agil sein“ mit ITIL zusammenspielt, wie agile Servicemanagement in der Praxis umsetzbar ist und welche Hürden bei der Umstellung auf eine agile Arbeitsweise überwunden werden müssen.