Agile Vorgehensweisen implementieren einen kontinuierlichen Verbesserungs- und Anpassungsprozess. Viele Organisationen setzen diesen Prozess bereits erfolgreich auf der Ebene der Produkt-Entwicklung und der direkten Leistungserbringung ein. Gleichzeitig schläft die Konkurrenz nicht. Kontinuierlich neue Innovationen versprechen einen Vorteil gegenüber den Mitbewerbern oder sind schlicht und einfach notwendig, um am Markt bestehen zu können.
Chief Digital Officers stellen sich zunehmend die Frage, wie sie ihr Business schneller und effektiver transformieren. Dabei spielen die Mitarbeitenden an der Basis eine zentrale Rolle. Deren Wissen und Erfahrung soll rasch und einfach einbezogen werden. Mit Hilfe der Lean Change Methode wird im bestehenden digitalen Arbeitsplatz ein Continuous Innovation Prozess initiert und verankert. Bei den einzelnen Innovations-Paketen orientieren wir uns an den Enablers aus dem Scaled Agile Framework (SAFe)®.
Der folgende Blueprint setzt bewusst niederschwellig an, um Widerstände, nicht-verrechenbare Arbeitszeiten und Infrastruktur-Kosten niedrig zu halten. Erste Erfolge auf Team-Ebene (Quick-Wins) werden genutzt, um den Innovationsprozess zu skalieren und auf Führungsebene (C-Level) verfügbar zu machen, so dass die Organisation ihre Agilität und Innovationsfähigkeit über einen kontinuierlichen Prozess mit befeuert. Der vorgestellte Blueprint ist tool-unabhängig (wenn auch Abbildungen von JIRA auftauchen) und lässt sich in Skalierungsframeworks wie SAFe® integrieren.
Innovation oder Improvement?
Mit Innovationen sind hier nicht nur disruptive Erfindungen gemeint, die ein neues Geschäftsfeld erschliessen. Vielmehr wird mit Innovation auch die fortlaufende Verbesserung von Arbeitsprozessen (und natürlich technischen Features) adressiert. Das sind die kleinen Schritte hin zu mehr Wettbewerbsfähigkeit und Motivation der Mitarbeitenden. Continuous Innovation beinhaltet also auch Continuous Improvements.
Scaled Agile Framework® als Basis-Framework
Die folgenden Überlegungen basieren auf SAFe®. Es spricht allerdings nichts gegen die Verwendung einer anderen Prozess-Methode wie z.B. LeSS oder einer Eigenentwicklung. Wichtig für Teams und Organisationen ist eine definierte und für alle Beteiligten transparente Prozess-Basis, auf die aufgebaut werden kann. Nehmen wir SAFe®, sind diese Voraussetzungen erfüllt, da das Framework die Arbeitsprozesse bis ins Detail hinunter spezifiziert, Rollen, Zuständigkeiten, Ergebnisse definiert und agile Techniken und Guide-Lines anbietet. Checklisten und definierte Meeting-Abläufe helfen bei der Orientierung und der effizienten Zusammenarbeit. Wenn es also darum geht, rasch und strukturiert in die skalierte agile Zusammenarbeit einzusteigen bietet SAFe® so ziemlich alles, was dazu benötigt wird.
Dabei gibt es aber auch eine grosse Gefahr: Einer Organisationen werden Best-Practices und Zusammenarbeitsmodelle oft zu schnell und unbedacht übergestülpt, d.h. “von oben herab” ist man jetzt agil, die Mitarbeitenden an der Basis sind aber noch gar nicht auf den Zug aufgesprungen. Die hochgehaltene agile Kultur finden wir dann höchstens in der Besenkammer. Dafür kann SAFe® nichts – es kommt einfach schon pfannenfertig daher und muss daher unbedingt in die Organisation nachhaltig integriert werden. Mit einem Bottom-Up-Framework wie LeSS besteht die Gefahr für diese Effekte weniger, es dauert aber auch länger, bis die Prozesse effektiv funktionieren. Dafür ist dieser Ansatz eher nachhaltig.
Wir starten deshalb mit den Enablers auf Ebene Team (siehe folgenden Grafik) und gehen dann hoch bis zur Portfolio-Ebene in einer Organisation.
Gesamtübersicht SAFe 4.5 mit Enablers bereits auf der Team-Ebene
Enablers sind mehr als technische Innovation
Gemäss SAFe sind Enablers wie folgt definiert:
Enablers support the activities needed to extend the Architectural Runway to provide future business functionality. These include exploration, infrastructure, compliance, and architecture development. They are captured in the various backlogs and occur at all levels of the Framework.
SAFe Enablers gibt es in 4 Typen:
Exploration enablers – support research, prototyping, and other activities needed to develop an understanding of Customer needs, to explore prospective Solutions, and to evaluate alternatives
Architectural enablers – are created to build the architectural runway, which allows smoother and faster development
Infrastructure enablers – are created to build, enhance, and automate the development, testing, and deployment environments. They facilitate faster development, higher-quality testing, and a faster Continuous Delivery Pipeline
Compliance enablers – facilitate managing specific compliance activities, including Verification and Validation (V&V), documentation and signoffs, and regulatory submissions and approvals
Obwohl nicht direkt Mehrwert bringend, sind Enablers mit Aufwand verbunden und können nicht “so nebenbei” erledigt werden. Die involvierten Personen machen also transparent, was sie nebst dem direkten Value-Stream leisten. Enablers können wie normale Stories, Epics, usw. bewertet geschätzt und proaktiv eingeplant werden. Enablers sind also nicht Teil des Grundrauschens, sondern ehrliche Aufgaben, die es zu bewerkstelligen gilt.
Was hier fehlt, sind die Aufgaben, die als Resultat aus Retrospektiven anfallen. Zum Beispiel sind dies Prozessverbesserungen innerhalb und zwischen Teams. Dazu gehören Anpassungen der Arbeitsschritte, Die Definition-of-Done, Tool-Konfigurations-Verbesserungen, Schulungen, usw. Da auch diese Aufgaben mit Aufwand verbunden sind und das Team absorbieren, sollen sie bewertet, geschätzt und geplant werden. Schließlich will ein Product-Owner auch nachvollziehen können, warum ein Team in den kommenden Sprints weniger direkten Output hat.
Das ewige Grundrauschen und die Prozess-Enablers
Natürlich kann jetzt argumentiert werden, dass Prozessoptimierungen einfach zum Grundrauschen gehören, wie die wöchentlichen Meetings, der Betriebs-Ausflug und die ständigen Störungen durch etwaige Stakeholder. Dem ist aber nicht so – Prozessoptimierungen sind meist zu groß resp. haben Auswirkungen auf zu viele Beteiligte, als dass sie vernachlässigbar wären.
Prozessoptimierungen bedeuten auch immer einen Change (nein, kein Software-Change) – die Beteiligten verlassen ihre gewohnten Arbeitsweisen, müssen kritisch reflektieren und ihr Verhalten ändern. Das ist mit mehr Aufwand verbunden, als oberflächlich sichtbar ist. Diese Change-Schritte sollen nach der “Umsetzung” auch bewertet werden. Hat die Prozessoptimierung den Output des Teams verbessert? Gemäß Lean Change Management (u.a. Jason Little) werden Ergebnisse bezüglich zwei Faktoren validiert: Anwendung und Kosteneffizienz/Output. Mit Anwendung ist gemeint, ob die Prozessoptimierungen auch effektiv durch das Team angewendet und gelebt werden (sichtbar an der Motivation der Mitarbeitenden). Der gesteigerte resp. reduzierte Output sollte selbsterklärend sein.
Prozess-Enablers sind also im Grunde genommen Experimente auf dem Weg hin zu einem effektiveren und effizienteren Prozess. Hat ein solcher Enabler nichts gebracht, müssen die Änderungen auch wieder rückgängig gemacht werden resp. die nächsten Schritte neu ausgelegt werden. Prozess-Enablers sind also Teil eines Gesamt-Planes, was auch wiederum sehr gut zur Skalierung auf die oberen SAFe-Ebenen passt.
Hands-on!
In einer ersten Phase wird das Ziel definiert und dazugehörig sind die ersten Prozess-Enablers festzulegen. Hier lohnt sich der Einsatz des Lean Change Canvas als Ausgangslage:
Lean Change Canvas (nach Jeff Anderson): The Lean Change Method, und Improvement Experiments
Der Lean Change Canvas unterstützt die Prinzipien „negotiated change“ und „validated learning“. Einerseits werden ein klares Ziel vorgegeben und Rahmenbedingungen geschaffen, andererseits bleibt genug Gestaltungs- und Reaktionsfreiraum auf dem Weg dahin. Zwischenschritte (In der Abbildung sind dies die Actions) werden mit den Betroffenen vereinbart und deren Commitment abgeholt. Die akzeptierten Zwischenschritte werden zu konkreten Prozess-Enablers (hier Improvement Experiments) ausformuliert. Wir haben nun ein Backlog von Prozess-Enablers. Diese sollten Teil des Team-Backlogs sein.
Im zweiten Schritt priorisieren/planen der Product-Owner und das Team die Prozess-Enablers zusammen mit den übrigen Stories und Aufgaben ein – als wären es “ganz normale” Issues.
Im dritten Schritt läuft die Umsetzung – hier als Sprint. Man achte auf die Swimlane Agile Adoption mit den Prozess-Enablers drin:
Die Agile Adoption Swimlane noch speziell hervorgehoben:
An Review- und Retrospektiven-Meetings werden die Prozess-Enablers dann genauso thematisiert wie alle übrigen Aufgaben auch:
Prozess-Enablers skalieren
In SAFe gibt es die Enablers auf sämtlichen Stufen vom Team bis zum Portfolio (siehe Grafik ganz oben). Warum also nicht auch Prozess-Enablers top-down angehen, wenn es darum geht, die ganze Organisation agiler zu gestalten und Organisationsweite Prozess-Standards zu schaffen resp. Prozesse zu verbessern? Und dabei werden sogar noch alle Mitarbeitenden ins Boot geholt. Natürlich braucht es dann einen etwas größeren Lean Change Canvas (z.B. den Strategic Change Canvas). Aber das ist auf jeden Fall zu schaffen!
Quellen
Scaled Agile Framework: https://www.scaledagileframework.com/
Alle verwendeten Texte und Grafiken der https://www.scaledagileframework.com/-Website: Copyright © Scaled Agile, Inc.
The Lean Change Method, Jeff Anderson, Leanpub
Lean Change Management, Jason Little
Strategic Change Canvas by Jason Little: https://leanchange.org/resources/canvases/
Haben Sie Fragen oder Anregungen zum diesem Blog-Beitrag? Dürfen wir Sie unterstützen? Schreiben Sie uns auf hallo@zuara.ch oder rufen Sie uns an: 031 302 60 00.