Mit Key Results zum Unternehmenserfolg

Effektive Zielsetzung startet mit diszipliniertem Nachdenken an der Spitze, mit Führungskräften, die Zeit und Energie investieren zu entscheiden, was wirklich zählt – John Doerr

Objectives and Key Results, oder kurz OKR, wurden durch die Verwendung bei Google bekannt. Erfunden hat sie jedoch Andrew S. Grove, ein Manager bei Intel.
Nachdem wir im letzten Beitrag einen Blick auf MbOs geworfen haben, hier die Fortsetzung zum Thema organisatorische Ziele.

OKR – Objectives and Key Results

Grove beschreibt in seinem Buch High Output Management (s.u.), wie aus seiner Sicht die richtige Implementierung von MbO (Management by Objectives) aussehen sollte. Der Planungsprozess einer Organisation besteht dabei aus drei Schritten:

1. Bedarf: Was ist im aktuellen Kontext der Organisation (Markt, Konkurrenz etc.)  nötig?
2. Status Quo: Wo steht die Organisation mit ihren Produkten und Services im Moment?
3. Lücke Schließen: Was muss und kann getan werden um die Lücke zwischen Bedarf und Status Quo zu schließen?

Zielorientiertes Management konzentriert sich nach Grove auf Schritt zwei und drei und macht diese konkret. Um erfolgreich zu sein müssen dabei nur zwei Fragen beantwortet werden:

1. Ziel: Wohin wollen wir? (Objective)
2. Schlüsselergebnisse: Wie erkennen wir, ob wir dem Ziel näher kommen? (Key Results)

Zum Festlegen der OKR von Mitarbeitern macht die Führungskraft ihre eigenen Objectives transparent. Mitarbeiter und Führungskraft einigen sich dann in freier, offener Diskussion, mit welchen eigenen Objectives der Mitarbeiter diese Ziele unterstützen kann (Delegation Level 4). So entsteht aus den Objectives von Führungskräften und Mitarbeitern eine verschachtelte, voneinander abhängige Hierarchie: Werden die Ziele der Mitarbeiter erfüllt, so werden automatisch die Ziele der Führungskraft erfüllt.

Key Results definiert ein Mitarbeiter hingegen selbst, sobald seine Ziele feststehen. Er überlegt wie er sein Vorwärtskommen messen kann und will und formuliert die Key Results so eindeutig, dass es keine Zweifel gibt, wann sie erfüllt sind. So werden sie zu einem Instrument für den Mitarbeiter, um seine eigene Leistung zu messen. Dazu müssen Key Results so terminiert sein, dass sie zeitnah Feedback geben, ob das eigene Handeln die richtige Wirkung zeigt (z.B. quartalsweise oder gar monatlich, etwa bei einer jährlichen Planung).

Es ist möglich seine Objectives zu verfehlen, obwohl man alle Key Results erfüllt hat. OKR sind kein Vertragswerk auf dessen Erreichen ein Performance-Review des Mitarbeiters passieren sollte, sondern maximal ein Feedback, wie erfolgreich der Mitarbeiter war.

Wenn man Drucker und Grove direkt vergleicht, stimmen ihre Sichtweisen auf Zielorientiertes Management größtenteils überein. Grove bezieht sich ja sogar direkt auf Management by Objectives. Nur beim Festlegen der Messgrößen gibt es Unterschiede. Bei Drucker werden die  Messgrößen tendenziell von Außen geliefert, bei Grove definiert sie jeder Mitarbeiter selbst. Von Grove gibt es allerdings wenig Veröffentlichungen zum Thema, so dass ein großer Interpretationsspielraum seiner Definition von OKR bleibt.

Deswegen kommt im nächsten Beitrag einen Schüler von Grove zu Wort, der OKR bei Google eingeführt hat. John Doerr beschreibt in seinem Buch Measure what Matters (s.u.) sehr ausführlich, wie Unternehmen OKR in der Praxis anwenden sollen.

Zum Weiterlesen einfach hier klicken: OKR in der Praxis

Literatur

Andrew S. Grove 1983: High Output Management*: Vintage

John Doerr 2018: Measure What Matters*: Portfolio Penguin

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

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.

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

• MeisterTask: Ein deutscher Anbieter
• Trello: Sehr gute Usability

Tools für bestimmte Methoden/Zeremonien

• Planning Poker:
  • Planit Poker
  • Planning Poker
• Delegation Poker: Delegationsstufen mit Management 3.0
• Moving Motivators: auch aus dem Mgmt.30. Der Link erlaubt euch eine Kopie eines Google Drawings zu machen. Dort können dann mehrere Personen ihre Motivatoren einstellen.
• Mentimeter: Schnelle Umfragen

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

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Retrospektive Remote – Team-Reflexion im Home-Office

Der Schmerz sich Trennen zu müssen ist nichts gegen die Freude, sich wieder zu treffen – Charles Dickens

Die Retrospektive steht an, aber dein Team ist im Home-Office? Das ist kein Grund die virtuelle Flinte ins virtuelle Korn zu werfen. Produktive Retrospektive können online auch ohne teure Tools durchgeführt werden.

Eine gute Retrospektive besteht aus folgenden 5 Phasen, an denen ich mich hier orientieren möchte. Gerade online Retros sollten kurz und knackig sein, ich gehe hier von 60 min aus.

1. Ankommen (Set the stage) – 6 min
2. Daten sammeln (Gather data) – 20 min
3. Einsichten erzeugen (Generate insights) – 20 min
4. Entscheidungen treffen (Decide what to do) – 12 min
5. Retrospektive abschließen (Close the retrospective) -2 min

Vorbereitung

Wähle ein Kommunikationsmittel: Skype, Teams, Zoom oder auch das gute alte Telefon. Jeder Teilnehmer sollte einen Computer mit Internetverbindung haben. Ich benutze hier außerdem ein Tool für virtuelle Boards, z.B. Trello oder MeisterTask. Verschicke vorab an alle Teilnehmer die entsprechenden Links und verifiziere, dass alle ihren Zugang getestet haben.

Es sollte einen expliziten Moderator geben, z.B. den ScrumMaster des Teams. Dieser sollte eine Liste der Teilnehmer vorliegen haben. Online ist es für den Moderator eine besondere Herausforderung allen Teilnehmern Aufmerksamkeit zu schenken, insbesondere wenn man gemeinsam auf eine Präsentation oder ein Online-Board schaut. Für die Teilnehmer ist es einfacher, wenn sie die Liste sehen. Wenn man z.B. der Reihe nach dran ist, weiß jeder Teilnehmer an welcher Position er steht.

In den folgenden Schritten gehe ich davon aus, dass du der Moderator bist!

1. Ankommen – drei Worte

Um die Teilnehmer zu aktivieren sollte beim Ankommen jeder mindestens einmal kurz zu Wort kommen, z.B. in einem Blitzlicht über den letzten Sprint:

• Herzlich Willkommen zu unserer Retrospektive. Lasst uns zum Ankommen den letzten Sprint mit maximal drei Worten beschreiben, z.B. “Eine perfekte Welle.” oder “Panik, Weltuntergang, Auferstehung.” Ihr bekommt jetzt 1 Minute Zeit, so dass ihr euch eure drei Worte überlegen könnt. Fragen? Nein? Dann los.

Frag nach einer Minute, ob alle fertig sind und verlängere bei Bedarf um eine weitere Minute. Dann ruf den ersten Teilnehmer von der Liste auf. Ist die Reihenfolge klar können sich die Teilnehmer dann das Wort selber übergeben. Ansonsten ruf jeden Teilnehmer explizit auf, damit keine Zeit verloren geht.

Die drei Worte sind ein erster Hinweis, ob der Sprint eher gut oder schlecht gelaufen ist.

2. Daten Sammeln – Mad, Sad, Glad

Um sinnvoll Daten zu sammeln bietet sich Tool-Unterstützung an. Tools für virtuelle Boards wie Trello oder MeisterTask haben schon in der kostenlosen Version ausreichend Funktionalität für eine Retro.

• Lasst uns nun mit dem Sammeln der Daten beginnen. Wir nutzen die Methode Mad, Sad, Glad. Denkt an die letzte Iteration und überlegt was euch glücklich gestimmt hat (das sind die Glad-Karten), womit ihr unzufrieden wart (Sad) und was euch in den Wahnsinn getrieben oder regelrecht wütend gemacht hat (Mad). Jeder von euch darf insgesamt maximal drei Karten schreiben, überlegt euch also was am wichtigsten für uns ist. Bitte ordnet die Karten in die richtige Spalte ein und markiert sie mit einem farbigen Label. Ihr bekommt 5 Minuten Zeit. Fragen? Nein? Los gehts!

Strukturiere das Board für Mad, Sad, Glad zum Beispiel wie in der folgenden Abbildung:

Die Teilnehmer sollten nun die ersten drei Spalten für die drei Kategorien Glad, Sad und Mad mit Karten füllen. In der Regel entstehen zu viele Karten, als dass man alle besprechen könnte, d.h. wir müssen die bestehenden Karten Priorisieren. Bei manchen virtuellen Boards gibt es die Möglichkeit Abstimmungen durchzuführen. Wenn das nicht möglich ist, kann man sich mit der Zuordnung von Personen zu den Karten behelfen, die normalerweise für die Aufgabenverteilung gedacht ist.

• Die Zeit ist um. Lasst uns nun die Karten priorisieren. Jeder von euch darf drei mal seinen Avatar vergeben. Wählt die drei Karten aus, die aus eurer Sicht heute besprochen werden sollten und zieht euren Avatar auf die Karte, so als wolltet ihr die Aufgabe übernehmen. Das dient im Moment nur der Priorisierung. Ob und wer die Karte dann bearbeitet entscheiden wir später.

Jetzt sollten auf den Karten die Avatare der Teilnehmer erscheinen. Am Ende sollte jeder Teilnehmer maximal drei Avatare verteilt haben. Sortiere nun die Karten mit den meisten Avataren in den Spalten nach oben und ziehe dann die 2-4 am höchsten priorisierten Karten in die Spalte “Priorisiert”, unabhängig davon, ob diese vorher in der Mad-, Sad- oder Glad-Spalte gehangen haben. Wo die Karte herkam, sollte am Label sichtbar sein.

3. Einsichten erzeugen – Root Cause Analysis

Jetzt kann die Analyse beginnen. Ziehe die erste Karte in die Spalte “in Diskussion”.

• Lasst uns über die Karte “zu wenig automatische Tests” sprechen. Bevor wir mit Lösungsvorschlägen kommen, würde ich gerne die Ursachen besser verstehen. Was glaubt ihr ist das Problem?

Anstatt nun wieder alle Karten zu den Ursachen schreiben zu lassen, bevorzuge ich an dieser Stelle die offene Kommunikation und schreibe mögliche Ursachen als Stichworte mit in die Beschreibung der Karte.

4. Entscheidungen treffen – SMART Goals

Sind die Ursachen geklärt, muss sich das Team auf sinnvolle Maßnahmen zur Lösung einigen. Bei Trello kann man das z.B. mit einer Checkliste machen, die man später abhaken kann.

• Lasst uns nun überlegen, welche Maßnahmen wir treffen wollen. Diese sollten möglichst SMART sein, also specific (=konkret), measurable (=messbar), attainable (=erreichbar), relevant, timely (=termingebunden). Was schlagt ihr vor?

Ihr könnt schließlich festlegen, wer sich um die Maßnahmen kümmert, indem ihr die Avatare, die vorher für die Abstimmung benutzt wurden entfernt und durch die Verantwortlichen für die Maßnahme ersetzt.

5. Abschluss

Zum Abschluss frage ich meistens nur, was gut lief und was man für die nächste Retrospektive verbessern könnte.

Für alle Phasen kann man sich vom Retromat inspirieren lassen, der dutzende Methoden zusammenfasst, die aber meistens für offline Retros gedacht sind.

Wenn man zuvor Retros durchgeführt hat, ist ein wichtiger Schritt natürlich zu überprüfen, ob die Maßnahmen vom letzten Mal umgesetzt wurden.

Nachdem ihr mein Vorgehen gelesen habt, würde mich natürlich interessieren, wie ihr Retrospektiven durchführt. Welche Tools verwendet ihr? Welche Methoden sind erfolgreich?

Literatur:

(1) Derby, Esther 2006: Agile Retrospectives*: Making Good Teams Great (Pragmatic Programmers)

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Team-Verantwortung oder Einzel-Verantwortung

Wenn Spinnen vereint weben, können sie einen Löwen fesseln – Äthiopisches Sprichwort

Viele glauben, dass Verantwortung für ein Thema immer bei genau einer Person liegen sollte. Dies wird gerechtfertigt mit Sprüchen wie: “Sind alle zuständig, dann trägt keiner Verantwortung.” oder “Viele Köche verderben den Brei.”

Natürlich ist es schlecht, wenn sich keiner verantwortlich fühlt, aber in manchen Fällen macht es die Benennung einer einzelnen Person noch schlimmer. Das kann man in einigen Unternehmen am Zustand der Büroküche sehen. Räumt die Reinigungsfachkraft mehrfach am Tag auf, machen sich wenige Mitarbeiter noch die Mühe ihre Kaffeetasse selbst in den Geschirrspüler zu stellen. Wenn die Fachkraft dann ausfällt, wird die Küche innerhalb weniger Stunden zum Saustall.

Verhalten sich die Mitarbeiter bei der Produktentwicklung genauso, entstehen Produkte, die qualitativ minderwertig sind oder die Entwicklung wird schneckenlangsam, weil überall auf den einen gewartet wird, der verantwortlich ist, sei es für Design, Architektur, Implementierung oder Qualitätssicherung.

Deswegen ist es oft eine gute Idee, die Verantwortung nicht auf einzelne Personen, sondern auf ein ganzes Team zu übertragen. Ein Scrum Entwicklungs-Team wird zum Beispiel immer als ganzes in die Verantwortung genommen:

Einzelne Mitglieder des Entwicklungsteams können zwar spezialisierte Fähigkeiten oder Spezialgebiete haben, aber die Rechenschaftspflicht obliegt dem Team als Ganzem. (Scrum Guide)

Es braucht bestimmte Rahmenbedingungen, damit Teams wirklich mehr sind als nur die Summe ihrer Mitglieder. Das Aristoteles Projekt von Google hat folgende Faktoren von effektiven Teams festgestellt:

• Psychologische Sicherheit: Die Teammitglieder fühlen sich sicher dabei, Fragen oder Ideen zu äußern, ohne als unwissend, inkompetent, negativ oder störend abgestempelt zu werden.
• Verlässlichkeit: Die Mitglieder liefern ihre Arbeit zuverlässig, pünktlich und in hoher Qualität ab
• Struktur und Klarheit: Jeder versteht, was von ihm erwartet wird, wie er die Erwartungen erfüllen kann und wie sich die eigene Leistung auf die Teameffektivität auswirkt. Spezifische, herausfordernde aber erreichbare Ziele.
• Sinnhaftigkeit: Das Erkennen eines Sinns in der Arbeit selbst oder in ihrem Ergebnis.
• Auswirkung: Das Gefühl einen signifikanten Unterschied zu machen.

Wenn es um Richtungsentscheidungen, Ziele und Prioritäten geht, ist es dagegen meistens besser einen einzelnen Verantwortlichen zu haben. Ansonsten entstehen Machtkämpfe oder faule Kompromisse. Ein Scrum Product Owner ist zum Beispiel immer genau eine Person, keine Komitee oder eine Doppelspitze.

Es sollte also eine Person geben, die das Was? festlegt und die Richtung vorgibt und ein Team, welches das Wie? bestimmt und die Umsetzung macht. Dabei kann es verschiedene Strategien geben, wie man Teams führt. Henrik Kniberg hat zum Beispiel für Spotify beschrieben, wie dort viele Teams gemeinsam an einem Produkt arbeiten. Die Teams sollen dort möglichst autonom agieren, damit sie nicht auf andere warten müssen. Gleichzeitig brauchen die Teams eine gute gemeinsame Ausrichtung (Alignment), damit das Produkt am Ende aus einem Guss ist und nicht zu einem Frankenstein-Monster wird.

Im nächsten Beitrag betrachten wir den inneren Verantwortungsprozess aus der Reihe zum Circle of Personal Agility.

Literatur:

(1) Charles Duhigg 2016: What Google Learned From Its Quest to Build the Perfect Team: New York Times

(*) Affiliate-Links.

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

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

 

 

 

 

Holger Tewis ist Agile Enterprise Coach (Freiberufler)

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.