IT-Großsystem aus einem Guss

Hinter Scrum verbirgt sich ein Vorgehensmodell für agiles Projektmanagement, das eine effektive Systemerstellung ermöglichen soll. Eine Voraussetzung dafür sind eigenverantwortliche Expertenteams mit großem Gestaltungsspielraum. Im Idealfall entsteht so die gewünschte IT-Architektur dynamisch und flexibel während der Umsetzung. Das Problem: In umfangreichen Vorhaben mit vielen Scrum-Teams kann eine zu große technische Vielfalt entstehen. Die Folge sind nachhaltige Auswirkungen auf Rekrutierung, Flexibilität in der Teamzusammensetzung und Komplexität des Gesamtsystems. In der Gesamtbetrachtung von Kosten, Umsetzungsgeschwindigkeit und Qualität ergeben sich dann mehr Nach- als Vorteile.

Doch wie können diese Nachteile verhindert werden, ohne die Scrum-Vorteile zunichtezumachen? Die Erfahrungen aus dem Aufbau einer agilen IT-Entwicklungsorganisation für ein digitales Kommunikationsprodukt zeigen, wie es gehen kann: Ziel war die Produktentwicklung auf Basis einer Scrum-Organisation: selbstmotivierte Entwickler, kurze Umsetzungszeiten sowie Änderungszyklen. Doch bei den zwölf eigenverantwortlichen und unabhängigen Scrum-Teams, die gleichzeitig auf dasselbe Release einliefern, entstand hohe Dynamik: alle zwei Wochen Änderungen und neue Komponenten durch alle Teams bis in die Produktion. Es wurde unübersichtlich: Jedes Team setzte eigene Technologien und Tools ein, es entstanden verschiedene Architekturen für Webclient und Server sowie eine uneinheitliche Konfiguration und Systemdokumenta­tion. Dies führte zu einem Einarbeitungsaufwand für die Entwickler und Administratoren bei Teamwechseln, in der Integration sowie bei Fehleranalysen.

Die Schwächen erkennen

Das Problem wurde nicht sofort erkannt, denn in ­Scrum implementieren Teams eigenständig und mit möglichst wenigen Abhängigkeiten ihre „User Stories“ im jeweils aktuellen Projektschritt, auch „Sprint“ genannt. Dadurch entstehen kurze Korrekturschleifen und die Menge des Entwicklungsaufkommens kann gering gehalten werden. Rahmenbedingungen und Vorgaben müssen zur Sprint-Planung explizit und vollständig definiert vorliegen. Trotz einer umfangreichen Vorgabe für die Systemarchitektur war jedoch nicht alles eindeutig definiert. Sonderfälle und Ausnahmen ermöglichten den Teams eigene „Interpretationen“ der Vorgaben. Diese Abweichungen wurden teamintern mit dem vorhandenen Wissen, den vorherrschenden Meinungen und im Kontext des aktuellen Sprints entschieden.

Für die fachlichen Anforderungen sieht    Scrum eine Rolle vor: Die fachlichen Klärungen erfolgen mit dem sogenannten „Product Owner“ operativ und während des Sprints. Eine vergleichbare Rolle für die Architektur kennt Scrum nicht. Eine Architekturfunk­tion außerhalb der Teams kann fehlerhafte Design- oder kostspielige Technologieentscheidungen frühestens im Sprint-Rückblick wahrnehmen – oder gar nicht. Dann ist es allerdings zu spät für Korrekturen, denn einmal bereitgestellte Systeme werden kaum wieder abgerissen und ersetzt. Mit ungesteuerten lokalen technischen Entscheidungen entsteht ein neues, modernes Legacy-System: Die Kosten für Betrieb, Wartung und Weiterentwicklung explodieren und die IT-Organisation wird abhängig von dem Wissen und der Kompetenz einzelner Leistungsträger. Um diese Schwächen zu vermeiden, müssen Architektur- und  Technologieentscheidungen mit einer gesamtheitlichen Betrachtung gesteuert werden. In den bisherigen hierarchisch geprägten Vorgehensmodellen erfolgt die Steuerung der Umsetzung an definierten Übergabepunkten im Entwicklungsprozess, an denen die Architekturabteilung hoheitlich Konzepte und Entwürfe überprüft: Die Teams müssen die Abnahme aktiv einholen und Ergebnisse verpflichtend umsetzen. Doch diese Mechanismen können in Scrum nicht sinnvoll eingesetzt werden, wenn Effektivitätsvorteile gehoben werden sollen.

Klare Rahmenbedingungen

Die Steuerung von flexiblen Architekturen in großen Scrum-Vorhaben darf die Eigenverantwortung und Unabhängigkeit der Teams nicht aushöhlen, d.h. die Entscheidungen müssen durch die Teams und auf der Grundlage vorher bekannter Regeln, Rahmenbedingungen, Vorgaben und Ziele getroffen werden können. Dies wurde dadurch erreicht, dass wenige, aber harte Rahmenbedingungen für die Entwicklung durch die Teams klar formuliert werden. Für die übergreifende Steuerung wurde der „Architektur-Elfenbeinturm“ abgerissen und die Architekten wurden als Mitglieder in den Teams für Programmierung, Test und weitere Aufgaben positioniert. Die Architekten müssen technisch und kommunikativ so stark sein, dass sie als Meinungsführer im Team akzeptiert werden. So können sie die Interpretation und Einhaltung der Rahmenbedingungen im Team steuern. Überdies etablierte man ein Gremium, in dem die Teams durch die Architekten vertreten sind. Es kommt einem „Architecture-Scrum-of-Scrum“ gleich, jedoch mit einer klaren Führungs- und Entscheidungshoheit durch den Hauptarchitekten.

Rahmenbedingungen für Scrum-Vorhaben

•   Architekturgrundsätze, die jede Komponente in ihrem Verhalten und ihren Leistungen einhalten muss
•   Ein Zielbild mit der fachlichen und technischen Struktur des Gesamtsystems
•   Ein Warenkorb nur für die Technologien, die für das Zusammenspiel und die Ziele der Organisation kritisch sind – d.h. für Programmiersprachen, Installation, Test und ­Systemkonfiguration sowie Überwachung
•   Die Verantwortung der Scrum-Teams für nicht funktionale Anforderungen, Wartung und Betrieb

Quelle: Xenium AG

Bildquelle: Thinkstock/iStock