Montag, 25. Dezember 2017
Das Increment als Geschenk
Reden wir über Geschenke. In meinem beruflichen Alltag als Scrum Master und/oder Agile Coach sind sie zwar nicht alltäglich, tauchen aber immer wieder auf, dann nämlich wenn ich im Rahmen von Workshops den Scrum-Flow mit seinen Rollen und Events auf ein Flipchart zeichne. An seinem Ende steht fast immer das Increment, also das benutzbare (Teil)Produkt. Und fast immer hat dieses Increment die Form eines Geschenks.
Dass ich meistens diese Darstellung wähle hat zum einen seinen Grund darin, dass viele Kunden, Auftraggeber und Stakeholder die regelmässige Auslieferung tatsächlich als Geschenk empfinden. Mit den Worten eines Managers eines DAX-Konzerns mit dem ich früher zusammenarbeiten durfte: "Früher haben wir zum Teil jahrelang warten müssen bevor irgendetwas zurückkam, jetzt habe ich das Gefühl als wäre alle zwei Wochen Weihnachten."
Der andere Grund ist der, dass ein Geschenk auch immer mit einer Erwartungshaltung an den Schenkenden verbunden ist. Ein Geschenk soll so ausgesucht sein, dass der Beschenkte es brauchen kann. Etwas das er noch nicht hatte und nach den er vielleicht schon länger vergeblich gesucht hat. Im besten Fall etwas das ihm Möglichkeiten aufzeigt an die er selbst noch gar nicht gedacht hat, die ihm aber sofort gefallen. Eigenschaften die sich idealerweise auch in jeder Produktneuerung wiederfinden sollten.
Zuletzt steckt im Geschenk auch implizit der Moment des Überreichens. Sei es mit oder ohne Geschenkpapier, das persönliche Geben und Entgegennehmen gehört dazu. Und mit der Zeit lernen wir durch die direkte Reaktion der Beschenkten wie es angenommen und bewertet wird, so dass wir beim nächsten mal eine noch bessere Auswahl treffen können. Auch das ist etwas was in den Beziehungen mit Auftraggebern und Kunden hochgradig Sinn macht.
In diesem Sinn: Schöne Bescherung.
Donnerstag, 21. Dezember 2017
Merit-Kalender
 |
| Bild: Pixabay / Hans Braxmeier - Lizenz |
Trotzdem tun sich viele Teams mit diesem Ansatz schwer. Es wird befürchtet, dass Beliebtheitswettbewerbe oder Klüngelrunden entstehen, dass manche Kollegen gar nicht belohnt werden oder dass sonstige Probleme auftreten. Um diese Sorgen zu zerstreuen kann es hilfreich sein zunächst einen Probelauf einzulegen, in dem ein Team noch ohne die finanziellen Folgen ein Merit-System ausprobieren kann. Ein Beispiel für einen solchen Lauf habe ich vor einiger Zeit mit einem von mir gecoachten Team durchgeführt - mit einem Adventskalender.
Es handelte sich genaugenommen nicht um nur einen Kalender sondern um mehrere (einen pro Teammitglied) hinter deren Türen sich Süßigkeiten befanden. Vor dem Daily Standup konnte jeder seine Süßigkeit des Tages an einen anderen vergeben, immer verbunden mit einer Begründung warum der sich das an diesem Tag verdient hatte. Bedingt durch den geringfügigen Wert war die Hemmschwelle deutlich geringer als sie es bei echten Boni gewesen wäre, gleichzeitig sorgte die tägliche Frequenz für einen schnellen Gewöhnungseffekt.
Selbst wenn sich die Weihnachtszeit durch den hohen Bekanntheitsgrad der Adventskalender besonders für solche Experimente anbietet kann man sie natürlich auch im restlichen Jahr durchführen. Und statt Süßkram können auch andere Belohnungen vergeben werden, von der Ernennung zum Mitarbeiter der Woche bis hin zu Wildcards mit denen Refactorings im Backlog hochpriorisiert werden können.
Letztendlich werden sich viele Teams auch nach erfolgreichen Probeläufen trotzdem gegen Merit Money-basierte Boni entscheiden, was auch in Ordnung ist. Mitunter behalten sie dann aber Elemente bei mit denen sie vorher experimentiert haben. Auch das ist dann bereits ein Mehrwert der sich gelohnt hat.
Montag, 18. Dezember 2017
Kontrollierte Experimente
 |
| Bild: Wikimedia Commons / Giorgio Selvini - CC BY 4.0 |
Ausgangspunkt eines solchen Experiment ist eine Verbesserungsidee, die irgendwann identifiziert wurde, z.B. in einer Retrospektive. Eine solche Idee könnte etwa sein, dass durch Pair Programming die Qualität einer Anwendung verbessert wird. Unerfahrene Teams setzen das häufig so um, dass sie sich einfach vornehmen mehr Pairing zu machen. Fragt man dann nach einiger Zeit ob es Verbesserungen gegeben hat kommen meistens unklare Antworten wie "vom Gefühl her ja, genau belegen kann ich es aber nicht".
Um derartige Situationen zu vermeiden hilft es, wenn man sich zu Beginn einige Gedanken macht: Welche Maßnahmen wollen wir konkret umsetzen? Wie wollen wir die Erreichung messen? Wann wollen wir die Messung vornehmen? Was passiert wenn wir unser Ziel erreicht, bzw. nicht erreicht haben? Am weiter oben genannten Beispiel würde das bedeuten: Um die Qualität der Anwendung zu verbessen wollen wir mindestens zwei Pairing Sessions pro Woche durchführen. Wir messen die bessere Qualität anhand der Zahl der nötigen Anpassungen die sich aus den folgenden Code Reviews ergeben, diese Zahl wollen wir halbieren. Wir überprüfen nach einem Monat wie sich diese Zahlen entwickelt haben. Wenn keine Veränderung sichtbar ist beenden wir das Pairing, wenn es zwar eine Verbesserung gibt aber nicht in der angestrebten Größenordnung diskutieren wir nochmal darüber.
Neben der besseren Überprüfbarkeit des Erfolgs ist bei diesem Vorgehen noch ein zweiter Vorteil hervorzuheben: wirkungslose Verbesserungsmassnahmen können einfach wieder rückgängig gemacht werden. Einer der häufigsten Einwände gegen Prozessverbesserungen ist, dass man die neu eingeführten Schritte nie wieder los werden kann. In dem Moment in dem klar wird, dass das im Misserfolgsfall sehr wohl geht gehen die Widerstände dagegen zurück.
Donnerstag, 14. Dezember 2017
Stillarbeit
 |
| Bild: Freegreatpictures / Max Pixel - CC0 1.0 |
Auch die Moderationsversuche des Scrum Masters hatten nicht das gewünschte Ergebnis sondern führten dazu, dass das Team jetzt auch mit ihm unzufrieden war. Die Extrovertierten nahmen es so wahr als würde er ihnen ständig ins Wort fallen, die Introvertierten fühlten sich auf unangenehme Weise bedrängt und ins Scheinwerferlicht gestellt. Moderation war also auch nicht die Lösung, zumindest nicht mit einem darin noch relativ unerfahrenen Moderator.
Der Ansatz der die Situation spürbar verbessern konnte war die so genannte Stillarbeit. Jeder Teilnehmer der nächsten Retrospektive wurde gebeten zunächst in Ruhe seine Themen auf Post Its zu schreiben. Danach wurden sie der Reihe nach vorgestellt (Diskussionen wurden an der Stelle noch wegmoderiert), gemeinsam priorisiert und erst danach der Reihe nach diskutiert. Bei der kurzen "Retro der Retro" am Ende gab es für diese Art der Durchführung durchweg positives Feedback.
Die Diskussion hatte zwar immer noch ein gewisses Ungleichgewicht, allerdings hatte jeder Teilnehmer seine Themen in Ruhe vorstellen können, so dass die Introvertierten sich weniger übergangen fühlten und die Extrovertierten nicht mehr das Gefühl hatten alleine Input liefern zu müssen. Für den Scrum Master wurde ausserdem die Moderation einfacher, da er die bereits vorgestellten Themen als Ausgangspunkt für weiterführende Fragen nutzen konnte und nicht mehr ständig darum bitten musste, dass überhaupt Beiträge geliefert wurden.
Natürlich ist diese Art der Themensammlung nicht immer die passende, in diesem und in anderen Fällen hat sie von mir gecoachten Teams aber sehr geholfen und ist später auch in andere Meetings übernommen worden.
Montag, 11. Dezember 2017
Kick the ball out of the tent
Ein Parforce-Ritt durch eine ganze Reihe von Aspekten: Wasserfall, Komplexität, Lean, Agile, Flow, Prinzipien, Prognosen und vieles mehr. Erkennbar für ein Publikum ohne vertiefte Vorkenntnisse gedacht und gerade deshalb geeinet für jeden der Inspirationen für seine eigenen Einführungsworkshops braucht.Ähnlich wie ich experimentiert Kniberg anscheinend mit seinen Vorträgen und verändert sie immer wieder, im wesentlichen sind die Folien aber mit diesen hier identisch.
Donnerstag, 7. Dezember 2017
User Stories
 |
| Bild: Pxhere - CC0 1.0 |
Um im Sinn des agilen Prinzips Maximizing the amount of work not done vozugehen lohnt es sich darüber nachzudenken wie man die Menge neu implementierten Codes so gering wie möglich halten kann. Ein weithin beliebter Ansatz ist dabei die Fokussierung auf den (End)Anwender. Nur was der tatsächlich benutzen kann ist von Wert, alles andere kann im Zweifel weggelassen werden. Folgerichtig sollten Anforderungen idealerweise auf Use Cases (Anwendungsfällen) beruhen.
User Stories greifen diese Idee auf und reichern sie um weitere Elemente an: in verständlicher Sprache erklären sie wer der Anwender ist, welche neue Funktion er braucht/bekommt und welcher Mehrwert damit verbunden ist. Neben dem oben genannten häufigsten Muster gibt es auch andere Variationen, etwa Um [Ziel ... zu erreichen] ermöglichen wir [Benutzer mit Rolle ...] die Aktion [...] durchzuführen oder ganz schlicht Nutzer: [...], Aktion: [...], Mehrwert: [...].
Natürlich werden trotzdem immer wieder Anforderungen auftauchen die nicht in dieses Muster passen: Arbeit an technischen Komponenten, Anpassungen an Architekturvorgaben, Bugfixes, Absicherung durch Tests, Code Cleaning, Abbau technischer Schulden, etc. Da viele von ihnen ein Zeichen von fehlender Anwender-Zentrierung oder (Spät)Folgen nachlässiger Arbeit sind kann es hilfreich sein das Verhältnis zu tracken: wieviel Prozent der umgesetzten Anforderungen sind User Stories und wie viele nicht? Bei einem zu niedrigem User Story-Anteil kann sich ggf. eine Retrospektive lohnen.
PS: es gibt leider auch Teams in denen der Begriff User Story ein generisches Synonym für Anforderungen aller Art ist. Mitglieder dieser Teams mögen sich bitte zur Behandlung in der nächsten Coach-Klinik melden.
Montag, 4. Dezember 2017
Scaled Agile: Chief Product Owner
 |
| Bild: Flickr / Rod Waddington - CC BY-SA 2.0 |
Wenn Teams nach Scrum arbeiten gilt in Bezug auf die Rolle des Product Owners das Highlander-Prinzip: Es kann nur einen geben. Der Scrum Guide formuliert das an gleich zwei Stellen sehr eindeutig: "For Product Owners to succeed, the entire organization must respect their decisions." und "The Product Owner is one person, not a committee." Für ein einzelnes Team ist das auch nachvollziehbar, aber was passiert wenn mehrere Teams zusammenarbeiten müssen? Einen Ansatz findet man in diesem Kontext immer wieder.
Passend zum teamübergreifenden Konstrukt des Tribes findet man in vielen Organisationen die Rolle des Chief Product Owners oder CPO (auch Head PO, Lead PO, o.ä.), der hierarchisch oberhalb der eigentlichen Product Owner angesiedelt ist. Wie diese Rolle aussieht wenn sie mit Scrum kollidiert wäre ein eigenes Thema, bezogen auf "Scrum by the Book" gibt es aber die klare Grenze, dass der eigentliche Product Owner nicht in seinen Kompetenzen eingeschränkt werden darf. Die spannende Frage: ist das überhaupt möglich? Welcher Spielraum bliebe noch für eine zusätzliche Rolle?
Eine Möglichkeit wäre diese: Das Produktmanagement-Themenfeld das der Scrum Guide für höhere Ebenen zugänglich hält ist die initiale Auswahl, bzw. Definition der Produkte, verbunden mit dem Setzen der Produktziele. Es heisst zwar "The Product Owner is [...] accountable for effective Product Backlog management, which includes: Developing and explicitly communicating the Product Goal.", aber das Entwickeln und Kommunizieren eines Produktziels ist eben etwas anderes als dessen Auswahl. Ein CPO kann also Produkte und deren Ziele (vor)auswählen, um sie dann den POs und deren Teams zu übergeben.
Was in Scrum explizit nicht zum Aufgabenbereich eines CPO gehören kann ist im Anschluss daran die Arbeit an den Backlogs, er soll also weder eine Ausdetaillierung der Backlog Items vornehmen noch spezifische Arbeitsaufträge an die Teams vergeben oder deren Reihenfolge oder Priorität festlegen. Das bleibt dem PO vorbehalten, der dafür auch Teil mehrerer Scrumteams sein kann (was so seit 2020 auch explizit im Scrum Guide steht und nicht mehr implizit daraus abgeleitet werden muss).
Diese Aufteilung in CPO (ausserhalb des eigentlichen Scrum) und PO (offizieller Teil von Scrum) kann in der Anwendung schnell künstlich wirken und im schlimmsten Fall zu Konflikten führen, durch die Ressourcen gebunden und die Organisation gelähmt werden. Im Rahmen des Scrum-Frameworks ist es aber die einzige mögliche Aufteilung. Das heisst zwar nicht, dass man nicht alles anders organisieren könnte - aber dann ist es kein Scrum mehr.
Nachtrag 26.02.:
Eine Übersicht über andere Interpretationen der Chief PO-Rolle gibt es hier.
Donnerstag, 30. November 2017
Kommentierte Links (XXXI)
 |
| Grafik: Pixabay / Geralt - Lizenz |
Mary Poppendiek: The cost center trap
Ich sage ja: ein Scrum Master sollte über den Tellerrand blicken und wirtschaftliche Zusammenhänge kennen. Mary Poppendiek beschreibt einen weiteren guten Grund dafür - das Center-Konzept, das in vielen Unternehmen verbreitet ist. Wenn die Softwareentwicklung eines Unternehmens als Cost Center (oder Service Center) gilt und nicht als Profit Center, dann besteht das dauerhafte Risiko im wahrsten Sinn des Wortes kaputtgespart zu werden. In einer solchen Situation kann man mit agilen Ansätzen bestenfalls Symptome abschwächen. Bevor es zu strukturellen Verbesserungen kommt muss das zentrale Impediment beseitigt werden: die Center-Zuordnung in ihrer bisherigen Form.
Jason Little: We don't need agile leadership
Hinter diesem Artikel stehen zwei Aussagen. Zum einen die, dass es sich bei den meisten Begriffen die "agile" als Präfix haben um Unsinn handelt. Speziell das aktuell gehypte agile Leadership hat erkennbar den primären Zweck Lehrgänge und Zertifikate zu verkaufen. Wirklich Bemerkenswertes findet man hier selten. Interessanter finde ich die zweite: Jason Little geht davon aus, dass der typische agile Coach ständig auf der Suche nach Neuem ist (oder wie er es sagt - schnell gelangweilt). Bedingt dadurch werden auch die obskursten Ideen durchdiskutiert und ausprobiert. Da ist leider etwas dran. Andererseits - wie sonst soll man diese Ansätze bewerten können?
John Cutler: The trouble with Scrum
Ein Thema das immer wieder aufkommt. Man kann sich komplett an alle Scrum-Regeln halten und trotzdem kann das Ergebnis unbrauchbar sein. Zweifellos richtig. Was John Cutler als "mechanistisches Scrum" bezeichnet kann auf derartige Effekte herauslaufen. Viele agile Practicioner (darunter auch ich) würden das allerdings nicht als echte Umsetzung betrachten sondern als Cargo Cult. Das zu erklären und zu begründen ist mittlerweile eine der Hauptaufgaben von agile Coaches und Scrum Mastern geworden, und dazu eine die dauerhafte Beschäftigung verspricht. Denn dass die mechanistischen Lösungen eine magische Anziehungskraft auf klassische Manager ausüben kann man in fast jeder größeren Firma erleben.
Anna Steiner: So einfach geht Elektroauto
Was Anna Steiner hier zur Firma Streetscooter zusammengetragen hat klingt sehr nach agiler Produktentwicklung. Die hier hergestellten Elektroautos sind MVPs (sie sind in der ersten Generation nur auf kurzen Strecken und in gemäßigten Klimazonen nutzbar), sie werden modular und iterativ weiterentwickelt (mit neuen Funktionalitäten in jedem Produktzyklus) und nach jeder dieser Iterationen können die Nutzer Feedback und Weiterentwicklungswünsche abgeben, die zügig in die Planung aufgenommen und umgesetzt werden. Verabschiedet hat man sich dafür von dem an Overengeneering grenzenden Perfektionismus, der im deutschen Ingenieurwesen noch immer vorherrscht. Man kann gespannt sein wie dieser Geist nach der Übernahme durch den Großkonzern Deutsche Post weitergetragen wird.
Ron Miller: How bad decision making could undermine good innovation
Wie man auf englisch sagt - der Niedergang von Kodak ist eine Geschichte "that keeps on giving". Nachdem ich schon vor drei Monaten eine Analyse des damaligen Management-Verhaltens verlinkt hatte führt Ron Miller in weitere Aspekte ein: die Firma Kodak hat nicht nur die Technologie von der sie vom Markt gefegt werden sollte (Digitalfotografie) selbst entwickelt, sie hat sie sogar selbst an den Markt gebracht. Das allerdings so sehr im Rahmen der bisherigen Produktstrategie, dass für die Nutzer kaum relevanter Mehrwert entstand. Erst als andere Firmen die neue Technologie auch in neuen Kontexten einsetzten wurden sie zu einer Disruption. Man kann erahnen welcher gewaltige Mindset-Change hier für agiles Reagieren notwendig gewesen wäre.
