Startseite » Agile Transformation schrittweise

Agile Transformation schrittweise

Voraussichtliche Lesedauer: 12 Minuten

Gerne gedacht:

Agiles arbeiten einführen heisst:

  1. Scrum Schulung
  2. loslegen & üben

Basta!

So oder so ähnlich wird die Umstellung oft wahrgenommen. Neben dem, dass Menschen beim Veränderungsprozess einige Schritte zu gehen haben, setzt eine solche „Einführung“ voraus, dass

agile Transformation schritteweisePin
agile Transformation schrittweise
  1. Es ein williges Team gibt
  2. Es ein crossfuktionales / interdisziplinäres Team gibt
  3. Dieses Team die Autonomie zum Entscheiden hat
  4. Vollständig an EINEM Ziel bzw. Produkt gearbeitet wird

… dann kann das in dieser Art klappen. Alles easy pisy ….

Nun entspricht das für viele Teams nicht der Realität. Und diese Quote an Teams, bei denen das anders aussieht, steigt mit der Quote an Teams, die nicht aus der reinen Produktentwicklung kommen.

Die Situationen, die ich häufig antreffe, sind:

  1. Wir sind ein Fachteam und stellen nicht als erstes unsere Teams neu zusammen.
  2. Unser Tagesgeschäft macht einen Großteil unserer Arbeit aus.
  3. Wir haben mit vielen Externen zu tun und sind nicht autonom.
  4. Bei uns laufen immer mehrere Projekte parallel.

Der schnelle Trugschluss ist dann oft agile passt bei uns nicht.

Konventionelles TeamPin
Konventionelles Team

Wir arbeiten so vor uns hin, sind als Team zusammen. Jeder hat seine Aufgaben. Jeder hat seine Meetings. Jeder hat seine Abhängigkeiten nach außen. Wir haben ein Team Meeting.

Definiert man auf agiles Arbeiten aber mit: „Wir wollen immer effizienter werden und mehr Werte liefern.“, können Teams und Team-Leads sich schon assoziieren.

Die Frage

Wie kann agiles Arbeiten Stück für Stück unseren Alltag verbessern? Und aus meiner Sicht ist das der beste Weg agil zu üben: schon die Einführung als erstes agiles Projekt im Team zu sehen und sich in Etappen zu wandeln.

Meine Vorannahmen hier:

  • Wir wollen als Team in den Wandel (ohne Bedürfnis oder Schmerz, kein Wandel),
  • Wir haben kein extra Budget für neue Rollen,
  • Wir haben keine Re-Org-Möglichkeit für crossfunktionale Personen,
  • Wir sind kein Vollzeit-Produkt-Team.

(alle Glaubenssätze für agiles Arbeiten nach dem Schulbuch sind unerfüllt)

Randbemerkungen:

  • Natürlich wäre der Weg auch gangbar, wenn die Grundlage besser ist
  • Die folgenden vorgeschlagenen Schritte sind auch kombinierbar oder in der Reihenfolge partiell austauschbar

Wie gesagt: die Einführung ist das erste agile Projekt, d.h. das Team entscheidet die Maßnahmen und das Tempo.

Sehnsucht erzeugen

Nichts verändert sich, ohne den Wunsch an sich zu arbeiten. Warum sollte man einen steinigen und unsicheren Weg der Veränderung gehen, wenn es keinen Bedarf, Wunsch, Schmerz gibt? Sich als Team also erstmal zu einigen: „Wir wollen an uns arbeiten.“ Und idealerweise ein grobes Bild oder Gefühl zu haben: „Wenn wir uns in 1 Jahr treffen, wie wollen wir dastehen?“.

Aufgabe: Beschreibt, wie ihr Euch heute als Team seht und was in 12 Monaten anders ist.

Das kann Euer Leuchtturm werden, wenn ihr die folgenden regelmäßigen, kleineren Anpassungen angeht.

Für wen erzeugen wir welchen Wert?

Sich als Team, gerade als Fachteam, klar zu machen, wer unser Abnehmer ist? Und Welchen Wert (Business Value) wir erzeugen? Ist sehr wertvoll. Interessanterweise ist das vielen Fachteams, die einfach „funktionieren“, oft nicht so bewusst, dass täglich daran Priorisierungen vorgenommen werden können.

Aufgabe: Definiere ein Werteversprechen für ein oder mehrere Zielgruppen. (z.B. Value Proposition Canvas)

Schritt 1: Zyklen etablieren

Ein Pfeiler agiler Arbeit ist es Zyklen zu etablieren, die dabei helfen regelmäßig zu messen. Messen heißt hier nicht nur den Produkterfolg, sondern generell zu bilanzieren, was erreicht wurde und was nicht erreicht wurde.

Agile Sprints etablierenPin
Agile Sprints etablieren

Aufgabe: Trefft Euch regelmäßig im Team (2-4 Wochen, aber ein fester Rhythmus), um Euch gegenseitig ins Boot zu holen, was im Team erreicht wurde und was ihr im kommenden Rhythmus erreichen wollt.

Erreicht heißt anfassbare, sichtbare Ergebnisse.

Erreicht heißt nicht zu berichten, war wir nicht geschafft haben und warum bestimmte Dinge wie gelaufen sind oder was wir alles gemacht haben.

Bare Bone: Hier sind meine sichtbaren Ergebnisse!

Das ist ein großer Schritt in Richtung „Wirkung“ bzw. „Outcome“ zu denken und mit dem Team zu teilen. Langfristiges Ziel ist die Einstellung: „Wir als Team liefern ab. Es gibt nicht den Einzelnen, der nicht performt, sondern das Team oder eben keiner.“ Das heißt erstmal „wissen was läuft“ und „wo haben „WIR“ Probleme, die wir vielleicht gemeinsam lösen können.

Schritt 2: Kontinuierlich Verbesserung

Agiler VerbesserungsprozessPin
Agiler Verbesserungsprozess

Sind die Rhythmen etabliert und es entsteht Stück für Stück ein Team-Verständnis /-Identifikation kann an der gemeinsamen Verbesserung und Zusammenarbeit gearbeitet werden. Wir starten nach den Zyklen mit einer Retrospektive und stellen uns am Ende des Zyklus 3 Fragen:

  • Was haben wir erreicht?
  • Was wollen wir erreichen?
  • Was sehen wir gerade für Hürden?

Die dritte Frage ist der neue Aspekt und sollte dazu führen, dass das Team gemeinsam überlegt, wer helfen kann die Hürden oder auch zeitlichen Engpässe zu beseitigen. Sobald das Team als Team denkt, wird auch eine fachfremde Person zur Seite springen und für Entlastung sorgen => das Team wird zum Team (siehe auch T-Shape oder drippy-T).

Aufgabe: Jeder Zyklus enthält einen geringen, zeitlichen Strang, in dem an Verbesserungen gearbeitet wird.

Schritt 3: Business as Usual planen

Agil Zeiträuber verstehenPin
Agil Zeiträuber verstehen

Hier geht es um die unvorhergesehenen Tätigkeiten – das war ja ein Grund, warum „agil nicht geht“. Das fängt an damit, dass wir einen Prozentsatz unserer Zeit hierfür vorsehen und im Laufe des Zyklus erfassen, was hier an Aufgaben entsteht. Wir planen also nicht, sondern erzeugen unser Taskboard „on the go“. Das hilft uns zu erfassen, wieviel und was pro Zyklus anfällt.

Die Erfassung ist die Grundlage für 1. Transparenz im Team, 2. Quantifizierung, 3. Die Möglichkeit zu prüfen, wo hier Potenzial für Optimierung und Priorisierung ist (wie tragen diese Tätigkeiten zu unserem Werteversprechen bei?)

Aufgabe: Erfasst Eure Tätigkeiten für Business as Usual auf Tagesbasis. Wieviel des Tages und für was habe ich verbracht?

Schritt 4: Partiell agil planen

Nun kann es Zeit werden für ein gemeinsames Taskboard. Das Team schnappt sich ein Projekt (oder auch mehrere) und plant konkret die Schritte (Tasks), die im kommenden Zyklus (Sprint) zu gehen sind, um das Ziel zu erreichen. Es wird für alle Team-Mitglieder verständlich, wie die Fachperson über die Schritte nachdenkt, die Schritte werden kleiner und einfacher, damit werden auch fachferne Personen in die Lage versetzt Teilaufgaben zu übernehmen.

Aufgabe: Schafft Euch ein Taskboard und plant gemeinsam anhand kleiner, z.B. täglicher Tasks, was in einem Projekt im nächsten Zyklus zu tun ist. Und schaut während des Zyklus gemeinsam auf den Fortschritt.

Am Anfang spielt es keine Rolle, ob alle Tasks erfasst sind. Versucht es und nutzt hinterher die Bilanz, um zu verbessern. Waren die Tasks zu grob? Haben wir nur die Hälfte geschafft? Haben wir die Hälfte vergessen? Starten – einfach loslegen – und dann messen und lernen: das ist agil.

Das ist auch der Moment, wo das Team dann während des Sprints regelmäßig auf den Fortschritt schaut, im Daily oder in mehrtägigen Abständen. Wichtig: dieses Draufschauen muss kurz und knapp sein und dient ausschließlich der Transparenz. Folge Aktivitäten, Klärungen und Kooperationen können im Anschluss geklärt werden.

Die Menge an planbaren Projekttätigkeiten, kann dann über die Zyklen steigen.

Aufgabe: ein Teil der Team-Tätigkeit wird vor dem Zyklus vom Team gemeinsam in ToDos gesplittet.

Schritt x: Backlog aufbauen

story points backlogPin
Backlog etablieren

Das Backlog ist das Rückgrat des agilen Teams, denn wir wollen weg von langfristigen und detaillierten Projektplänen und gleichzeitig eine Planbarkeit für uns und äußere Abhängigkeiten erzeugen. Und es ist bei Teams, die heute durch Tagesaufgaben oder durch langfristige Projekte getrieben sind, die größte Hürde. Das Verständnis für den Bedarf, wird schon bei den oben genannten Schritten entstehen. Wann der Zeitpunkt gekommen ist, wird das Team selbst wissen. Wenn das Feedback ist: Wollen wir jetzt alle Pläne wegschmeißen? Ist es zu früh. Wenn das Feedback ist: Die Pläne sind doch jetzt veraltet! Oder lasst uns mal etwas länger planen als „von der Hand in den Mund“ ist vermutlich der richtige Zeitpunkt.

Sind wir also in unserem täglichen Doing transparent, messen und verbessern uns stetig, ist spätestens Zeit auch über eine Umstellung der mittel- und langfristigen Planung nachzudenken.

Das kann bei Projekt-Teams sein wie einmal schnell ein Pflaster abzureißen. Oder es kann bei Tagesgeschäft-getriebenen Teams überraschend sein, dass es eine „Roadmap“ gibt.

In beiden Fällen empfehle ich eine grösser werdende Zeitspanne für die Planung:
Was wollen wir in:

  • 1 Monat
  • 3 Monaten
  • 6 Monaten
  • 12 Monaten

erreichen.

Auf diese Zeitleiste gehören dann vor allem alle externen Termine, die „gegeben“ sind. Die internen Ziele in Sinne des Werteversprechens, sollten diese Zeitleiste nach Wert priorisiert anreichern. Im Regelfall sind einige Themen schon vorgedacht und andere nicht. Das wollen wir nicht verlieren. Alles was da ist, gerne mitspeichern.

Aufgabe: Nehmt Euch eine Stunde Zeit und sammelt, was ihr an Lieferterminen in der Zukunft habt und was ihr in den kommenden 3 Monaten zusätzlich liefern wollt.

Wenn diese Reihenfolge erzeugt ist, kann etwas mehr in die Zukunft gedacht, gearbeitet werden – also über den nächsten Zyklus hinaus. Wir können bei jedem Gedanken in die Themen (Stories) der Zukunft hineindenken und dokumentieren. Wir können aus als Team auch immer mal wieder treffen und schauen, was in den kommenden 1-2 Monaten ansteht. Wir können die Themen je nach Umfeld und Wert auch umpriorisieren.

Rollen entstehen

Team SupportPin
Agiles Team etablieren

Meist passiert das durch Team-Dynamik automatisch oder durch Rollen, die in der Vergangenheit schon „grob“ in die Richtung gingen.

Es ist hilfreich, wenn es:

  1. Eine Person gibt, die dafür sorgt, dass das Backlog für das Team gepflegt, priorisiert und voll genug ist für mehr als einen weiteren Sprint
  2. Eine Person gibt, die dafür sorgt, dass der Prozess gelebt wird und das Team immer besser wird.

Aufgabe: Wer übernimmt „nebenberuflich“ welchen Hut?

Fazit: agil geht für jedes Team

  1. Wir sind ein Fachteam und stellen nicht als erstes unsere Teams neu zusammen

Wenn wir uns unsere Zielgruppe und unser Werteversprechen klar machen, kann jedes Team agil für seinen „Abnehmer“ produzieren.

  • Unser Tagesgeschäft macht einen Großteil unserer Arbeit aus

Wenn wir lernen, was und wieviel unser Tagesgeschäft ausmacht, können wir es optimieren, priorisieren und gut planen, bzw. planen wieviel unserer Zeit für mittelfristige Tätigkeiten bleibt.

  • Wir haben mit vielen Externen zu tun und sind nicht autonom

Alle externen Termine und Abhängigkeiten landen in der Roadmap/Backlog und können als Tasks erfasst werden. Sie müssen nach wie vor auf der Agenda bleiben.

  • Bei uns laufen immer mehrere Projekte parallel.

Ein Team, ein Werteversprechen. Mehrere Projekte sind kein Problem. Wenn wir ein Team werden, sind all diese Projekte alle unsere Projekte.

Also: agil geht für jedes Team, auch wenn es erstmal nach dem Scrum-Schulbuch nicht danach aussieht.

Weiterführende Artikel


Wie hilfreich war dieser Beitrag?

Klicke auf die Sterne um zu bewerten!

Durchschnittliche Bewertung 4.8 / 5. Anzahl Bewertungen: 6

Bisher keine Bewertungen! Sei der Erste, der diesen Beitrag bewertet.

Neues per E-Mail?