Beliebte Suchanfragen

Cloud Native

DevOps

IT-Security

Agile Methoden

Java

//

Agile Skaliert – Teil 2

8.2.2014 | 6 Minuten Lesezeit

Im ersten Teil der Blogserie habe ich die Ideen von Ken Schwaber zu skalierten agilen Vorgehen dargestellt. In diesem Teil sehen wir uns nun das derzeit recht populäre Scaled Agile Framework (SAFe™) an.

Auf den ersten Blick fällt auf, dass bei diesem Framework die Produktentwicklung (bzw. das Projekt) in drei Ebenen aufgeteilt wird.

  • Portfolio
  • Program
  • Team

Portfolio Ebene

Auf dieser Ebene werden von einem sog. „Program Portfolio Management“ anhand der Unternehmensstrategie die Programme abgeleitet und verabschiedet. Hier entstehen die Epics, und zwar zwei Arten davon: die Business Epics und die Architectural Epics. Die Business Epics sind von der zeitlichen Dimension her so beschaffen, dass mehrere Releases benötigt werden um diese umzusetzen. Dies können mehrere Monate bis zu Jahren sein! Für die Erzeugung dieser Business Epics sieht SAFe ein Kanban System vor, um die notwendigen Schritte zur Analyse und Genehmigung bzw. Ablehnung der Epics durchzuführen.

Funnel: Dies ist der Ideenpool der Organisation. Hier können alle Ideen für die weitere Entwicklung des Produktes / des Unternehmens platziert werden. Da jede Idee willkommen ist, gibt in dieser Stufe keinen Beschränkung hinsichtlich Anzahl. (Kein Limit des Work in Progress.)

Backlog: Um den Grund und den Wertbeitrag des Epics darzulegen, wird ein „Value Statement“ formuliert. In dieser Bearbeitungsstufe wird das Epic auch grob geschätzt. Außerdem wird ein „Epic Owner“ festgelegt, der die weitere Bearbeitung des Epics begleitet.

Analysis: In dieser Bearbeitungsstufe werden Workshops durchgeführt, um aus Sicht der Fachbereiche und des Managements die wirtschaftliche Betrachtung und die Erfolgskriterien durchzuführen und festzulegen. Um den Implementierungsaufwand und Auswirkungen auf bestehende Systeme abzuschätzen, werden sog. „System Architects and Agile Team Leads“ heran gezogen. Am Ende dieses Bearbeitungsschrittes steht die Go/No-Go-Entscheidung.

Implementation: Das Epic wird nun in das Portfolio Backlog eingetragen und wartet dort, bis die Implementierung starten kann. Der Epic Owner muss gemeinsam mit Product Managern und System Architects das Epic kleiner schneiden: in Sub-Epics und Features. Diese Ergebnisse werden dann für die weitere Bearbeitung auf die individuellen Program Backlogs verteilt.

Program Ebene

Während der Planungshorizont der Portfolio Ebene mehrere Monate umfassen kann, arbeitet die Program Ebene mit Zyklen von ca. 8-10 Wochen. Der Fokus liegt hier auf dem Feedback der Kunden und der Fachbereiche. Die entwickelten Softwareartefakte werden dabei mit Hilfe des „Release Train“-Prinzips (http://scalingsoftwareagilityblog.com/wp-content/uploads/2009/03/whitepaper_systems-of-systems-and-the-agile-release-train2.pdf) ausgeliefert. Der Release Train fast die Ergebnisse von 5-15 Entwicklungsteams zusammen. Auf dieser Ebene des SAFe ist ein „System Team“ für den Zusammenbau der gelieferten Softwareartefakte und ggf. End-To-End-Tests verantwortlich. Unterstützt wird dieses Team bei Bedarf von einem „Release Management Team“. Die Produktsicht, d.h. die letztendliche Entscheidung welche Features geliefert werden, wird von einem „Product Management“ vertreten.

Team Ebene

Die vollständige Umsetzung der Anforderungen aus den jeweiligen Team Backlogs liegt in der Verantwortung der „Agile Teams“. Mit Hilfe von Scrum und XP arbeiten alle Teams selbstverantwortlich an der Umsetzung ihrer Backlog Items – natürlich mit Blick auf das gemeinsame Ziel auf Program Ebene. Wie im Konzept des Release Train beinhaltet schlägt SAFe zusätzlich zu den reinen Entwicklungsiterationen spezielle HIP-Iterationen vor (Hardening, Innovation, Planning) die auch als Planungspuffer dienen können. Ansonsten werden die meisten Praktiken von Scrum übernommen:

  • Rollen: Scrum Master, Product Owner, Developers und Tester
  • Meetings: Daily Standup, Planning, Team Demo (Review), Retrospective (auf Ebene der einzelnen Teams)
  • Metriken: Burndown-Charts, relatives Schätzen mit normalisierten (!) Story Points

Zusammenfassung

Das SAFe beinhaltet auf der Teamebene viele Elemente von Scrum die mit weiteren Konzepten, z.B. dem „Agile Release Train“ ergänzt werden. Um die Komplexität großer Organisationen in den Griff zu bekommen wird eine hierarchische Struktur mit zwei weiteren Ebenen (Program, Portfolio) eingeführt. Für die Softwareentwicklung wird zwar Scrum vorgeschlagen, dabei sind aber wichtige Zuständigkeiten wie UX, Architektur, Delivery aus den Scrum Teams extrahiert und an dedizierte Rollen abgegeben.

Bewertung

Für eine Einschätzung des SAFe schauen wir uns einmal die Wertepaare des agilen Manifests an:

Individuals and interactions over processes and tools

Damit eine Idee für eine neue Funktionalität den Weg in den Programcode findet, müssen einige Stationen passiert werden: Über die Portfolio Vision mit dem Epic Owner durch das Program Portfolio Management in die Roadmap und das Program Backlog. Dann folgt das Product Management und Release Management welches das Program Backlog in die Team Backlogs überführt. Dabei bringen sich dann noch Business Owner, UX-Experten, Architekten und der Release Train Engineer mit ein. Im Anschluss kümmert sich dann der Product Owner über die korrekte Umsetzung des ihm übertragenen Team Backlogs.

Bei diesen Entscheidungswegen werden die Scrum Teams nur noch als Werkbank zur Umsetzung der von den diversen Management Teams beschlossenen Ideen verwendet. Eine gemeinsame und übergreifende Zusammenarbeit zur Findung neuer Ideen und Weiterentwicklung des Produktes kann m.E. bei diesem Setup nur schwer stattfinden. Abteilungsübergreifende Rückkopplungsschleifen, sei es nun zu dem Produkt oder dem Prozess konnte ich im SAFe nicht finden. Doch gerade die Möglichkeit der ständigen Anpassung an neue Gegebenheiten ist ja eines der wichtigsten Aspekte bei agilen Vorgehensweisen bzw. Scrum.

Working software over comprehensive documentation

Bei dieser starken Trennung der Zuständigkeiten (Architektur, UX, Deployment) besteht die große Gefahr, dass die Teams wieder in alte Verhaltensmuster von phasenorientierten Vorgehensweisen zurückfallen und nur noch die genau zugewiesenen Aufgaben ausführen, ohne nach links oder rechts zu schauen. Ich sehe hier schon ausführliche UI-Dokumentationen oder riesige bunte Architekturbilder vor meinem geistigen Auge…

Customer collaboration over contract negotiation

Die Einbindung des wichtigsten Personenkreises -den Kunden- findet durch das Product Management, den Business Ownern und den Product Ownern statt. Wie mit dieser Konstellation eine enge Zusammenarbeit mit den Kunden möglich ist, erschließt sich mir nicht. Für mich besteht hier eher die Gefahr, dass Kundeninteressen auf der Strecke bleiben da hier klare Zuständigkeiten nicht zu erkennen sind.

Responding to change over following a plan

Die vielen zuständigen Teams (Program Portfolio Management, Product Management, Release Management, Architect, UX-Experte, Product Owner) bedingen natürlich entsprechende Entscheidungswege und Planungen. Nehmen wir einmal an, in einem Sprint Review hat ein Entwickler eine Idee für ein neues Feature. Es wird einige Zeit dauern, bis diese Idee dann durch alle Gremien gewandert ist und Berücksichtigung in der Portfolio Vision, der Roadmap, dem Program Backlog, den Team Backlogs und letztendlich in der Entwicklung findet.Bis dahin wird natürlich der ursprüngliche Plan weiter verfolgt, d.h. eine schnelle Reaktion auf geänderte Marktanforderungen ist nicht möglich.

Das SAFe bietet auf den ersten Blick ein vollständiges Bild über die Durchführung agiler Softwareentwicklung in großen Organisationen mit einer großen Anzahl von definierten Rollen und klaren Zuweisungen der jeweiligen Aufgabenbereiche. Diese detaillierte Darstellung macht die Transition zu „Agile“ natürlich auf den ersten Blick leichter; man muss ja nur diesen genauen Vorgaben von SAFe folgen.

Doch meines Erachtens liegt genau hier die Gefahr bei der Anwendung von SAFe. Gerade dadurch dass das Vorgehen mit allen Rollen und Zuständigkeiten bereits feststeht und ausführlich beschrieben ist, wird dem Unterbleiben der notwendigen Inspektion und Adaption auf die speziellen Bedürfnisse der Organisation Vorschub geleistet. Doch gerade dieses ständige Reflektieren und Anpassen / Verbessern der täglichen Arbeit, der Prozesse und damit der gesamten Organisation ist das Herz von agilem Vorgehen.

Die großen Vorteile agiler Vorgehensweisen zum Beispiel die intensivere Einbindung aller Beteiligten, die schnelle Reaktion auf Änderungen, die Zufriedenheit der Kunden und auch der größere Spaß bei der gemeinsamen (!) Arbeit um nur ein paar zu nennen gehen meines Erachtens bei der Anwendung von SAFe verloren oder können zumindest nicht die volle Wirkung entfalten.

Anregungen, Erfahrungen, Hinweise? Kommentare willkommen.

Dies war Teil zwei der Serie „Skalieren von agilen Vorgehen“ mit dem Scaled Agile Framework von Dean Leffingwell. Im dritten Teil sehen wir uns die Ideen von Craig Larman und Bas Vodde an.

Beitrag teilen

Gefällt mir

0

//

Gemeinsam bessere Projekte umsetzen.

Wir helfen deinem Unternehmen.

Du stehst vor einer großen IT-Herausforderung? Wir sorgen für eine maßgeschneiderte Unterstützung. Informiere dich jetzt.

Hilf uns, noch besser zu werden.

Wir sind immer auf der Suche nach neuen Talenten. Auch für dich ist die passende Stelle dabei.