SAFe® Enablers für Prozessoptimierungen nutzen

26. Jun. 2018SAFe®, Scaled Agile

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. Schliesslich 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 gross 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äss 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össeren Lean Change Canvas (z.B. den Strategic Change Canvas). Aber das ist auf jeden Fall zu schaffen!

Quellen

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. Wir freuen uns auf Ihre Anfrage!

Der Autor:

Sebastian Fiechter

Sebastian Fiechter

sebastian.fiechter@zuara.ch

Direkt: +41 79 307 60 00

      

Weitere Fachartikel und Neuigkeiten von Zuara

Jira App-Entwicklung: JQL verarbeiten ohne Kopfschmerzen

Die Herausforderung In vielen Projekten haben wir Kundenanforderungen, die mit den normalen Bordmitteln von Jira nicht mehr zu erfüllen sind. Häufig ist die einfachste Lösung, selbst ein kleines Add-on zu implementieren. Eine solche Anforderung, die wir kürzlich...

Confluence Data Center und GlusterFS

Einführung In den Blog-Beiträgen Atlassian Testumgebungen automatisieren und Docker Images erstellen mit Packer habe ich die Grundlagen dargelegt, wie wir Testinstanzen von Atlassian-Produkten schnell zur Verfügung stellen können. Ein Problem der bisherigen Lösung...

Quo Vadis Jira Service Desk?

Ausgangslage Am 9. November hat Atlassian das neueste Produkt angekündigt: Jira Service Management. Es handelt sich dabei nicht um ein komplett neues Produkt, sondern um eine Weiterentwicklung von Jira Service Desk. Atlassian will damit auf geänderte Anforderungen und...

Erweiterte Auditing-Funktionen – Atlassian Data Center

Sobald es darum geht, die Effizienz und die Effektivität in Ihrem Unternehmen zu steigern, sind die Monitorig- und Reportfunktionen die besten Freunde. Diese Funktionen ermöglichen Ihnen Einblicke wie Ihre Teams die Software benutzen. Als Admin sind Sie für die...

Atlassian setzt auf Cloud

Atlassian setzt seine Cloud-First Strategie in die Tat um: Ab dem 2. Februar 2021 wird Atlassian keine neuen Server-Lizenzen für seine Produkte mehr verkaufen. Die bestehenden Server-Lizenzen können ab diesem Termin noch für maximal 3 Jahre erneuert werden. Für...

In Confluence Finden, statt ewiges Suchen

Haben Sie auch schon versucht, in Confluence etwas zu finden und dafür kostbare Zeit verschwendet?  Die Indexierung von Confluence ist wirklich ein grosser Vorteil, kann aber auch dazu führen, dass das Gesuchte durch die Masse an Ergebnissen einfach nicht gefunden...

Confluence als Innovationsplattform

Confluence kann so erweitert werden, dass es Organisationen als Innovationsplattform dient. Alle Mitarbeitenden können neue Ideen zur Verbesserung von Angeboten oder internen Prozessen liefern. Diese Ideen werden aufbereitet, bewertet und priorisiert. Auch die...

Wo befinden sich meine Daten bei Atlassian Cloud?

Wie im Blog «Atlassian setzt auf Cloud» beschrieben, wird ab dem 2. Februar 2021 keine neue Server-Lizenz für die Atlassian Produkte verkauft und die Lizenzen können maximal noch für 3 Jahre gelöst werden. Anschliessend stellt Atlassian das Produkt ein. Die Zeit bis...

Phänomene ineffektiver Teams

Kennen Sie das? Irgendwie happert es dem Team an Drive, z.B. werden nicht alle User-Stories aufs Sprint-Ende umgesetzt oder auf dem KanBan Board stapeln sich die MMFs in der "To-Deploy"-Spalte. Und dann hat das Ganze auch noch keine Konsequenzen für die...

Vorsicht bei der Migration von Drittanbieter-Apps!

Für eine erfolgreiche Migration von Atlassian Server in die Cloud, müssen Sie sich unbedingt einen Plan erstellen. Berücksichtigen Sie dabei unter anderem die Ermittlung eines geeigneten Migrationsansatzes, die Migrationsreihenfolge oder die Sicherheit der migrierten...

Pin It on Pinterest

Share This