Donnerstag, 25. Oktober 2018
Backlog-Priorisierung
Die Priorisierung noch zu erledigender Arbeit scheint auf den ersten Blick ein Thema zu sein in dem sich agile und klassische Vorgehensweisen kaum unterscheiden. Auch vor der Erfindung von Scrum und Co wurde schon überlegt welche Aufgaben wichtiger und welche unwichtiger sind. Auf den zweiten Blick tun sich dagegen Unterschiede auf, die vor allem mit einem Instrument in Verbindung stehen - dem Product Backlog.
Um zu verstehen warum diese Art der Priorisierung anders ist empfiehlt sich ein Blick darauf wie Priorisierung klassischerweise stattfindet. In den meisten Unternehmen bekommen Anforderungen entweder eine Wichtigkeitsklasse (z.B. Minor, Medium, Major, Blocker) oder eine die Bedeutung anzeigende Zahl zugewiesen (z.B. 1 = unwichtig bis 100 = extrem wichtig). Je höher diese Wichtigkeitsklasse, bzw. diese Zahl sind, desto höher die Priorität.
Was in der Theorie zunächst einfach und nachvollziehbar klingt erweist sich in der Realität in der Regel als unpraktikabel. Da jeder Stakeholder ein Interesse daran hat, dass seine Anforderungen zuerst umgesetzt werden, wird er sich um eine hohe Bewertung bemühen. Im Zweifel wird ihm diese auch zugestanden werden, da mit dieser Einstufung ja noch keine weiteren Zusagen verbunden sind. Es geht an dieser Stelle nur um die Wichtigkeit, noch nicht um die Machbarkeit.
Schon nach kurzem wird dieses Vorgehen dazu führen, dass eine hohe zwei- oder dreistellige Zahl an Anforderungen als Blocker, bzw. zwischen 90 und 100 eingeordnet wird. Ist dieser Punkt erreicht ist die Priorisierung wertlos geworden. Wenn alles super-wichtig ist, dann ist alles gleich (un)wichtig. Übliche Reflexe sind jetzt die Erweiterung der Skala (z.B. um einen Showstopper-Status oder um die Zahlen 101 bis 110), was aber bald auch wieder entwertet sein wird.
Die Einträge eines Product Backlog werden dieser Bedeutungs-Inflation normalerweise bewusst entzogen, indem auf Wichtigkeitsklassen einfach verzichtet wird. Die Priorität ergibt sich hier anders, nämlich durch die Natur des Backlogs selbst. Dieses ist keine Ansammlung von unterschiedlich wichtigen Teilmengen mehr (deren jeweilige Einzelteile unter sich gleichwertig sind), sondern etwas viel Einfacheres - eine sortierte Liste.
Was eine solche Liste besonders macht ist, dass auf ihr keine Punkte nebeneinander stehen können sondern nur untereinander. Aufgelistet eben. Es gibt also immer einen wichtigsten Eintrag, einen zweitwichtigsten, einen drittwichtigsten, etc. Und wo auch immer man eine neue Anforderung dazwischenschiebt, sie wird immer jeweils ober- und unterhalb einer anderen stehen und damit automatisch priorisiert sein.
Es bleibt die Frage - wenn es so einfach ist, warum macht es dann nicht jeder so? Die Antwort - weil ein als Liste sortiertes Backlog seinen Verwalter dazu zwingt, Konflikte sowohl früh als auch immer wieder auszutragen. Es ist mit diesem Vorgehen nicht mehr möglich, jeden wichtigen Stakeholder zufriedenzustellen indem man ihm die höchste Wichtigkeitsklasse gibt. Wenn seine Idee auf Position 43 von 120 liegt (und demnach nicht so schnell umgesetzt werden wird) dann sieht er das sofort und kann das eskalieren.
Um derartige Konflikte zu vermeiden wird häufig die klassische Art der Priorisierung bevorzugt. Die Auseinandersetzungen tauchen zwar auch hier auf, aber erst wesentlich später, wenn den Beteiligten langsam dämmert, dass die scheinbar hohe Priorität weitgehend ohne Aussagekraft ist. Manche Organisationen haben es zu erstaunlicher Meisterschaft darin gebracht, diesen Punkt immer weiter nach hinten zu verlagern, mit langen Phasen des Stillstands als Folge.
Zu lernen, dass das kein zielführender Weg ist, und dass das frühe (und konstruktive) Austragen von Konflikten zwar schmerzhaft aber letztendlich besser ist, ist Teil des zu agilen Transitionen gehörenden Kulturwandels. Der ist zwar mitunter unangenehm, bringt aber einen grossen Vorteil mit sich: man ist plötzlich in der Lage Priorisierungen durchzuführen, in einer Art die diesen Namen auch verdient.
Montag, 22. Oktober 2018
Deine Muda: Warten
 |
| Bild: Wikimedia Commons / Siyuwj - CC BY-SA 3.0 |
Ähnlich wie in vielen anderen Zusammenhängen ist auch das Warten aus mehr als einem Grund problematisch. Zum einen weil es dazu führt, dass bestimmte Arbeiten später fertig werden, zum anderen wegen der Tätigkeiten die währdenddessen durchgeführt werden. Denn Nichtstun bedeutet in diesem Kontext nicht etwa völlige Untätigkeit, sondern lediglich die Untätigkeit in Bezug auf eine bestimmte Arbeit.
Zunächst aber zu den Verspätungen. Man kann es ohne grosse Erläuterungen verstehen: wenn ein Produktionsprozess immer wieder so lange angehalten werden muss, bis bestimmte Vor- oder Zuarbeiten erledigt sind, dann verlängert sich dadurch die Produktionsdauer. Wie im Fall fast aller anderen Mudas wird das Produktionsmaterial dadurch zeitweise dem Wirtschaftskreislauf entzogen. Es entsteht totes Kapital. Aber das ist noch nicht alles.
Als zweiter Effekt kommt es zu dem so genannten Cost of Delay, bzw. zu Verspätungskosten. Wäre der Produktionsprozess schon früher beendet gewesen, hätte man mit seinem Ergebnis bereits Geld verdienen können. Die Summe die einer Firma dadurch entgeht, dass das nicht möglich ist, ist mit dem Begriff des Cost of Delay gemeint.
Auch damit sind aber noch nicht alle negativen Effekte erwähnt. Was noch fehlt sind die weiter oben genannten Tätigkeiten die währdenddessen durchgeführt werden. Mit dem Warten ist nämlich das Warten des Produkts auf seine Fertigstellung gemeint, nicht etwa das Warten eines Angestellten auf Beschäftigung. Der beginnt in der Regel währenddessen bereits mit dem nächsten Arbeitspaket.
In der Praxis sieht das so aus, dass sobald an einer Arbeit kein Fortschritt mehr möglich ist eine zweite begonnen wird, sobald es auch an der nicht mehr weitergeht eine dritte, etc. Sobald die für das Weiterarbeiten an der ersten Aufgabe notwendige Zulieferung erfolgt ist werden die später begonnenen unterbrochen, es geht mit der ersten weiter, nach deren Abschluss wieder mit den späteren.
Wird auf diese Art und Weise vorgegangen treten aber zwangsläufig Probleme auf: zum einen das Multitasking mit seinen üblichen Begleiterscheinungen von Konzentrationsverlust und Umgewöhnungsaufwand, zum anderen Priorisierungskonflikte. Was ist jetzt wichtiger, die Wiederaufnahme der schon länger wartenden ersten Aufgabe oder das störungsfreie Weiterarbeiten an einer späteren? Auch diese Konflikte kosten Zeit und Geld.
In Summe sind die genannten Folgen von Wartephasen im Produktionsprozess so kostspielig, dass nach Möglichkeit versucht werden sollte sie zu vermeiden. Die einfachste Möglichkeit dazu ist die Bildung eines Crossfunktionales Teams. Wenn alle Tätigkeiten selbst erledigt werden können verschwindet mit der Abhängigkeit von anderen Gruppen die häufigste Ursache des Wartens.
Auch andere Ansätze sind möglich, etwa die bessere Abstimmung von Teams untereinander (Just in Time-Delivery) oder das Anhäufen von Vorarbeiten in einem ausreichenden Ausmass um später nicht in Leerlauf zu geraten (ein durchaus sinnvolles, aber häufig auf andere Art problematisches Vorgehen, das man sich gut überlegen sollte).
Was auf jeden Fall bewusst sein sollte: Bemühungen zur Vermeidung von Wartezeiten führen häufig zu anderen nicht gewinnbringenden Tätigkeiten (Transport, Lagerhaltung, etc.), deren Optimierung möglicherweise wieder zu neuen Wartezeiten führt. Der so entstehende Verbesserungsprozess ist dadurch nie abgeschlossen - was auch absolut Sinn macht.
Donnerstag, 18. Oktober 2018
Agile Workshops
 |
| Bild: Pxhere / Rawpixel - CC0 1.0 |
Ein agiler Workshop im Sinn der Durchführung ist in meinem Verständnis gegeben wenn noch während seiner Laufzeit auf sich ändernde Wünsche und Fragen eingegangen werden kann. Ein Exkurs Richtung Lean Startup wird gewünscht? Ein Eingehen auf alternative Schätztechniken wie #Noestimates? Fallbeispiele für Agilität ausserhalb der IT? Alles machbar, und zwar alles sofort, aus der Veranstaltung heraus.
Dass das möglich ist liegt daran, dass ich meine Schulungs- und Workshop-Inhalte in Module eingeteilt habe. Ein Modul agile Basics, ein Modul Scrum, ein Modul User Stories & Story Points, etc. Jedes dieser Module habe ich schon mehrfach durchgeführt, so dass ich es schnell parat habe. Und (in dem Kontext noch wichtiger) sie sind so geschnitten, dass sich einzelne oder mehrere von ihnen hinzufügen, ersetzen oder in ihrer Reihenfolge vertauschen lassen.
Dieses Vorgehen bietet Vorteile für beide Seiten: die Teilnehmer können auch noch kurzfristig Themenwünsche äussern, die (sofern sie nicht zu exotisch sind) sofort erfüllt werden können, für mich bietet es die Möglichkeit hohe Flexibilität mit berechenbarer Durchführung zu verbinden. Und auch ein weiterer Punkt kommt noch dazu - wenn ich interne Scrum Master oder Agile Coaches ausbilde können sie einzelne Module erlernen und nach und nach in den Workshops übernehmen.
Ganz ohne Voraussetzungen geht das natürlich nicht. Die Module muss man parat haben und man muss in der Lage sein kurzfristig zwischen ihnen hin- und herzuschalten. Die Agenda sollte kurzfristig modifizierbar sein (ich benutze Post Its, die sich einfach umhängen und austauschen lassen). Nicht zuletzt würde ich immer von den zu statischen Powerpoint-Präsentationen abraten und stattdessen im Rahmen der Veranstaltung Flipcharts bemalen und beschreiben. Alles das muss man können.
Angesichts des deutlich gesteigerten Ausmasses an Flexibilität und Kundenorientierung sind das allerdings Mühen von denen ich überzeugt bin, dass man sie auf sich nehmen sollte wenn man agile Workshops (in beiden Begriffsbedeutungen) durchführen will. Denn eine agile Wissensvermittlung die selbst nicht agil ist - wäre das nicht ein Widerspruch in sich?
Montag, 15. Oktober 2018
Ein Bild sagt mehr als 1000 Worte (XXII)
Für den nächsten der Innovationsbemühungen abbügeln will indem er davor warnt das Rad neu zu erfinden.
Donnerstag, 11. Oktober 2018
Wo Politik herkommt und wie man sie loswird
Eine kurze Bemerkung zum Kontext: in Firmen und ähnlichen Organisationen versteht man unter Politik nicht Regierungen, Parlamente und Wahlen sondern die unnötige Verkomplizierung von Abläufen durch Machtspiele und Konflikte zwischen Personen und Gruppen. Mit dieser Information im Hinterkopf: Bühne frei für Katherine Kirk.Montag, 8. Oktober 2018
Warum niemand zum Sprint Review kommt
 |
| Bild: Pixabay / Magic Desk - Lizenz |
Es gibt keine Stakeholder
So einfach ist es manchmal. Wenn z.B. die aktuellen Entwicklungsziele die Kopfgeburt eines einzelnen Topmanagers sind, die dieser gegen den Willen aller Beteiligten durchgesetzt hat, dann ist es nicht verwunderlich wenn ausser ihm keiner erscheint.Es wurden keine Features entwickelt, sondern Komponenten
Wenn das was entwickelt wurde nicht benutzbar und bewertbar ist, warum sollte dann jemand zum Review kommen wollen? Es gibt ja nichts worüber man reden könnte (und ganz nebenbei hat dieses Vorgehen auch nicht viel mit Scrum zu tun).Es gab kein Sprintziel / keinen Fokus im Sprint
Wenn ein Sprint kein Ziel hat sondern stattdessen unterschiedliche Anforderungen hineingestopft werden stellen viele Stakeholder die Sinnfrage. Lohnt sich ein zweistündiges Meeting wirklich, wenn für jeden nur ein Feature dabei ist, das von Interesse ist? Eher nicht.
Es ist kein Review sondern eine Demonstration
Manche Teams führen kein Sprint Review durch sondern ein Demo-Meeting. Der Unterschied: Neuerungen werden nur vorgeführt und nicht diskutiert. Wird den Stakeholdern so die Möglichkeit zum Feedback geben genommen sinkt erfahrungsgemäss die Teilnahmebereitschaft.Es gab keine Ankündigung
Da nicht jedes Thema für jeden gleich interessant ist kommen viele Stakeholder nicht zu jedem Review. Um sie zu aktivieren hilft es, wenn die Inhalte mit einigen Tagen Vorlauf kommuniziert werden, so dass klar ist ob sich das Erscheinen lohnt.Die Vorführung der neuen Features ist konfus oder lustlos
Wer die Teilnehmer eines Meetings nicht ernstnimmt muss sich nicht wundern wenn sie wegbleiben. Und ein nicht vorbereitetes, unstrukturiertes oder widerwillig durchgeführtes Review ist ein Zeichen, dass dieses nicht ernst nehmen stattfindet.Es gibt keine gemeinsamen Reviews
Ein Sonderfall für Projekte oder Produkte mit mehreren Teams. Wenn es den Anschein hat, dass zu viele Meetings stattfinden neigen, Stakeholder dazu nicht mehr alle zu besuchen. Die einzelnen Reviews zusammenzulegen kann dem entgegenwirken.---
Natürlich gibt es noch viele weitere mögliche Gründe dafür, dass Sprint Reviews schlecht besucht sind, diese hier sind mir aber vergleichsweise häufig aufgefallen. Behebt man sie ist zumindest die Wahrscheinlichkeit, dass sich weitere Teilnehmer einfinden, deutlich höher.
Freitag, 5. Oktober 2018
Red Flag Laws
 |
| Bild: Wikimedia Commons / Santeri Viinamäki - CC BY-SA 4.0 |
Dass diese Gesetze erlassen wurden hatte natürlich einen Grund: die Parlamente befürchteten, dass von motorisierten Fahrzeugen eine erhöhte Unfallgefahr ausgehen könnte. Anders als ein Pferd würden sie schliesslich nicht von sich aus vor einem Hindernis stehen bleiben. Als die Erfahrungen zeigten, dass diese Sorge unberechtigt war, war der Schaden bereits angerichtet - andere Länder hatten sich einen technischen und wirtschaftlichen Vorsprung erarbeitet.
Das Problem der Red Flag Laws ist, dass sie zwar auf den ersten Blick wie ein Anachronismus aus einer längst vergangenen Zeit wirken, auf den zweiten aber hochaktuell sind. Der Unterschied ist nur, dass es sich heute nicht mehr um Autos handelt, die aus Sorge vor Unkontrollierbarkeit überreguliert werden, sondern um andere Aspekte des technischen oder organisatorischen Fortschritts.
Gerade in den Konstellationen agiler Transitionen sind gut gemeinte aber in ihren Auswirkungen verheerende Regulierungen häufig. Ein Product Owner der alleine Produktentscheidungen treffen darf? Den kontrolliert man besser durch ein Lenkungsgremium. Automatisierte Tests und Deployments? Nur wenn jeder von ihnen durch einen Menschen manuell überprüft wurde. Selbstorganisierte Teams wählen ihre Tools selber aus? Ja, aber nur aus denen die vorher von einer zentralen Stelle zertifiziert wurden.
Die Folgen sind die gleichen wie damals im 19. Jahrhundert: zunächst fühlt sich die Veränderung besser (weil beherrschbarer) an, aber irgendwann dämmert die Erkenntnis, dass man sich ohne Not gerade die Potentiale verbaut hat wegen derer die neuen Methoden und Techniken überhaupt eingeführt wurden. Und währenddessen sind die Wettbewerber mit weniger Berührungsängsten schon längst vorbeigezogen und haben Marktanteile übernommen.
Nach Red Flag Laws im eigenen Unternehmen zu suchen und sie abzuschaffen kann ein schmerzhafter Prozess sein, da es fast immer bedeutet, dass man sich eingestehen muss, aus bestem Willen heraus Mist gebaut zu haben. Das nicht zu tun wäre aber noch schlimmer, was man sich an einem einfachen Beispiel vor Augen führen kann: wie wäre es wohl heute um Grossbritannien bestellt wenn noch immer vor jedem Auto ein Mensch mit eine einer roten Fahne herlaufen müsste?
Dienstag, 2. Oktober 2018
Eine Entscheidungshilfe für Scrum Master-Communities
 |
| Bild: Pexels / Fauxels - Lizenz |
Selbst wenn ein Problem in den eigenen Einflussbereich fällt, gibt es aber noch eine weitere Frage zu beachten: betrifft es wirklich alle Teams oder nur einen Teil von ihnen? Ist das letzte der Fall sollte man davon absehen Regeln für alle Teams einzuführen, sonst würde einigen von ihnen eine Lösung aufgenötigt für die sie kein Problem haben - es wäre Überregulierung. Ein Beispiel dafür wäre die Qualitätssicherung von Anforderungen durch die Einführung einer Definition of Ready. Betroffene Teams können sich selbst eine geben, anderen brächte sie zwar Aufwand aber keinen Mehrwert.
Entscheidungshilfen wie diese scheinen auf den ersten Blick zwar banal zu sein, trotzdem kann es Sinn machen sie im Teamraum einer Scrum Master-Community gut sichtbar aufzuhängen. Auch die besten Scrum Master können mitunter Züge von Betriebsblindheit, Helfersyndrom und Selbstüberschätzung aufweisen und Group Think entwickeln. Gegen diese Phänomene ist die oben zu sehende Grafik zwar kein Allheilmittel, sie kann aber ein Anstoss zur Selbstreflektion und zu einer realistischeren Betrachtung der Umstände sein. Oft ist das schon genug um die Situation zu verbessern.
1Es sei denn, der besser Geeignete hat keine Zeit.
