5 min on Scaling - Vorsicht vor standardisierenden Modellen

In seiner wundervollen Präsentation „Why is Agile failing in large enterprises“ zeigt Mike Cottmeyer, dass drei Grundannahmen dabei helfen, die agile Enterprise zu etablieren:

• Working Hypothesis: Agile transformation begins by defining a rational system of delivery for the enterprise
• Working Hypothesis: True agility is about breaking dependencies across the entire organization
• Working Hypothesis: Healthy culture and effective practices only emerge within a rational delivery framework

Damit man diese Hypothesen umsetzen kann, definiert er dann im Anschluss eine agile Organisation, die im Kern aus Teams auf vier Ebenen besteht:

• Services Teams – These teams support common services across product lines. These teams support the needs of the product teams.
• Product Teams – These teams integrate services and write customer facing features. This is the proto-typical Scrum team.
• Programs Teams – These teams define requirements, set technical direction, and provide context and coordination.
• Portfolio Teams – These teams govern the portfolio and make sure that work is moving through the system.

Ja, ich teile die Behauptung, dass man Service Teams und Product Teams in großen Organisationen unterscheiden sollte. Die Product Teams sind dann die Stakeholder der Service Teams. Je mehr ich darüber nachdenke, werden bei mir aus den "!" aber einige große "?". Mikes Framework mit Program Teams und Portfolio Teams muss ich entgegenhalten, dass hier eine hierarchische und von oben nach unten tröpfelnde Kette von Inhalten (Anforderungen, Constraints) etabliert wird.Der beschriebene Ansatz, der auch Kern des Scaled Agile Framework ist, ist auf den ersten Blick erfolgreich. Doch macht er aus sich selbst organisierenden, eigenverantwortlich arbeitenden Teams eine Scrum-Maschine. Scrum-Teams waren anders gemeint: Sie stellen eine Organisation dar, die ähnlich wie eine Verbindung aus Business Units funktioniert. Die agile Organisation so wie beschrieben zu strukturieren, zerstört den Kern von Scrum und Agilität.Es hat mit dem, was hinter Scrum steckt und mit dem Agile Manifesto einmal definiert wurde, leider nicht mehr viel zu tun. Nonaka, Ken, Jeff und ich - wir gingen davon aus, dass die Product Teams (so wie schon bei Skunk Works und im berühmten Artikel von Nonaka - "The New New Product Development Game" beschrieben) selbständig darüber nachdenken, was sie liefern. Das führt zur Schlussfolgerung, dass die Product Scrum Teams tatsächlich selbst die Anforderungen definieren. Selbständig, weil sie cross-funktional Lösungen für die Probleme der Kunden/User liefern. Die Scrum-Teams schaffen also eigenverantwortlich einen Wert für ein Unternehmen.Ich verstehe den Impuls, dass man von oben her denken will. Aber Scrum war und ist immer von der Kernidee der eigenverantwortlichen und sich selbst auf das Ziel ausrichtenden, cross-funktionalen Teams getrieben, denen man einen Management-Framework zur Unterstützung gibt. Skalierung so verstanden lässt den Teams den Raum, sich zu organisieren - sogar wenn es um 300 oder 1000 Teammitglieder gibt. Modelle wie dieses finden sich NICHT in den Büchern der derzeit modernen agilen Coaches, sondern in den Ideen aus der Organisationsentwicklung der letzen 20 Jahre. Es gibt Modelle wie die Open Space Technologie, die viel besser geeignet sind, wirklich große Projekte zu steuern, wie z.B. Harrison Owen schon mehrfach bewiesen hat. Mit diesen Management-Methoden, die man um Scrum herum aufstellen kann, lassen sich große Organisationen steuern - dann sind große SAP-Implementierungen, Data-Warehouse-Entwicklungen, medizintechnische Produkte oder andere Hardware-Entwicklungen genauso einfach mit agilen Methoden umzusetzen, wie es heute schon bei großen Software-Development-Projekten passiert.Wer darüber mehr wissen will - wir haben ein neues Training dazu:Scrum international - verteilt, skaliert und multikulti