Sprint Reviews in der Produktentwicklung

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

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

Wer nimmt an unserem Sprint Review teil?

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

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

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

Was wird gezeigt?

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

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

Was machen wir mit dem Feedback?

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

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

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

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

Wer zeigt was?

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

Wie lange dauert so ein Review Meeting?

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

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

Literatur

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

(2) Andresen, Judith: Agiles Coaching*

(3) Agile Product Management with Scrum*

(*) Affiliate-Links.

 

Aber freitags sind wir freundlich!

Es ist schon kräftezehrend. Da muss man als Scrum-Master oder Team-Mitglied eines Scrum-Teams immer wieder Leute, die mit ihrem Anliegen in den Raum kommen, wegschicken. Man will ja schließlich ungestört und konzentriert an dem Sprint-Ziel arbeiten! Und daher wird ein Kollege oder eine Kollegin aus einem anderen Team mit ihrer fachlichen oder technischen Frage öfters mal schroff abgewiesen (es sei denn, es ist wirklich sehr wichtig).
Und dazu die enttäuschten, genervten oder wütenden Gesichter der so Abgewiesenen! Da nagt auch bei dem einen oder andern hartgesottenen Entwickler das schlechte Gewissen.
Das war dann letztendlich mit ein Grund dafür, dass in einem meiner Teams die Idee aufkam, dass man die Hilfesuchenden doch wenigsten an einem Tag der Woche nicht so schroff abweisen und sie im Gegenteil einfach mal freudig begrüßen sollte.

Damit war er geboren, der freundliche Freitag (oder wie wir sagen friendly Friday).

Ab sofort werden freitags „Eindringlinge“ fröhlich begrüßt – etwa mit einem von möglichst vielen gerufenen “Hey Holger, schön, dass du da bist! Juhhei!” Außerdem nimmt man sich im Team dann eher die Zeit, die Anliegen der Besucher in Ruhe anzuhören und ihnen dann, wenn möglich, auch zu helfen.
Am ersten Freitag, an dem wir das praktiziert hatten, waren sich viele Besucher nicht sicher, ob wir das ernst meinen. Aber mittlerweile entlocken wir diesen fast immer ein Lächeln. Es ging sogar so weit, dass ein Kollege nur in den Raum gekommen ist, um sich den wertschätzenden Begrüßungsruf abzuholen und anschließend den Raum mit einem Lächeln zu verlassen. Das trägt dann mit zu einem verbesserten Verhältnis zu anderen Teams bei.

Also, probiert es mal aus. Erfahrungen dürft ihr gerne in die Kommentare schreiben!

Pipeline – ein Teambuilding Spiel

Letztes Jahr konnte ich leider nicht dabei sein, aber dieses Jahr habe ich ihn mir nicht entgehen lassen: Der Agile by Nature Play Day will für die tägliche Arbeit spielerische Formen finden und fördern, um beim Lernen zu helfen. 24 Spielwillige trafen sich in den Räumen von sitegeist in Hamburg, stellten sich gegenseitig Spiele vor und networkten über kalten Getränken. Bilder von dem Tag gibt es auf der Webseite von Agile by Nature zu sehen.
Von den vielen interessanten Sessions stelle ich hier als erstes ein Spiel aus der Session „Teambuilding Spiele“ von Hendrik vor.

Pipeline
Bei Pipeline geht es darum, im Team eine rollende Kugel in ein Ziel zu befördern. Dazu bekommt jedes Team einige Rinnen. Die Anzahl variiert mit der Anzahl der Teammitglieder. Es sind immer deutlich weniger Rinnen als Mitspieler. Das Team muss schnell und geschickt Rinne an Rinne reihen, während die Kugel durch diese rollt. Leider ist die Gesamtlänge aller Rinnen kürzer als die zu überwindende Strecke …

Es gibt die folgenden einfachen Grundregeln:

• Die Kugel muss jederzeit vorwärts durch eine Rinne rollen.
• Kein Teilnehmer darf die Kugel berühren.
• Eine Rinne darf nur von genau einem Team-Mitglied gehalten werden.
• Wenn jemand eine Rinne mit der Kugel in der Hand hat, dann darf diese Person sich nicht mit der Rinne im Raum bewegen.

Material:

• Mehrere Rinnen (z.B. Regenrinnen aus dem Baumarkt)
• Eine Kugel, die in die Rinne passt

Lernziel ist es, dass sich das Team koordinieren muss, um die Kugel ins Ziel zu bringen. Die Kugel kann alles mögliche repräsentieren, z.B. ein Software-Artefakt, das erstellt und deployed werden soll.
Das Spiel lässt sich leicht an den jeweiligen Kontext anpassen, z.B. durch Hinzufügen oder Anpassen von neuen Regeln oder durch Aufteilung in mehrere Teams, die gegeneinander antreten müssen. Auch die Aufgabe kann angepasst werden, z.B. indem ein Team mehrere Kugeln ins Ziel bringen und deren Durchlaufzeit kontinuierlich reduzieren muss.
Eine weitere Variationsmöglichkeit ergibt sich durch die Art des Zielbehälters. In unserem Fall war dies eine flache Plastikbox. Das hat den Schwierigkeitsgrad erhöht, da die Kugel leicht über das Ziel hinausschießen kann. Eine breite Tonne oder ein Eimer als Ziel wäre meiner Meinung nach einfacher gewesen.

Hier eine Aufnahme von einem unserer grandiosen (Fehl-) Versuche:

Mein Fazit zum Play Day

Der Play Day ist eine super Veranstaltung, auf der man viel lernt und neue Bekanntschaften macht.

Besonders empfehlenswert ist er für Agile Coaches und solche, die es werden wollen. Im kommen Jahr will ich unbedingt wieder dabei sein und möglichst ein eigenes Spiel vorstellen. So kann man in freundlicher Umgebung die Moderation eines Spiels üben, bevor man es am eigenen Team ausprobiert.

Also, einen Daumen hoch für die Veranstaltung!

Ich werde in ein, zwei Blog Posts noch weitere Spiele vorstellen, die ich kennenlernen durfte.

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.

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:

Wake-Up Call für das Daily-Scrum

Die meisten Menschen, die ich kenne, werden morgens lieber mit Musik als mit den nervigen elektronischen Tönen von einfachen Weckern geweckt.

Besonders eindrucksvoll ist das zu beobachten, wenn ich morgens versuche meine Tochter aus dem Bett zu bekommen damit sie noch pünktlich zur Schule kommt. Wenn sie langsam mit Musik geweckt wird, gestaltet sich nicht nur der gesamte Prozess bis sie aus der Tür ist deutlich einfacher – sie scheint auch mit mehr Schwung und Energie aus dem Haus zu gehen.

Was hat das jetzt mit Scrum zu tun? Nun, in einigen unserer Teams gibt es manchmal einen ähnlichen Effekt, und zwar wenn es um das Daily-Scrum geht. Die haben ihr Stand-up Meeting morgens. Da wir aber flexible Arbeitszeiten haben, ist es so, dass einige der Kollegen bereits deutlich früher zur Arbeit kommen, während andere erst kurz vor dem Stand-up erscheinen.

Dies führt dazu, dass einige Teammitglieder vor dem Daily-Scrum bereits mit ihrer Arbeit begonnen haben und in ihre Aufgaben, gerne auch mit anderen im Pair-Programming, vertieft sind. Dabei verliert man schnell die Uhr aus dem Auge, so dass sie vom Scrum Master oder anderen Teammitgliedern zum Stand-up “geweckt” werden müssen. Das kann auch mal das gesamte Team betreffen.
Im Idealfall  sollte ein Scrum Team zwar von selbst und ohne Aufforderung durch den Scrum Master zum Stand-up erscheinen. In der Realität kommt es meiner Erfahrung nach immer wieder vor, dass ein Team dabei ist, den Termin aus den Augen zu verlieren, etwa weil “Prozess-Treiber” nicht da sind oder alle schon zu sehr in ihre Arbeit vertieft sind.

Um das “STAND-UP!”-Gerufe am morgen zu vermeiden, bin ich irgendwann mal auf die Idee gekommen, ein bis zwei Minuten vor dem Daily-Scrum einfach mal die Aktivlautsprecher an meinem Arbeitsplatz-PC einzuschalten, den Lautstärkeregler ordentlich aufzudrehen und dann “Get up Stand Up” vom Altmeister Bob Marley zu spielen, auch wenn der Song eigentlich nur vom Titel zum Stand-up passt (aber das ist eine andere Diskussion). Der Effekt war ähnlich wie bei meiner Tochter. Zunächst blickten alle erst mal verw​undert auf und einige Momente später hatten sie die Verbindung zwischen der Musik und dem Daily-Scrum hergestellt und kamen zum Stand-up. Irgendwann habe ich damit angefangen das von Zeit zu Zeit zu wiederholen, auch wenn die Teammitglieder schon alle das Stand-up auf dem Zettel hatten. Die  Kollegen versammeln sich mit Musik deutlich beschwingter zum Daily-Scrum, ähnlich wie meine Tochter nach dem Wecken mit Musik beschwingter und besser gelaunt beim Frühstück erscheint.

Die Idee, Teams mit Hilfe der Musik zusammenzutrommeln, hatten auch schon andere. Jason Yip beschreibt auf martinfowler.com wie ein gutes Stand-up Meeting aussehen könnte. Musik als Opener spielt in dem beschriebenen Szenario eine wichtige Rolle.

Nach Yip soll ein gutes Stand-up Meeting und damit ein Daily-Scrum den GIFTS-Kriterien entsprechen. GIFTS steht dabei für Good Start, Improvement, Focus, Team und Status. Sind die Kriterien erfüllt, so sind im Stand-up, oder in unserem Fall  im Daily-Scrum, tatsächlich viele schöne Gaben (engl. gifts) für das Team enthalten. Wir werden in einem späteren Blog- Beitrag noch mal zu den GIFTS-Kriterien zurückkehren. Für diesen Beitrag ist zunächst nur „good start“ interessant. Gerade die Musik und das lockere Zusammentrommeln für das Stand-Up sollen helfen, den Start in den (Entwicklungs-) Tag angenehm, gut und energiereich zu gestalten . Genau dabei hilft den Scrum Teams und meiner Tochter die Musik.

Natürlich wird es irgendwann langweilig immer nur die gleiche Musik zu spielen. Man kann entweder andere für das Team angenehme Stücke oder auch Cover-Versionen des  Bob Marley Songs heraussuchen. Bei einer einfachen Suche auf YouTube hatte ich die folgenden Version gefunden:

• Eric Clapton, Roger Waters & Nick Mason – Get Up Stand Up
• Fonta – Get Up Stand Up
• John Butler – Get Up Stand Up Toy Session
• POD – Get up, stand up
• Red Hot Chili Peppers – Get Up, Stand Up
• Ben Harper, Oppression – Get Up Stand Up Live
• Get up stand up Exodus – Tribute to Santana
• Bruce Springsteen, Peter Gabriel, Sting, Tracy Chapman, Youssou N’Dour – Get Up Stand Up
• The Rolling Stones – Get Up Stand Up (live Bob MarleyPeter Tosh cover)

Ich kann nur empfehlen, den Stand-up-Call mal mit Musik zu versuchen (wenn es die Gegebenheiten zulassen). Ich bin gespannt von den Erfahrungen anderer zu hören und/oder weitere Song-Vorschläge zu bekommen.

Synchronisation von Scrum Teams mit Boundary Stories (Teil1)

Bei der Skalierung von Scrum wird von der Literatur häufig empfohlen, ein großes Team, das an einem gemeinsamen Projekt arbeitet, in mehrere kleinere Teams aufzuspalten, die dann als Feature Teams unterwegs sind und über ein Scrum of Scrums koordiniert werden.
Leider lässt sich dieser Optimalfall nicht immer so einfach umsetzen. Es kann durchaus sein, dass die Komplexität eines Software-Produkts es den Entwicklungsteams sehr schwer macht, einzelne Features durch verschiedene Module bzw. Komponenten hindurch zu implementieren. In diesen Fällen macht es dann, wie zum Beispiel bei CoreMedia, mehr Sinn, dass Scrum Teams einzelne Komponenten weiterentwickeln.

Schwierig wird es dann, wenn die einzelnen Komponenten nicht unabhängig voneinander sind. In diesem Fall ist auch die Arbeit der einzelnen Teams nicht unabhängig voneinander. Da Scrum-Teams ihrer Arbeit über die User-Stories planen, kann es Abhängigkeiten zwischen den Stories einzelner Teams geben. Diese Abhängigkeiten können uni- oder bidirektional sein. Unidirektional bedeutet, dass ein Team an einer Story arbeitet, bzw. arbeiten muss, auf die ein anderes Team wartet. Bei der bidirektionalen Abhängigkeit zwischen Stories arbeitet ein Team A an einer Story, die von einem anderen Team B benötigt wird. Gleichzeitig benötigt Team A auch die Implementierung einer anderen Story von Team B.

So entsteht ein Geflecht von Abhängigkeiten zwischen den Stories unterschiedlicher Teams, welches die Releaseplanung für ein Gesamtprodukt beeinflusst. Gerade Ketten von Abhängigkeiten sind dabei interessant. Nehmen wir als Beispiel ein Team A, dass eine Funktion bauen soll, für die erst ein Team B eine API in seiner Komponente ändern muss. Wenn nun für die Story von Team B weitere Funktionalität von einem Team C benötigt wird, entsteht eine Kette von Abhängigkeiten. Diese Kette ist bei der übergeordneten Releaseplanung für das Produkt zu berücksichtigen, da Verzögerungen bei den einzelnen Stories von Team B und Team C dazu führen, dass sich entweder das Release verzögert, oder aber Features der Story von Team A nicht im Release des Gesamtprodukts enthalten sind.

Um schnell reagieren zu können, muss den Vertretern der jeweiligen Teams für das Scrum of Scrums die Abhängigkeiten zwischen den Stories der Teams bewusst sein. Die Verantwortung solche übergreifenden Stories zu koordinieren liegt letztlich bei der Gruppe der Product Owner bzw., wenn diese Rolle vorhanden ist, bei einem Chief Product Owner.
Es gibt also eine Reihe von Personen, die sich über diese Art von Stories verständigen müssen. Bei der Diskussion der betroffenen Teams untereinander (genauso wie für die Beschreibung in einem Blog-Beitrag) ist es extrem hilfreich, wenn sie sich von der Bezeichnung her von „normalen“ User-Stories unterscheiden lassen. Die Bezeichnung sollte

• kurz, prägnant und damit einprägsam sein,
• widerspiegeln, dass es sich um eine Klasse von User Stories handelt, und
• noch nicht anderweitig belegt sein.

Als Lösung dafür bin ich auf den Gedanken gekommen, Stories, die einen Einfluss auf Stories anderer Teams haben oder von anderen beeinflusst werden, als Boundary Stories zu bezeichnen.
Der Begriff hat meines Erachtens nach alle Merkmale, die oben gefordert sind.

Das „Stories“ in Boundary Stories macht zunächst klar, dass es sich um eine Story im Sinne von Scrum handelt. „Boundary“ hat zwei Aspekte, die die Verwendung rechtfertigen; eine Boundary ist gleichzeitig eine Verbindung und Grenze.

Stories versprechen die Umsetzung einer vom Kunden gewünschten Funktionalität. Ist der Kunde direkt oder indirekt ein Team, das für eine andere Komponente zuständig ist, so stellt die Story die Verbindung zwischen den Teams dar.

Gleichzeitig ist es in Scrum den Teams überlassen, wie und mit welchen Mitteln, sie Stories umsetzen. Damit stellen Stories generell auch eine Grenze dar, nämlich die zwischen dem Implementierungsteam und dem Product Owner. Etwas weiter gefasst stellen sie damit eine Grenze zwischen den Teams dar.

Zusätzlich wurde der Begriff von mir bewusst in Anlehnung an den Begriff Boundary Object aus der Soziologie gewählt. Das Konzept der Boundary Objects wurde von Susan Leigh Star und James R. Griesemer 1989 publiziert:

“Boundary objects are both plastic enough to adapt to local needs and constraints of the several parties employing them, yet robust enough to maintain a common identity across sites. They are weakly structured in common use, and become strongly structured in individual-site use. They may be abstract or concrete. They have different meanings in different social worlds but their structure is common enough to more than one world to make them recognizable means of translation. The creation and management of boundary objects is key in developing and maintaining coherence across intersecting social worlds.”

Quelle: Star SL & Griesemer JR (1989). “Institutional Ecology, ‘Translations’ and Boundary Objects: Amateurs and Professionals in Berkeley’s Museum of Vertebrate Zoology, 1907-39”. Social Studies of Science 19 (4): 387–420.

Sicherlich lässt sich das Konzept nicht eins zu eins in die Welt der Software-Entwicklung übertragen, es gibt aber einige Parallelen, die so groß sind, dass sie den Vergleich von User Stories mit Boundary Objekten zulassen.

Wie bereits erwähnt, sind bei CoreMedia einzelne Teams für bestimmte Komponenten zuständig, d.h. es gibt keine Feature Teams. Auch wenn sich die Teams in der Zusammensetzung ähneln und die Teammitglieder in der Regel einen ähnlichen Ausbildungshintergrund (meistens Softwareentwickler) haben, gibt es trotzdem in jedem Team eine leicht unterschiedliche (Team-) Kultur.
So haben die einzelnen Teams beispielsweise unterschiedliche Strategien zur Erledigung der täglichen Arbeit entwickelt. Einige Teams malen Burn-Down-Charts, andere Burn-Up-Charts und wiederum andere machen nichts dergleichen. Auch die Meeting Kultur ist ganz unterschiedlich geprägt. Einige haben spezielle Architektur-Meetings, andere nicht.
Eine besondere Ausprägung der unterschiedlichen Team-Kultur spiegelt sich in der Weise wieder, in der die einzelnen Teams auf Task-Karten die jeweiligen aktuellen Bearbeiter vermerken: Einige schreiben Kürzel an die Task-Karten an den Scrum Boards, andere wiederum verwenden dazu Magnete, die sie mit Bildern oder kleinen Lego-Figuren (bzw. „Lego-Avataren“) beklebt haben.
Auch beim Schätzen von Stories und Tasks werden teilweise unterschiedliche Techniken verwendet, so dass man durchaus von Unterschieden in den Teamkulturen sprechen kann.
Star und Griesemer sprechen davon, dass Boundary Objekte dazu dienen, die kulturellen Barrieren zu überwinden. In unserem Fall ist die Barriere zwar recht klein, trotzdem machen sich auch kleine Unterschiede schon bei Personalwechseln zwischen Teams bemerkbar. Es gibt demnach aus Sicht der Team-Kultur durchaus eine kleine Grenze zwischen den Teams.

Wichtiger noch mit Blick auf Barrieren ist die Tatsache, dass einzelne Teams Experten für bestimmte Komponenten sind. Dadurch arbeiten sie teilweise sogar mit unterschiedlichen Basistechnologien (etwa auch unterschiedlichen Programmiersprachen). Selbst wenn Entwickler aus anderen Teams mit den verwendeten Basistechnologien sowie den groben Architekturentscheidungen vertraut sind, werden sie in anderen Teams in der Regel bei der Architektur im Kleinen bzw. bei einzelnen Tasks wenig Überblick haben. Wenn sich Entwickler Taskboards anderer Teams ansehen, können sie daher in der Regel nicht bei jeder Task sofort erkennen, was genau damit gemeint ist. Das wird dadurch verstärkt, dass sich in den Teams teilweise unterschiedliche Standards etabliert haben, was das Formulieren von Task-Karten angeht. Dies macht es Personen von außerhalb des Teams zusätzlich schwerer, die Tasks zu verstehen.
Es gibt also zwischen den Teams Barrieren, die auf einem unterschiedlichen Vokabular (induziert durch die verwendeten Basistechnologien sowie den Formulierungsstandards von Tasks) und unterschiedlichen Normen bezüglich der Task-Karten basieren.

Viele Scrum Teams haben physikalische Task Boards, auf denen sie Story Karten aufkleben oder anpinnen. Aufgrund der physikalischen Story Karten passt auch die Aussage von Star und Griesemer, dass es sich bei Boundary Objekten um Objekte aus der physikalischen Welt handelt. Das ist für das Konzept von Boundary Stories allerdings nicht ausschlaggebend.

Insgesamt sind die Parallelen zwischen Boundary Stories und Boundary Objects nicht so abwegig, so dass die Begriffsähnlichkeit aus meiner Sicht legitim ist.

Boundary Stories fallen nicht vom Himmel; sie müssen in der Menge der User Stories in den Backlogs der einzelnen Product Owner gefunden und als solche markiert werden. Im einfachsten Fall passiert das in den Schätzklausuren und Sprintplanungen, in denen einzelne Teams überlegen müssen, ob eine Story bereits Ready ist, also alle Voraussetzungen für ihre Abarbeitung gegeben sind, oder nicht. Werden für die Umsetzung von Funktionalität erst Arbeiten von einem anderen Team benötigt, so ist die Story automatisch eine Boundary Story. Gleichzeitig muß der Product Owner die gewünschte Funktionalität über den Product Owner des anderen Teams anfordern. Die dazugehörige User-Story ist in dem anderen Team automatisch eine Boundary Story.

Schwieriger ist es mit Stories, die andere Teams eher ungeplant betreffen, etwa weil durch sie Funktionalität geändert wird. In diesem Fall müssen die Entwickler und der Product Owner gemeinsam überlegen, ob Stories andere Teams betreffen werden oder nicht. Die POs müssen dieses Thema ebenfalls diskutieren und entsprechende Stories als Boundary Stories markieren. Das wichtigste ist, dass in den Teams Bewusstsein für Boundary Stories geschaffen wird, damit die einzelnen Scrum Teams besser zusammenarbeiten und so Risiken in der übergeordneten Releaseplanung verringern.

Boundary Stories werden bei uns mit einem Look-ahead von 12 Wochen in den Backlogs der Product Owner markiert (also in der Regel 6 Sprints). Dazu wurde eigens eine neue Spalte in den Execl Standard-Vorlagen der Product Owner eingeführt.

In dem nächsten Blog Beitrag werden Holger und ich schildern, wie wir mit den Boundary-Stories bei CoreMedia umgehen und wie wir sie zur einfacheren Koordination visualisieren.