Fokusthema: Agile Transformation

THINK BIG: SO SKALIEREN SIE MIT SAFE AGILITÄT IN IHRER ORGANISATION

Vom Start-up bis zum Großkonzern haben sich agile Vorgehensmodelle in der Software- und Produktentwicklung etabliert. Grund dafür ist, dass klassische Phasen- und Meilenstein-basierte Projektmanagement-Methoden für die Software- und Produktentwicklung an ihre Grenzen stoßen. Gerade Großkonzerne, die genauso wie Start-ups in deutlich kürzeren Zyklen Produkte auf den Markt bringen müssen, kämpfen mit aufwendigen und formalen Prozessen. Die notwendige Transformation ihrer (IT-) Organisation hin zu einem agilen System stellt für sie eine besondere Herausforderung dar.

Wie reagieren Unternehmen auf diese Herausforderung? Durch die Gründung von „Acceleratoren“, „Innovation Labs“, „Agilen Inseln“ oder „Garagen“, in denen hoch qualifizierte und motivierte Mitarbeiter unter hervorragenden Bedingungen agile Vorgehensweisen wie Design Thinking im Innovationsbereich und Scrum, Kanban oder andere iterative Ansätze in der Software- und Produktentwicklung anwenden können. Gilt es jedoch komplizierte Produkte oder Implementierungen durch Teams von oft mehreren hundert Entwicklern, Designern, Testern oder UX-Fachleuten zu implementieren, kommen große, traditionell aufgestellte Organisationen mit auf kleine Teams ausgerichteten Implementierungsansätzen nicht mehr weiter. Daher suchen viele Unternehmen inzwischen nach Ansätzen und Frameworks zur Skalierung der auf Teamebene gut funktionierenden Methoden. Agiles Denken und Handeln – dezentrale, schnelle Entscheidungen, kontinuierliches Kundenfeedback, unkomplizierte Governance – sind das Fundament dieser Ansätze. Sie stehen dem klassischen Managementbild jedoch diametral gegenüber, weshalb Unternehmen immer wieder daran scheitern. Sie versuchen bei komplexeren Vorhaben vermeintliche Sicherheit durch aufwändige Kontrollmechanismen und Vorgaben herzustellen.

Die wichtigsten agilen Skalierungsansätze im Überblick

Das Angebot an agilen Skalierungsansätzen für Unternehmen besteht aus wenigen etablierten Modellen. Die wichtigsten agilen Frameworks am Markt sind:

  • Scaled Agile Framework (SAFe) für die agile Skalierung umfassender Organisationsformen
  • „Enterprise Scrum“ von der Scrum Alliance – Organisationsweite Scrum-Vorgehensweisen
  • Nexus von Scrum.org für bis zu neun Scrum-Teams, die sich zu einem solchen Nexus und einem Team aus Product Ownern und anderen Integrationsrollen formen
  • Large Scale Scrum (LeSS) für die Koordination von mehreren Scrum-Teams

Agile Skalierungsansätze richtig nutzen

Die Auswahl eines passenden agilen Skalierungsansatzes ist das eine, der adäquate Einsatz und eine angemessene Nutzung das andere. Aus Sicht von Q_PERIOR kann man die agile Software- und Produktentwicklung mit bis zu drei Scrum-Teams mit einer zweiteiligen Sprintplanung sehr gut abbilden. Der Ablauf sieht dann wie folgt aus:

  • Sprint Planning 1: Team-übergreifend
  • Sprint Planning 2: je Team kombiniert mit Scrum of Scrums analog zu LeSS. Auch Nexus setzt auf diese zweiteilige Sprintplanung.

Bei mehr als drei Teams bildet das Scaled Agile Framework (SAFe) das ganzheitlichste Organisationsmodell für Scrum-Teams ab. Dies geht aus dem SAFe Aufbau hervor, der die Teamebene durch eine koordinierende und synchronisierende Programmebene „umklammert“. Alle Rollen aus den Scrum-Teams sowie die Planungs-, Feedback- und Review-Prinzipien werden auf diese nächst höhere Gesamtprodukt-Ebene skaliert.

Abbildung 1: Scaled Agile Framework 4.5 by Scaled Agile Inc.

Hier gelangen Sie zu Abbildung 1

Die Programmebene installiert folgende Rollen: „Chief Scrum Master“, „Chief Product Owner“, Systemarchitekten, permanente fachliche Anforderer, Feedbackgeber und Entscheider. Diese Programmebene arbeitet dann analog zu den Teams mit einem Gesamtprodukt-Backlog. Sie schätzt und priorisiert – auf Programmebene Features statt User Stories – und entwickelt kontinuierlich die Produkt-Roadmap. Die Skalierung von Sprints erfolgt, indem SAFe, im Unterschied zu anderen Frameworks, eine gemeinsame Planung aller Teams in einer agilen Programmorganisation (Agile Release Train genannt) vorsieht. Die gemeinsame Planung erfolgt nach jeweils fünf Sprints (ca. 10-12 Wochen). Dieser Planungshorizont lässt sich in großen Organisationen häufig sehr gut abbilden und auf der nächst höheren Portfolio-Ebene mit quartalsweiser Portfolio-Priorisierung harmonisieren.

Die Skalierungsoptionen agiler Vorgehensweisen haben auch Grenzen

Die mithilfe von SAFe geschaffene agile Organisation bedeutet für die einzelnen Scrum-Teams eine gewisse Einschränkung an Kreativität und Umsetzung in Bezug auf Technologien, Architektur und Entwicklung. Dieser oft als größter Kritikpunkt angebrachte Aspekt ist aber nicht wegzudiskutieren. Jedoch ist dies im Kern genau der erforderliche Grad an Governance und Abstimmung, den große Produktentwicklungsorganisationen benötigen. Es kommt eben genau darauf an, Entscheidungen und Arbeitsorganisation ganz den agilen Werten und Prinzipien entsprechend zu leben und diesen „Agile Release Train“ als agiles Team bestehend aus mehreren kleinen agilen Teams zu verstehen und zu etablieren. Schematisch dargestellt kann eine an SAFe orientierte agile Organisation somit die Klammer um Scrum-Teams bilden und genau die Lücken schließen, die der Scrum-Guide offenlässt und für die Unternehmen oftmals versuchen „selbstgestrickte“ Lösungen zu finden.

Abbildung 2: Generische Q_PERIOR Variante einer SAFe Adaption bei Kunden

Gemeinsame Planung aller Teams, keine intransparenten Entscheidungen und schnelles Feedback bis an die Spitze der Organisation sorgen für möglichst kurze Entwicklungszyklen auch bei komplexen Produkten oder Systemimplementierungen. Sie verhindert veraltete Anforderungen in Spezifikationen aus langen Vorstudien und „versteckte Annahmen“, die im klassischem Management oft zu spät aufgedeckt werden. Ein wesentliches, individuelles Merkmal von SAFe ist die Beschreibung von Wertströmen (Value Streams), die auf der Portfolioebene budgetiert werden. Die agile Organisation wird über Fachbereichsgrenzen und bestehende organisatorische Silos hinweg gebildet, um den gesamten Wertschöpfungsprozess organisatorisch zusammenzuführen. Dies stellt einen starken Paradigmenwechsel dar und sorgt somit für die notwendige Agilität auf der Skalierungsebene oberhalb der Scrum-Teams, die fast immer das K.O.-Kriterium gescheiterter agiler Transformationen darstellen. SAFe spricht nicht mehr von Projekten, sondern weist Themen auf Portfolioebene diesen festen agilen Organisationsteilen (Agile Release Trains) zu. Dadurch kann viel Overhead und Zeit, die sonst für Projektvorplanung, Beantragung und Formalismus erforderlich sind, gespart werden und die gewonnene Produktivität direkt in die Wertschöpfung fließen. In immer mehr Unternehmen zeigt sich, dass agile Skalierung gelingt, wenn man Methoden, Rollen und Frameworks nicht dogmatisch verordnet, sondern eine agile Organisation gemäß einer realistischen Transformations-Roadmap entwickelt. Erfolgskritisch ist zudem die intensive Einbindung und Begleitung aller Beteiligten sowie ein Management, das agile Prinzipien selbst lebt und entsprechend Rahmenbedingungen schafft. Erst dann kann auf Augenhöhe mit den Scrum-Teams eine agile Organisation erfolgreich aufbaut werden.

Q_PERIOR verfügt über fundierte Erfahrung aus agilen Transformationsvorhaben – ob nach SAFe oder anderen Ansätzen. Diese Erfahrung fließt permanent in unseren Transformationsansatz ein. Unser SAFe-zertifiziertes Experten-Team zum Thema agile Transformation beschäftigt sich kontinuierlich mit der Weiterentwicklung aller Frameworks und unterstützt Sie gerne bei Ihrem Transformationsvorhaben.

SAFe in der Praxis. Die Business- und IT-Beratung Q_PERIOR unterstützt die Swisscom auf dem Weg zur agilen Organisation. Lesen Sie hier mehr über die erfolgreiche Transformation.

Weitere Fokusthemen

WIR SIND FÜR SIE DA!

Mit Q_PERIOR steht Ihnen ein starker Partner zur Seite.
Wir freuen uns auf Ihre Herausforderung!

6. Oktober 2017|