Gerade in Zeiten des stetigen Wandels erkennen viele Unternehmen den Bedarf, ihre IT-Entwicklung agiler zu machen und auf kontinuierlichen Wandel auszurichten. Ziel dabei ist es, schnell und flexibel auf ändernde Kundenanforderungen zu reagieren.
Die Kernideen des "klassischen" agilen Entwicklungsansatzes schaffen bei einer solchen Ausgangslage im kleineren Rahmen normalerweise Abhilfe, jedoch passt es oftmals nicht zu den Gegebenheiten wie sie in Großkonzernen vorzufinden sind: Wie bewahrt man die agilen Prinzipien bei gleichzeitig vorhandenen starren Organisationsstrukturen und Hierarchien eines Großunternehmens? Wie richtet man die Softwareentwicklungsmethodik auf Veränderung aus, wenn Budget und Ziele auf Monate oder sogar Jahre hinaus geplant werden? Wie setzt man die auf kleinen, lokalen Teams basierenden agilen Prinzipien um, wenn das Unternehmen verteilte Arbeit in Großprojekten unter Einbeziehung von Near- oder Offshore-Standorten vorgibt?
Zur Beantwortung dieser Fragen bedarf es einer durchdachten Methodik und einem Framework, das auf die individuellen Herausforderungen des Unternehmens wie seine Kultur, Systemlandschaften, Erfahrungen oder Release-Zyklen angepasst wird.
Skalierung durch Größe, Lokation und organisatorische Verteilung
Pauschalisiert gibt es im Umfeld der vorhandenen Entwicklungsmethodiken wie Wasserfall, iterativ, inkrementell, Scrum oder Extreme Programming keine, die besser oder schlechter ist. Vielmehr kommt es auf die konkreten Anforderungen und Charakteristika des Unternehmens und der Anwendungslandschaft an, welche Methodik die zielführendste ist. Agile Methoden haben ihre Stärken insbesondere in Bereichen, in denen eine enge Abstimmung von IT- und Fachabteilung notwendig ist, flexibel auf Änderungen reagiert werden soll und Anforderungen nicht im Vorfeld fixiert werden können, sondern schrittweise erarbeitet werden müssen. Zu den Prinzipien von agiler Entwicklung gehören kleine und lokale Teams, enge Kooperation und viel Entscheidungsfreiheit. Diese sind aber auf den ersten Blick nicht mit den Anforderungen der Unternehmen in Einklang zu bringen wie Kosteneinsparungen, zum Beispiel durch verteilte Entwicklung, Teams mit 50 oder mehr Mitarbeitern sowie Organisationsstrukturen mit starken Abhängigkeit zu umliegenden Systemen oder Budgetvergaberichtlinien.
Bestehende Frameworks an die Gegebenheiten anpassen und erweitern
Abhilfe schafft hier die Anwendung einer Methodik für große und verteilte agile Projekte, die auf der Grundlage eines etablierten Frameworks wie etwa SAFe beruhen kann, aber immer auf die konkreten Charakteristika des Unternehmens und der Systemlandschaft angepasst werden muss. Durch zahlreiche Projekte in diesem Umfeld haben sich hierbei nachfolgend beschriebene Best Practices herauskristallisiert:
1. Team Setup: Die herkömmlichen Rollen eines agilen Teams müssen bei großen und verteilten Organisationen in die bestehende Governance eingebettet werden. Sinnvoll ist hier die Funktion eines Projektleiters für die Koordination, aber auch als Eskalationsinstanz über mehrere Teams hinweg. Für das Setup der verteilten Scrum-Teams sind verschiedene Konstellationen möglich. Bewährt hat sich hierbei, dass das Team über die Lokationen hinweg als ein Team aufgestellt ist, was das Zusammengehörigkeitsgefühl stärkt und die Entstehung eines "Wir" und "Die anderen" Gefühls verhindert. Man liefert immer gemeinsam. Oft ergibt es auch keinen Sinn, dass der Product Owner aus der Fachabteilung kommt (wie im "klassischen" Ansatz vorgesehen). Stattdessen bietet sich das Konzept eines "Product Owner Proxy" zum Beispiel in Form eines erfahrenen Business Analysts an, der die Interessengruppen orchestriert um Informationen zu sammeln, aufzubereiten, zu bündeln und dann ans Team weiter zu geben.
2. Kommunikationsmodelle: Es empfiehlt sich, explizite und allgemeinverbindliche Kommunikationspläne zu definieren. Dies ist essentiell um ein effektives, virtuelles Zusammenarbeiten in einem agilen Setup zu ermöglichen. Dies erfordert abgestimmte Zyklen und detaillierte Pläne, welche Meetings es gibt, wer die Teilnehmer sind, und mit welchen Kommunikationsmedien (etwa Messenger, WebMeeting, VideoCall) diese durchgeführt werden. Nur durch einen expliziten Kommunikationsplan - und seine stringente Umsetzung - kann trotz verteilter Lokationen ein effektives Zusammenarbeiten gemäß agiler Prinzipien gewährleistet werden.
3. Gesamtplanung: In Organisationen mit vielen agilen Teams ist ein einzelnes Team nur bis zu einem gewissen Grad selbstbestimmt und frei in seinen Entscheidungen. Oft sind strategische Rahmenbedingungen und Ziele durch Roadmaps und Meilensteine vorgegeben. Dies umfasst sowohl externe Abhängigkeiten, zum Beispiel zu nicht agilen Projekten oder externen Zulieferungen, als auch vorgegebene Budgets und Liefervereinbarungen mit den Endabnehmern. Oft hilft daher eine "klassische" Release-Planung aus der dann die agilen Arbeitspakete abgeleitet werden.
4. Übergreifende Funktionen: Es hat sich ebenfalls bewährt, nicht alle Disziplinen in jedem einzelnen Team unabhängig ausarbeiten zu lassen. Übergreifende Aspekte sollten in zentralen Teams mit und für die einzelnen agilen Teams konsolidiert werden. Beispiele hierfür sind
ein "Architektur-Büro" um zentrale Vorgaben bezüglich Laufzeitarchitektur, Programmierrichtlinien, Entwicklungsvorgaben und Handbücher zu definieren,
Infrastruktur Management zur Vereinheitlichung der Entwicklungs- und Testinfrastruktur,
als auch ein übergreifendes Release- und Konfigurationsmanagement.
Diese zentralen Teams stellen ein einheitliches und optimiertes Arbeiten sowie eine langfristige, effiziente Wartbarkeit sicher.
5. Auslieferbare Software: Die Planung von Produktionseinführungen sollte losgelöst von den einzelnen Sprint-Lieferungen der einzelnen Scrum-Teams betrachtet werden. Oft gibt es zahlreiche Abhängigkeiten zu Lieferungen umliegender Systeme. Es muss somit auch hier eine Verbindung der agilen Prinzipien, also häufige Lieferung in kurzen Sprints, mit den Anforderungen in Großunternehmen wie der klassischen Release-Planung stattfinden. Dies erfordert dann in der Regel auch einen klassischen Integrations- und Akzeptanztest vor einer Produktionseinführung, in dem die in verschiedenen Teams entwickelten Module zusammen getestet werden.
Man muss das Rad nicht neu erfinden...
Das "agile Rad" muss also auch für große und verteilte Projekte in Großunternehmen nicht neu erfunden werden, sondern sollte auf vorhandener und bewährter Methodik aufsetzen. Wichtig ist hier aber eine Anpassung auf die Charakteristika des Unternehmens und der Systemlandschaft, um das Rad eventuell größer, farbiger und vielleicht breiter auszustatten, damit es sich am Ende dann auch so dreht, wie man es sich vorgestellt hat… oder sogar ein bisschen schneller…