Es klang alles so logisch: Um mehr Geschwindigkeit in die IT zu bringen, empfiehlt das Analystenhaus Gartner den bimodalen Ansatz. Soll heißen: Altsysteme pflegen und entwickeln weiterhin die (Alt-)ITler nach den bewährten Methoden. Damit sei sichergestellt, dass nicht irgendwelche Java-Freaks an den Kernsystemen herumfrickeln, ohne angemessen zu testen und zu dokumentieren.

Auf Apps und alles, was sonst noch hip, chic und schnell sein muss, lässt der CIO hingegen die agilen ITler los, die für das Erstellen von sauberen Pflichtenheften sowieso keine Geduld aufbringen. So war das gedacht mit dem Arbeiten in zwei Geschwindigkeiten. "Funktioniert aber nicht", sagt BMW-CIO Klaus Straub.

Damit zählt er zu den zahlreichen Zweiflern, die Gartners Idee vielleicht gerade noch für die Übergangszeit für gut halten, in der Softwareingenieure vom alten Schlag den Begriff "Time to Market" mental durchdringen. Wer ganz am Anfang steht, bei wem sich die Entwickler noch an armdicke Pflichtenhefte klammern, für den könnte demnach die Two-Speed-IT ein Einstieg sein. Sie sei jedoch nicht geeignet, um dauerhaft eine IT-Abteilung zu strukturieren, meint Straub: "Ich hatte bis September letzten Jahres auch noch eine bimodale Welt im Kopf - aber dann war das Konzept für mich nicht mehr nachvollziehbar."

Kein Mitarbeiter mag zu den Langsamen gehören

Hauptkritik: Kein Mitarbeiter mag zu den Langsamen gehören. "Und wie wollen Sie entscheiden, wer auf den schnellen Zug aufspringen darf und wer auf den langsamen?", fragt Straub. Technologisch sei diese Frage kaum zu beantworten, regional auch nicht. Es gebe einfach keine Technik und keine Region, die sich eindeutig den Kategorien "schnell" oder "langsam" zuordnen ließe.

Wer tatsächlich Geschwindigkeit als Unterscheidungskriterium einführt, müsste also eine Organi­sationsmatrix aufbauen, die Mitarbeiter nicht nur fachlich und disziplinarisch zuordnet, sondern auch noch nach schnell oder langsam. Das wäre eine dreidimensionale Matrix. "Die versteht dann keiner mehr", gibt Straub zu bedenken.

Alles wird jetzt agil

Deshalb gilt ab jetzt bei BMWBMW das Motto "100 % agileagile". Im November 2016 hatte sich die IT-Führung zu diesem radikalen Schritt entschieden. Im Mai hat sich Straub das Konzept im Vorstand absegnen lassen - wichtig, weil die Fachbereichsseite natürlich auch ihre Arbeitsweise ändern muss. Und seit dem 1. Juni werden alle Projekte sukzessive auf agil umgestellt. "Das wird ein Weg der Veränderung für drei Jahre", prophezeit Straub. Ende 2019 sollen dann wirklich alle rund 300 laufenden IT-Projekte bei BMW agil sein. "Projekte, die jetzt schon anderthalb Jahre nach der Wasserfallmethode laufen und noch einmal so lange bis zu ihrem Abschluss brauchen, werden wir natürlich nicht mehr umändern." Top-500-Firmenprofil für BMW Alles zu Agile auf CIO.de

Die 5 größten Mythen der agilen Methodik

Um für mehr Akzeptanz zu sorgen, hat Straub lustig illustrierte Postkarten drucken lassen, auf denen mit den fünf größten Mythen der agilen Methodik aufgeräumt wird:

1. Agile Entwicklung ist Chaos und Anarchie

Stimmt nicht: Auch im Agilen werden ComplianceCompliance, DatenschutzDatenschutz, SecuritySecurity, Architektur und Betriebsreife eingehalten. Eigenverantwortliche und interdisziplinäre Produktteams stellen dies sicher. Alles zu Compliance auf CIO.de Alles zu Datenschutz auf CIO.de Alles zu Security auf CIO.de

2. Agil ist Arbeiten ohne Plan und Ziel

Stimmt nicht: Die inhaltliche Planung erfolgt über die im Backlog durch den Product Owner priorisierten User-Stories. Machbarkeit und Umsetzungsaufwand werden durch das Entwicklungsteam geschätzt. Die Planung wird in den Sprint-Planning-Meetings regelmäßig aktualisiert, die Zielerreichung in den Sprint-Review-Meetings regelmäßig überwacht.

3. Agile Fehlerkultur und Qualitätsanspruch passen nicht zusammen

Stimmt nicht: Agil bedeutet nicht nur schnell. Das Testen ist fest in der Softwareentwicklung integriert. Fehler werden früh identifiziert. Formalisiertes Lernen aus Fehlern ist Teil der agilen Kultur und garantiert höhere Qualität als traditionelle Entwicklung.

4. Agile Entwicklung braucht keine Dokumentation

Stimmt so nicht: Dokumentiert wird nur das Wesentliche, wie zum Beispiel:

• Explorationsphasen,

• Epics (Anforderungsbeschreibung auf abstraktem Niveau),

• User-Stories (feingranulare Anforderungsbeschreibung) und

• für Nutzung, Betrieb, Weiterentwicklung und gegebenenfalls Ausschreibungen wichtige Informationen.

5. Agil macht Manager überflüssig

Stimmt so nicht: Führungskräfte werden im agilen Kontext nicht überflüssig, aber ihre Rollen und Aufgaben ändern sich. Sie unterstützen ihre Mitarbeiter bei der persönlichen Weiterentwicklung. Sie sorgen für eine Kultur, in der die agilen Werte nachhaltig gelebt werden. Sie schaffen den Rahmen für eigenverantwortliches Arbeiten im Team.

Gerade die letzte Postkarte hat natürlich Sprengkraft. Stimmt das wirklich, dass Manager nur anders arbeiten? Und nicht überflüssig werden? Rund 2000 Mitarbeiter der BMW-Group-IT haben durch die agile Neuverteilung der Verantwortungen bereits neue Chefs bekommen. Straub beteuert, dass selbst eingefleischte Anhänger des Wasserfallmodells Spaß am agilen Arbeiten entwickeln. "Wenn jemand vorher für 150 Produkte verantwortlich war und jetzt nur noch 120 betreut, dann tut ihm das nicht weh - eher im Gegenteil", sagt der CIO. "Und in den Teams gibt es jede Menge Menschen, die sich freuen, wieder richtig IT zu machen."

Straub ist nicht der einzige, der bimodale IT für einen Irrweg hält. Auch in anderen Sektoren gibt es Beispiele für hundertprozentige Agilität. So hat auch der Holländer Ron van Kemenade, CIO des Bankhauses ING, seine IT radikal umgebaut - und ist dafür gerade "European CIO of the Year" geworden.

Die ING beschäftigt weltweit 52.000 Mitarbeiter, rund 10.000 davon arbeiten in der IT. Allein in Amsterdam sitzen knapp 3000 Entwickler, die ausnahmslos agil arbeiten. Mittlerweile hat sich ein kleiner Tourismus von ungläubig staunenden CIOs um das dortige Zentrum entwickelt, maßgeblich getrieben von Dorothée Appel, COO im IT-Bereich der Bank. Die ehemalige BMW-Mitarbeiterin lädt mit missionarischem Eifer CIOs ein, die einfach nicht glauben wollen, dass auch Banken-Kernsysteme agil betrieben werden können.

Mitarbeiter verloren

Ihr Chef van Kemenade hält - ähnlich wie Straub - nichts von der IT der zwei Geschwindigkeiten, weil sie zu einer Demoralisierung jener Mitarbeiter führe, die dann eben nicht zu den schnellen Truppen gehörten. Anders als Straub sagt van Kemenade allerdings, dass er sehr wohl mehrere hundert Mitarbeiter verloren habe, die den Schritt in die Agilität nicht mitgehen wollten.

Nicht alle Silberrücken fühlen sich wohl bei dem Gedanken, Verantwortlichkeiten an Scrum-Master und Produktteams abzugeben. Van Kemenade bedauert das, hält aber den Schwund an Mitarbeitern für leichter verkraftbar als den Spagat zwischen schneller und langsamer IT. Natürlich hat die ING auch Legacy-Systeme. Diese könnten aber auf ähnliche Weise gepflegt werden, wie man neue hippe Apps aufsetze, meint van Kemenade.

Betreiben ING und BMW Etikettenschwindel, wenn sie von 100 Prozent agil sprechen, gleichzeitig aber Systeme unterhalten, die höchstens jedes halbe Jahr ein Release erfahren? Auch die gute alte Wasserfallmethode ist ja nicht stehen geblieben. Auch in den 80er Jahren hatten wir bereits agile Elemente. "Ja, aber anders", meint Straub: "Inzwischen hatten wir ITILITIL, und alle Prozesse sind viel durchdachter." Erst jetzt könne man unter anderen Vorzeichen von agil sprechen und damit sogar auch dezentraler werden. Alles zu ITIL auf CIO.de

Fachbereiche müssen mitziehen

Perspektivisch sollen bald alle 4500 Mitarbeiter in der BMW-Group-IT agil arbeiten - auch solche, die in den Infrastrukturbereichen beheimatet sind und selbst nichts entwickeln. Es gehe dabei aber nicht darum, einen Incident-Prozess agil zu machen: "Da will ich genau einen haben und nicht 150 verschiedene", sagt Straub. Aber in der Zusammenarbeit mit den Entwicklern müssten natürlich auch die Infrastrukturbetreiber wissen, wie die neuen Methoden funktionieren.

Außerdem wünscht sich der CIO, dass der agile Funke auch auf die Fach­bereiche überspringt, die dann BizOps statt DevOps betreiben. Es gebe da schon Projekte in den Fachbereichen Logistik und Vertrieb, in denen Mitarbeiter aus Fachbereichen und IT gemeinsam ganz weit vorne liegen. "Wir sind überhaupt die ersten, die agil im industriellen Bereich so weit denken", meint Straub.