In dem hier beschriebenen – vollständig anonymisierten – Fall geht es um die vom Topmanagement verordnete agile Transformation der IT-Organisation eines großen Telekommunikationsunternehmens. In der IT sind dort rund 2.500 Mitarbeiter beschäftigt, die zum größten Teil in Pools organisiert waren. Neu- und Weiterentwicklung der betrieblichen Software lief in Form von einzelnen Projekten ab; für besonders umfangreiche Vorhaben wurden Programme aufgesetzt. Es gab einen Pool mit mehr als 30 Projektleitern jeder Seniorität, die budgetverantwortlich ihre temporären Teams leiteten.

Im Folgenden schildere ich als Mitglied dieses Projektleiter-Pools meine persönlichen Erfahrungen mit der unternehmensweiten Reorganisation von der poolorientierten Organisation (oftmals auch als "alte Welt" bezeichnet) hin zu der moderneren "agilen Welt". Konkret ging es um die Transformation der Poolorganisation in eine agile, an Business-Produkten orientierte Organisation, die mit dem Schlagwort "DevOps" bezeichnet wird. Zunächst gebe ich einen Überblick über die Eckdaten dieses Transformationsprozesses, um Ihnen Orientierung und die erforderlichen Informationen für die folgenden Situationsbeschreibungen zu geben.

Anschließend beschreibe ich einzelne Situationen, die sich aus meiner Sicht nachteilig auf den Transformationsprozess, das Unternehmen und vor allem die betroffenen Personen auswirkten. Daraus leite ich jeweils Lessons Learned ab und versuche, Handlungsempfehlungen zu geben, mit denen sich diese negativen Auswirkungen aus meiner Sicht vermeiden oder zumindest abmildern hätten lassen.

Die "alte Welt"

Große und z.T. auch größere mittelständische Unternehmen mit eigener IT-Abteilung, evtl. mit eigener Software-Entwicklung, benötigen eine Projektorganisation für ihre IT-Vorhaben. Weit verbreitet ist hierbei die sogenannte Poolorganisation: Projekte, vor allem Entwicklungsprojekte, werden mit Projektleitern aus Pools besetzt. Ebenso werden Business-Analysten, Entwickler oder Tester in Pools organisiert und den Projekten zugewiesen. Ein Poolverantwortlicher kümmert sich um Kapazitäten und Fähigkeiten der Mitarbeiter, hat aber mit den Projekten oder dem Betrieb nur indirekt zu tun. Das bedeutet, dass für jedes neue Projekt die Teams neu zusammengestellt werden.

Der Betrieb von IT-Infrastruktur und Unternehmens-Software ist hingegen in Linien organisiert, entweder anhand der Technologien (Datenbanken, Betriebssysteme usw.) oder – seltener – anhand der Produkte des Fachbereichs (z.B. unterschiedliche Versicherungsprodukte oder Modellreihen eines PKWs).

Typischerweise gibt es für die Projekte temporäre Organisationseinheiten in Form von Project Offices. Sowohl Namensgebung (z.B. auch Project Management Office oder Center of Excellence for Project Management) als auch die Konstruktion solcher Organisationseinheiten unterscheidet sich von Unternehmen zu Unternehmen erheblich. Manche Unternehmen steuern zusammenhängende Projekte auch in Programmen, um so höhere Effizienz zu erzielen (z.B. durch ein Programme Management Office anstatt mehrerer Project Offices, einheitliche Methodik und Berichterstattung) und die Abhängigkeiten der Projekte besser steuern zu können.

DevOps und Agile statt Pools und Project Offices

Diese projektorientierte Unternehmensorganisation wird zunehmend in Frage gestellt, da sie stark dem traditionellen Projektmanagement verhaftet ist. Mit dieser Struktur ist typischerweise das Wasserfallmodell verbunden, das oftmals als zu statisch und zu langsam angesehen wird: Time-to-Market und schnelle Anpassung an sich verändernde Anforderungen werden nicht mit dem Wasserfallmodell in Verbindung gebracht. Vor allem der Trend zur Agilität führt dazu, dass Unternehmen die Poolorganisation gänzlich aufgeben und alles in produktorientierten Linien organisieren. Die Linienmanager sind dann sowohl für den Betrieb als auch für die Neu- und Weiterentwicklung der Software und die Umsetzung der Fachbereichsanforderungen verantwortlich.

Die Unternehmensverantwortlichen erhoffen sich so, die Verbindung zwischen IT und Fachbereich zu stärken (weil Fachbereiche oftmals um Produkte herum organisiert sind) und die Time-to-Market von Fachbereichsanforderungen zu reduzieren. Für kleinere Änderungen wird eine Realisierungszeit von der Kundenanforderung bis zum Release von nur einigen Tagen angestrebt. In einem Extremfall (einem anderen Unternehmen) erlebte ich, dass neben dem Fachbereichsspezialisten ein Entwickler saß und die Wünsche direkt umsetzte.

Das Topmanagement verordnet die agile Transformation

Im hier vorgestellten Fall war das Ziel, den Betrieb und die Entwicklung zusammenzulegen sowie die Pools aufzulösen. Für jedes Produkt bzw. für jede Produktlinie (z.B. Festnetz, Internetanschluss, Mobilfunk usw.) sollte ein eigenes Profitcenter entstehen und eine eigene Gewinn-und Verlustrechnung aufgestellt werden. Insgesamt entstanden so rund 20 unterschiedlich große Profitcenter, die jeweils eine eigene IT-Abteilung erhielten. Zentrale Funktionen wie Project Office, Design und Architektur sollten hingegen wegfallen. Dafür sollten Produktmanagement und IT gemeinsam die Verantwortung tragen und auch gemeinsam an der Performance ihres Profitcenters gemessen werden.

Damit sollte sichergestellt werden, dass nur das entwickelt wird, was der Endkunde auch tatsächlich braucht und zu bezahlen bereit ist. Das Produktmanagement sollte diese Anforderungen an die IT geben, damit diese die Produkte entsprechend entwickelt. Indem Produktmanagement und IT in die gemeinsame Verantwortung für den Geschäftserfolg gestellt wurden, sollte ein starker Anreiz dafür geschaffen werden, sehr schnell kundenorientierte Produkte auf den Markt zu bringen.