Komplexität von Projekten beurteilen

Ist ihr Projekt zu spät dran? Dann haben Sie wohl ein Versprechen gemacht, dass Sie nicht halten konnten.

Fixe Kosten bei fixer Qualität, fixem Umfang und fixem Termin kann funktionieren, wenn das Projekt oder Produkt einfach genug ist. Leider machen wir es uns oft zu einfach: Wir scheren Projekte unterschiedlicher Komplexität über einen Kamm. Nach Schema F machen wir eine Analyse, wägen Optionen ab, entscheiden uns für die passendste Lösung und setzen sie dann um.

Dave Snowden liefert mit dem Cynefin Framework ein Modell, mit dem man über die Einordnung von Projekten differenziert nachdenken kann. Es kennt folgende Bereiche:

path828Einfach: Die Milch kocht über? Ich schalte den Herd aus und nehme den Topf von der heißen Platte. Über einfache Probleme muss man nicht lange nachdenken. Man erkennt das Problem, beurteilt es und reagiert. Es gibt in der Regel nur eine beste Lösung, die sogenannte Best Practice.

Kompliziert: Befindet man sich in einem komplizierten System, braucht man einen Experten. Springt mein Auto nicht an, lasse ich den Kfz-Mechaniker anrollen. Der gelangt mit oben genanntem Schema zum Erfolg: Er analysiert das Problem, wählt die passendste Lösung aus und setzt sie um. Schon hier gibt es keine Best Practice mehr, sondern nur noch Good Practices, Optionen die jeweils Vor- und Nachteile haben.

Komplex: Leider starten gerade viele große und innovative Softwareneuentwicklungs-Projekte in einem komplexen System. Es ist unvorhersehbar und instabil. Es gibt keinen Experten, der mit einer einfachen Analyse zum Erfolg kommt. Bewegt man sich in komplexer Umgebung, muss man Dinge ausprobieren, Experimente machen.

Chaotisch: Die Cynefin-Beispiele für den chaotischen Bereich sind bürgerkriegsähnliche Zustände oder Natur-Katastrophen. Erfolgreiches Vorgehen besteht in diesen Situationen im Stillen der Blutung durch klare Führung, also z.B. Ausgangssperren oder großflächige Evakuationen.

Selbstzufriedenheit: Manchmal wägt man sich im einfachen Bereich, in dem man alles unter Kontrolle hat und dann fliegt einem das System um die Ohren. Die Fukushima-Katastrophe wird hier als Beispiel genannt.

Unklarheit: Wenn man nicht weiß in welchem der Bereiche man ist, läuft man Gefahr die falsche Vorgehensweise zu wählen.

Die folgende Übung hilft, die Diskussion zu eröffnen, in welchen Systemen man sich bewegt. Ich führe sie mit meinen Kunden z.B. bei der Vorstellung von agilen Frameworks durch.

Als Basis für die Übung dient die Stacey Landscape Matrix, welche die vier Bereiche einfach, kompliziert, komplex und chaotisch anhand von zwei Achsen aufteilt, wie in der Abbildung gezeigt.

stacey

Die X-Achse beschreibt den Grad der Unsicherheit bei der Lösung, also z.B. inwieweit technische Herausforderungen bestehen, die so noch nie gelöst wurden. Die Y-Achse beschreibt den Grad der Uneinigkeit im Projekt darüber was umgesetzt werden soll. Je mehr Stakeholder und je größer die Meinungsverschiedenheiten, umso weiter verschiebt sich das Projekt nach oben.

Nun versucht man (z.B. in Kleingruppenarbeit) die laufenden und anstehenden Projekte oder Produkt-Entwicklungsvorhaben auf der Matrix zu verorten. Anschließend diskutiert man das Ergebnis. Im Bild habe ich vier Beispiele aufgezeigt.

Projekt IO könnte z.B. der Bau einer Elb-Philharmonie sein: Was am Ende herauskommen soll ist relativ klar, aber die bautechnischen Herausforderungen sind völlig neu. Landet das Projekt wie abgebildet im komplexen (roten) Bereich sind also keine genauen Voraussagen möglich, solange bis die Herausforderungen durch safe-to-fail Experimente gemeistert sind und der Rest des Projekts dann nur noch kompliziert ist.

Projekt Babylon ist von der Umsetzung und Technologie-Seite keine große Herausforderung, aber es gibt so viele Meinungsverschiedenheiten, dass diese soziale Komponente das ganze Projekt in den komplexen Bereich verschiebt. Auch hier sollte man nicht einfach durch-implementieren, sondern durch Prototypen Konsens über die gewünschte Art der Lösung herstellen.

Projekt OPUS („Ohne Plan und Sachverstand“) ist ein gigantisches Projekt mit immensen sozialen und technischen Herausforderungen. Es ist so unüberschaubar, dass es ans chaotische grenzt. Ehe man Millionen hinein versenkt, ist es wahrscheinlich besser das ganze in mehrere kleine Projekte zu zerschneiden bzw. sich auf einen kleinen Bestandteil zu fokussieren.

Manche Projekte sind gar nicht so kompliziert. Projekt 08-15 wurde schon tausendmal durchgeführt und birgt keine Überraschungen. Führt man hier aufwändig eine agile Vorgehensweise ein, schießt man wahrscheinlich mit Raketen auf Spatzen.

Die Diskussion ergibt oft, dass die Teilnehmer je nach Sichtweise die Projekte unterschiedlich einordnen. Das ist oft sehr lehrreich. Business Analysten unter- oder überschätzen technische Herausforderungen, Techniker unterschätzen Uneinigkeit und Unklarheit auf Anforderungsseite.

Wenn man regelmäßig vorab seine Projekte klassifiziert kann man nicht nur die richtige Vorgehensweise wählen, sondern auch versuchen die Projekte bewusst in bestimmte Bereiche zu verschieben. Z.B. könnte man im 08-15-Projekt eine neue Technologie ausprobieren, um das System zu erneuern oder auch um es für die gelangweilten Entwickler interessanter zu machen. Umgekehrt könnte man bei Projekten mit großen Herausforderungen auf Anforderungsseite darauf verzichten auch noch eine völlig unerprobte Technologie zu benutzen.

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Aber freitags sind wir freundlich!

Es ist schon kräftezehrend. Da muss man als Scrum-Master oder Team-Mitglied eines Scrum-Teams immer wieder Leute, die mit ihrem Anliegen in den Raum kommen, wegschicken. Man will ja schließlich ungestört und konzentriert an dem Sprint-Ziel arbeiten! Und daher wird ein Kollege oder eine Kollegin aus einem anderen Team mit ihrer fachlichen oder technischen Frage öfters mal schroff abgewiesen (es sei denn, es ist wirklich sehr wichtig).
Und dazu die enttäuschten, genervten oder wütenden Gesichter der so Abgewiesenen! Da nagt auch bei dem einen oder andern hartgesottenen Entwickler das schlechte Gewissen.
Das war dann letztendlich mit ein Grund dafür, dass in einem meiner Teams die Idee aufkam, dass man die Hilfesuchenden doch wenigsten an einem Tag der Woche nicht so schroff abweisen und sie im Gegenteil einfach mal freudig begrüßen sollte.

Damit war er geboren, der freundliche Freitag (oder wie wir sagen friendly Friday).

freundlicher_freitagAb sofort werden freitags „Eindringlinge“ fröhlich begrüßt – etwa mit einem von möglichst vielen gerufenen “Hey Holger, schön, dass du da bist! Juhhei!” Außerdem nimmt man sich im Team dann eher die Zeit, die Anliegen der Besucher in Ruhe anzuhören und ihnen dann, wenn möglich, auch zu helfen.
Am ersten Freitag, an dem wir das praktiziert hatten, waren sich viele Besucher nicht sicher, ob wir das ernst meinen. Aber mittlerweile entlocken wir diesen fast immer ein Lächeln. Es ging sogar so weit, dass ein Kollege nur in den Raum gekommen ist, um sich den wertschätzenden Begrüßungsruf abzuholen und anschließend den Raum mit einem Lächeln zu verlassen. Das trägt dann mit zu einem verbesserten Verhältnis zu anderen Teams bei.

Also, probiert es mal aus. Erfahrungen dürft ihr gerne in die Kommentare schreiben!

Responsibility Game

Sitzen Sie gerade in einem langweiligen Meeting? Oder arbeiten Sie an etwas, dessen Inhaltslosigkeit mit Vakuum vergleichbar ist?

Der Responsibility Process von Christopher Avery hilft dabei, Probleme auf positive Art zu lösen, indem wir unsere natürlichen inneren Barrieren erkennen und überwinden:

Stoßen wir auf ein Problem durchlaufen wir bis zu 7 Phasen, manchmal innerhalb von Sekunden, aber oft stecken wir Tage, Wochen oder gar Jahre in einer Phase fest.

Beispiele helfen, um den Prozess plastisch zu machen. Nehmen wir hier also an wir hätten ein wichtiges Vorstellungsgespräch und müssten um 7 Uhr morgens aufstehen um pünktlich zu kommen.

wecker

Problem: Wir wachen auf, blicken auf den Wecker und sehen die leuchtenden Ziffern: 08:00 – eine Stunde vorher wollten wir spätestens aufstehen …

DENIAL: Der erste Impuls ist in der Regel das Leugnen der Situation: „8 Uhr? Das kann nicht richtig sein!“ Wahrscheinlich stehen wir trotzdem senkrecht im Bett und das Herz schlägt 180.

LAY BLAME: „Schaaatz! Du hast den Wecker falsch gestellt!“ Avery vermutet, dass die Schuldzuweisung an andere in unseren Gehirnen fest verdrahtet ist. Vielleicht brachte das in Urzeiten die entscheidende Millisekunde bei der Abwehr von Feinden?

JUSTIFY: In dieser Stufe gibt man nicht mehr anderen Personen die Schuld, sondern den Umständen. „Der Wecker ist kaputt.“ oder „Es war wohl wieder Stromausfall.“

SHAME: Wenn man beginnt den Fehler bei sich selbst zu suchen ist man einen wichtigen Schritt weiter, die Stufen bauen aufeinander auf. Der Fokus der Gefühlswallungen verlagert sich von externen Verursachern auf interne. „Ich Idiot hab den Klingelton abgestellt.“

OBLIGATION: Ab dieser Phase kommt man schließlich ins Handeln. Man springt auf, macht Katzenwäsche, hüpft in den Anzug und rast erst zum und dann mit dem Auto, überschreitet die Geschwindigkeitsbegrenzung, parkt im Halteverbot und versucht irgendwie doch noch pünktlich zu kommen. Zeichen dieser Phase ist, dass es einem dabei schlecht geht. Man versucht seiner Verpflichtung nachzukommen, weil man den Erwartungen anderer entsprechen will. Wahrscheinlich hadert man noch im Vorstellungsgespräch mit sich und kann sich nicht zu 100% einbringen.

QUIT: In diese Phase flüchtet man sich, um Shame und Obligation aus dem Weg zu gehen. Man nimmt den Wecker vom Strom und verkriecht sich unter sein Kopfkissen und versteckt sich vor dem Problem.

RESPONSIBILITY: Erst in dieser Phase übernimmt man nach Averys Modell aktiv Verantwortung. Man lotet Optionen aus und entscheidet sich für die Option, mit der man das beste Gefühl hat. Die Last fällt von einem ab und man kann sich wieder zu 100% engagieren. Je nach Person und Situation kann die Lösung sehr unterschiedlich aussehen, in unserem Fall entschuldigt man sich vielleicht telefonisch und vereinbart einen neuen Termin.

responsibility process

Responsibility Game

Auf dem it-agile Partnertag schlug Ute vor, sich Gedanken zu machen, wie man den Prozess spielerisch erlernen könnte. Hier das Regelwerk (mit ein paar eigenen Ergänzungen):

Spieler: 4-8
Material:

  • 2 Sets mit 7 Karten auf denen jeweils der Name einer der sieben Phasen des Prozesses steht.
  • Klebe-Zettel oder Karteikarten und Stifte

Ablauf:

  1. Einer der Spieler übernimmt die Rolle des „Verantwortlichen“. Er mischt das erste Set der 7 Karten und teilt sie verdeckt an seine Mitspieler aus. Jeder kriegt eine Karte. Bleiben Karten über, werden diese verdeckt zur Seite gelegt.
  2. Jetzt denkt sich der „Verantwortliche“ ein Problem aus oder nimmt am Anfang einfach das oben beschriebene und schildert es den Mitspielern.
  3. Die Mitspieler denken sich einen Kommentar oder Gedanken aus, der zu dem geschilderten Problem und der auf ihrer Karte beschriebenen Phase passt und schreibt diesen auf einen Klebe-Zettel. Beispiel: Steht auf der Karte LAY BLAME und das Problem ist „Du stehst vor dem Auto und hast keinen Autoschlüssel“ könnte der Spieler auf seinen Klebe-Zettel schreiben „Meine blöde Schwester hat mir den Autoschlüssel nicht wiedergegeben.“ Jeder legt nun seinen Zettel für die anderen lesbar vor sich aus.
  4. Der „Verantwortliche“ muss nun erraten, in welche Phasen die Kommentare gehören. Dazu kriegt er das zweite Set an Phasen-Karten und ordnet jedem Mitspieler eine Karte zu. Dabei sollte er seine Gedanken laut aussprechen, damit die anderen nachvollziehen können was und warum er eine Zuordnung macht.
  5. Hat der „Verantwortliche“ alle Karten Zetteln zugeordnet drehen die Mitspieler ihre verdeckten Karten um. Diskutiert Abweichungen und die Gedanken dahinter.
  6. Für jede richtige Zuordnung kriegt der „Verantwortliche“ einen Punkt.
  7. Jetzt wird der nächste Spieler „Verantwortlicher“ und denkt sich ein neues Problem aus. Es geht wieder bei Schritt 1 los.

Wer die meisten Punkte hat ist Sieger. Wer den Prozess durch das Spiel besser versteht hat gewonnen ;-).

Das Buch von Christopher Avery wurde mittlerweile auch auf Deutsch übersetzt (LINK)*. Es gibt einen historischen Abriss und erklärt die einzelnen Phasen ausführlich und mit vielen Beispielen.

holger

Holger Tewis ist Agile Enterprise Coach (Freiberufler)

Nordstern Board – True North visualisieren

Schon die Wikinger haben den Polarstern zur Navigation genutzt. Agile Teams können das jetzt auch ;-).

Nordsterne helfen selbst-organisierten Teams ihre Fähigkeiten im Sinne der Organisation zu verbessern. Im Gegensatz zu klassischen Unternehmenszielen wie „Steigerung des Umsatzes um 20%“ oder „Verdopplung der Page Impressions“ fokussieren Nordsterne auf die Fähigkeiten der Organisation bzw. deren Mitarbeitern und Teams. Beispiele für Nordsterne aus der Praxis:

  • Jede Tätigkeit ist wertschöpfend
  • Jeder macht Vertrieb
  • Zero Bugs
  • Alle Teams sind vollständig autonom

Wie man schnell erkennt, sind Nordsterne in der Regel nicht erreichbar. Aber sie geben eine Richtung vor, mit der Mitarbeiter das eigene Handeln verändern können. Orientiert sich ein Team z.B. am Nordstern „Jede Tätigkeit ist wertschöpfend“ und stellt in der Retrospektive fest, dass sehr viel Zeit im letzten Sprint durch wiederkehrende manuelle Schritte beim Deployment verschwendet wurden, könnte eine Maßnahme für den nächsten Sprint sein, diese Schritte zu automatisieren. Solche konkreten Maßnahmen nennt man Target Conditions. Sie sollen nach wenigen Wochen, z.B. nach einem Sprint erreicht werden und überprüfbar sein.

Bei Tchibo haben wir im Rahmen eines Pilot-Teams Nordsterne eingeführt und dafür neben unserem Kanban-Board ein eigenes Nordstern-Board erarbeitet.

Norstern Board

Ziel dieses Boards ist es, nicht nur die Team-bezogenen vier Nordsterne dauerhaft transparent gegenüber Teammitgliedern und Stakeholdern zu machen und für den nötigen Fokus darauf zu sorgen, sondern auch den Fortschritt im Sinne eines Information Radiators zu verdeutlichen.

Der Aufbau des Boards folgt einer einfachen Tabelle, bei dem jede Zeile für einen der vier Nordsterne des Teams steht; damit folgt das Prinzip einer Swimlane-Logik und wird zusätzlich durch eine Farb-Codierung unterstützt, denn jeder Nordstern hat seine eigene Farbe. Die Spalten der Tabelle auf dem Board folgen einer Ableitung der Demig-Kreis Phasen „Plan-Do-Check-Act“:

  • Plan: Die Plan-Spalte beinhaltet jeweils eine oder mehrere Target Conditions, die sich das Team in zweiwöchigen Iterationen passend zum Nordstern selbst-organisiert ableitet.
  • Do: Die Target Conditions werden in die Do-Spalte gezogen, sobald die Arbeit an der Maßnahme beginnt. In einigen Fällen entstehen aus einer Target Condition auch zusätzliche kleinere Tasks, die ebenfalls in der Spalte sichtbar gemacht werden können.
  • Check: Am Ende jeder Iteration findet als Teil der Reflexion eine Überprüfung hinsichtlich der Erreichung der Target Conditions durch das Team statt. In Abhängigkeit der Ergebnisse werden in dieser agilen Zeremonie dann auch gleich die Target Conditions für die nächste Iteration festgelegt (Act).
  • Progression: Anstatt einer Spalte „Act“ hat sich das Team für eine ergänzende Spalte „Progression“ entschieden. Anhand von gemeinsam im Team verabschiedeten Metriken zur Messung, wird der Fortschritt in Richtung der Nordsterne transparent, fördert Commitment und Zusammenarbeit.
    Als zusätzliche Information werden auf dem Board der übergeordnete Arbeitsauftrag des Teams sowie die Erreichungsgrad der Target Conditions über alle Iterationen hinweg dargestellt.

Fazit:

Für das Team hat sich das zusätzliche Board als hilfreiches Tool zur konsequenten Navigation gen Nordsterne gut etabliert. Regelmäßig sind wir am Board folgende Fragen durchgegangen:

  • Was haben wir zuletzt erreicht?
  • Was wollen wir als nächstes erreichen?
  • Stehen unsere Maßnahmen immer im Fokus unseres übergeordneten Arbeitsauftrages?

Durch die physische Visualisierung und die ritualisierte Auseinandersetzung des Teams mit den Fragen finden agile Werte wie z.B. Transparenz, Kollaboration, Workflow, Verbesserung und Vereinbarung praktischen Einzug bei Tchibo.

Theda Howaldt ist Agile Coach bei Tchibo

 

 

 

 

holgerHolger Tewis ist Agile Enterprise Coach (Freiberufler)

Pipeline – ein Teambuilding Spiel

playday2018-header

Letztes Jahr konnte ich leider nicht dabei sein, aber dieses Jahr habe ich ihn mir nicht entgehen lassen: Der Agile by Nature Play Day will für die tägliche Arbeit spielerische Formen finden und fördern, um beim Lernen zu helfen. 24 Spielwillige trafen sich in den Räumen von sitegeist in Hamburg, stellten sich gegenseitig Spiele vor und networkten über kalten Getränken. Bilder von dem Tag gibt es auf der Webseite von Agile by Nature zu sehen.
Von den vielen interessanten Sessions stelle ich hier als erstes ein Spiel aus der Session „Teambuilding Spiele“ von Hendrik vor.

Pipeline
Bei Pipeline geht es darum, im Team eine rollende Kugel in ein Ziel zu befördern. Dazu bekommt jedes Team einige Rinnen. Die Anzahl variiert mit der Anzahl der Teammitglieder. Es sind immer deutlich weniger Rinnen als Mitspieler. Das Team muss schnell und geschickt Rinne an Rinne reihen, während die Kugel durch diese rollt. Leider ist die Gesamtlänge aller Rinnen kürzer als die zu überwindende Strecke …

Es gibt die folgenden einfachen Grundregeln:

  • Die Kugel muss jederzeit vorwärts durch eine Rinne rollen.
  • Kein Teilnehmer darf die Kugel berühren.
  • Eine Rinne darf nur von genau einem Team-Mitglied gehalten werden.
  • Wenn jemand eine Rinne mit der Kugel in der Hand hat, dann darf diese Person sich nicht mit der Rinne im Raum bewegen.

Material:

  • Mehrere Rinnen (z.B. Regenrinnen aus dem Baumarkt)
  • Eine Kugel, die in die Rinne passt

Lernziel ist es, dass sich das Team koordinieren muss, um die Kugel ins Ziel zu bringen. Die Kugel kann alles mögliche repräsentieren, z.B. ein Software-Artefakt, das erstellt und deployed werden soll.
Das Spiel lässt sich leicht an den jeweiligen Kontext anpassen, z.B. durch Hinzufügen oder Anpassen von neuen Regeln oder durch Aufteilung in mehrere Teams, die gegeneinander antreten müssen. Auch die Aufgabe kann angepasst werden, z.B. indem ein Team mehrere Kugeln ins Ziel bringen und deren Durchlaufzeit kontinuierlich reduzieren muss.
Eine weitere Variationsmöglichkeit ergibt sich durch die Art des Zielbehälters. In unserem Fall war dies eine flache Plastikbox. Das hat den Schwierigkeitsgrad erhöht, da die Kugel leicht über das Ziel hinausschießen kann. Eine breite Tonne oder ein Eimer als Ziel wäre meiner Meinung nach einfacher gewesen.

Hier eine Aufnahme von einem unserer grandiosen (Fehl-) Versuche:


Mein Fazit zum Play Day

Der Play Day ist eine super Veranstaltung, auf der man viel lernt und neue Bekanntschaften macht.

playday2018-fun

Besonders empfehlenswert ist er für Agile Coaches und solche, die es werden wollen. Im kommen Jahr will ich unbedingt wieder dabei sein und möglichst ein eigenes Spiel vorstellen. So kann man in freundlicher Umgebung die Moderation eines Spiels üben, bevor man es am eigenen Team ausprobiert.

Also, einen Daumen hoch für die Veranstaltung!

Ich werde in ein, zwei Blog Posts noch weitere Spiele vorstellen, die ich kennenlernen durfte.

Stakeholder Adoption Matrix für Agile Transitionen

Die meisten Transitionsbemühungen scheitern an Menschen. Sie sind uneinsichtig, veränderungsresistent und boykottieren jede gute Initiative…

… oder nicht? Wollen sie vielleicht nur richtig abgeholt werden, verstehen was eine Veränderung bringt und angemessen mitgestalten?

Natürlich gibt es in jeder Organisation Zauderer, die am Status Quo festhalten, als seien ihre Füße darin einbetoniert. In der Regel ist aber die Höhe der Aufgeschlossenheit und Bereitschaft zur Veränderung unterschiedlich und konstant breit verteilt. In seinem Buch “Diffusion of Innovations“ beschreibt Everett Rogers die vielen bekannte Adoption Curve.

adoption curve

Rogers unterteilt fünf Gruppen von Personen, die durch unterschiedliche Kommunikationsreichweite und Meinungsführerschaft die Verbreitung von Innovationen auf verschiedene Art fördern bzw. bremsen:

  • Innovatoren springen sofort begeistert auf die neue Idee auf.
  • Early Adopters sind respektierte Personen und Meinungsführer, die etwas vorsichtiger sind, aber dennoch offen für Neues.
  • Die bedächtigere, aber immer noch überdurchschnittlich hohe Bereitschaft zur Innovation zeigende Mehrheit der Leute wird Early Majority genannt.
  • Die Late Majority besteht aus skeptischen Personen, die erst anfangen etwas zu benutzen, wenn die Mehrheit dies bereits tut.
  • Die Laggards (Zauderer) sind die letzten. Sie halten bis zum Schluss an alten Gewohnheiten fest, äußern Kritik oder bekämpfen eine Veränderung sogar aktiv. Sie springen erst auf, wenn die Innovation bereits Mainstream ist.

Die Gruppen müssen auf unterschiedliche Weise angesprochen werden und das Modell kann dabei helfen die richtige Botschaft und Methode auszuwählen um den jeweiligen Personenkreis optimal zu adressieren.

Rogers hat bereits vor 55 Jahren über Diffusion of Innovation geschrieben und mittlerweile wurde sein Ansatz in vielen Untersuchungen und Arbeiten aufgegriffen. Jurgen Appelo ergänzt die Adoption Curve in seinem Buch „How to change the world“ z.B. um die Gruppe der Initiatoren, also der Change Agents selbst, die eine Innovation anstoßen.

Die Indiana University Bloomington hat eine Online-Simulation entwickelt, bei der man einen fiktiven Change an einer Schule durchführt, in dem man verschiedene Stakeholder beeinflusst. Man hat zwei Jahre Zeit den Change durchzuführen und investiert Kalenderwochen in Gespräche, Analysen über Einstellung und Kommunikationsnetzwerke (wer luncht mit wem) und findet dabei Schritt für Schritt heraus, wer von der Belegschaft eher Innovator oder Zauderer ist.

Eine andere Methode aus dem klassischen Projektmanagement ist die Projektumfeldanalyse, auch als Stakeholder Analyse bekannt. Dabei werden für ein Projekt relevante Stakeholder identifiziert und auf verschiedenen Dimensionen bewertet, z.B. ob sie Organisationsintern oder –extern sind, wie sie gegenüber dem Projekt eingestellt sind und wie viel Einfluss sie darauf haben. Dieses Modell soll helfen, alle Rahmenbedingungen, Einflüsse und äußere Faktoren zu sammeln, die auf das Projekt wirken können, um daraufhin geeignet Maßnahmen zu finden, wie man mit den jeweiligen Stakeholdern umgeht.

umfeldanalyse

Meine Beschäftigung mit beiden Methoden brachte mich auf die Idee sie in einem Workshop zu kombinieren. Nach einer Vorstellung der Adoption Curve bat ich die Teilnehmer relevante Stakeholder in die 5 Gruppen einzuordnen. Dann begannen wir weitere Dimensionen abzuklopfen. Für den nächsten Workshop habe ich mir folgende Schritte überlegt:

  1. Sammeln von wichtigen Stakeholdern als Post-Its. Je nach Einstellung der Stakeholder zur Transition auf grünen, blauen oder roten post-its.
  2. Vorstellung der Adoption Curve (Flipchart/Whiteboard)
  3. Erste Einordnung der Stakeholder in die 5 Adoption Gruppen, in dem die Post-Its darunter gehängt werden. Grüne Post-Its hängen wahrscheinlich weiter links, rote weiter rechts.
  4. Sortieren der Stakeholder in jeder Gruppe danach, wieviel Einfluss sie auf die Transition nehmen (können).

Das ganze sieht dann zum Beispiel so aus:

adopter stakeholder matrix

Im fünften Schritt überlegt man sich Maßnahmen. Dabei können folgende Leitpunkte helfen:

Finde die Personen, die als erstes eingebunden werden müssen. Durch die in der Adoption Kurve enthaltene zeitliche Komponente (X-Achse) stehen frühe Helfer bei der Initiative auf der linken Seite. Dennoch kann es sein, dass man schon am Anfang besonders einflussreiche und negativ eingestellte Zauderer berücksichtigen muss und sei es um Schaden zu begrenzen.

Beurteile das Verhältnis des Geschäftsführers zur Transition. Im besten Fall ist er begeisterter Treiber und Unterstützer, der dem Wandel durch eigenes gutes Beispiel vorangeht. Im schlechteren Fall sieht er das ganze als Experiment und sich selbst als neutralen Beobachter. Dann ist die Frage auf wessen Rat er sich für die Beurteilung der Transition stützt. Wo stehen diese Personen in der Matrix?

Beurteile Menge und Art der Early Adoptors. Diese sind wichtig um die Kluft zur Early Majority zu überwinden, denn diese Gruppe von Personen ist zu groß, als dass man sie als Veränderungstreiber allein noch persönlich beeinflussen kann.

Über Feedback würde ich mich wie immer freuen.

holger-jpg

 

Holger Tewis ist freier Coach und Berater für Agile Transition

Alignment von agilen Teams

Dies ist der dritte Teil einer Beitragsserie, die sich mit der Notwendigkeit des Austarierens von Autonomie und Alignment bei agilen Organisationen auseinandersetzt.

Nach dem ersten Artikel, der sich auf die Frage fokussiert, warum das Gleichgewicht von Alignment und Autonomie wichtig ist und dem zweiten Artikel mit konkreten Beispielen für gelebte Autonomie, beschreibt dieser Blog Post nun Techniken, mit denen wir bei meinem Arbeitgeber CoreMedia  das Alignment der verschiedenen Teams sicherstellen.

Wie schon im vorhergehenden Beitrag erhebt auch dieser keinen Anspruch auf Vollständigkeit, sondern soll nur als Beispiel für mögliche Ausprägungen für andere dienen.

Regelmäßige Firmen-weite Präsentation der Unternehmensstrategie

Damit Alignment überhaupt funktioniert, muss klar sein, auf welches Ziel man sich ausrichtet. Dazu wird regelmäßig die Produkt- und Firmenstrategie an die ganze Firma kommuniziert und Unklarheiten und Anmerkungen diskutiert.

Ziel dieser Veranstaltung ist, dass jeder in der Firma das Ziel Nummer Eins kennt und sein Handeln entsprechend daran ausrichten kann.

Produktplanungsmeetings

Zu den Produktplanungsmeetings treffen sich bei CoreMedia nicht nur Product Owner und Product Manager quartalsweise, um darüber zu diskutieren, was demnächst von Entwicklungsteams gebaut werden soll. Es wirken dabei weitere Stakeholder aus anderen Bereichen der Firma mit und helfen so, das Produkt an der Unternehmensstrategie auszurichten. Für die nicht direkt an der Produktentwicklung beteiligten Stakeholder wird dabei auch klar, was alles nicht gebaut wird und wie es zu dieser Entscheidung kam. Dies ist genauso wichtig wie die Information über die geplanten Dinge.

 Review Meetings der Teams

Nach Scrum sind das Scrum-Team, dessen PO und vom PO eingeladenen Key-Stakeholder Teilnehmer der Sprint Review. Bei CoreMedia haben wir uns dazu entschlossen, dass alle Firmenmitglieder Stakeholder sind, und laden deshalb auch prinzipiell die ganze Firma dazu ein. Naturgemäß ist der Teilnehmerkreis viel kleiner als die Anzahl aller Mitarbeiter, aber immer noch größer als der vom Scrum Guide ursprünglich angedachte Teilnehmerkreis.
Die Review-Meetings dienen vor allem der Präsentation von Ergebnissen und dem Einsammeln von Feedback. Es dürfen aber auch Zwischenstände gezeigt werden, wenn das Feedback dazu für die Entwickler wichtig ist oder die Information darüber, dass es Änderungen geben wird, wichtig für andere Teams ist. Durch die breite Aufstellung entstehen aber auch viele Punkte, die das Alignment mit anderen Teams (auch Nicht-Entwickler-Teams) fördern.

Team-übergreifende Retrospektiven

Ein wichtiger Mechanismus, mit dem man Alignment zwischen mehreren Teams herstellen kann, sind Team-übergreifende Retrospektiven. Immer dann, wenn mehrere Teams gleichzeitig in gemeinsamen Bereichen arbeiten, besteht u.a. die Gefahr, dass aufgrund fehlender Kommunikation oder Missverständnissen mehrere Lösungen für dieselben technischen Probleme gebaut werden, unterschiedliche Architekturmuster angewendet werden oder sich die Teams in  ihren Prozessen in die Quere kommen. In diesen Fällen ist es die einfachste Lösung, zu einer Team-übergreifenden Retrospektive einzuladen, bei der die Teams sich auf gemeinsame Vorgehensweisen einigen können. Dazu werden alle oder einige Team-Mitglieder der beteiligten Teams eingeladen und von einem Moderator durch eine klassische Retrospektive geführt.

Product Owner Collaboration Day

Um mehr Alignment zwischen den einzelnen Product Ownern der Teams sowie der Product Managern herzustellen, treffen sich diese regelmäßig 1-2 Mal die Woche zum Arbeiten in einen großen Raum. Sonst sitzen die POs bei ihren Teams.
Es gibt in der Regel keine vorgegebene oder im Vorwege festgelegte Agenda. Stattdessen finden Gespräche zu Themen spontan statt. Viele Synergien zwischen Aufgaben/Stories der Teams sind in diesen Meetings schon aufgedeckt worden.

 Interne Open Spaces

Bei CoreMedia halten wir regelmäßig firmen-weite Open Spaces ab, bei denen der Firmenvorstand mit konkreten Fragestellungen an die Belegschaft geht. Dies dient neben der Arbeit an Problemen oder Aufgaben auch der Festigung des Verständnisses der Firmenstrategie.

Communities of Practice

Wenn Teams alleine, über die Grenzen von technischen Modulen hinweg, Features implementieren, besteht der Bedarf  zur Koordination zwischen Teams. Hierfür sind bei CoreMedia Communities of Practice (CoP) eingeführt worden. In diesen werden die unterschiedlichsten Themen über Team-Grenzen hinweg diskutiert. Die CoPs bilden sich aus Vertretern einzelner Teams. Für einige CoPs gibt es die von der Leitung der Produktentwicklung vorgegebene Rahmenbedingung, dass aus jedem Team mindestens ein Vertreter entsandt werden muss.

Viele gemeinsame Events

Das meiner Meinung nach Wichtigste für Alignment: viel miteinander reden. Dazu haben wir große und kleine Events. Das geht von gemeinsamen, Team- und Abteilungs-übergreifenden Lunch-Terminen über gemeinsame Sportgruppen bis zu den großen Firmenfeiern. Das wichtige dabei ist die Vernetzung über Team- oder Abteilungsgrenzen hinweg.

Newsletter

Regelmäßige, firmenweite Newsletter von Abteilungsleitern oder der Geschäftsführung sind ein weiteres Mittel, um Alignment über Wissensverteilung herzustellen. Diese Möglichkeit wird trotz der vielen Austausche auf der persönlichen Ebene regelmäßig genutzt und auch gut angenommen.

 

Die vielen einzelnen Methoden, Praktiken und Techniken zahlen gemeinsam darauf ein, dass wir bei CoreMedia Kunden-orientiert und agil arbeiten können, ohne die gemeinsame Ausrichtung zu verlieren.