Scrum bietet viele Vorteile, aber falsch aufgesetzt können Kosten, Umsetzungsgeschwindigkeit und Qualität die Pluspunkte in ein Minus verwandeln. Beachtet man die Grundsätze aus dem Aufbau einer agilen IT-Entwicklungsorganisation für ein digitales Kommunikationsprodukt in der Informationslogistik, lassen sich die negativen Folgen vermeiden.
Scrum ist ein Vorgehensmodell für agiles Projektmanagement und ermöglicht eine hocheffektive Systemerstellung. Voraussetzung für die Effektivität sind eigenverantwortliche Experten-Teams mit großem Gestaltungsspielraum für die eingesetzten Technologien und Werkzeuge in Entwicklung, Integration, Test und Produktion. Im Idealfall entsteht die Architektur dynamisch und flexibel während der Umsetzung durch die Experten-Teams. Und hier genau liegt das Problem: In großen Vorhaben mit vielen Scrum-Teams kann eine große – manchmal zu große – technische Vielfalt entstehen mit nachhaltigen Auswirkungen auf die Rekrutierung, die Flexibilität in der Team-Zusammensetzung und die Komplexität des Gesamtsystems.
In der Gesamtbetrachtung von Kosten, Umsetzungsgeschwindigkeit und Qualität beim Endkunden ergeben sich dann durch den Einsatz von Scrum mehr Nachteile als Vorteile. Wie aber können diese Nachteile verhindert werden ohne die Vorteilen von Scrum zunichte zu machen? Die Grundsätze aus dem Aufbau einer agilen IT-Entwicklungsorganisation für ein digitales Kommunikationsprodukt in der Informationslogistik zeigen, wie es gehen kann.
Es war eine lange Diskussion mit dem Meinungsführer des Teams, ob Play mit Scala für eine neue Komponente eingesetzt werden kann. »Scala passt mit seinem Verarbeitungsmodell hervorragend«, »Das Pattern-Matching geht damit sehr effizient«, »… lernt sich praktisch von selbst… in zwei Wochen ist jeder Java-Entwickler produktiv«. Jedes Argument wurde in Frage gestellt, neue Argumente generiert. Zum Abschluss wurde das Argument gebracht, das die Ergebnis-offene Diskussion beendet: »… sonst kann das Team kein Commitment für die Story abgeben…«.
Was war passiert? Ziel für den Aufbau der agilen IT-Entwicklungsorganisation war, dass eine Scrum-Organisation entsteht: Kein Overhead, selbst-motivierte Entwickler, kurze Umsetzungszeiten und Änderungszyklen bis in Produktion. Ein Kernelement sind dabei eigenverantwortliche und unabhängige Scrum-Teams. Dies führt bei den mehr als zwölf Scrum-Teams, die gleichzeitig sprinten und auf dasselbe Release einliefern, zu einer sehr hohen Dynamik: Alle zwei Wochen Änderungen und neue Komponenten durch alle Teams bis in Produktion. Es wurde schnell unübersichtlich: Jedes Team setzte eigene Technologien und Tools ein, verschiedene Architekturen für Web-Client und Server entstanden sowie eine uneinheitliche Konfiguration und Systemdokumentation. Dies führte zu hohen Einarbeitungsaufwänden für die Entwickler und Administratoren bei Team-Wechseln, in der Integration und bei Fehleranalysen.
Warum entsteht das Problem überhaupt? Ein weiteres Merkmal unserer Entwicklungsorganisation ist, dass jedes Team als Feature-Team alle Änderungen an allen technischen Komponenten selbst ausführt. Dadurch entstehen keine Engpässe durch dedizierte Teams und die Komplexität durch Teamaufträge wird verhindert. Doch das bedeutet »shared code ownership« und dazu müssen alle Entwickler auf hohem Niveau mit den eingesetzten Programmiersprachen, Technologien und Tools umgehen können. Neue Technologien können daher nicht durch ein Team »lokal« eingeführt werden: Jede genutzte Technologie benötigt die Verbreitung des Know-hows in allen Teams und im Betrieb.
Abbildung 1: Der Unterschied zwischen einem klassischen Entwicklungsprozess und einem Scrum-Entwicklungsprozess ist deutlich.
So können die Scrum-Teams eigenständig und mit möglichst wenigen Abhängigkeiten ihre User-Stories im aktuellen Sprint implementieren. Dadurch entstehen kurze Feedback-Schleifen und die Menge des »work in progress (WIP)« kann klein gehalten werden. Rahmenbedingungen und Vorgaben für einen Sprint müssen zum Zeitpunkt des Commitments als explizit definierte Constraints vollständig vorliegen. Trotz einer umfangreichen Vorgabe für die Systemarchitektur war doch nicht alles oder nicht alles eindeutig definiert. Sonderfälle und Ausnahmen erforderten »Interpretationen« der Vorgaben. Diese lokalen Lösungen wurden Team-intern 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 Product Owner operativ und während des Sprints. Eine vergleichbare Rolle für die Architektur kennt Scrum nicht. Eine Architektur-Funktion außerhalb der Teams kann fehlerhafte Designentscheidungen oder kostspielige Technologie-Entscheidungen frühestens im Sprint-Review wahrnehmen – oder gar nicht. Dann ist es allerdings zu spät, denn einmal bereitgestellte Systeme werden nicht leicht wieder abgerissen und ersetzt. Mit ungesteuerten lokalen technischen Entscheidungen entsteht ein neues, modernes Legacy-System:
- Wartungs- und Weiterentwicklungskosten
Individuelle Technologie- und Werkzeugentscheidungen können Einschränkungen verursachen, die erst in der Weiterentwicklung und Wartung wahrgenommen werden. - Betriebskosten
Eine Vielfalt an eingesetzten Produkten und Werkzeugen erhöht die Komplexität bei der Installation, im Regelbetrieb und in der IT-Vorfallsbearbeitung – und mehr Komplexität bedeutet mehr Kosten. - Personalkosten
Für jede eingesetzte Technologie und für jedes Werkzeug müssen mehrere Mitarbeiter in der Organisation auf Expertenniveau arbeiten. Diese Mitarbeiter müssen speziell rekrutiert werden und möglichst lange gehalten werden.
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.
Was tun: zurück zu »comand and control«? In den bisher etablierten 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 Architekturfunktion erstellt umfangreiche und detaillierte Vorgaben.
- Im Entwicklungsprozess sind Quality-Gates definiert, an denen die Architekturfunktion hoheitlich Konzepte und Entwürfe überprüft.
- Die Teams müssen die Abnahme an den Quality-Gates aktiv einholen und Review-Ergebnisse verpflichtend umsetzen. Die Architekturfunktion überprüft die tatsächliche Umsetzung vor dem Golive.
Doch diese Mechanismen können nicht sinnvoll in Scrum eingesetzt werden, wenn die Vorteile für Effektivität und Effizienz gehoben werden sollen.
Abbildung 2: Die Steuerung der emergenten Architektur in großen Scrum-Vorhaben.
Emergente Architekturen müssen agil gesteuert werden. Die Steuerung von emergenten Architekturen in großen Scrum-Vorhaben darf die Eigenverantwortung und Unabhängigkeit der Teams nicht aushöhlen, das heißt die Entscheidungen müssen durch die Teams und auf der Grundlage vorher bekannter Regeln, Rahmenbedingungen, Vorgaben und Zielen getroffen werden können. Dies haben wir dadurch erreicht, dass wenige aber harte Rahmenbedingungen für die Entwicklung durch die Teams klar formuliert werden:
- Architekturgrundsätze, die jede Komponente in seinem Verhalten und seinen Leistungen einhalten muss.
- Ein Zielbild mit der fachlichen und technischen Struktur des Gesamtsystems.
- Eine kurze verbindliche Liste der Technologien, die für das Zusammenspiel und die Ziele der Organisation kritisch sind, also für Programmiersprachen, Installation, Test und Systemkonfiguration und Überwachung.
- Die Verantwortung der Scrum-Teams für nicht funktionale Anforderungen, Wartung und Betrieb.
Für die übergreifende Steuerung haben wir den »Architektur-Elfenbeinturm« abgerissen und die Architekten als Mitglieder in den Teams positioniert für Programmierung, Test und alles andere auch. Die Architekten müssen Senior Developer sein, die technisch und kommunikativ so stark sind, dass sie als Meinungsführer im Team akzeptiert werden. So können sie die Interpretation und Einhaltung der Rahmenbedingungen unmittelbar im Team steuern.
Darüber hinaus haben wir ein Architekturgremium etabliert, in dem die Teams durch die Architekten vertreten sind. Das Architektur-Board ist ähnlich einem Architecture-Scrum-of-Scrum, aber mit der klaren Führungs- und Entscheidungshoheit durch den Hauptarchitekten.
Welche Probleme werden damit wie gelöst? Durch die beschriebenen Lösungen haben wir eine Reihe der vorher aufgeführten Probleme vermieden oder abgeschwächt:
- Die Architektur ist Teil der Teams und die Vorgaben und Rahmenbedingungen werden über Teammitglieder transportiert. Meinungen und Entscheidungen entstehen im Team und sind über die Architekten transparent.
- Im Architektur-Board werden Erkenntnisse, neue Anforderungen und Entscheidungen für alle sichtbar und nachvollziehbar. Der Hauptarchitekt erhält einen vollständigen Überblick und kann nötige Änderungen an Vorgaben und Rahmenbedingungen einerseits und Teamentscheidungen andererseits frühzeitig beeinflussen.
- Die »Architektur« behindert die Teams nicht, sondern definiert Regeln und unterstützt bei den konkreten und aktuellen Bedürfnissen in den Teams.
- Die Teams werden in ihrer Verantwortung gestärkt und können ihre Entscheidungen so treffen, dass sie die langfristigen Ziele der Organisation unterstützen.
Fazit. Emergente Architekturen in großen Scrum-Organisationen können gesteuert werden. Dies erfordert eine grundsätzliche Veränderung im Selbstverständnis der Architektur-Abteilung sowie im Skill-Set und der Stellenbeschreibung der Architekten: nur das Nötigste vorgeben und Architekten als Teil der Teams. So kann die »richtige« Umsetzung direkt in der täglichen Arbeit der Experten-Teams gesteuert werden.
Thiemo Hörnke,
Chef-Berater Xenium AG,
München