Change-Projekt in einem Großunternehmen

Agilität in Unternehmen – so wird man agil [Teil 2]
Keine Kommentare

Software agil entwickeln – ja oder nein? Es ist tatsächlich merkwürdig, dass sich Unternehmen diese Frage immer noch stellen. Um es vorweg zu nehmen: Eigentlich bleibt ihnen keine Wahl, denn Agilität ist schon lange kein Trend und keine Mode mehr. Der zweite Teil des Artikels zeigt an einem Beispiel, wie ein Unternehmen agil werden kann.

Nachdem der erste Teil des Artikels zeigte, wieso die Anforderungen an das neue Verhalten von Unternehmen für agile Konzepte sprechen und welche Rolle agile Methoden dabei spielen, geht es in diesem zweiten Teil an die Praxis. Er zeigt anhand einer Case Study, wie sich Agilität in Unternehmen integrieren lässt.

Zu den Anforderungen des auf Dienstleistungen spezialisierten Unternehmens, das im ersten Teil des Artikels angesprochen wurde, passte lange Zeit die Softwareentwicklung nach „klassischen“ Vorgaben: ausführliche Spezifikationen, phasenorientiertes Vorgehen, große Releases. Aber alle Beteiligten stellten fest, dass dieses Vorgehen immer häufiger zum Hemmschuh wurde. Aufwendige Abstimmungsprozesse, zahlreiche Änderungen der Anforderungen, unzureichende Koordination zwischen den nach IT-Kompetenzen aufgestellten Abteilungen und eine geringe Termintreue sorgten für Unzufriedenheit und damit Handlungsbedarf.

Agile Prozesse, abgestimmt auf die Anforderungen einer großen Organisation, sollten Abhilfe schaffen. Aber wie können 150 IT-Experten auf agile Methoden eingeschworen werden? Wie können komplexe Prozesse mit eng verzahnten Systemen, die mehrere Teams betreffen, agil gestaltet werden? Unterstützt durch den IT-Dienstleister adesso machten sich die IT-Verantwortlichen daran, Agilität im großen Maßstab umzusetzen.

Artikelübersicht

Teil 1: Agilität – eine Grundvoraussetzung für funktionierende Digitalisierung
Teil 2: Agilität in Unternehmen – So wird man agil

Individualentwicklung für ein individuelles Geschäft

Die IT-Teams fungieren aktuell noch als interner Dienstleister des ganzen Konzerns. Ihre Auftraggeber sind Fachabteilungen oder auch das Marketing. Für viele der intensiv IT-gestützten Prozesse werden intern eigene Lösungen entwickelt, da auf dem Markt erhältliche Softwareprodukte weder den geforderten Funktionsumfang noch die benötigte Funktionstiefe erreichen. Dazu gehören fachliche Standardthemen wie Abrechnung und Service, das Kerngeschäft des Konzerns, aber auch neue innovative digitale Endkundenprodukte. Dabei hört der Service nicht an den Landesgrenzen auf. Auch für ausländische Gesellschaften entwickeln die Fachleute Lösungen neu beziehungsweise weiter.

Die IT-Organisation folgte dabei in der Vergangenheit einer weit verbreiteten Aufstellung: Anforderungs-, Entwicklungs- und Testbereich waren hintereinandergeschaltet. Die Teams arbeiteten in Form eines Phasenmodells inklusive Rückkoppelungsschleifen zwischen den Phasen Planung, Analyse, Entwicklung, Test und Produktion. Ungewöhnlich an der Organisation: Die Teams entwickelten bis zu fünf Releases gleichzeitig, die jeweils um eine Phase verschoben waren. Während das erste Release noch in der Planung steckte, war das zweite bereits in der Analyse, das dritte in der Entwicklung und so weiter. Über 150 IT-Fachleute waren so in einer Kette von der Anforderungsanalyse bis hin zum Testing organisiert.

In dieser Kette knirschte es jedoch. Dabei gab es nicht das eine Ereignis oder die eine Kennzahl, die eine Diskussion über den Softwareentwicklungsprozess anstieß. Eine ganze Summe von kleineren und größeren Faktoren ließ die Entscheider hellhörig werden. Insbesondere das Vertrauen der Mitarbeiter in die Releaseplanung war nicht so groß, wie sich das Management das wünschte. Häufig änderten sich die Anforderungen an das neue Release – Anpassungen, die die Teams aufgrund der engen Verzahnung der Abläufe vor große Herausforderungen stellten – und Termine mussten immer wieder angepasst werden.

Einerseits viel Aufwand, der in Planung und Abstimmung investiert wurde, andererseits ein Ergebnis, das von vielen als unbefriedigend empfunden wurde: Die IT-Verantwortlichen entschlossen sich dazu, die Arbeit ihrer Teams neu zu organisieren und trugen die Diskussion zu diesem Thema in das Management. In dieser Runde wurden Alternativen geprüft: noch mehr Planung, eine noch engere Begleitung der Projekte. Am Ende entschlossen sich die Entscheider aber dazu, einen auf den ersten Blick genau anderen Weg zu gehen: mehr dezentrale Abläufe und mehr Selbstverantwortung. Methoden der agilen Softwareentwicklung sollten die vorhandenen Unzulänglichkeiten abstellen.

Von vornherein war klar: Für dieses Projekt können die Entscheider agile Methoden wie Scrum nicht eins zu eins umsetzen, denn diese Ansätze sind häufig auf die Teamebene zugeschnitten und führen hier auch zum Ziel. Aber wenn es darum geht, teamübergreifende Abhängigkeiten darzustellen, war das Vertrauen in diese Konzepte zu gering. Gesucht wurde deshalb eine Variante der Agilität, die auch im großen Maßstab Sicherheit vermittelt. Die Verantwortlichen entschieden sich für das Scaled Agile Framework (SAFe).

DevOps Docker Camp

Sie lernen die Konzepte von Docker und bauen Schritt für Schritt eine eigene Infrastruktur für und mit Docker auf.

Agilität entsteht im Kopf, nicht auf dem Organigramm

Zwischen der ersten Idee und dem ersten Release, das agil entwickelt wurde, lag ein umfangreicher Change-Management-Prozess. Denn auch in diesem Punkt war sich das IT-Management einig, primär geht es bei Agilität darum, die Einstellung der Beteiligten zu verändern.

Bei der Gestaltung und Umsetzung dieses Prozesses arbeiteten die Verantwortlichen eng mit externen Consultants des IT-Dienstleisters adesso zusammen. Am Anfang stand adesso beratend zur Seite, mit fortschreitendem Projekt arbeiteten die Experten immer häufiger als Coaches und unterstützen die Teams in ihrer tagtäglichen agilen Arbeit.

Schon sehr früh konnten so externes Wissen und externe Erfahrung in das Projekt eingebracht werden. Noch bevor die Entscheider den eigentlichen Roll-out planten, wurden im Kreis der IT-Führungskräfte Workshops zum Thema Agilität durchgeführt. Ihr Zweck war es, auf der Ebene des mittleren Managements Verständnis aufzubauen und unterschiedliche agile Ansätze kennenzulernen. In dieser Frühphase besuchten Vertreter des Führungskreises auch andere Unternehmen, die bereits agil entwickelten.

Agilität muss agil eingeführt werden

Schnell kristallisierte sich bei den Projektverantwortlichen eine Vorstellung davon heraus, wie der Weg der Einführung aussehen kann. Es war aber auch allen bewusst, dass ein starrer, konsequent umgesetzter Plan nicht zur agilen Idee passt. Das Einführungsprojekt wurde deshalb auch als Möglichkeit betrachtet, die agile Idee vorzuleben. So wurden gezielt nur einige Meilensteine definiert, die das Team zeitlich und inhaltlich erreichen wollte; den Weg dazwischen passten sie flexibel an Situation und Personen an.

Dieser Weg begann für die über 150 IT-Teammitglieder mit einem gemeinsamen Event, das den Teilnehmern nachhaltig im Gedächtnis blieb. Hier kamen alle Beteiligten außerhalb der Tagesroutine und auch außerhalb der eigenen Räumlichkeiten zusammen, hier wurde der Grundstein der agilen Offensive gelegt. Der Aufwand, der für die Organisation und Durchführung der Veranstaltung betrieben wurde, zeigte allen von Beginn an deutlich: Das Unternehmen meint es mit der Agilität ernst.

Nach dieser zentralen Veranstaltung ging es daran, ein Bewusstsein für Agilität zu entwickeln. Welche Ideen, Werte und Konzepte verbergen sich dahinter? Wie kann ich agil arbeiten? Die Antworten auf diese Fragen erarbeiteten die Teams auf ungewöhnliche Art und Weise – spielerisch in Workshops. Im ersten Schritt ging es nicht um Softwareentwicklung oder Releaseplanung, sondern um das Bauen von LEGO-Türmchen oder das Planen von Haushaltstätigkeiten. Anhand von einfachen Aufgaben – ohne die Belastung des täglichen Arbeitens – setzten sich die Teams mit agilen Prinzipien auseinander.

So lernten die Experten „live“, dass sogar ein Turm aus Bauklötzchen sehr agil aufgebaut werden kann, oder ganz klassisch nach der Wasserfallmethode. Am Ende hatten die Beteiligten die Unterschiede zwischen den einzelnen Konzepten direkt vor Augen. Zahlreiche solcher Übungen, die Aspekte der Agilität vermittelten, dachten sich die internen Projektverantwortlichen gemeinsam mit den adesso-Beratern aus. Pro Termin wurden zirka fünfzehn Mitarbeiter geschult, die Gruppen waren ganz bewusst bunt gemischt. Java, Host und SAP, Tester, Entwickler und Requirements Engineers – die Projektorganisation achtete darauf, dass jeder einzelne Kollege möglichst mit Personen in einer Schulung saß, mit denen er in der täglichen Arbeit bisher wenig zu tun hatte. Wissensvermittlung und Teambuilding gingen so Hand in Hand.

Auf die Workshops folgten Basisschulungen, die die Grundlagen realer agiler Methoden vermittelten. Diese Schulungen waren für alle Teilnehmer gleich, die Spezialschulungen für Rollen wie Scrum Master, Teammitglied oder Product Owner bauten dann anschließend darauf auf. Dort ging es darum, den Beteiligten Details über Scrum auf Teamebene und das übergeordnete Scaled Agile Framework zu vermitteln.

Dieses Framework war die Antwort auf die eingangs gestellte Frage, wie komplexe Prozesse, die mehrere Teams betreffen, agil gestaltet werden können. SAFe ist ein Rahmenwerk für skalierte Agilität und liefert dem Konzern einen bewährten Rahmen, der dafür sorgt, dass Agilität auch in Größenordnungen von 150 und mehr Mitarbeitern funktioniert. Diesen Rahmen passten die Projektbeteiligten so an, dass er optimal zu den Unternehmensforderungen passte.

Bei diesen Spezialschulungen unterstützten die adesso-Experten nicht nur die Vorbereitung, sie waren auch bei den Terminen dabei. So schulten erfahrene adesso-Coaches gemeinsam mit internen Trainern zukünftige Product Owner, Scrum Master oder Entwickler aus DBT-Teams für ihre neuen Rollen – ein Konzept, das sich rückblickend bewährt hat. So konnten die Projektverantwortlichen während der Schulungsphase die Brücke zwischen agiler Theorie und Praxis schlagen.

Auch wenn das Schulungsprogramm prall gefüllt war: Neben all diesen Terminen ging die Arbeit für das IT-Team weiter, Releases mussten geplant und neue Funktionen entwickelt werden. Den zur Verfügung stehenden Schulungszeitraum nutzte die gesamte IT-Führungsmannschaft dafür, in enger Abstimmung mit den einzelnen Mitarbeitern und dem Betriebsrat, Teams zu planen und zu besetzen. So entstanden die Strukturen, in denen Agilität künftig umgesetzt werden sollte.

Während die Schulungen zu Ende gingen, fing die Zeit der konkreten agilen Softwareentwicklung an. Dabei wählten die Manager keine Big-Bang-Strategie, sondern entschieden sich dafür, Team für Team auf Agilität umzustellen. Dies hatte zwar zur Folge, dass in der IT-Abteilung für einen längeren Zeitraum zwei Konzepte – Agilität und „Phasenorientierung“ – gelebt und koordiniert werden mussten. Auf der anderen Seite verschaffte dieses schrittweise Vorgehen den Verantwortlichen aber den nötigen Spielraum, um gemeinsam mit externen Coachs den Weg jedes einzelnen Teams intensiv zu begleiten.

Um diesen Übergang von Phasenorientierung zu Agilität auf Teamebene erfolgreich zu gestalten, setzten die Experten auf das Konzept des so genannten „Preparation Sprint“. Mit diesem ersten Sprint verfolgten sie dabei zwei Ziele: Einerseits diente er als weitere Übung und sorgte dafür, dass jeder Einzelne die Scrum-Grundlagen noch einmal auffrischen konnte. Andererseits sollte sich das ganze Team während dieser ersten Sprint-Phase so finden und koordinieren, dass es im Anschluss agil durchstarten kann. Somit diente dieser erste Schritt der Selbstorganisation. Alle Teammitglieder suchten die Antwort auf die Frage: „Was ist noch zu tun, um ab dem nächsten Sprint ‚echt‘ zu arbeiten?“

Entwickler Magazin

Entwickler Magazin abonnierenDieser Artikel ist im Entwickler Magazin erschienen.

Natürlich können Sie das Entwickler Magazin über den entwickler.kiosk auch digital im Browser oder auf Ihren Android- und iOS-Devices lesen. In unserem Shop ist das Entwickler Magazin ferner im Abonnement oder als Einzelheft erhältlich.

Grenzen überwinden – Fortschritt erzielen

Noch läuft nicht alles rund, aber vieles läuft deutlich besser als vorher. Dank der agilen Teams konnte der Konzern die Grenzen zwischen den Abteilungen innerhalb der IT überwinden – ein wichtiger erster Schritt. Es heißt nun nicht mehr: „die Tester und wir“ oder „die Entwickler und wir“. Stattdessen arbeiten alle zusammen auf ein gemeinsames Ziel hin.

Ein wichtiger Baustein sind auch die Release-Planning-Events. Auf ihnen treffen sich alle Beteiligten und planen das kommende Release. Die Teams koordinieren ihre Arbeit eigenständig, und jeder Einzelne wird zu seiner Einschätzung gefragt; Gegenmeinungen werden explizit berücksichtigt. Am Ende entsteht so eine Planung, die von allen verstanden und getragen wird.

Dieses Projekt zeigt auch, dass agile Softwareentwicklung nicht nur in homogenen technologischen Umgebungen mit nur einem Produkt sinnvoll ist. Der Konzern arbeitet mit einer sehr heterogenen IT-Landschaft und hat große SAP-, Java- und Mainframe-Technologie-Teams. Aber Agilität zahlt sich für alle Bereiche aus.

Fazit

Der aktuelle Zwischenstand lautet: Es existiert eine agile IT-Abteilung in einem nicht agilen Unternehmen. Das Projektteam hat also erreicht, was erreicht werden sollte. Die Optimierung der IT-internen Abläufe ist voll wirksam. Viel wichtiger jedoch: Bei den Verantwortlichen hat ein Veränderungsprozess begonnen. Reviewmeetings ohne Nutzer oder gar ohne Kunden werden von allen Beteiligten laut beklagt und deren Anwesenheit eingefordert. Anforderungen der Fachabteilungen erörtern die Experten untereinander konstruktiv und auf Augenhöhe. Das Thema der „agilen Führung“ ist nun auf Managementebene – auch über die IT hinaus –angekommen. Die Grenze zwischen IT und Fachbereichen wurde aber noch nicht aufgelöst, hier besteht noch Handlungsbedarf.

Und wie steht es mit der skalierten Agilität? Ist SAFe ein sinnvolles Modell? Der Exkurs zeigt: Es hilft beim Start. Die Einführung eines klassischen Scrums als teambezogenes Framework hätte nicht wie SAFe alle Beteiligten mit ins Boot geholt, der Beginn der Transition wäre um ein vielfaches schwieriger gewesen und der agile Ansatz höchstwahrscheinlich auf der Teamebene stecken geblieben. Genau so war es bei dem Unternehmen des beschriebenen Beispiels bei einem vorangegangenen Versuch schon einmal geschehen. Stand-up-Meetings und Boards waren bereits da, wirkliche Agilität jedoch nicht.

Die Antwort ist aber auch: SAFe baut neue Hürden auf, da Konformität mit einem Modell für ein digitalisiertes Unternehmen eigentlich kein Wert mehr sein kann. Es ist für ein Change-Projekt hin zur Agilität aber eben auch entscheidend, den Schwung nicht zu verlieren und möglichst viele der Protagonisten zu überzeugen. Das ist mit SAFe, aber auch LeSS (Large Scale Scrum) oder irgendeinem anderen Ansatz möglich, der bei der Selbstorganisation hilft – solange es von innen kommt.

Und die Digitalisierung? Auch hier gibt es erste Erfolge. Neue Services wurden in sehr kurzen Zeiträumen geschaffen, beim Nutzer nicht Erfolgreiches wurde schnell wieder reuelos verworfen, und wichtige Erkenntnisse wurden gesammelt. Die Teams verstehen zunehmend besser, welche Bedeutung die Softwareentwicklung für die Marktchancen von Unternehmen hat und beteiligen sich aktiv. Aber es bleibt viel zu tun – und der Druck zur Digitalisierung steigt stetig.

Unsere Redaktion empfiehlt:

Relevante Beiträge

Hinterlasse einen Kommentar

Hinterlasse den ersten Kommentar!

avatar
400
  Subscribe  
Benachrichtige mich zu:
X
- Gib Deinen Standort ein -
- or -