Schlagwort-Archive: agile

Circle of Personal Agility – CoPA

“Wir sind schon agil, wir haben doch ein Board an der Wand!” Solche und ähnliche Aussagen begegnen mir in vielen Unternehmen. Manche haben ihre Projektmanager in Scrummaster umbenannt, andere haben digitalisiert und von schnöder auf New Work umgestellt. Oft herrscht gleichzeitig Unzufriedenheit, weil sich am Output kaum etwas verändert hat. Es gibt neue cool klingende aber abstrakte Begriffe und nichts verändert sich, weil alle im Grunde so weiterarbeiten wie bisher.

Der Kern der Veränderung muss von den Menschen ausgehen und uns fällt Veränderung in der Regel schwer. Vor allem werden wir nicht gerne durch äußere Strukturen dazu gezwungen uns verändern zu müssen.

“People don’t resist change. They resist being changed!” – Peter Senge

Um Menschen bei Veränderung in ihrer Entwicklung zu helfen, gibt es professionelles persönliches Coaching. Die Methoden und Kategorien der klassischen Coaching-Welt ziehen aber oft ein zu breites Feld auf, in dem zum Beispiel über Family, Romance und Fun geredet wird. Auch wenn diese Bereiche für ein ausgewogenes Leben wichtig sind, lenken sie von einer fokussierten Weiterentwicklung am Arbeitsplatz tendenziell ab. Ich habe sogar erlebt, dass es für Mitarbeiter unangenehm sein kann, über vermeintlich private Themen zu reden, wenn ihr Arbeitgeber das Coaching bezahlt.

Für einen besseren Einstieg in ein Personal Coaching im Business Kontext haben wir den Circle of Personal Agility (CoPA) entwickelt. Dieser fokussiert zum einen auf berufsbezogene Themen. Zum anderen haben wir für jeden Bereich im CoPA verschiedene Modelle und weiterführende Tools und Methoden hinterlegt, die für eine Entwicklung in diesem Bereich wertvoll sein können.

Wie wird der CoPA verwendet?

Für jeden Bereich bewertet man sich selbst, wie gut man jeweils aufgestellt ist und wo noch Herausforderungen sind.

Je niedriger die Einstufung ist, desto mehr Potential kann gehoben werden. Jeder muss dabei für sich persönlich entscheiden, welcher Sektor gerade der wichtigste ist.

Der ausgefüllte Circle bildet den eigenen Status Quo ab. Egal ob in der Selbstreflexion oder als begleitendes Werkzeug im Gespräch mit einem Mentor, Coach oder Berater. Schritt für Schritt geht man einen Sektor des Circles nach dem anderen ab. Entsprechend der persönlichen Ziele, Prioritäten und Energie-Budgets entscheidet man wo man anfängt und weitermacht.

Damit man nicht auf der grünen Wiese beginnen muss, folgt hier eine Kurzübersicht für die Bereiche mit weiterführenden Begriffen und Links:

Erfolg
Karriere, persönliche Ziele, Entwicklungspfad – Erreichen Sie das, was Sie erreichen wollen? Siehe auch: Hypothesen, OKR, KPI

Reflexion
Konstruktive Kritik geben und annehmen, Feedback nutzen, persönliche Zielerreichung, – Werden eigenes Handeln und Gedanken regelmäßig und selbstkritisch betrachtet?
Siehe auch: CoPA, Johari-Fenster, GfK, Kollegiale Beratung, v.Thun

Verantwortung
Wahrnehmung von Rechten und Pflichten, Führungsverantwortung, Innere Barrieren erkennen und überwinden – Stellen Sie sich Ihren Schwächen und Fehlern?
Siehe auch: Responsibility Process, Trauerkurve

Ausgeglichenheit
Gesundheit, Stressresistenz, Fokus, An- und Entspannung, Selbst-Regulation – Sind Sie geistig und körperlich Leistungsfähig und haben Ihren Stress-Level im Griff?
Siehe auch: Work Life Balance, Achtsamkeit

Selbstorganisation
Disziplin, Lernkompetenz, persönliche Effizienz und Effektivität. Wie effektiv und effizient erledigen Sie ihre Aufgaben?
Siehe auch: CoPA, GTD, Personal Kanban (3), Zeit-Management, Priorisierung

Markt und Produkte
Fachwissen, analytische Fähigkeiten, Gespür für Bedarf und Bedürfnisse, (Selbst-) Vermarktung – Wie klar sind Ihnen die Anforderungen der Projekte und Produkte Ihres Unternehmens? Wie klar sind die Anforderungen an Sie selber?
Siehe auch: Innovation Vortex (2), Fit for Purpose (1)

Das große Ganze
Systemische Kompetenz, Komplexe Systeme und systemische Veränderungsprozesse, Netzwerken – Wie gelingt Ihnen der ständige Wechsel zwischen den Details deiner Arbeit und dem Blick auf die Zusammenhänge?
Siehe auch: Cynefin, Business Agility, Kanban (4)

Methodik
Agile, Lean, Handwerk, Führung, Ownership – Welche Methoden und Werkzeuge sind für ihre Aufgaben relevant und wie gut beherrschen Sie diese?
Siehe auch: Scrum, Kanban, Management3.0

Literatur:

(1) Anderson, David J. 2018: Fit for Purpose*: Wie Unternehmen Kunden finden, zufriedenstellen und binden: dpunkt Verlag

(2) Appelo, Jurgen 2019: Startup, Scaleup, Screwup*: 42 Tools to Accelerate Lean and Agile Business Growth (English Edition): Wiley

(3) Benson, Jim 2013: Personal Kanban*: Visualisierung und Planung von Aufgaben, Projekten und Terminen mit dem Kanban-Board: dpunkt.verlag

(4) Eisenberg, Florian 2018: Kanban – mehr als Zettel*: Wie die Methode Ihnen zu echtem Mehrwert verhilft: Carl Hanser Verlag

(5) Senge, Peter 2006: The Fifth Discipline*: Currency

(*) Affiliate-Links.

holger

Holger Tewis ist Agile Enterprise Coach
www.holgertewis.de

Shift Up – auf Innovation umschalten

„Von 60 Ideen führt nur eine zu einem erfolgreichen Produkt“ – Robert Cooper.

Geht das auch besser? Woran scheitern die Ideen? Wie kann ich eine Idee erfolgreich machen?

In seinem neuen Buch Startup, Scaleup, Screwup (2) befasst sich Jurgen Appelo mit Innovation in Organisationen und dem Lebenszyklus von Geschäftsmodellen. Wie schon in seinen vorhergehenden Büchern Management3.0 (3) und Managing for Happiness (4), erfindet er das Rad nicht neu, sondern nimmt vorhandene Modelle und Werkzeuge und veredelt sie. Von ein paar dieser Diamanten möchte ich hier berichten. Zudem gibt es ein neues Workshop-Format, in dem man die Modelle lernen und praktisch vertiefen kann.

Der Business Lifecycle

Buch und Workshop starten mit dem Business Lifecycle von Geschäftsmodellen, den Appelo aus verschiedenen Modellen zusammengefügt hat. Appelos Lebenszyklus ist mit 10 Phasen sehr fein aufgegliedert:

  1. Initiation : Das Business Model ist nur eine Idee
  2. Expedition: Erste Experimente, Passung von Problem und Lösung suchen
  3. Formation: Volles Team Commitment auf die Idee
  4. Validation: Iterative Experimente, Passung von Produkt und Markt suchen
  5. Stabilization: Passung von Business und Markt suchen, auf die Skalierung vorbereiten
  6. Acceleration: Wachstum fördern und schnelle Skalierung auf einen großen Markt
  7. Crystallization: Am Markt etabliert, Umschalten auf Optimierung
  8. Expansion: Expansion in andere Gebiete und Produkt-Varianten
  9. Conservation: Alle Ziele sind erreicht; Geschäftsmodell im Niedergang
  10. Finish: Schließen des Geschäfts; Fokus auf andere Produkte

Lebensphasen – der Mensch als Metapher

Für die 10 Phasen nimmt Appelo das menschliche Leben als Metapher, was erstaunlich gut funktioniert. Neue Ideen für Geschäftsmodelle in den frühen Phasen des Lebenszyklus sind wie Kinder. Man muss ihnen gewisse Freiheiten lassen und in sie investieren, ohne dass sie gleich Gewinn abwerfen. Sobald die Geschäftsmodelle etwas ausgereifter sind, müssen sie an echten Kunden ausprobiert werden, ohne dass man zu viel Geld verbrennt.

Hat man bewiesen, dass das Geschäftsmodell erfolgreich ist und der Markt dafür groß genug, ist es erwachsen geworden. Nun kann man beginnen es zu skalieren. Die Gewinne, die man jetzt einfährt können in neue Kinder investiert werden. Schließlich kommt das Modell ins Rentenalter, die Umsätze sinken und man muss sich Gedanken machen wie und wann man das Geschäft ablöst.

Der Business Lifecycle eignet sich hervorragend dazu, die eigenen Produkte zu reflektieren bzw. von den Produkt- oder Management-Teams reflektieren zu lassen:

  • In welcher Phase ist unser Produkt?
  • Welche Punkte müssen wir in dieser Phase beachten?

Hiermit kann man aufdecken, ob eine Idee schon bereit ist für den nächsten Schritt. Oft wird zum Beispiel zu früh skaliert. Eine brandneue Idee braucht noch kein Vollzeit-Team. Ein vor fehlerhafter Prototyp sollte nicht produktiv eingesetzt werden. Eine nicht skalierbare Architektur eignet sich nicht für den Weltmarkt.  

Shiftup-Workshop

Für Organisationen, die schnellere Innovation und Veränderung brauchen, gibt es den Shiftup Business Agility & Innovation Leader Workshop.

Als einer der ersten in Norddeutschland werde ich diesen 2-tägigen Workshop ab Oktober anbieten. Hier die nächsten Termine:

Ihr lernt dort, wie ihr eine Startup-Kultur auch in eurem Unternehmen etablieren könnt, wie ihr Produkte wirksam skaliert und euch für Innovation reorganisiert. Details findet ihr hier: LINK

Ein Kopfsprung in das Becken erfolgreicher Methoden für Business Leader und Produkt-Teams. Wir sehen uns dort.

Literatur:

(1) Cooper, Robert 2017: Winning at New Products*: Creating Value Through Innovation: Basic Books

(2) Jurgen Appelo 2019: Startup, Scaleup, Screwup*: 42 Tools to Accelerate Lean and Agile Business Growth (English Edition): Wiley

(3) Jurgen Appelo 2018: Managing for Happiness*: Übungen, Werkzeuge und Praktiken, um jedes Team zu motivieren: Vahlen

(4) Jurgen Appelo 2011: Management 3.0*: Leading Agile Developers, Developing Agile Leaders (Addison-Wesley Signature Series (Cohn)): Addison-Wesley

(*) Affiliate-Links.

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

Nordstern Board – True North visualisieren

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

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

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

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

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

Norstern Board

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

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

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

Fazit:

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

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

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

Theda Howaldt ist Agile Coach bei Tchibo

 

 

 

 

holgerHolger Tewis ist Agile Enterprise Coach (Freiberufler)

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.