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.

Autonomie von Teams

In dem vorhergehenden Artikel habe ich geschrieben, dass ein Gleichgewicht von Autonomie und Alignment bei agilen Teams wichtig ist, damit man für eine Firma zu einem globalen Optimum kommt.

In diesem Beitrag geht es darum, wie wir bei meinem Arbeitgeber CoreMedia die Autonomie von Teams ermöglichen. Die Punkte sind nicht vollständig und sollen nur als Ideengeber dienen.

Warum Autonomie?

Autonomie von Teams ist essentieller Bestandteil von agilem Vorgehen. Dies ist übrigens auch wichtig für die Motivation von Wissensarbeitern (siehe https://www.scrumalliance.org/community/articles/2014/february/autonomy ), zu denen auch Softwareentwickler gehören.

Wichtiger noch ist, dass autonome Teams gerade wegen ihrer Unabhängigkeit schneller auf Veränderungen reagieren können. Auch werden Wartezeiten bei der Entwicklung von Produkten reduziert. Beides kann ein entscheidender Vorteil gegenüber der Konkurrenz sein.

Die Autonomie der Teams spiegelt sich bei CoreMedia in verschiedenen Dingen wider (der Schwerpunkt der Beschreibung liegt auf den Entwicklungsteams, ähnliche Prozesse gibt es auch bei anderen Teams):

Scrum und Kanban

Unsere Teams arbeiten nach Scrum, Kanban oder einer Kombination von beiden. Diese Vorgehensmodelle erfordern und fördern Autonomie in Form von Selbstorganisation. Teams sollen möglichst cross-funktional aufgestellt sein und möglichst viele Entscheidungen selbstständig treffen können. Insbesondere “Wie” etwas gebaut wird liegt im Entscheidungsbereich eines Teams.

Selbstorganisation

Viele Dinge wie zum Beispiel Sprintlängen, Gestaltung und Vorgehen beim Task-Board, allgemeine Prozesse und Meetingstrukturen werden von jedem Team individuell festgelegt. Auch Urlaube werden bei den meisten Teams nicht wirklich vom Vorgesetzten genehmigt, sondern ein Teammitglied, dass Urlaub machen möchte, schickt zunächst eine Mail mit dem Urlaubswunsch an sein Team. Wenn es hier keine Einwände gibt, wird die Verwaltung – wiederum durch das Teammitglied selbst – über den geplanten Urlaub informiert. Damit ist der Prozess abgeschlossen.

Cross-funktionale und Feature-Teams

Die Entwicklungsteams haben prinzipiell erstmal keine exklusive  Verantwortung für einzelne (technische) Komponenten des Produktes. Diese ergeben sich eher aus dem Wissen der Teammitglieder. Damit kann ein Team auch prinzipiell an vielen Bereichen des Produktes arbeiten und einzelne Features unabhängig von anderen Entwicklerteams quer durch viele unterschiedliche Komponenten implementieren. Dieses Vorgehen hat sich weitestgehend etabliert (außer für sehr komplexe Spezialthemen).
Aufgrund der Wissensverteilung und vorhandenen Kompetenzen für die Aufgaben ist es den Teams überhaupt erst möglich, autonom zu agieren.

Team-Infrastruktur für Continuous Integration

Die Entwicklerteams haben eigene Infrastruktur für Continuous Integration in Form von eigenen Jenkins-Servern und -Slaves. Die Konfiguration der Systeme und die Tests, die auf diesen sog. Pipelines ausgeführt werden, werden allerdings wieder global für alle verwaltet, um gemeinsame Qualitätsstandards sicherzustellen. Teams können davon zeitweilig abweichen, etwa um neue Technologien einzuführen. Änderungen fließen dann anschließend in die globale Konfiguration zurück. Dadurch können Teams an Infrastrukturthemen arbeiten, ohne dass dadurch gleich andere Teams betroffen sind.

Eigenständige Weiterbildung

Die Weiterbildung der einzelnen Teammitglieder wird eigenständig organisiert. Dies kann ganz verschiedene Ausprägungen haben. Ein Entwickler kann sich Slack-Time nehmen (siehe dazu etwa https://www.impulse.de/management/unternehmensfuehrung/slacktime/2178126.html oder https://www.scrum.de/portfolio-posts/slack-time-was-ist-das/ ), um sich selbstständig in ein Thema einzuarbeiten. Dazu kann sich jeder auch Bücher bestellen. Oder jemand darf – unter gewissen Rahmenbedingungen – eine Konferenz besuchen, die er oder sie interessant findet. Klassische (und zentral organisierte) Schulungen sind bei uns eher die Ausnahme. So entsteht Autonomie auf der Ebene der einzelnen Mitarbeiter.

Zeiterfassung/-abrechnung

In jedem Team gibt es eine vom Team beschlossene Art der Zeiterfassung. Zentrale Vorgabe ist nur, dass für bestimmte Themen die Aufwände erfasst werden, die in dem Team zu einem bestimmten Thema entstehen. Alle unserer Entwickler-Teams haben sich mittlerweile dazu entschieden, ihre Aufwände mit Hilfe von Lego-Steinen zu erfassen. Mehr dazu findet sich in einen früheren Blog-Post von mir: https://scrumburg.wordpress.com/2013/04/05/stein-fur-stein-zur-besseren-zeiterfassung/

Release Trains

Bei CoreMedia verwenden wir eine Art von  Release Trains (https://en.wikipedia.org/wiki/Software_release_train) für verschiedene Versionen unseres Produkts. Der Zeitplan dieser ist unabhängig von den Sprintlängen/-enden der Teams. Damit released ein Team am Ende eines Sprints die Software nicht unbedingt. Wichtig ist nur, dass am Ende eines Sprints Dinge fertig werden und prinzipiell einsetzbar/releasebar sind. Dasselbe gilt für Teams, die eher nach Kanban arbeiten.
Release Trains fördern einerseits die Autonomie von Teams, die dadurch selbständig entscheiden können, mit welchem Release-Train sie ihr Feature veröffentlichen wollen. Es entsteht weitere Entkopplung, da sich Teams mit dem Releasen von Stories und anderen Dingen nicht unbedingt mit anderen Teams abstimmen müssen. Weitere Autonomie würde durch die Fähigkeit, selbst Software in Produktionsumgebungen zu releasen, entstehen. Dies ist bei SaaS-Firmen durchaus üblich, im Umfeld von On-Premise-Produkten eher schwierig umzusetzen.

Andererseits sind Release-Trains aber auch ein Mittel, mit dem man die Arbeit von Teams wieder zusammenbringen, bzw. alignen kann.

Wie bereits im vorhergehenden Beitrag beschrieben, reichen autonome Team alleine nicht aus, sondern es muss ein Gleichgewicht zwischen Autonomie und Alignment geschaffen werden. In dem nächsten Blog-Beitrag geht es dann abschließend darum, wie wir bei CoreMedia das Alignment sicherstellen.

Agilität, Autonomie und Alignment – Passt das Zusammen?

Das Agile Manifest beschreibt Werte, die als Grundlage für agiles Arbeiten in der Softwareentwicklung dienen. Die im Manifest beschriebenen Werte werden durch 12 Prinzipien ergänzt, die als Leitsätze für die agile Arbeit dienen.  

Längst hat sich dieser Ansatz auch außerhalb von Entwicklerteams herumgesprochen. Doch was bedeutet Agilität für die Arbeitsorganisation von Teams? Stefan Roock fasst dies sehr treffend wie folgt zusammen:

„Agilität  bedeutet Autonome Teams mit Business-Fokus, die ihren Prozess in Besitz und Verantwortung nehmen.“ 

Das heißt, agile Teams sollen möglichst autonom agieren können. Dies ist schön und gut für einzelne  Teams, reicht aber nicht, wenn man Agilität skalieren möchte, also mehr als ein Team agil an einem gemeinsamen großen Produkt arbeiten lassen möchte.

Lokale vs. Globale Optimierung

Wenn man einfach nur viele autonome Teams arbeiten lässt, dann werden diese Teams mit Hilfe von Techniken aus ihrem Agilen Werkzeugkasten kontinuierlich an der Optimierung ihrer Prozesse arbeiten. Dies ist erst mal gut und gewünscht. Es besteht aber die Gefahr, dass man am Ende viele (Team-) lokale Optima hat, die durchaus in Konkurrenz zueinander stehen können und so bei der Organisation insgesamt zu einem Verlust von Business-Fokus führen. Die Frage ist auch ob die Teams dann noch der Firmenstrategie oder einer gemeinsamen Produktion folgen oder eigene, entkoppelte Ideen zu diesen Themen verfolgen.

Was fehlt, ist die eine einheitliche Ausrichtung auf ein gemeinsames, großes, ja Unternehmens-weites Ziel hin. Dies wird als Alignment bezeichnet.

Um ein globales Optimum für eine Firma zu schaffen, muss man daher ein Gleichgewicht aus Autonomie und Alignment der agil agierenden Teams schaffen.

Wie macht man das praktisch?

Die Idee, Autonomie und Alignment, zu kombinieren um bessere Produkte zu schaffen, ist nicht unbekannt. Henrik Kniberg, zum Beispiel,  beschreibt in einem Video über Spotifys Engineering Culture  den Zusammenhang zwischen Autonomie und Alignment.

Kniberg geht dabei so weit, dass er sagt, dass ein hohes Alignment größere Autonomie in den Entwicklungsteams ermöglicht.

In dem vorhergehenden Beitrag von Holger beschreibt dieser, wie wichtig Alignment bei einer agilen Transition ist.

In je einem weiteren Beitrag werde ich schildern, mit welchen Techniken und Prozessen wir bei meinem Arbeitgeber CoreMedia Autonomie und Alignment ins Gleichgewicht bringen.

Struktur eines agilen Transitionsteams

Die Durchführung einer größeren organisatorischen Veränderung kann von einem Transitionsteam begleitet werden, das die Transition vorantreibt und für eine Umgebung sorgt, die im Sinne der Transition erwünschte Muster verstärkt. Im Zuge der agilen Transition der Web Development Abteilung bei Goodgame Studios durchlief unser Transitionsteam verschiedene Organisations-Formen, über die ich hier berichten möchte.

Ende 2014 hat sich Goodgame Studios (im Folgenden GGS) entschieden die Software-Entwicklung im zentralen Bereich Web Development auf agile Vorgehensweise umzustellen (Scrum/Kanban). Mit dem Mandat des CTO haben wir dazu von Anfang an ein Team etabliert, das diesen Prozess begleiten und vorantreiben sollte.

Um gleichzeitig als Vorbild zu dienen, haben wir uns entschlossen dieses Transitionsteam auf agile Art zu organisieren und uns am Scrum-Framework orientiert. Als Produkt des Transitionsteams betrachteten wir die vollständig agilisierte Abteilung, auf die wir uns in wertschaffenden Sprintinkrementen zubewegen wollten. Zu besetzen waren nun die drei Rollen Scrum Master (bzw. Agile Coach), Product Owner und Team. Product Owner wurde der Abteilungsleiter, Scrum Master eine erfahrene externe Coachess und das „Dev“-Team setzte sich zusammen aus Führungskräften und Vertretern der einzelnen Positionen (Projekt Manager, Produkt Manager, Entwickler).

transition-team

Wir begannen mit einer Sprintlänge von zwei Wochen, wobei wir Sprintplanung, Review und Retro komplett am Mittwochnachmittag durchführten. Standups gab es zwei die Woche, am Dienstag und Donnerstag. Transitions-Backlog und Sprint-Backlog haben wir nicht als physisches Board aufgesetzt, sondern in Jira, vor allem um den auf dem GGS-Gelände weit verteilten Entwicklungsteams einfachen und transparenten Zugriff zu gewährleisten.

Nachdem wir dies circa ein halbes Jahr ausprobiert hatten, stießen wir auf eine Reihe von Problemen:

  • Das Transitionsteam konnte nicht alle Entwicklungsteams gleichzeitig adressieren, so dass sich manche Teams vernachlässigt fühlten, insbesondere da wir öffentlich versprochen hatten, dass das Transitionsteam für die ganze Abteilung da sein würde.
  • Parallel zum Transitionsteam trafen sich wöchentlich die Teamleads des Bereichs und verfolgten eine eigene Agenda, die zum Teil im Widerstreit mit den Zielen des Transitionsteams stand. Obwohl in beiden Teams der Abteilungsleiter als Product Owner fungierte, gab es immer wieder Alignment-Schwierigkeiten zwischen den beiden Führungsteams.

In Summe gab es Entwicklungsteams, die gar nicht adressiert wurden und dann wiederum solche, die von beiden Führungsteams mit z.T. widersprüchlichen Zielen angesprochen wurden.

Um dieses Problem zu lösen, schwenkten wir um auf das von uns sogenannte Flower-Modell:

flower

Dazu ordneten wir die ganze Abteilung in drei Cluster, aus denen Product Owner (PO), Teamlead (TL) und Agile Coaches (AC) der Entwicklungsteams ein für ihren Cluster verantwortliches Transitionsteam bildeten (POTLAC). Das alte Transitionsteam, verwandelte sich in eine Art Product Owner Team und entsandte Delegierte als Transitions-Product Owner in die drei POTLACS. Die Treffen der Teamleads wurden abgeschafft.

Die POTLACS führten 4-Wochen-Sprints durch, jeweils um eine Woche versetzt, so dass sich das Transitions-Product-Owner-Team in der 4. Woche mit Koordinationsthemen beschäftigen konnte.

sprints

Mit dem Flower-Modell schafften wir es tatsächlich, näher an die Teams heranzurücken. Nur die 4-wöchigen Sprints fühlten sich zu lang an. Dieses Problem lösten die Teams unterschiedlich: Einer der Cluster entschloss sich auf Kanban umzustellen. Statt längerer Scrum-Meetings alle 4 Wochen führte dieses Team tägliche Standups durch, zu denen der Product Owner bei Bedarf dazustieß und im Anschluss Stories priorisieren bzw. abnehmen konnte. Der freigewordene Meeting-Slot am Mittwoch ermöglichte den anderen beiden POTLACS auf 2-Wochen-Sprints zu wechseln.

Retrospektiv betrachtet lag die größte Herausforderung beim Aufsetzen der Struktur des Transitionsteams darin, ein für die Größe der zu agilisierenden Abteilung angemessenes Alignment zu finden. Das Spannungsfeld sah dabei ähnlich aus wie Henrik Knibergs Autonomy/Alignment Matrix:

agile-team-alignment

Das Management strebte Quadrant A an, also hohes Alignment bei hoher Autonomie der Teams. Im Laufe der Zeit wurde aber immer wieder darum gerungen, was das bedeutete.

Für einige Teams sah es so aus, als wäre man zu weit in Quadrant B gerutscht, da die Arbeit mit dem Transitionsteam zusätzlichen Aufwand erzeugte, der als Overhead oder gar Micro-Management wahrgenommen wurde. Neben den Transitions-Meetings waren dies vor allem vorgeschlagene Standards (z.B. ein einheitliches Format für Roadmaps), für die manche Teams keinen direkten Mehrwert zu bekommen glaubten.

Aus Perspektive des Managements sah es gerade am Anfang so aus, als rutschten die Teams zu stark in den Quadranten C, zum einen weil sie unterschiedliche Schwerpunkte bei der Agilisierung setzten, zum anderen weil manche Teams in der ursprünglichen Aufstellung des Transitionsteams unter dem Radar flogen.

Business Value Poker and more (PO-Tools Nr.3)

Hier der dritte und letzte Teil meines Beitrags zu Product Owner Tools.

Umsetzungsplanung

Nachdem der Kontext eines Produktes definiert ist und ein allgemeines Commitment von allen Beteiligten erreicht wurde, muss die Produktidee umgesetzt werden. Eine detaillierte Zeitplanung im Vorfeld zu erstellen ist in der Regel den Aufwand nicht wert. Man erlangt bessere Ergebnisse, wenn das Team immer wieder neu entscheidet, was der nächste Schritt ist um der Vision ein Stück näher zu kommen anstatt einem festgelegten Plan zu folgen. Dennoch möchte man verschiedene aufeinander aufbauende Ziele definieren und diese in eine zeitliche Abfolge bringen um kommunizieren zu können, was und bis wann möglich sein soll.

Zielorientierte Roadmap

Die Roadmap beschreibt Etappenziele um der Vision näher zu kommen.

Ich zerlege das Big Picture aus der Storymap in kleinstmögliche Pakete, die ein wertvolles Kundenziel abbilden, sogenannte Minimal Viable Products (MVP).

roadmap

Dazu gehören:

  • Die ‘Value proposition’, der Vorteil den man sich erhofft, wenn das Ziel erreicht ist.
  • 1-2 überprüfbare Messwerte (KPI), um die Erreichung zu objektivieren.
  • Eventuell eine grobe Liste von Tasks, wenn zum besseren Verständnis hilfreich

Für die Abschätzung der Lieferpunkte der MVPs verlasse ich mich nur bedingt auf die Hochrechnung mittels Storypunkten und  Velocity, sondern diskutiere mit den Entwicklern, wie viel Zeit wir uns geben wollen um das jeweilige Ziel zu erreichen.

Im Laufe der Sprints verändert sich die Roadmap durch neue Erkenntnisse und Refokussierung auf den nächst besten Schritt um der Vision näher zu kommen.

Outcome Metriken

Wir verwenden Outcome Metriken im wesentlichen für 2 unterschiedliche Anwendungsfälle.

  1. Wir messen, ob wir den erwarteten Wert aus einem Etappenziel auch tatsächlich abschöpfen konnten.
  2. Wir messen auf lang- bis mittelfristiger Sicht die Performance des Entwicklung Teams.

Die Art und Weise wie wir Etappenziele überprüfen können, hängt sehr stark von dem jeweiligen Kontext ab.

Hier ein paar Beispiele um das Prinzip zu verdeutlichen.

Ziel:
Wir möchten in der Lage sein, für unser neues Spiel eine “Comeback Mail” an Spieler zu verschicken, die X Tage nicht im Spiel aktiv waren.

Metrik:
Die Churn Rate (Anzahl Spieler, welche das Spiel nicht weiter nutzen, geteilt durch die Summe aller Spieler) sinkt um X %.

Ziel:
Unser Backend soll sich automatisch fehlerhafte Daten nach einem Ausfall aus dem Data Ware House ziehen.

Metrik:
Der Aufwand für manuelle Datenimporte reduziert sich auf X Stunden pro Sprint.

Im Gegenzug dazu sollte man für die Performance Messung möglichst wenige bzw, wenn möglich sogar nur eine Businesskritische KPI definieren auf die man das gesamte Projekt optimiert.

Beispiel: Mittels Email Marketing möchten wir die Retention unsere Spiele langfristig erhöhen.

Die selbe KPI dient auch um Prioritätsentscheidungen zu treffen. Die Priorität wird auf Basis eines Forecast gemacht, die Performance sollte allerdings mit realen Daten gemessen werden. Die Prio KPI sollte deswegen einheitlich sein, damit man auch sehr unterschiedliche Features gegeneinander beurteilen kann.

http://www.startuplessonslearned.com/2013/03/lean-analytics.html

Business Value Poker

Oft ist es schwierig ein Produkt auf eine entscheidende Business KPI runter zu brechen, wie bei dem Beispiel Email Marketing oder bei Inhouse Reporting Tools. Außerdem sind Werte wie Zeitersparnis oder strategische Vorteile oft schwer zu messen bzw. vorherzusagen. In solchen Fällen versuchen ich den Wert von MVPs durch Business Value Poker zu objektivieren. Dabei bewerten wir ähnlich wie im Planning Poker in gemeinsamer Runde die MVPs relativ zueinander. Anstatt mit Entwicklern die Komplexität von Stories in Storypunkten zu schätzen, wird der Business Value von MVPs mit den Stakeholdern relativ zueinander geschätzt.

Da jeder Stakeholder natürlich sein eigenes Thema am wichtigsten und damit am wertvollsten findet, darf er bei der Vorstellung nur inhaltliche Fragen beantworten, aber noch keine Stellungnahme zum Wert abgeben. Dann wird in der Gruppe der übrigen Stakeholder gepokert und diskutiert, um das MVP in der Fibonacci-Skala einzuordnen. Da einigen Stakeholdern das Pokern zu “fancy” ist, orientieren wir uns z.T. auch am Team Estimation Game bzw. ordnen die MVPs einfach gemeinsam in der Skala ein.

bvpoker

Da die MVPs in der Regel noch wesentlich größer sind als die Userstories, verteilen wir die Value-Points anteilig auf die Storys. Die Stakeholder dürfen mitbestimmen, welche Stories den größten Anteil an der Zielerreichung haben.

Genau wie mit Storypunkten kann die Performance des Teams in jedem Sprint mit Value-Punkte gemessen und optimiert werden. Die Value Punkte sind aber in jeden Fall nur ein Workaround, besser ist es eine “harte” KPI für das Produkt zu ermitteln.

Fazit

Die Richtung der Produktentwicklung festzulegen ist eine komplexe Aufgabe für die der Product Owner auf eine große Zahl an Methoden zurückgreifen kann, von denen wir hier einige vorgestellt haben. Dabei ist klar geworden, dass das Einbeziehen von Entwicklungs-Team und Stakeholdern essentiell für den Produkterfolg und für den Verlauf des Projektes ist.

Ich denke, dass es hierbei  notwendig ist, das richtige Verhältnis zwischen klar definierten Zielen und kreativen Lösungsansätze zu finden. Generell sollte jedoch eine konkrete technische Umsetzung niemals Teil einer agilen Planung auf der hier beschrieben Ebene der Produktziele sein. Nur durch flexible taktische Entscheidungen und validiertes Lernen kann man mit jeder Iteration sicherstellen, dass das entstehende Produkt auch zu der initial definierten Produktidee passt.

Wärend der Produktentwicklung ist es notwendig, dass der Produkt Owner das Entwickler-Team immer wieder an der definierten Produktidee und dem erwarteten Outcome ausrichtet. Auch hierfür gibt es eine Vielzahl von Methoden und Praktiken.

gregor Gregor Meyenberg ist Product Owner bei Goodgame Studios

Domain Driven Design (PO-Tools Nr.2)

Hier die Fortsetzung meines Beitrags zu Product Owner Tools.

Domain Driven Design

Für die Modellierung des Produkts bedienen wir uns verschiedener Methoden aus dem Domain Driven Design (DDD), insbesondere Context Maps und Event Storming Workshops:

Context Map

Context Maps können helfen um Rahmenbedingungen zu definieren und/oder zu visualisieren.

In Zusammenarbeit mit dem Entwicklerteam und Domänen Experten modelliert man den Produktkontext und die Schnittstellen zu angrenzenden Bereichen, also welche Fachdomänen von dem Produkt berührt werden und welche nicht.

ddd1

Event Storming Workshop

Eine Methode zum Ermitteln und Validieren der Kontextgrenzen ist Event Storming: In einem gemeinsamen Brainstorming erschließen sich Entwickler und Fachexperten die Domäne und bringen sich gegenseitig auf ein gemeinsames Verständnis.

Dies sind die grundlegenden Schritte zu dem Vorgehen:

Die richtigen Leute einladen.

Idealerweise benutzt man einen großen Meetingraum mit sechs bis acht Leuten. Es sollten die Personen anwesend sein, die die richtigen Fragen stellen können, in der Regel sind das die Entwickler. Sowie die Personen, die die Antworten dazu haben, die Domänenexperten.

eventstorming

Keine Limitierung

Wenn man eine Domäne noch nicht kennt, kann man auch nicht wissen wieviel Platz man braucht um sie zu modellieren. Deswegen sollte man den Platz nicht begrenzen. Idealerweise bereitet man die Wände des gesamten Raums mit einer Papierrolle vor.

Entdecke die Domäne anhand von Events (Ereignissen).

Events werden immer in der Vergangenheitsform aufgeschrieben. Man verwendet orangene Stickies für die Events und ordnet diese in einer zeitlichen Abfolge. Der Workshop startet mit der Frage an die Domainexperten: “Was ist das für euch wichtigste Event”. Der erste orangene Sticky wird in die Mitte der Wand geklebt. Dann geht es weiter mit der Frage: “Was passiert davor” und “Was passiert danach” usw.

Entdecke die Auslöser von Events

Was muss passieren, damit ein Event eintritt. Manche Events werden durch eine Aktion ausgelöst (Commands). Für Commands werden blaue Stickies verwendet.

Events können durch externe Systeme oder andere Events ausgelöst werden. Für externe Systeme werden pinke Stickies verwendet. Die Auslöser von Events werden an das Event selber geklebt.

Entdecke Aggregate und ordne das Chaos

Hier geht es nicht um Aggregate im technischen Sinne. Es geht darum zusammengehörige Events in Clustern zusammenzufassen. Beispielsweise könnten alle Events die den Shop betreffen zum Aggregat Shop zusammengefasst werden. Aggregate selber können Commands entgegen nehmen und Ereignisse auslösen.

Entdecke Subdomains

Im letzten Schritt werden Aggregate zu Subdomains zusammengefasst. Hier wird ermittelt für welchen Bereich des Prozesses welche Fachexperten zuständig sind. Ausgehend von den Subdomains können dann die Kontextgrenzen und Kontextzusammenhänge definiert werden.

Fortsetzung HIER

gregor Gregor Meyenberg ist Product Owner bei Goodgame Studios