Erfahrungsbericht: Lean Agile Transformation

Abteilung mit 12 Mitarbeitern

Mandatsdauer von Februar 2018 bis Juli 2018

Ablauf in sechs Phasen
1) Einführen von Iterationen / Takt
2) Erwartung von Aussen weiterhin bedienen
3) Vor-Sondierungs-Phase
4) Start-Setup
5) Offizieller Start mit Consulting-Unterstützung
6) KPI based KVP in Selbstorganisation

1) Einführen von Iterationen / Takt

Anfänglich hat der Abteilungsleiter der Abteilung begonnen, zusätzlich zum bestehenden Setup mit Projekten/Produkten, zu Takten und Iterationen einzuführen. Mit der Zeit entflochten wir die Aufgaben, Rollen und Verantwortlichkeiten von Projekten, Produkten und Iterationen vollständig.

Wo wir Iterationen einführen, also mit iterativ inkrementellem Arbeiten beginnen, sind wir völlig frei und offen. Das kann in der Produktentwicklung sein, kann in spezifischen Projekten sein, oder auch einfach in der Abteilung. Auch das Leadership-Team für Linien-Aufgaben bietet sich dafür an, ganz im Sinne von „Sei ein produktives Vorbild“, ist doch der wöchentliche Meeting-Takt normalerweise bereits existent, die Aufgaben- und Pendenzen-Verwaltung und -Verfolgung erfahrungsgemäss jedoch weniger professionell als in den Projekten, und der kontinuierliche Verbesserungsprozess in der Regel noch einzuführen.

2) Erwartung von Aussen weiterhin bedienen

Durch die vollständige Entflechtung der Aufgaben, Rollen und Verantwortlichkeiten von Projekten, Produkten und Iterationen wird uns auch sehr klar, warum wir das eine oder andere tun, oder eben tun müssen, um den Erwartungen, die an uns gestellt werden, gerecht zu werden. Dies sind zum Beispiel:
2.1) Projekt-Reporting ans Management
2.2) Einhalten vor Regulatorien: DQ, IQ, OQ
2.3) Einhalten von aktuell gültigen SOP/PDP

Wenn wir die Erwartungen von Aussen nach wie vor erfüllen, haben wir Innen einen geschützten Raum, um unsere neuen Arbeitsweisen zu erfahren und zu verbessern, bevor wir ans Aussen treten, und gleiches erwarten.

3) Vor-Sondierungs-Phase

Anfänglich haben wir mehrere Iterationen gefahren, die vor allem dazu dienten, Liefergelegenheiten wahrzunehmen, auch um als Abteilung besser/zuverlässiger wahrgenommen zu werden, und um Projekte endlich abzuschliessen, um den Work in Progress und dadurch die parallelen Verpflichtungen zu reduzieren. Dabei haben wir in Kauf genommen, dass wir auch die Teams bezüglich Zusammensetzung optimal auf die jeweiligen Iterationsziele ausrichten. Wechselnde Team-Zusammenstellung pro Iteration ist gar nicht im Sinne von Agile und Scrum, hatte aber den weiteren Vorteil, dass wir beobachten konnten, wer mit wem gut zusammenarbeiten konnte, wer welches Mindset hat, wer wie mit Veränderungen umgeht, und wer in welcher neuen Rolle funktionieren könnte, bzw. schon entsprechende Verantwortung übernimmt und dafür brennen könnte. Auch konnte sich jeder Einzelne ein Bild davon machen, wie seine Zukunft aussehen könnte. Einzelne haben auch erkannt, dass sich ihre Rolle, in der sie vorher funktionierten, so verändert, dass für sie etwas Wesentliches verloren geht, weil zum Beispiel ein Projektleiter nur die Bedürfnisse von aussen bedient, selber aber keine eigenen Projektmitarbeiter hat, weil die eigentliche Arbeit neu in Scrum Teams erledigt wird.

4) Start-Setup

Für das Start-Setup haben wir die Scrum Teams so aufgestellt, dass jegliche Arbeit für die Iterationen bzw. für die Sprints über Backlogs in die Teams kommt. In der folgenden Übersicht ist folgendes ersichtlich:
4.1) Jegliche Bedürfnisse werden in Backlogs gepflegt.
4.2) Jegliche Bedürfnisse werden durch die Stakeholder vorpriorisiert.
4.3) Für die Iterationen erfolgt eine Vorbereitung, gemäss einer «Definition of Ready» [DoR].
4.4) Die eigentliche Umsetzung erfolgt in Teams, gemäss einer «Definition of Done» [DoD].

Für das Start-Setup haben wir die Rollen Product Owner, Scrum Master und Test Engineer mit Personen besetzen können, die bereits während der Vorbereitung zum ersten Sprint im neuen Setup für ihre Rolle zu brennen begannen, es kam richtiges Startup-Feeling auf.

Abbildung 4.1: Start-Setup bezüglich der Backlog-Struktur

5) Offizieller Start mit Consulting-Unterstützung (aktuelle Phase)

Nachdem das Zusammenspiel von Abteilung, Services, Projekten/Produkten und Iterationen erlebt werden konnte und die entsprechend funktionierenden Strukturen gefunden werden konnten, also ein durch die Beteiligten erarbeiteter Start-Setup entstand, ist der Zeitpunkt gekommen, um Nägel mit Köpfen zu machen und Scrum mit Consulting-Unterstützung einzuführen, ohne Gefahr zu laufen, dass die Organisation im Standard-Verfahren auf den Kopf gestellt wird.
5.1) Rollen ausbilden mit Zertifizierungen
5.2) Rollen im Doing coachen
5.3) Den Start-Setup professionell validieren

Diese aktuelle Phase ist heikel, weil wir die alte Arbeitsweise im alten Setup am Verlassen sind, aber die neue Arbeitsweise im neuen Setup noch nicht wirklich erlebt haben, und auch noch keine Erfolge auszuweisen haben, und in den neuen Rollen noch keine oder nur wenige Erfolgserlebnisse hatten. Bei den meisten wird sich die Frage stellen, ob der Weg, den wir am Einschlagen sind, wirklich der richtige ist und ob wir so funktionieren können. Also Verunsicherung und Zweifel an allen Ecken und Enden, und das in einem Umfeld, das mittlerweile auch mittbekommen hat, dass wir Veränderungen vorgenommen haben, und sich ähnliche Fragen stellt, und natürlich Erwartungen an uns hat.

Die oben gestellte Frage, ob wir auf dem richtigen Weg sind und ob das funktionieren kann, ist aus meiner Sicht die falsche Frage, denn sie gibt den Zweiflern und der Verunsicherung Raum, und das in dieser kritischen Phase.
Die besseren Fragen sind
– „Wofür brenne ich?“
und
– „Wo ist mein Platz im neuen Setup?“.

Jetzt gilt es das „Ding“ durchzuziehen und uns auf unsere Ziele zu konzentrieren, und alles zu tun, damit wir unsere Ziele erreichen und auch die Erwartungen von Aussen an uns bestmöglichst erfüllen, ganz im Sinne von „Gib anderen, was sie brauchen.“, nach Innen wie nach Aussen.

6) KPI based KVP in Selbstorganisation (geplant, noch im Aufbau)

Die Organisation ist nun fit um selber zu fliegen, und pilotiert mit mehrdimensionalen Backlogs und geeigneten Cockpits in Selbstorganisation basierend auf Kennzahlen (KPIs) einen kontinuierlichen Verbesserungsprozess (KVP) gemäss Scrum.

Wir wünschen viel Erfolg und Erfüllung

Wir wünschen viel Erfolg und Erfüllung auf dem eigeschlagenen Lean Agile Weg.

Das grösste Geschenk für die Abteilung ist aus meiner Sicht, dass wir Zeit und Raum für einen PDCA-Zyklus schaffen konnten, damit wir den aktuellen Start-Setup, die Prozesse und uns kontinuierlich verbessern können.

Wir wünschen der Abteilung und ihren Mitarbeitern viel Erfolg, dass dieses Vorhaben zum Fliegen kommt, und die Früchte tragen darf, die wir erwarten und erhoffen. Und dass die Mitarbeiter weiterhin den Raum und die Zeit zugesichert bekommen, mit derer sie ihre Prozesse, ihre Arbeitsumgebungen und sich selber so kontinuierlich verbessern können, damit sie mit Spass und Freude den Tätigkeiten nachgehen können, für die sie brennen, und so den Erfolg auch langfristig sichern.

Im Weiteren ist zu hoffen, dass dieses Vorgehen auch in anderen Abteilungen zur Anwendung kommt und zur nachhaltig erfolgreichen Praxis wird, und die bereits laufende Lean Initiative so auch die Entwicklungsabteilungen mit Agile bereichern wird.