Agile Skalierungsebenen und ihre Auswirkungen


Es gibt viele verschiedene Arten von agilen Skalierungsebenen. Ich fasse den Begriff relativ weit. Es geht dabei nicht nur darum, mehr Personen oder Teams zu involvieren. Es kann auch bedeuten, mehr Produkte zu entwickeln oder die Arbeit in Teams auf eine andere Art und Weise aufzuteilen. In diesem Beitrag präsentiere ich sie in einer subjektiven Reihenfolge danach, wie nützlich ich sie für Organisationen empfinde, die wachsen und sich neuen Herausforderungen stellen müssen.

Die Implementierung von Scrum bei einem oder mehreren Softwareentwicklungsteams ist der typische erste Schritt, den eine Firma in Richtung „Agile“ macht. Nach der Vorstellung der Erfinder und auch der Beschreibung im Scrum Guide, wird Scrum um ein einzelnes Team herum aufgebaut, welches sowohl aus fachspezifischen, als auch technisch orientierten Leuten besteht, die zusammen, autonom an der Entwicklung eines einzelnen Produktes arbeiten. Das hört sich ziemlich einfach an und man könnte denken, dass dieses Szenario nur in einem kleinen, IT-produktorientiertem Startup erfunden werden konnte, das den Luxus von Softwareentwicklung auf der grünen Wiese genoss ohne mit Legacythemen, Abhängigkeiten oder Skalierungsbedarf zu kämpfen. Tatsächlich aber war es überhaupt nicht einfach und Ken und Jeff benötigten jede Menge Erfahrung und mussten viele Anpassungen vornehmen, um am Ende ein Framework zu haben, das stark genug, gleichzeitig aber auch ausreichend verallgemeinbar und flexibel war, um von jeder Organisation verwendbar zu sein, die sich mit kreativer, marktorientierter Produktentwicklung beschäftigt. Mit viel Mut und Führungsfähigkeit, wie sie damals Ken und Jeff hatten, hat heute jede Firma die Möglichkeit, Scrum „handelsüblich“ zu verwenden und ihre Produktentwicklungsteams dabei zu unterstützen, höhere Ebenen an Engagement und Produktivität zu erreichen. Möglicherweise gab es aber auch Aspekte, die es den beiden damals leichter gemacht haben, ein Unternehmen so zu verändern, dass Scrum einen Platz hatte und dann wiederum gab es sicherlich auch Aspekte, die schwerer zu verändern waren und einen Einfluss auf die frühe Entwicklung von Scrum an sich hatten. Auch heute finde ich es OK, wenn in einer Firma Scrum nicht 100% wie im Scrum Guide beschrieben angewendet wird. Wichtiger ist, dass alles unternehmerischen Sinn macht. Sollte es entweder nicht das Hauptziel der Firma sein, Scrum perfekt auszuüben oder sollte die perfekte Ausübung teurer sein (oder andere Probleme mit sich bringen), dann ist gesunder Menschenverstand gefragt. Es müssen Alternativen gefunden werden. In diesem Blogbeitrag widme ich einigen Situationen, mit denen sich größere Firmen konfrontiert sehen könnten und zeige einige Wege auf, sie zu bewältigen. Die meisten Skalierungsmodelle sind Kompromisse für die puren „Einzelteam, Einzelprodukt“ Ansätze von Scrum, sind aber trotzdem geeignete Ansätze für größere Firmen.  

Eine Produktfirma hat sogar ein Interesse daran, diesen Moment frühzeitig zu erkennen und das nächste Produkt zu planen, an dem ein Team arbeiten kann, um so zu vermeiden, dass Mitarbeiter nur rumsitzen und Wertverlust entsteht. Ein Dienstleister hat diesen Luxus nicht. Wenn der Product Owner Teil des Kunden ist und entscheidet, die Entwicklung ungeplant zu beenden, (was er auch tun sollte, wenn die Weiterentwicklung sich nicht mehr lohnt), dann kann es sein, dass sich der Dienstleister in einer ungünstigen Situation befindet. Um dieses Risiko einzudämmen, könnte der Dienstleister einen Mutli-Produkt Ansatz wählen. Dies stellt die erste Ebene der Skalierung von Agile dar: Einzel-Team, Multi-Produkt. Es sind nicht nur Dienstleister, die dieses Risiko minimieren können, indem sie eine Multi-Produkt-Strategie einsetzen. Produktfirmen müssen oftmals gleichzeitig an der Instandhaltung der Altversion eines Produktes sowie der Entwicklung einer moderneren Neufassung arbeiten oder, allgemeiner gesagt, als Teil der Produktportfoliostrategie der Abteilung oder des Unternehmens, Aufwand in Produkte stecken,die sich in verschiedenen Phasen des Prouktlebenszyklus befinden. Interessanterweise werden die zwei bekanntesten, leichtgewichtigsten Ansätze für diese Art von Skalierung nicht unterstützt. LeSS und Nexus sind beide explizit auf Einzelprodukt-Modelle ausgerichtet. In diesem Fall ist mein Vorschlag für den Multiprodukt-Ansatz die Verwendung von Kanban zusammen mit Scrum, das leichtgewichtig genug ist, um sinnvoll in einem Team angewendet werden zu können, ein einfaches Portfolio- und Kapazitätsmanagement anbietet und einfach zu erweitern ist, falls später mehrere Team dazu kommen.  

Mit dem “Single Team, multi-product”-Ansatz hat jedes Produkt einen separaten Owner und Backlog. Der Scrum Master hilft dabei, die Team-Kapazitäten entlang der Produkte nach einem wirtschaftlichen Modell zuzuteilen.

Der zweite Ansatz sind funktionale Teams. Hier fangen wir schon an, die Scrum Regel zu verletzen, die besagt, dass Teams funktionsübergreifend sein und autonom arbeiten müssen. Es entstehen Abhängigkeiten zwischen Teams, die lieber vermieden werden sollten. Aus verschiedenen Gründen ist dies jedoch manchmal notwendig. Oder wird zumindest als notwendig angesehen. In jedem Fall ist es typisch. Die Grenzen zwischen Teams können an normalerweise an zwei Stellen gezeichnet werden. Oft sieht man zum einen eine Trennung zwischen Business-Teams und IT-Teams. Zum anderen wird manchmal zwischen Produkt-Teams und einem oder mehreren Teams, die Dienste (wie bspw. gewöhnliche UI oder Datenbankaufgaben, Bereitstellung der Infrastruktur oder Fähigkeiten, die Produkt-Teams nicht in jedem Sprint brauchen, wie SAP- oder Großrechnerfähigkeiten) zuliefern, gesplittet. Eine Trennung in Business und IT Teams bringt meistens nur Nachteile mit sich. Meist geschieht dies in Fällen, in denen die Splittung historische Gründe hat und daher aufgrund kulturell und sozial schwer zu überbrücken ist. Was dann oft passiert, ist, dass das Business-Team das Produkt entwickelt ohne agile Vorgehensweisen zu berücksichtigen. Das Team entwickelt die Vision, führt die Marktforschung aus und stellt die Anforderungs- und Designdokumentation bereit. Oftmals erstellen sie sogar Screenshots der UI. Es wird alles erledigt, was ein komplettes Produkt erfordert ohne dass je eine einige Zeile Quellcode geschrieben wurde. Dann wird das Ganze an das IT-Team überliefert – schließlich soll Scrum verwendet werden, doch tatsächlich bleibt nur über, das fast fertige Produkt als Quellcode einzutippen. Das ist natürlich nicht Sinn der Sache. In diesem Fall hätte das Business Team Scrum verwenden müssen, denn es hat die gesamte komplexe, kreative Produktentwicklungsarbeit geleitstet. Das IT-Team braucht Scrum jetzt nicht mehr, Scrum ist für dieses Team überflüssig. Jetzt reicht es, sich mit der Dokumentation auseinanderzusetzen und sie in Software zu konvertieren. 

Ein Team, das nur an einem Produkt arbeitet, setzt sich einem hohen finanziellen Risiko aus, besonders während „Introduction“ und „Decline“, wenn die Kosten die Umsatzerlöse übersteigen. Dieses Risiko kann mit einem Produktportfolio ausgeglichen entlang Lebenszyklusphasen abgesichert werden.

Der andere Fall, bei dem die Trennung zwischen funktionsübergreifendem Produktentwicklungsteam und den Teams, die weitere Dienste anbieten, ist nicht so schlimm, kommt aber doch häufig vor. Ich finde, dass es in der Regel viel besser ist, wenn das Produktteam die Entwicklungsarbeit wirklich selbst macht, auch wenn es um Komponenten geht, die später von weiteren Teams verwendet werden. Aufgaben wie die Webserviceentwicklung oder Datenbankverwaltung sind Aufgaben, mit denen die meisten Entwickler oder zumindest jedes Team, klarkommen sollten. Auch, wenn bestimmte Dienste, Schemen oder DB-Instanzen von mehreren Produkten benutzt werden, solle das Produktteam selbst die Arbeit direkt erledigen und sich nicht auf ein anderes Team verlassen. Darunter versteht man das „Extreme Programming“ Konzept der „Collective Ownership“. Es gibt natürlich eine Grauzone, in der es Sinn machen könnte, gewisse Abhängigkeiten einzuführen. Beispielsweise bei der Infrastruktur der Produktionsumgebung sollte aus Gründen der Sicherheit und Effizienz vieles zentral gesteuert werden. Aber in Entwicklungs- und Testumgebungen müssen Produkt-Teams viel Freiheit haben und nach Bedarf neue VMs stellen können ohne auf ein externes Team warten zu müssen. Geht es um Fähigkeiten, die ein Team nur ab und zu braucht, wie z.B. Anpassungen innerhalb eines SAP-Systems oder auf dem Großrechner, dann macht es vielleicht Sinn diese Fähigkeiten außerhalb des Produktteams zu platzieren.

In diesem Fall arbeiten zwei Teams an einem Produkt – aber auf eine suboptimale Art und Weise. Geschäfts und Softwareentwicklung zu trennen, ist eine schlechte Idee. Aber wenn man es schon tut, sollte das Business Team Scrum benutzen, nicht das Softwareentwicklungsteam, das mit einem einfachen Ticketsystem arbeiten kann.

Das beste Werkzeug um mit dieser Art von Skalierung, bei der mehrere Teams für verschiedene Dienste zuständig und voneinander abhängig sind, ist einmal mehr der Lean Kanban Ansatz und sein großer Bruder, Enterprise Services Planning.

Der dritte Art von Skalierung ist der Fall wofür die bekannten Frameworks existieren: Multi-Team. Dieses Modell wird verwendet wenn mehrere Teams zusammenarbeiten müssen, aus dem einfachen Grund, das so viele Kapazitäten benötigt werden. Am einfachsten haben wir das Multi-Team, Einzelprodukt Szenario, bei dem es nur um die Entwicklung eines einzigen Produktes geht, das aber groß genug ist, das mehrere Teams benötigt werden. Für diesen Fall könnte Scrum-of-scrums ausreichend sein, ein Ansatz, bei dem Teilnehmer aus jedem Team zusammen kommen um kurz zu besprechen, was die einzelnen Teams machen, was für Schwierigkeiten sie haben und welche Art von Hilfe benötigt wird. Das ist oft völlig ausreichend, besonders wenn das Produkt in verschiedene Teile „zerlegt“ werden kann, um die Anhängigkeiten zwischen Teams minimal zu halten. Sollte es nicht ausreichend sein – und das ist bei größeren Produkten manchmal der Fall, dann sind vielleicht die Frameworks LeSS und Nexus geeignet. Nach meiner Erfahrung aber kann ich sagen:Sobald eine Organisation so komplex ist, dass ein Framework gebraucht wird, wird auch Multi-Produkt Unterstützung nötig, was leider von LeSS und Nexus nicht angeboten wird.

Produktentwicklungsteams, die dem Markt zugewandt sind, können Scrum nutzen sowie gemeinsame Services, die von anderen Teams zur Verfügung gestellt werden. Die multiplen Wertströme können effizient mit Kanban verwaltet werden.

In solchen Fällen, also wenn ein Multi-Team, Multi-Produkt Ansatz benötigt wird, ist SAFe eine gängige Lösung. SAFe ist ziemlich schwergewichtig, und sollte alle Skalierungsszenarien abdecken die mehr als ca. 150 Leute involvieren. Es bietet Unterstützung für multi-Team, multi-Produkt, multi-Wertschöpfungskette, die Verwendung von Service-orientierten Teams, und beschreibt auch Mechanismen für Portfolio- und Programmanagement. Das SAFe Framework ist aber ziemlich stark auf die Entwicklung von Softwareprodukten ausgerichtet und ist ziemlich verordnend. Es kann für Organisationen, besonders außerhalb der IT, schwierig sein SAFe umzusetzen. Alle müssen irgendwie passende Rollen finden was oft kulturell schwierig ist. Wenn eine Firma schon mit Scrum (und Selbst-Organisation, „Servant Leadership“ usw.) angefangen hat, könnte sich eine SAFe-Einführung wie ein „top-down, command and control“ Aufzwingen anfühlen. Ein flexibler, allgemeiner Ansatz wäre die Verwendung von Lean Kanban sowie Enterprise Services Planning um alle Teile der Wertschöpfungsketten zu integrieren, ohne dass es wie eine IT-orientierte Transformation aussieht (also auch leichter für die anderen Abteilungen zu akzeptieren ist), in einem holistischen „Service Delivery“-basierten System. Solche Systeme sind auf Visualisierung, das Management von Warteschlangen, Ziehsystemen und neue Möglichkeiten und die Implentierung einer Reihe von kleineren „Kaizen“-Syle Verbesserungen ausgelegt und zwar genau dort, wo sie den meisten Wert zu erzeugen ohne dass sie gleich eine großen, störenden, frühzeitigen Neuaufbau der Firma zu benötigen.

 

Post a Comment

* indicates required

Comment Area

    1. Kurt Häusler28. März 2017

      Hallo Christian,
      danke für deinen Kommentar. Mit dem groben Ansatz den Jurgen in seinem Blog Artikel beschreibt stimme ich 100% zu. Es ist auch nichts neues. Es ist (nicht nur) mir schon längstens klar das Kotter-artige Änderungsprojekten unpassend für moderne Wissensarbeit sind. Leute wie Deming und Ohno haben das seit Jahrzehnten erwähnt. Aber bald wird es anders sein. Firmen entdecken schon wie die Verbesserungen in der Softwareentwicklung durch Agile viel Potenzial hat, und nicht mehr der Flaschenhals ist. Die fangen erst jetzt zu verstehen das wahre end-to-end Verbesserungen brauchen nicht nur statische Änderungen in der IT, aber holistische Änderungen im Mindset über den gesamten Wertstrom, und auf alle Ebene. „Agility-Scales“ kenne ich noch nicht so gut, aber es scheint mir eine sehr nützliche Sammlung von Werkzeugen die diese Evolution in der Firmenkultur unterstützen könnten. Ich bin allerdings ein bisschen skeptisch, weil alle progressive Berater haben ihre Lieblingstools, die das richtige Mindset folgen, aber irgendwie die Welt ist immer noch top-down gesteuert durch command & control. Ich weiß nicht ob Agility-Scales plötzlich alles ändern wird aber ich soll es auf jeden Fall genauer anschauen.

      Grüße,
      Kurt