Markt und Produkte – Strömungsabriss im Feedbackzyklus

The number one reason for business screwups is the lack of a market need for a new product – Jurgen Appelo.

Eine Priorisierung ist nur eine Momentaufnahme. Die besten Produkte entstehen in der kontinuierlichen Zusammenarbeit mit Kunden. Egal welche Tools und Modelle man verwendet, es bleibt die Frage, wie häufig man dafür mit dem Kunden zusammenkommen sollte.

Agilisten zeigen gerne das Video vom Nordstrom Innovation Lab, um zu verdeutlichen, was agiles Arbeiten eigentlich bedeutet: Ein Entwicklungsteam setzt sich in die Filiale eines Optikers und entwickelt, in direkter Interaktion mit den Kunden, eine App zur Auswahl von Brillen. 

Stefan Roock von it-agile hat in seinem Beitrag über den Agilen Kernzyklus destilliert, was den Kern agiler Zusammenarbeit ausmacht:

Das Umsetzungsteam und der Endkunde arbeiten in möglichst direktem Kontakt. Der Problemlösungskreislauf zwischen ihnen ist so eng wie möglich. Je näher das Vorgehen an diesem Kernzyklus liegt, umso besser wird das Produkt wahrscheinlich den Bedarf des Kunden treffen. 

Nicht jedes Produkt lässt sich wie im Nordstrom Innovation Lab direkt beim Kunden entwickeln, aber oft reisst im Eifer der Entwicklung der Feedbackkanal zum Kunden komplett ab. Kommt man nur am Anfang eines Projektes mit dem Kunden zur Definition von Lasten- und Pflichtenheft zusammen, ist man maximal weit vom Kernzyklus entfernt. Es ist in diesem Fall fast zwangsläufig, dass gegen Ende des Projekts einige böse Überraschungen auf alle Beteiligten warten. Dinge wurden etwa falsch verstanden und nicht geklärt, die Bedürfnisse des Kunden haben sich verändert und/oder mögliche Synergien durch kurze Feedback-Zyklen wurden verschenkt.

Es gibt eine Reihe von Methoden, die Empfehlungen geben, wie man den Feedbackzyklus mit dem Kunden optimal ausgestaltet: Scrum fordert, dass man Mindestens einmal im Monat den Zyklus durchläuft und z.B. im Review ein Teilprodukt präsentiert und auf Basis des Feedbacks die Entwicklung anpasst. Als Framework gibt Scrum aber wenig Hinweise, wie genau die konkrete Ausgestaltung passieren soll (siehe Scrumguide).

Design Thinking oder kurz DT ist ein Ansatz für Produktdesign, der danach strebt, das Optimum aus dem Widerstreit von Kundenbedürfnisse und technischen Möglichkeiten herauszuholen. DT ist damit sehr nah am agilen Kernzyklus dran. Es gibt verschiedene Schulen des Design Thinking. Die d.school der Stanford University z.B. definiert 5 Schritte mit flexibler Reihenfolge:

1. Empathize: Interviews führen, Handlungen beobachten, Menschen in ihrem Kontext verstehen, Gedanken aussprechen, Gefühle offenlegen, Storys suchen
2. Define: Kernproblem synthetisieren, inspirierende Perspektive gewinnen, Kriterien für die Bewertung konkurrierender Ideen festlegen
3. Ideate: Raum der Lösungsmöglichkeiten aufziehen, so viele Ideen wie möglich generieren, Brainstorming, aussichtsreichste Ideen auswählen.
4. Prototype: schnelle, billige Prototypen bauen, die Antworten auf wichtige Fragen für die finale Lösung liefern können. Bsp.: Wand mit Post-its, Rollenspiel, Storyboard,  Bastelei
5. Test: Prototypen den Kunden zeigen und Feedback einsammeln.

Auch Lean Startup ist eine Vorgehensweise um Produkte zu bauen, die optimal auf Kundenbedürfnisse zugeschnitten sind. Im Gegensatz zu Design Thinking betrachtet es Produktentwicklung als strukturiertes Experiment, bei dem im wissenschaftlichen Sinne zuvor aufgestellte Hypothesen überprüft werden. Es gibt 3 Schritte:

1. Build: Ideen schnell in Produkte verwandeln
2. Measure: Reaktionen von Kunden messen
3. Learn: Strategie fortführen oder verändern (pivot)

Jurgen Appelo kombiniert wiederum Design Thinking und Lean Startup zum Innovation Vortex. Dieser “Wirbelsturm” dreht sich in der Geburtsphase eines Business Modells sehr schnell. Man hat bisher nur wenig Erkenntnisse über die Bedürfnisse des Kunden und arbeitet dicht am agilen Kernzyklus, um möglichst schnell seine Annahmen zu validieren. Je stärker das Produkt am Markt etabliert ist, umso langsamer dreht sich der Vortex. Man schmeißt nicht mehr bei jeder neuen Erkenntnis alles über den Haufen, muss mehr auf Bestandskunden, CI, die eigene angewachsene Organisation und andere entstandene Strukturen achten.

Fazit: Eine gute Produktentwicklung erfordert schnelles Feedback vom Kunden. Dieses sollte mindestens einmal im Monat, gerade am Anfang der Entwicklung aber tendenziell schneller passieren. Mit leichtgewichtigen Prototypen sollten die kritischen Hypothesen zum Produkt überprüft werden. 

Der Innovation Vortex ist übrigens Teil des Shiftup-Workshops, den ihr bei mir in Hamburg und demnächst auch online buchen könnt. Informationen dazu findet ihr hier: Shiftup-Workshop.

Literatur

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

Michael Lewrick 2018: The Design Thinking Playbook*: Mindful Digital Transformation of Teams, Products, Services, Businesses and Ecosystems: Wiley

Eric Ries 2011: The Lean Startup*: How Today’s Entrepreneurs Use Continuous Innovation to Create Radically Successful Businesses: Currency

(*) 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

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.

 

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.

Struktur eines agilen Transitionsteams

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Stein für Stein zur besseren Zeiterfassung

Für viele Softwareentwickler gehört die Zeiterfassung ihrer Arbeit zu den am wenigsten beliebten Tätigkeiten. Die Gründe hierfür sind vielfältig – schlecht bedienbare Tools gehören aber auf jeden Fall dazu.

In seinem Blog Post “Why Time Sheets are Lame! “ nennt Jeff Sutherland einige Gründe, warum die Zeiterfassung aus seiner Sicht keinen Sinn macht.

Viele Firmen müssen die Zeit, die ihre Mitarbeiter mit bestimmten Aufgaben verbringen,  aus rechtlichen bzw. buchhalterischen Gründen erfassen. Die Zeiterfassung erfolgt dabei in den meisten Fällen auf individueller Basis.

Bei Nutzung einer agilen Entwicklungsmethode ist die individuelle Erfassung der Arbeitszeiten ein Problem. Beispielsweise stellt Scrum das Team und nicht Individuen in den Fokus. So gibt das Entwicklungsteam am Sprint-Anfang ein Commitment (oder in neueren Versionen des Scrum Guides einen Forecast) auf ein Sprint-Ziel ab.  Konsequenterweise wird am Sprint-Ende  der Erfolg des Teams gemessen und nicht der Erfolg von Individuen.

Für ein Unternehmen ist es eigentlich auch nur wichtig zu wissen, wie viel Zeit insgesamt für welche Themen (z.B. Maintenance, Entwicklung von neuen Features, Management der Infrastruktur etc. ) verwendet wurde. Die Summe der Zeiten entspricht im Grunde der Investitionssumme, die für verschiedene Themen aufgebracht worden ist.

Mein Arbeitgeber, die CoreMedia AG, hat sich deshalb dazu entschlossen die Zeiterfassung versuchsweise nur noch auf Team-Level durchzuführen. Die Wahl des Werkzeugs zur Erfassung ist dabei den Teams überlassen worden (Strichlisten, Software, Excel-Sheet,…). Wichtig ist nur, dass die Summe der aufgewendeten Zeiten am Ende eines Sprints an das Controlling übermittelt wird.

Damit die Zeiterfassung wieder mehr Spaß macht und wegen der einfachen Handhabbarkeit, haben sich einige unserer Teams, inklusive dem, in dem ich zur Zeit als Scrum Master tätig bin, dazu entschlossen, die Zeit mit Lego-Steinen zu tracken. Unsere “Zeiterfassung” sieht dann so aus:

Jeder Entwickler enthält am Anfang des Sprints entsprechend der Sprintlänge dieselbe Anzahl von Legosteinen. In dem Team, von dem das Beispiel stammt, steht ein Legostein für einen halben Tag.
Direkt neben unserem Task-Board und dem Ausgang zum Raum hängt eine große Legoplatte an der Wand. Auf dieser Platte sind mit festgeklemmten Post-its unterschiedliche Kategorien von Aufgaben markiert. Mögliche Kategorien sind unter anderem „Arbeit an Funktion A“, „Arbeit an Funktion B“, „Wartung“, „Pflege der Infrastruktur“ oder „Support“. Die Post-its werden mit flachen Steinen sicher auf der Basisplatte festgeklemmt.
Die Entwickler platzieren ihre Legosteine entsprechend ihrer Tätigkeiten am Tagesende jeweils in die passende Kategorie. Am Sprint-Ende werden die Legosteine in den einzelnen Bereichen vom Product Owner gezählt und in Zeiten umgerechnet, die dann elektronisch erfasst werden.

Wir machen diese Art der Zeiterfassung schon seit einigen Sprints. Bisher hat sich der Ansatz als ein pragmatischer Weg bewährt. Die Vorteile sind im Einzelnen:

• Eine gesteigerte Akzeptanz der Zeiterfassung durch die Entwickler.
• Die Zeiterfassung wird während des Sprints durchgeführt und nicht erst nach mehrmaligen Erinnerungen sehr viel später.
• Die Entwickler haben das Gefühl, mit dieser leichtgewichtigen Lösung nicht zu viel Zeit in die Benutzung eigentlich unbenutzbarer Zeiterfassungssysteme stecken zu müssen.
• Durch die Verwendung von Lego hat das Ganze zusätzlich eine spielerische Note bekommen, durch die alle Beteiligten deutlich motivierter sind.
• Das prominent sichtbare Sammeln der Steine im Team-Büro ist Teil des Informative Workspace geworden und gibt so dem Team kontinuierliches Feedback über die Zeiten die in bestimmte Aufgaben geflossen sind. (Genauso gut erkennt man „Waste“ im System).
• Die Informationen können auch gut in Retrospektiven genutzt werden.

Wir sind an Eurer Meinung zu diesem Ansatz der Zeiterfassung interessiert! Wollt Ihr das auch mal probieren? Was sind Eure Erfahrungen mit Zeiterfassungssystemen? Kennt Ihr andere, die einen ähnlichen Ansatz praktizieren? Bitte nutzt die Kommentarfunktion für Feedback!

Wenn es Herbst wird auf dem Task Board

Dreh- und Angelpunkt bei der täglichen Arbeit eines Scrum Teams ist das Task Board. Teams gestalten dies mit der Zeit individuell aus und nutzen auch verschiedene Materialien dafür. Die Bandbreite reicht von elektronischen Systemen über Post-its auf Wänden, Glasflächen oder Pinnwänden, bis zu Klebezetteln auf mobilen oder stationären Whiteboards. Wahrscheinlich gibt es aber noch tausend andere Arten Task Boards einzurichten.
Die meisten Scrum Teams, mit denen ich zu tun habe, scheinen  gerade den Ansatz der Post-its auf mobilen Whiteboards zu favorisieren. Dies hat den Vorteil, dass die Boards bei Bedarf mit im Scrum Meetings genommen werden können, die nicht in dem Team Raum stattfinden. Leider hat dieser Ansatz aber einen gravierenden Nachteil. Die Post-its halten nicht wirklich gut auf den Whiteboards und fallen gerne mal wie Blätter im Herbst über Nacht ab. Das passiert besonders dann, wenn die Zettel bereits mehrfach um gehangen worden sind. Die erste Lösung dafür ist, die Post-Its mit Magneten zu sichern. Aber das nervt nicht nur beim Umhängen der Karte, man braucht auch noch einen großen Vorrat an Magneten.

Mein Kollege Jesco hatte eine andere Idee das Problem zu lösen. Er nutzt zur Sicherung Magnetband, das auf den Klebestreifen der Post-its befestigt wird. Ich konnte ihn dazu überreden, seinen Ansatz, der mittlerweile von drei unserer Teams genutzt wird, in einem Youtube Video der Welt zu erklären (Danke Dir Jesco!). Aber seht selbst:

Satisfaction Histogram

Das Bauchgefühl des Entwicklungsteams kann ein wichtiger Indikator für Engpässe im Entwicklungsprozess sein.

Esther Derby und Diana Larsen beschreiben in ihrem Buch Agile Retrospectives: Making Good Teams Great* die Methode des Satisfaction Histograms. Bei CoreMedia habe ich die Methode über einige Sprints als Teil der Retrospektive genutzt und möchte hier darüber berichten. Auch die anderen ScrumMaster haben die Methode in ihren Teams übernommen.

Je nach Team wurden verschiedene Aspekte bewertet:

• Teamwork
• Sprint Deliverable Quality
• Product Quality
• Product Vision

Bei der Benotung habe ich mich an den im Buch vorgegebenen Beispiel für Teamwork orientiert. Hier z.B. meine Formulierungen für Product Vision und Product Quality:

Product Vision
1 = The vision is brilliant and directs to amazing success.
2 = I believe following the vision will lead to success. It motivates me.
3 = The vision is clear and understandable, but it doesn’t help much.
4 = To me the vision is not plausible. It doesn’t encourage me at all.
5 = I don’t know the product vision or I think following it is a complete waste of time.

Product Quality
1 = I think we have a perfect product! It is absolutely flawless.
2 = I am fully satisfied with the quality of our product.
3 = I’m fairly satisfied. Overall the quality is nothing to be ashamed of.
4 = We didn’t ignore quality, but it was not enough.
5 = I’m unhappy and dissatisfied. I lie awake at night because of our poor product quality.

Das Team hat anonym abgestimmt, den Durchschnitt berechnet und in ein Diagramm eingetragen, in dem man den bisherigen Verlauf sehen konnte. Anschließend wurde darüber reflektiert, insbesondere bei großen Ausschlägen oder wenn das Ergebnis überraschend ausfiel. Der Product Owner durfte mit abstimmen. Ich als ScrumMaster habe nicht mitgestimmt.

Mit der Zeit entstanden Verlaufskurven wie die folgende:

Die Abstimmung und das Diagramm dienten in vielen Fällen als Katalysator für Diskussionen: Schlechte Werte oder Tendenzen nach unten bildeten einen guten Ausgangspunkt für die Frage nach dem Warum. Oft hat die Diskussion Gründe aufgezeigt, die nicht offensichtlich waren. So hatte zum Beispiel ein starkes Absinken der Product Quality und Sprint Deliverable Quality (Sprint F) keine Ursache in technischen Veränderungen, sondern in verstärkter Analyse. Weniger überraschend war, dass die Qualität des Sprint-Deliverables stärker schwankt als die Qualität des Produkts insgesamt. Zum Teil waren die Tendenzen dort sogar gegenläufig (Sprint C), wenn z.B. nicht alle für den Sprint geplanten Stories umgesetzt werden konnten, aber ein unangenehmer Performance-Bug entfernt werden konnte. Die Messung der Product Vision zeigte, wann diese wieder aufgefrischt werden muss, wenn das Team sie im Tagesgeschäft mit der Zeit aus dem Blick verloren hat. Wichtig ist aber auch die Ergebnisse nicht überzuinterpretieren. Je nachdem wer gerade anwesend ist und je nach Tagesstimmung schwanken die Ergebnisse.

Insgesamt halte ich das Histogram für ein nützliches Mittel um ein objektiviertes Gefühl für verschiedene Aspekte des Entwicklungsprozesses zu bekommen. Mehr als vier Bereiche würde ich dabei nicht gleichzeitig betrachten, damit die Methode leichtgewichtig bleibt.

Im Buch wird empfohlen die Messungen nur alle paar Iterationen durchzuführen. Es ist richtig, dass sich mit der Zeit ein gewisser Ermüdungseffekt einstellt. Ich fand es allerdings wertvoll jeden Sprint einen Messwert zu haben, um Trendwenden zeitnah mitzubekommen.Wenn man feststellt, dass die Werte konvergieren bzw. kaum noch neue Erkenntnisse produzieren, sollte man die betrachteten Bereiche variieren.