Montag, 28. Mai 2018

Datengetriebene Retrospektiven

Bild: Pexels / Lukas - Lizenz
Nachdem ich in der letzten Woche von Klaus Leopold in dessen unverwechselbarer Art mit Zahlen bombardiert wurde möchte ich dieses Thema auch hier aufgreifen. Agile Vorgehensweisen nehmen für sich in Anspruch, dass sie empirisch basiert und datengetrieben sind, und die naheliegendste Verwendung der erhobenen Zahlen ist ihre Nutzung als Teil des ständigen Verbesserungsprozesses. Ein guter Moment dafür sind die Retrospektiven, in denen die Metriken gemeinsam analysiert werden können. Erfahrungsgemäss bieten sich dann je nach Art der Metrik unterschiedliche Massnahmen an.

Cycle Time

Die Zeit zwischen dem Beginn einer Umsetzung und deren Ende, wobei am Ende ein Produktinkrement stehen sollte das jederzeit live gehen könnte. Im Sinn der Agilität sollte diese Zeit möglichst kurz sein, sollte das Team sie als zu lang empfinden können Massnahmen beschlossen werden um das zu beschleunigen. Dazu gehören z.B. das Kleinerschneiden von Anforderungen oder das Automatisieren von Tests.

Lead Time

Entspricht der Zeit zwischen dem ersten Aufkommen einer Anforderung und dem Ende der Umsetzung (also Cycle Time plus vorgelagerte Prozesse), was bedeutet, dass häufig andere Teams oder Abteilungen beteiligt sind. Auch diese Zeitspanne sollte so kurz wie möglich sein, zu den möglichen Verbesserungsmassnahmen gehören die Harmonisierung von Übergaben zwischen den Phasen oder die Verbesserung der Kommunikation zwischen den Teams und Abteilungen.

Throughput

Eine der häufigsten und einfachsten Metriken: erfasst wird die Zahl der vervollständigten Arbeitspakete pro Zeiteinheit (z.B. pro Monat). Da diese Zahl durch eine Vielzahl von Faktoren beeinflusst werden kann gibt es keine Verbesserungsmassnahmen die naheliegender sind als andere, hier kommt es auf den Einzelfall an.

Velocity

Im agilen Kontext wird dieser Begriff vor allem von Scrum Teams benutzt (obwohl er kein offizieller Teil von Scrum ist). Unter ihm wird die Summe der Story Points aus allen im letzten Sprint fertiggestellten User Stories verstanden. Da Story Points keine exakte Schätzung sind und ggf. nicht alle Items im Sprint so geschätzt werden ist diese Zahl mit Vorsicht zu behandeln, sie kann aber die Ausgangsbasis für eine Problemanalyse sein.

Work in Progress

Die Menge verschiedener Aufgaben an denen ein Team gleichzeitig arbeitet. Das mit zu viel paralleler Arbeit verbundene Multitasking führt in der Regel zu Konzentrationsverlust und höherer Cycle Time, umgekehrt kann bei Arbeitsprozessen die sich über mehrere Phasen erstrecken zu wenig Arbeit in einer Phase dazu führen, dass die nachgelagerten Phasen leerlaufen. Die Gegenmassnahmen sind Ober- oder Untergrenzen, die so genannten Work in Progress-Limits oder WIP-Limits.

WIP-Age

Eine Ableitung der Lead Time. Konkret geht es darum, wie hoch die bisherige Lead Time der Aufgaben ist, die im aktuellen Moment, bzw. im aktuellen Sprint bearbeitet werden. Ist diese Wert zu hoch, die Cycle Time innerhalb der Umsetzungsphase aber niedrig, kann das bedeuten, dass in den vorgelagerten Prozessschritten Staus bestehen weil dort zu viel vorgearbeitet wird. Um das zu beheben kann es Sinn machen WIP-Limits einzuführen die über alle Phasen harmonisiert sind und dabei auch die jeweiligen unterschiedlichen Cycle Times berücksichtigen.

Blocked Days/Hours

Sowohl hohe Lead Times und Cycle Times als auch hohes WIP-Age können darauf zurückgehen, dass Arbeiten unterbrochen werden müssen um auf Zulieferungen oder Abnahmen zu warten, die von Personen ausserhalb des Teams vorgenommen werden. Ist die Anzahl der dadurch entstehenden Verzögerungstage oder -stunden zu hoch kann das dadurch ausgeglichen werden, dass das Team diese Arbeiten selbst erledigt (und das ggf. erlernt).

Bug Rate/Incident Rate

Eher unschöne Metriken, da sie die Folge von früher gemachten Fehlern und Versäumnissen sind. Dementsprechend sollten Verbesserungen am besten auf die Qualitätsaspekte der Produktentwicklung abzielen, etwa auf Testabdeckung und Code Reviews.

Bugfix Time

Auch das ist klar, je länger es dauert Bugs zu beheben desto mehr Probleme treten auf, und das sowohl bei der Systemstabilität als auch bei der Nutzerzufriedenheit. Die Bugfix Time als Sonderfall der Lead Time oder Cycle Time ist daher von besonderer Bedeutung. Die beste Gegenmassnahme ist eine Zero Bug-Policy.

---

Voraussetzung für all das ist natürlich, dass die jeweiligen Metriken permanent erhoben werden, entweder digital durch die jeweiligen Tools oder von Hand. Das ist zwar ein gewisser Aufwand, allerdings einer der sich definitiv lohnt.

Freitag, 25. Mai 2018

How to do safety differently

Zu den häufigsten Einwänden gegen vollkommen autonome und selbstorganisierte Teams gehören Sicherheitsbedenken aller Art. Wenn es da nicht Vorschriften und Regeln geben würde, dann wäre alles riskant und gefährlich, heisst es. Dass das so nicht stimmt zeigt der folgende Film. In ihm sieht man, dass selbstorganisierte Teams sogar für mehr Sicherheit sorgen können. Sehenswert.

Dienstag, 22. Mai 2018

Definition of Done

Bild: Pexels / Daria Shevtsova - Lizenz
Praktisch jeder der jemals an der Erstellung eines komplizierten oder komplexen Produkts mitgewirkt hat dürfte sie kennen - die Diskussionen um die Rand-, Umgebungs- und Kontextfaktoren der Produktentwicklung und darum ob diese abnahmerelevant sind. Die Kompatibilität mit bestimmten (Produktions-)Daten gehört dazu, Schnittstellen-Anbindungen, Dokumentation, Absicherung durch Tests und vieles mehr. "Das hätte man sich doch denken können.", "Das ergibt sich aus dem gesunden Menschenverstand" und ähnliche Argumente tauchen immer wieder auf und belegen, dass die Verständnisse an diesen Stellen weit auseinandergehen.

Um dem entgegenzuwirken gibt es in Scrum (und auch in vielen Teams die andere agile Vorgehensweisen bevorzugen) die Definition of Done (DoD), eine verbindliche Regelung, die definiert was alles gegeben sein muss damit eine Abnahme stattfinden kann. Wichtig ist dabei nicht etwa, dass die DoD umfassend alle Eventualitäten regelt. Das würde zwangsläufig zu ausufernd grossen Kriterienkatalogen führen, die alleine aufgrund ihres Umfangs nicht mehr zu übersehen und kaum zu befolgen wären. Besser sollten dort nur die Bereiche geregelt werden bei denen die Teammitglieder ein unterschiedliches Verständnis haben. Dieses durch gemeinsame Entscheidungen des gesamten (Scrum) Teams zu vereinheitlichen ist der eigentliche Mehrwert.

Ich würde immer empfehlen mit einer sehr schlanken Definition of Done zu beginnen, die z.B. nur definiert auf welcher Umgebung eine Abnahme stattfindet und dass mindestens zwei Personen an jeder Anforderung gearbeitet haben müssen (Vier Augen-Prinzip). Mit der Zeit können dann weitere Kriterien dazukommen, etwa das notwendige Ausmass von Testautomatisierung und Dokumentation oder die Sprachen in denen das Produkt verfügbar sein muss. Es ist erfahrungsgemäss immer einfacher einen geringen Umfang zu erweitern als einen grossen zurückzuschneiden, zumindest gilt das für neue oder noch unerfahrene Teams. Bei ihnen nimmt der Umfang der DoD häufig über einige Monate immer weiter zu.

Erfahrene Teams tun sich mit der Reduzierung auf das Wesentliche leichter. Viele Teams mit denen ich gearbeitet habe haben ihre DoD früher oder später auf wenige Sätze zusammengestrichen, die dann eher einen Sinn reflektiert haben als konkrete Vorgaben zu machen. Eines meiner Lieblingsbeispiele ist ein Team dessen DoD aus nur einem Satz bestand: "Eine Anforderung ist abgenommen wenn der Product Owner Kuchen mitbringt". Das ganze Team hatte ein einheitliches und sehr hohes Qualitätsverständnis, und der PO war bekannt dafür, den "Abnahme-Kuchen" nur dann mitzubringen wenn das neue Feature diesem Verständnis zur Gänze entsprach und niemand mehr Widerspruch einlegte. In diesem Zusammenhang reichte dieser eine, zunächst wunderlich klingende Satz als DoD völlig aus.

Bleibt noch die Frage: was ist wenn mehrere Teams an einem gemeinsamen Produkt arbeiten, sollte man die Definition of Done in einem solchen Fall nicht vereinheitlichen? Die Antwort darauf ist ein klares Ja. Aber: der Knackpunkt ist das Wort "man". Mit ihm ist nicht etwa ein Manager, eine QA-Abteilung oder eine sonstige übergeordnete Person oder Struktur gemeint. Die gemeinsame DoD muss gemeinsam von den beteiligten (Scrum) Teams entwickelt werden. Nur so kann sichergestellt werden, dass sie bedarfsgerecht, unbürokratisch und von den Beteiligten nicht als Fremdkörper empfunden ist (das sieht auch der Scrum Guide so). Alles andere wäre ein Antipattern.

Donnerstag, 17. Mai 2018

Decision Stories

Bild: Pixabay / Qimono - Lizenz
Eine der eher nervtötenden Tätigkeiten in Organisationen jeglicher Grösse ist das Nachvollziehen von Entscheidungen, die vor längerer Zeit getroffen worden sind. Selbst wenn alle Beteiligten noch immer anwesend sind kann es zu einer echten Herausforderung werden rückwirkend zu klären warum und unter welchen Bedingungen ein Beschluss gefasst wurde. Grundsätzlich ist das erklärbar, gerade in einem agil arbeitenden Umfeld sind Entscheidungen so häufig nötig, dass der Einzelfall in der Erinnerung verschwimmt. Man muss also dokumentieren. Und damit beginnen weitere Probleme.

Im besten Fall wird die Entscheidung im Rahmen eines Meeting-Protokolls festgehalten. Diese sind in der Regel knapp gehalten und Ergebnis-orientiert, was dann so aussehen kann (angelehnt an einen echten Fall):
Man sieht - die Entscheidung ist festgehalten, es sind auch die an der Diskussion beteiligten Personen genannt und es wird sogar auf die besprochenen Them eingegangen. Trotzdem ist im Rückblick völlig schleierhaft was letztendlich den Ausschlag für eine Option gegeben hat. Und wie gesagt, das ist noch ein gutes Beispiel. Schlimmer sind Fliesstexte, die häufig so aussehen:
Die Ausschreibung erfolgte unter den im Vergabeportal registrierten Preferred Suppliern mit Fristende auf dem letzten Tag von Q4. Basierend auf den in der Evaluierungsphase gesammelten Kriterien (vergleiche Kriterienkatalog PA30005 in der Version vom 26.11. und Procurementrichtlinie ITBesT28, Version 32.05) konnte die Auswahl auf drei Bieter eingeengt werden (siehe Entscheidungsvorlage Bieter Q4 final mit Aufschlüsselung auf die 49 als relevant identifizierten Schlüsselkriterien). Basierend auf der im Vergleich höheren Fach- und Branchenexpertise der QWERT AG und im Hinblick auf zu erwartende Synergieeffekte mit dem vom selben Bieter unterstützten Oktopus-Projekt konne in einem ersten Pitch der postive erste Eindruck bestätigt werden ...
Und so kann es über mehrere Seiten weitergehen. Schwer zu lesen, schwer zu ertragen und schwer nachzuvollziehen. Letztendlich wird die Entscheidung hier eher verschleiert als nachvollziehbar gemacht. So sollte es also nicht sein. Aber wie dann?

Eine bessere Möglichkeit die in den letzten Tagen durch meinen Newsfeed gerauscht ist greift die Idee hinter der User Story und der Vision auf und überträgt sie: wenige, in verständlicher Sprache verfasste Sätze fassen sowohl die Entscheidung als auch die dazugehörenden Kontextinformationen zusammen. Ein Beispiel:
Basierend auf der Annahme, dass der Personalbestand weiterhin um 10 % pro Quartal wächst wird die angemietete Bürofläche um 500 m2 erweitert, um während des gesamten Folgejahres eine Co-Location mit 12 m2 je Mitarbeiter gewährleisten zu können. Ein Plan-Ist-Abgleich findet einal pro Quartal statt, um ggf. Anpassungen der Flächengrösse vornehmen zu können.
Sechs Informationen sind hier enthalten: zugrundeliegende Hypothese, abgeleitete Massnahme, erwarteter Mehrwert, Prüfkriterien, Überprüfungsintervall und mögliche Korrekturmassnahme. Eine auf diese Weise dokumentierte Massnahme ist jederzeit nachvollziehbar, validierbar und bei Bedarf korrigierbar, ohne dass gross diskutiert oder überlegt werden müsste. Würden Entscheidungen durchgehend nach diesem Format dokumentiert würden die Unklarheiten deutlich abnehmen.Und falls das Ding einen Namen braucht - analog zur User Story würde sich die Decision Story anbieten.

Montag, 14. Mai 2018

Onsite Customer

Bild: Pexels / Yan Krukov - Lizenz
Nicht alles was im agilen Kontext Sinn macht muss notwendigerweise aus Scrum oder Kanban kommen. Auch andere Ansätze haben Good Practices herausgebildet, die grossen Mehrwert stiften können. Einer davon ist der sogenannte On Site Customer aus dem Extreme Programming, bzw XP. Ein Vertreter der Kunden oder Anwender der beim Umsetzungsteam anwesend ist und mit ihm zusammenarbeitet.

Wie häufig in derartigen Fällen ist die Einrichtung des On Site Customers die Reaktion auf einen Missstand. Bedingt dadurch, dass komplexe Themen nicht immer einfach zu erklären sind und verstärkt dadurch, dass Kunde und Entwickler so unterschiedliche Hintergründe haben können, dass sie quasi verschiedene Sprachen sprechen, sind in der Produktentwicklung Missverständnisse praktisch unvermeidbar. Diese zu beheben kostet dann Zeit und Geld. Der einfachste (und in vielen Fällen einzige) Weg um diese Situation aufzulösen ist die Anwesenheit eines Kunden, bzw. Endanwenders vor Ort, der unmittelbares Feedback geben kann ob die Umsetzung den Bedürfnissen entspricht.

Was dabei zu beachten ist: dieser Kundenkontakt sollte nicht nur in den Rewiew- oder Demonstrationsmeetings erfolgen (wobei das zumindest besser ist als nichts) sondern auch darüber hinaus. Ein Kunden- oder Benutzervertreter kann in Refinements seine Sicht der Dinge erläutern, kann Teams und Product Owner beraten welche Anforderungen dringend sind, welche einen hohen Business Value haben oder ein grosses Risiko beseitigen, kann MVPs und Prototypen begutachten, sich an Akzeptanztests beteiligen, eine Schnittstelle zu anderen Teilen seines Unternehmens bilden, etc.

Um das Verständnis zu klären: der On Site Customer ist nicht notwendigerweise eine immer gleiche Person, es kann auch sein, dass es mehrere gibt die sich in dieser Rolle abwechseln oder gemeinsam erscheinen. Es kann sogar sein, dass das Umsetzungsteam komplett zu den Kunden/Nutzern zieht und dort eingebettet arbeitet. Im Grunde sind die Konstellationen nicht begrenzt, alles was möglich ist kann ausprobiert werden. Nur von einer Idee ist abzuraten - davon, dass nicht die eigentlichen Benutzer des Produkts zu On Site Customern werden sondern deren Vorgesetzte. Das schafft erfahrungsgemäss direkt wieder neue Kommunikationsprobleme.

Ein Sonderfall tritt ein wenn das mit der Umsetzung betraute Team ein verteiltes Team ist, also eines das nicht an einem Ort sitzt sondern geografisch verstreut angesiedelt ist. Da solche Teams in der Regel über Videokonferenzen und Screensharing kommunizieren kann man einen On Site Customer auch auf diese Weise einbinden. Dass damit Effektivitäts- und Effizienzverluste verbunden sind ist zwar richtig, allerdings sind diese dann durch Teamstruktur verursacht und nicht durch die Kunden-Kooperation.

Donnerstag, 10. Mai 2018

Minimum Work in Progress

Bild: Flickr / Vic - CC BY 2.0
Jeder der sich etwas mit den Themen Kanban oder Lean beschäftigt hat dürfte vom Konzept des Limited WIP (Limited Work in Progress) bereits gehört haben. Es ist von entscheidender Bedeutung wenn es darum geht Durchlaufzeiten zu erhöhen und Störungen des Arbeitsflusses zu vermeiden. WIP-Limits gelten als eines der zentralen Erkennungsmerkmale von Kanban-Systemen, und doch wird praktisch immer nur eine ihrer möglichen Dimensionen betrachtet, die andere wird weitgehend ignoriert.

Die überall bekannte Dimension, die oft auch mit dem generellen Begriff des Limited WIP gleichgesetzt wird ist die des Maximum Work in Progress. Diese Obergrenze und ihren Sinn näher zu betrachten wäre ein Thema für sich, verkürzt gesagt verhindert sie Multitasking und trägt dazu bei, dass Arbeit nicht unkontrolliert einfliessen und sich irgendwo im System stauen kann. Auch für sich alleine erbringt sie einen Mehrwert, kann aber nur einem Teil der möglichen Fehlentwicklungen auffangen.

Was durch eine WIP-Obergrenze nur eingeschränkt reguliert werden kann ist die Gefahr, dass irgendwo im System Leerlauf entsteht. Die tritt unter anderem dann auf, wenn zeitweise alle verfügbaren Kräfte auf eine einzige Stelle des Wertstroms konzentriert werden, etwa auf das Releasen. Wenn infolgedessen die Arbeit in einem früheren Abschnitt (etwa der Software-Entwicklung) vorübergehend eingestellt wird, kann es sein, dass ein mittlerer Teil (z.B. die Qualitätssicherung) plötzlich nichts mehr hat was er verarbeiten kann. Bis von weiter vorne neue Zwischenergebnisse kommen herrscht dann an dieser Stelle Stillstand.

Ein Mittel um einen solchen kostspieligen Leerlauf zu verhindern (auch im Stillstand müssen Gehälter bezahlt werden), ist die Einrichtung weiterer WIP Limits, nur in diesem Fall an der Untergrenze. Ein solches Minimum Work in Progress sorgt dafür, dass bei ihrem Erreichen sofort neue Arbeit nachgezogen werden muss, selbst wenn das auf den ersten Blick nicht dringend erscheint. Die nachfolgende Station ist dadurch ebenfalls immer in der Lage Arbeit nachzuziehen sobald sie freie Kapazitäten hat.

An dieser Stelle muss auch klar sein, dass ein Minimum WIP nicht nur Probleme lösen sondern sie im schlimmsten Fall sogar erzeugen kann. Wenn es dazu führt, dass einer oder mehrere Abschnitte eines Produktionsprozesses zu 100 Prozent ausgelastet sind, sind mitunter verstopfte Warteschlangen die Folge. Optimalerweise sorgt es daher nicht nur dafür, dass jederzeit Arbeit nachgezogen werden kann, sondern es lässt auch Spielraum für neue, ungeplante Arbeit. Minimum WIP und Maximum WIP sollten nicht gleich groß sein, sondern immer einen Korridor dazwischen freilassen.

Montag, 7. Mai 2018

Eine Hilfe für die (De)Zentralisierung von Entscheidungen

Bild: Pxhere - CC0 1.0
Da das Thema der Skalierung von agilen Vorhaben bei fast allen meinen Kunden eine Rolle gespielt hat, komme ich nicht daran vorbei, mich mit den verschiedenen gängigen Skalierungsframeworks zu beschäftigen, unter anderem mit SAFe. In diesem Zusammenhang bin ich an dessen Dezentralisierungs-Prinzip hängengeblieben, bzw. an einem dort empfohlenen Tool. Mit seiner Hilfe kann geklärt werden ob eine Entscheidung zentral oder dezentral getroffen werden sollte.

Nun kann man in Bezug auf SAFe geteilter Meinung sein, das Tool ist aber tatsächlich hilfreich, vor allem in Organisationen in denen Agilität noch nicht sehr tief verwurzelt ist. Ins Deutsche übersetzt (und leicht angepasst) sieht es so aus:
Die drei Entscheidungskategorien sind schnell erklärt: häufige Entscheidungen würden zentrale Instanzen überlasten, was zu langen Wartezeiten führen würde. Zeitkritische, also dringende Entscheidungen würden in der zentralen Instanz weniger dringende, aber in der langfristigen Betrachtung wichtigere Themen verdrängen. Kontextabhängige Entscheidungen würden einen zeitaufwändigen Wissenstransfer zur zentralen Instanz erfordern oder müssten uninformiert getroffen werden. Um diese negativen Auswirkungen zu vermeiden bleibt nur eine Delegation nach unten, in die Teams.

Wie genau die drei Faktoren ermittelt werden können kann von Fall zu Fall unterschiedlich sein, ein denkbarer Weg wäre z.B., dass alle Beteiligten sich zusammenfinden und durch das Hochhalten von Fingern oder Planning Poker Karten ihre Einschätzung abgeben. Das hätte den zusätzlichen Vorteil, dass verschiedene Sichtweisen eingebracht werden können. In anderen Fällen ist das Ergebnis vielleicht so offensichtlich, dass es keiner grossen Diskussion mehr bedarf.

Zuletzt empfiehlt es sich, das Tool in gewissen Abständen immer wieder einzusetzen, da die Faktoren sich mit der Zeit ändern können. Beispielsweise kann es sein, dass der Austausch mit einem Kunden zuerst auf Geschäftsführer-Ebene stattfindet, sich aber mit der Zeit zu einem intensiven Austausch zwischen Produktentwicklung und Endanwender entwickelt. In einem solchen Fall wäre eine nachträgliche Dezentralisierung sinnvoll.

Siehe auch: Subsidiarität.

Donnerstag, 3. Mai 2018

Brainstorm Hole

Es ist nicht so, dass Brain Stormings per se schlecht wären. Man muss sich aber bewusst machen: der Grundsatz, dass jeder alles sagen darf ohne kritisiert zu werden kann dazu führen, dass auch viel Unsinn dabei ist. Dass sollte von Beginn an jedem klar sein. Ohne gute Moderation entstehen dann Situationen wie die hier.