Samstag, 27. Mai 2017
Seite auswählen

"Agile" macht ja nur Probleme, oder… — Transparenz muss gewollt sein

Ampelmann rot

Die einschneidende Wirkung einer öffentlichen → Impediment-Liste.

… neulich in einem mir bekannten Projekt …
(ein komprimierter Rückblick auf einen Projekt-Start mit Scrum [1] …)

Hintergrund:
In einem Finance Profit Center arbeiten in mehreren Abteilungen insgesamt ca. 45 Mitarbeiter in der Produkt-Entwicklung (→ CRM-Software), verteilt auf sechs Teams. Diese entwickeln gleichzeitig parallel an mehreren Standard- und Individual-Software-Produkten (Makler-Versionen).

Die bisherigen Projekte laufen im besten Fall „unrund“ [häufige Release-Verzögerungen]. Tatsächlich sind die letzten zwei Individual-Projekte gescheitert [jeweils mit Abbruch wg. erheblichen Kosten- und Termin-Überschreitungen] – Lösungen müssen her.

Transparenz-Angst ?

Die beiden verantwortlichen Bereichsleiter [BL] wählten als „Lösungsmittel“ – → natürlich – Scrum.

Der Auftrag lautete

„Wir wollen unsere Probleme mit Agilität lösen … und das ganz schnell … Scrum soll da ganz gut sein … bitte setzen Sie Scrum bei diesen beiden Teams ein“

und direkt nachgeschoben:

„Scrum darf aber nur bei diesen beiden Teams eingesetzt werden“

Genau bei diesen beiden Teams waren die eingangs erwähnten Projekte gescheitert … wirklich ? So sah es zumindest aus bzw. so wurde es fleißig „motivations-fördernd“ kommuniziert – und durch eben die BL nicht dementiert.

Scrum ist in dem Profit Center bisher nur auf der Ebene der Marketing-Begriffe bekannt. Auf meine Nachfrage nach den Scrum-Kenntnissen war der zuerst und immer wieder zitiere Begriff „Transparenz“ (bzw. „Transparenz, aber … !“ – in Anlehnung an → „Manifesto for Half-Arsed Agile Software Development“ ?). Im Konzern gibt es keine Erfahrungen mit Scrum im speziellen oder Agilität im allgemeinen.

Während der Sondierungsgespräche drängte sich körper-sprachlich bei der BL – neben einem Eindruck von Unsicherheit und Unbehagen – immer irgendwie auch Angst auf – Angst vor Transparenz?

Die ersten Schritte

Eingeladen und verteilt auf drei Scrum-Infoveranstaltungen wurden alle Teams, maßgebliche Stakeholder und Vertreter des Managements. Die Erwartungshaltung – nicht nur bei den beiden durch die BL ausgesuchten Teams – war sehr hoch. Deshalb musste im Eröffnungs- und den Folge-Workshops mehrfach klargestellt werden:

„Agile“ bzw. „Scrum“ löst keine Probleme, nicht mal triviale.
Menschen (!) lösen Probleme …
[… mit cleveren „Werkzeugen“ – intelligent eingesetzt …]

Eine Reihe von Workshops mit Ursachenanalysen und Herausarbeitung von Kommunikations-Schnittstellen aller Teams führten immer und immer wieder zu dem Kern-Thema

Fehlende Transparenz !

Einige der Ursachen, die rund um dieses Schlüssel-Thema geschildert wurden:

  • fehlende oder zu späte Kommunikation
  • unpräzise, unklare, teils sich widersprechende Vorgaben
  • bewusste Nicht-Kommunikation (Verteidigung von Komfortzonen)
  • Projekt-„Wissen“ liegt in unzähligen Excel-Tabellen bzw. in eMail-Archiven vergraben
  • veraltete Projektpläne
  • Es gibt keinen aktuellen Projekt-Überblick

[→ IMHO: agil oder nicht agil – genau ein „sichtbar machen“ bzw. „durchscheinen lassen“ (lateinisch transparens „durchscheinend“) führt zu einem „begreifbar machen“ der alltäglichen Situationen bzw. Aufgabenstellungen und einem „geordnet und vorteilhaft darauf reagieren können“ – aber genau die häufig anzutreffende gegenteilige Intransparenz bzw. Undurchsichtigkeit führt immer wieder zu den wohl bekannten Problemen]

Vision

Die Mitarbeiter der betroffenen Abteilungen entwarfen eine gemeinsame Vision:

höhere Motivation durch Transparenz
führt zu einer besseren Zusammenarbeit aller Beteiligten

Diese ersten Maßnahmen wurden vereinbart:

  • Scrum-Piloten installieren
  • Transparenz schaffen
  • Kampagnen als Basis für Offenheit und Vertrauen überlegen und durchführen …

Bei den Teams war überwiegend eine positive Grundstimmung spürbar. Die Maßnahmen wurden rege diskutiert und entwickelt.

Von der BL blieb der Eindruck, dass dort das Thema „Transparenz“ nur bedingt willkommen war. Berichte und Informationen an die – und nur an die – BL waren willkommen. Ansonsten wollte man die Fäden in der Hand halten („Command and Control“). Transparenz mit allen Konsequenzen und Chancen zuzulassen scheint noch ein langer Weg.

Transparenz schaffen – wie ?

Gemeinsam erarbeitet und abgesegnete Ergebnis-Elemente für „mehr Transparenz“ sind u.a.

  • öffentliches Impediment Backlog
  • ein(!) öffentliches Product Backlog (hier werden auch die „Aufträge“ der nicht „scrum’menden“ Teams aufgeführt)
  • Defects/Bugs als Stories
  • „Produkte“-Wiki
    von den Fluren aus einsehbar (Büros sind durch Glaswände separiert):

  • Story-Boards
  • BurnDowns (für Task, Business/Risk Value, Technical Debt)
  • „rote Karte“ [3]

Die erste umgesetzte „Transparenz“-Aktion war das öffentliche Impediment Backlog.

Alle Team-Räume liegen benachbart am Ende eines Hauptflures. Dort wurde auf einem großem Whiteboard das Impediment-Backlog und direkt oberhalb eine „Impediment-Ampel“ [2] platziert.

Die Ampel liegt „zufälligerweise“ so „günstig“, dass diese auch vom Zentral-Aufzug aus sichtbar ist.

Versuchsweise einigte man sich auf folgendes Regelset:

  • Jeden Morgen zeigt die Ampel zunächst „grün“
  • bei neuen Impediments wird diese auf „rot/grün-blinkend“ gestellt (in der Regel nach einem Daily)
  • besondere bzw. kritische Projekt-Situationen werden durch ein „rotes Blinklicht“ angezeigt (z.B. Build- oder Sprint-Abbruch)
  • bei nicht im vereinbarten Zeitrahmen gelösten Impediments wird die Ampel auf „rot“ gestellt

Der Status auf dem Whiteboard wird mindestens nach dem Daily aktualisiert.

Bereits diese erste Maßnahme wurde per eMail an alle Mitarbeiter im Unternehmen vorgestellt. Folge-Maßnahmen wurden angekündigt.

„Agile“ macht ja nur Probleme !

Für die Beteiligten meist erstaunlich (→ q.e.d.), für Insider erwartet (→ q.e.e.):

eine öffentliche Impediment-Liste bringt eine Menge Bewegung in die sonst häufig eingefahrenen und verkrusteten Strukturen – insbesondere mit der Ampel als „Katalysator“ und Eye Catcher an einer so exponierten Stelle.

Spannend, wie schnell sich ein „blinkender“ oder „rot“ Status als Lauffeuer durch die Abteilungen und das Unternehmen bewegten. Die „Impediment-Ampel“ wurde zum Dauer-Thema.

Von den Team-Mitgliedern konnte man vernehmen, dass die vielen Probleme und Problemchen endlich einmal Gehör fanden (auch an ganz unerwarteten „Stillen Örtchen“). Themen, die teils schon seit Jahren immer wieder angesprochen, aber nie umgesetzt wurden, hatten nun eine Plattform.

Allerdings fühlten sich auch einige Kollegen der noch nicht „scrum’menden“ Teams mit der inhaltlichen Transparenz der öffentlichen Impediment-Liste zunächst überrollt und teilweise überfordert. Hier musste mit zahlreichen begleitenden Maßnahmen und (Re-)Aktionen („inspect & adapt“) eine vertrauensvolle Atmosphäre geschaffen werden [3,4]. Ein nicht endendes Unterfangen.

Transparenz kann unbequem sein – sehr unbequem. Insbesondere die BL hatte so ihre Befindlichkeiten mit dieser neuen Art von Transparenz und Öffentlichkeit. Mit so schnellen und intensiven Reaktionen hatten sie nur bedingt gerechnet. → „Wassermelonen grün“-Meldungen oder z.B. einen Sprint-Abbruch zu „vertuschen“ wurden immer schwieriger [2].

Agile macht ja nur Probleme …“ oder „kaum seit ihr am Scrum’men, habt ihr schon Probleme …“ [5] waren – und sind teils immer noch – Anknüpfungspunkte für Gespräche, in denen sich die BL anfangs in eine Rechtfertigungsposition treiben liessen. Nach Aussage der BL verlagern sich die Gespräche nur langsam und mühsam auf gesamtheitliche und lösungsorientierte Aspekte.

Die durch diese Transparenz aufgezeigten Probleme als systemische Schwierigkeiten der Organisation und als Chance für Verbesserungen zu begreifen empfinden sie als einen noch langen, steinigen, aber inzwischen „richtigen“ Weg.

Lessons Learned

Die ersten Lern-Ergebnisse:

  • Transparenz kann brutal sein
  • „Transparenz muss gewollt werden“ [5]
  • es muss eine Transparenz-Kultur, ein Transparenz-Mindset gefördert werden
  • Transparenz und die sich daraus ergebenden Chancen muss in den Köpfen ankommen
  • Offentheit basiert auf Vertrauen und kann nicht diktiert werden
  • die Bereitschaft aus Problemen zu Lernen und Erkenntnisse abzuleiten, muss sich entwickeln
  • eine Einstellung „Fehler als Feedback, d.h. Fehler als etwas Positives sehen, als Chancen nutzen“, muss gefördert werden
  • die Beseitigung der häufig anzutreffenden [und leider erwarteten] „Fingerzeig-Mentalität“ benötigt Ausdauer
  • Scrum-Einführung nur in einem Teil des Unternehmens ist sub-optimal

und vieles weitere mehr !

 

Die Scrum-Reise geht weiter …

about "Boeffi" ...CU
@ Boeffi  .net     aktualisiert am 21.06.2015

 

 

[1] ein komprimierter Rückblick auf einen Projekt-Start mit Scrum: ein sehr komplexes Thema, das hier nur ausschnittweise, sehr lückenhaft, eher stichwort-artig dargestellt werden kann und viel Raum für weitere Beiträge lässt – aber wie immer, das Schreiben eines solchen Artikels ist für den Verfasser ein probates Mittel der Eigen-Reflexion und des Lernens

[2] eine Leihgabe aus einem anderen Projekt: → Ampelmann und → NET-PwrCtrl HOME – Ethernet gesteuerte Steckdosenleiste

[Die WebCam-Leihgabe – für die Intranet-Live-Übertragung des Impediment-Boards auf der „Produke“-Wiki-Startseite – wird derzeit von der BL blockiert]
Interessante Beiträge zum Thema „Transparenz“:

[3] Das Prinzip der roten Karte → wissen.harvardbusinessmanager.de/…

[4] White Noise – Ein Igel bändigt die Stimmen aus dem Hintergrund → klausleopold.com/…

[5] Agiles Versprechen: 1. Agilität führt zu Transparenz, auch über die Probleme. 2. Es wird einem nicht gefallen, was man dann sieht.
..und, es wird schnell sichtbar, ob Transparenz wirklich gewollt wird / der AgileCoach bei der „Reifung“ unterstützen muss/kann – siehe → conversation @henningwolf with @Boeffi

Medien- / Artikelbilder-Nachweis: Danke an und © siehe » 
Javier Vidal

1 Kommentar

  1. tural

    Die ersten Lern-Ergebnisse: – Ich kann Ihnen nur zustimmen.
    – Die Menschen merken relativ schnell, dass sie an den organisationalen Strukturen anfassen müssten, wenn die Projektlandschaft tatsächlich „agil“ funktionieren soll. Da ducken sich viele, da sie die Macht dazu nicht haben.
    – Wenn ich zu einem Betrieb gehe, stelle ich mich in die Teeküche, um mal zu lauschen, wie die Leut´ miteinander reden. Dadurch versuche ich erste Eindrücke von der Unternehmenskultur zu gewinnen. Gehen die Leut´ locker miteinander um, ist die Sprache charmant, da ist´s nicht mühsam, über Agilitätsstrukturen zu hirnen.

    Antworten

Trackbacks/Pingbacks

  1. “Agile” macht ja nur Probleme - oder … » Boeffi's "Denkräume" » cu @Boeffi .net - [...] in einem mir bekannten Projekt … (ein komprimierter Rückblick zu einem Scrum-Start [1] [...]

Kommentar absenden

Deine E-Mail-Adresse wird nicht veröffentlicht. Erforderliche Felder sind mit * markiert.