Category Archives: Allgemein

Erfolg in Organisationen durch Zielorientiertes Management

Unsere Fehlschläge sind oft erfolgreicher als unsere Erfolge – Henry Ford.

Wie kann man eine Organisation erfolgreich machen? Durch das Definieren, Kommunizieren, Umsetzen und Messen von Zielen. Genau darum geht es in diesem Beitrag.

Im Vergleich zu persönlichen Zielen liegt die besondere Herausforderung in Organisationen darin, dass es mehrere handelnde Akteure gibt, u.a. sogenannte Manager, die nicht unbedingt alle in die gleiche Richtung wollen. Daher haben sich hier auch andere Methoden für den Umgang mit Zielen entwickelt. Unter Anderem:

  • Zielorientiertes Management: Management by Objectives (MbO)
  • Ziele und Schlüsselergebnisse: Objectives and Key Results (OKR)
  • Nordstern-Konzept: True North

MbO – Management by Objectives

Drei starke Kräfte führen Management ganz natürlich in die Irre:

  1. Die spezialisierte Arbeit der meisten Manager
  2. Die hierarchische Struktur von Management
  3. Die Unterschiede in Vision und Arbeit und der resultierenden Isolation verschiedener Managementebenen

So beschreibt es jedenfalls der bekannte Management-Vordenker Peter Drucker in seinem Buch The Practice of Management (s.u.).

Drucker sagt, dass viele Manager als funktionale Manager starten und sich darauf fokussieren, ihren Bereich zum besten im ganzen Land zu machen. Das führt aber zu lokaler Optimierung, die oft schädlich für die Gesamtorganisation wird, also der globalen Optimierung im Wege steht.

ziele

Solche Manager messen ihre Performance nicht daran, wieviel sie zum Erfolg des Unternehmens beitragen, sondern an der Kunstfertigkeit und Professionalität der Ausführung ihrer Arbeit. Über die Zeit zerfallen Unternehmen dadurch in eine lose Ansammlung funktionaler Königreiche, die nur noch in Sorge um ihren Fachbereich leben. Eifersüchtig bewachen sie ihre Geheimnisse und ihr Augenmerk liegt mehr auf der eigenen Machtausdehnung als auf dem Ausbau des Gesamt-Geschäfts.

Die hierarchische Struktur birgt die Gefahr, dass beiläufige Kommentare und Angewohnheiten von Managern auf die Goldwaage gelegt werden. Um dies zu vermeiden, muss der Fokus darauf ausgerichtet werden was der Job verlangt, anstatt alleinig darauf, was der Chef verlangt.

Lokale Optimierung kann auch durch isolierte Managementebenen entstehen: Jede Ebene versucht in der Regel innerhalb ihrer vorgegebenen Rahmenbedingungen von Budget und Kompetenzen zu agieren. Kommunikation, ob eine ebenenübergreifende Lösung für die Organisation günstiger wäre, findet selten statt. Drucker illustriert dies anhand eines Bahnunternehmens, in dem hohe Kosten für den Aufbruch von Toilettentüren entstanden, weil die Nutzer den Schlüssel nicht zurück brachten. Auf oberer Ebene war beschlossen worden, dass ein Schlüssel pro Toilette reiche. Auf unterer Ebene gab es die Befugnis im Notfall Maßnahmen zu ergreifen, worunter der Aufbruch einer Toilette fiel, nicht aber die Beschaffung eines neuen Schlüssels.

Management by Objectives (MbO) soll diesen drei Kräften entgegenwirken, ohne dass eine Lücke, Reibung oder doppelte Arbeit entsteht. Erst wenn alle Mitarbeiter zum gemeinsamen Ziel der Organisation beitragen und jeder Manager auf den Erfolg des Ganzen Unternehmens ausgerichtet ist, wird die Organisation wirklich performant.

Die Objectives werden vom Ziel der Organisation abgeleitet, über die ganze Hierarchie klar formuliert und betonen von Anfang an Teamarbeit und gemeinsame Ergebnisse:

  • Welche Performance wird von der Abteilung eines Managers erwartet?
  • Mit welchen Beiträgen unterstützen er und seine Abteilung die Ziele anderer Abteilungen?
  • Welche Beiträge liefern andere Bereiche zur Abteilung des Managers?

Jeder Manager sollte die Objectives seiner Abteilung zusammen mit seinen Führungskräften entwickeln und  die Ausarbeitung der Ziele auf der höheren Organisationseinheit aktiv mitgestalten. Es reicht  nicht aus, unteren Managern nur das Gefühl zu vermitteln, eingebunden zu sein. Sie müssen die höheren Ziele mitgestalten und mittragen (meeting of minds).

MbO ermöglicht es Managern, ihre eigene Performance zu bewerten. Dadurch werden sie in die Lage versetzt, sich selbst-kontrolliert zu steuern, anstatt von höherer Stelle ständig kontrolliert und dominiert zu werden.

Nach Peter Drucker sollten Manager zu ihren Zielen mit klaren Messgrößen (Measurements) versorgt werden, anhand derer sie ihre Aufmerksamkeit und Anstrengung lenken können. Diese müssten nicht strikt quantitativ oder exakt, aber unmissverständlich klar sein und keine komplizierte Interpretation verlangen.

Im nächsten Teil schauen wir uns das Thema Objective and Key Results oder kurz OKR an.

Literatur:

Peter Drucker 2010: The Practice of Management*: Harper Business

(*) Affiliate-Links.

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Team-Tools für das Home-Office

Wer Abstand hält, hat sich nicht unbedingt entfernt – Edith Linvers

Aus aktuellem Anlass hier eine kleine Auswahl von Tools für Team-Arbeit aus dem Home-Office. Ich beschreibe nur die Features für die freien Versionen der Tools, gegen Entgelt gibt es natürlich mehr und bessere Funktionen.

Video-Konferenzen

  • Jitsi: Französische Open Source Lösung
  • Skype von Microsoft – Konferenzen für bis zu 50 Gesprächsteilnehmern
  • Zoom: Bis zu 100 Teilnehmer, aber Beschränkung auf 40 min. Break-out rooms, in denen man sich in Kleingruppen treffen kann.
  • Slack: Bis zu 15 Teilnehmer
  • Microsoft Teams: unlimitierte Teilnehmer!?
  • WebEx: 100 Teilnehmer

Eine detaillierte Besprechung von Video-Tools findet ihr z.B. auf Golem.de.

Dokumente teilen

  • MagentaCloud (Deutsche Telekom): 10 GB Speicherplatz – Usability z.T. nicht so gut
  • Dropbox: 2 GB Speicher. Gute Usability, wenn man auf verschiedensten Plattformen unterwegs ist.
  • Google Drive: 15 GB Speicher.
  • OneDrive von Microsoft: 5 GB.

Office Dokumente gemeinsam bearbeiten

  • Google Docs: Die Google eigenen Formate für Texte, Tabellenkalkulation und Präsentationen.
  • Microsoft Office Webapp: Microsoft Word, Excel und Powerpoint gemeinsam im Browser editieren.

Mindmaps kollaborativ erstellen

  • MindMeister: Bis zu drei Mindmaps gemeinsam erstellen.
  • Coggle: Auch maximal drei Mindmaps in der freien Version

Virtuelle Whiteboards

  • Ziteboard: Flexibel und vergleichsweise leichtgewichtiger Zugang.
  • Miro.com: Whiteboard mit Templates für Mind Maps, User Story Maps, Retrospektiven etc.

Eine Übersicht zu verschiedenen Whiteboards gibt es z.B. auf voipreview.org.

Virtuelle Task-Boards

Tools für bestimmte Methoden/Zeremonien

Die Sammlung von Tools ist groß und ich werde die Liste im Laufe der Zeit ergänzen.
Welche Tools nutzt ihr?

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Ein Tuning-Tag bei it-agile

Wollen Sie mal wieder an Ihrem Auto rumschrauben? Dann sind Sie beim Tuning-Tag von it-agile falsch!

Als Teil der agilen Ausbildung zum Certified Agile Leadership und (Advanced) Scrum Master sowie Product Owner bietet it-agile diese Tage an, auf denen sich die Teilnehmer untereinander austauschen und in einigen Programmen auch einen Abschluss-Workshop machen. Man trifft dort also andere Agile Coaches, Product Owner, Scrum Master und Führungskräfte, die auch gerade in einem dieser Ausbildungsprogramme sind.

Ich selbst mache die Certified Agile Leadership (CAL) Ausbildung und war nun schon auf meinem zweiten Tuning-Tag.

it-agile gestaltet den Ablauf primär als Open Space, d.h. die Teilnehmer legen am Morgen fest worüber sie sprechen wollen und bauen gemeinsam den Tagesplan auf. Das sah diesmal so aus:

Manche Sessions basierten auf einer einzelnen Frage, in anderen wurde ausführlich die Situation in einem Unternehmen geschildert oder Modelle vorgestellt, die man genutzt oder selber entwickelt hat.

In einer Session trafen sich alte und neue CAL-Teilnehmer und tauschten sich darüber aus, welche Herausforderungen es in der Ausbildung gibt und wie man sie meistern kann.

Ich selbst habe eine Session genutzt um ein Coaching-Modell (COPA) vorzustellen, mit dem ich mich im Rahmen meiner Ausbildung beschäftige:

Parallel zum Open Space wird eine Coaching Clinic angeboten, in der man Beratern von it-agile im vertraulichen Rahmen Fragen stellen kann.

Zwischendurch gab es noch ein gemeinsames Spiel: Team-Tic-Tac-Toe. Drei Teams spielten eine Mischung aus Vier Gewinnt und Tic Tac Toe gegeneinander. Für 6 Kreuze in einer Reihe oder Spalte gibt es 100 Punkte für 5 noch 50 Punkte und für 4 Kreuze in einer Reihe 25 Punkte. Jedes Team hat sich zuvor über seine Strategie beraten und dann einen Schreiber ausgewählt, der auf Basis der Strategie die Kreuze gesetzt hat. Gewonnen hat, wer am Ende die meisten Punkte hat.

Spätestens in der Diskussion nach dem Spiel sollten die Spieler realisieren, dass man nur über einen kooperativen Ansatz viele Punkte ansammeln kann.

Insgesamt war der Austausch mit den anderen Teilnehmern sehr angenehm, konstruktiv und hilfreich. Einige Teilnehmer konnten sich am Ende gar nicht entscheiden was ihr größtes Highlight war. Ein Teilnehmer meinte: “Der ganze Tag war wie Drogen nehmen. Gute Drogen!”

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Sprint Reviews in der Produktentwicklung

Sind Sie unzufrieden mit dem Ablauf Ihrer Sprint Review Meetings? Suchen Sie nach Verbesserungen? Dann lesen Sie weiter, wie wir bei CoreMedia Sprint Reviews gestalten, und probieren Sie die Ideen in Ihrem Team aus!

In den fast 10 Jahren, in denen wir Scrum in der Produktentwicklung einsetzen, haben wir mit zunehmenden agilen Reifegrad (siehe dazu auch (2)) unserer Organisation immer wieder das Format des Sprint Reviews angepasst. Unser, im folgenden beschriebenes Format weicht an vielen Stellen von dem im Scrum Guide beschriebenen Vorgehen für das Review ab, ohne die Werte und Prinzipien von Scrum außer Acht zu lassen.

Wer nimmt an unserem Sprint Review teil?

Wir sind ein Produkthersteller, dessen Software in klassischen Releases daherkommt. Zur Zeit haben wir 6 Entwicklerteams, die gemeinsam am Produkt arbeiten. Kontakt zu Kunden gibt es auf diversen Ebenen direkt oder indirekt durch verschiedene Mitarbeiter. Die Arbeit eines Teams hat dadurch an vielen Stellen einen Einfluss auf andere Teile der Firma und umgekehrt. Damit ist (fast) jeder CoreMedia-Mitarbeiter ein potentieller Stakeholder. Konsequenterweise laden die Teams deshalb auch alle Kollegen zu ihren Review Meetings ein.

Natürlich können nicht immer alle Mitarbeiter kommen. Um den Kollegen die Entscheidung für oder gegen einen Besuch des Reviews zu erleichtern, werden die Themen des Reviews in einer Einladungsmail durch die Teams angekündigt.
Um Kollegen, die nicht in unserer Hamburger Zentrale arbeiten oder dienstlich unterwegs sind, die Teilnahme zu ermöglichen, nutzen wir für die Reviews auch immer ein Videokonferenzsystem. Da einige Kollegen kein Deutsch können, wird nur Englisch gesprochen.

Um sicherzustellen, dass sich die Teams gegenseitig in ihren Review Meetings besuchen können, haben wir die Regel, dass es keine parallelen Review Meetings geben darf. Das geht bei unseren sechs Entwicklungsteams gerade noch.

Was wird gezeigt?

Die Teams zeigen im laufenden System neben den fertigen auch unfertige Stories, berichten über ihre Erfahrungen und Learnings aus dem Vorgehen oder stellen technische Konzepte für zukünftige Stories zu Diskussion.
Das auch unfertige Sachen gezeigt werden können, scheint auf den ersten Blick überhaupt nicht Scrum zu entsprechen. Schließlich soll ein Sprint ja immer ein potentiell nützliche Version des Produktes liefern (1). Ganz grundlegend für Scrum sind aber Überprüfung, Anpassung und Transparenz. Und der Scrum-Guide sieht das Sprint Review als formales Ereignis zur Überprüfung und Anpassung vor. Wenn ein Team während des Sprints feststellt, dass es zur Fertigstellung einer Story noch mehr Feedback braucht und dieses nicht vor Sprintende anders bekommen kann, dann spricht nichts dagegen, das Review dafür zu nutzen. Weiterhin kann das Team auch die Diversität der Review-Besucher (potentiell alle Mitarbeiter!) nutzen, um noch andere Sichten auf Stories zu beleuchten.

Wichtig ist vor allem, dass das Feedback der Teilnehmer zum Sprint Review festgehalten wird.

Was machen wir mit dem Feedback?

Das Feedback wird an einem Flipchart festgehalten. Das muss keinen bestimmten formalen Regeln entsprechen. Ich versuche aber diese immer auch ein wenig ansprechender zu gestalten.

Von dem Flipchart machen wir ein Foto und hängen das in unser Firmen-Wiki auf eine Seite, die alle Themen des Review Meetings auflistet. So können wir später gut nachvollziehen, wann Feedback zu bestimmten Themen gekommen ist.

Die Auswertung des Feedbacks wird in den Teams unterschiedlich gehandhabt. Zum Teil wird es als Einstimmung am Anfang der Retro durchgegangen und Maßnahmen abgeleitet (neue Stories, Änderungen am Backlog usw.). Andere Teams nehmen das Feedback mit in die Sprintplanung oder laden die Feedbackgeber zu einer eigens anberaumten vertiefenden Diskussions-Session ein.

Wichtig ist, dass das Team im nächsten Review Meeting darlegt, was es aus dem Feedback gemacht hat.

Wer zeigt was?

Jeder im Team kann etwas präsentieren. In der Regel zeigen die einzelnen Teammitglieder die Stories, an denen sie mitgearbeitet haben. Der Product Owner beschreibt den Kontext, erläutert das Sprint-Ziel und gibt am Ende des Reviews einen Ausblick auf die kommenden Sprints.

Wie lange dauert so ein Review Meeting?

Wir haben wir die Länge der Reviews bewusst auf 30 Minuten beschränkt. In der Regel reicht das, um sich auf das Wesentliche zu fokussieren. Wenn mal nicht alles gezeigt werden kann, dann kann das entweder im nächsten Review Meeting nachgeholt werden, oder es gibt einen Extra-Termin zu bestimmten, speziellen Themen.

Was halten Sie von dem Vorgehen? Haben Sie noch Fragen? Oder Anregungen, was wir verbessern können? Dann schreiben Sie uns das bitte in die Kommentare.

Literatur

(1) Scrum Guide, https://www.scrumguides.org/docs/scrumguide/v2017/2017-Scrum-Guide-German.pdf

(2) Andresen, Judith: Agiles Coaching*

(3) Agile Product Management with Scrum*

(*) Affiliate-Links.

 

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!

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:

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, 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.