Donnerstag, 18. Oktober 2018

Agile Workshops

FS
Bild: Pxhere / Rawpixel - CC0 1.0
Zu den Aufgaben die ich bei verschiedenen Kunden habe gehört das Halten von Schulungen und Workshops. Einführung in die Grundlagen agilen Arbeitens, Einführungen in Scrum oder Kanban, Product Ownership, Skalierung, Backlog Management, etc. Mitunter werde ich sogar nur für einzelne derartige Veranstaltungen gebucht. Mein Anspruch ist dabei, dass der Begriff Agile Workshop in mehr als einer Hinsicht zuteffend ist: in Bezug auf den Inhalt aber auch in Bezug auf die Durchführung.

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)

FS
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

FS
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

FS
Bild: Pixabay / Magic Desk - CC0 1.0
Es ist eine traurige Geschichte die ich schon von vielen Scrum Teams gehört habe: der Sprint ist beendet, alle Anforderungen sind umgesetzt, alles ist in einem präsentationsfähigen Zustand - aber kein einziger Stakeholder erscheint zum Review Meeting. Nach zwei Wochen Arbeit ist das frustrierend, aber es geschieht selten ohne Grund. Folgende Ursachen habe ich bereits bei verschiedenen Teams erleben dürfen:

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

FS
Bild: Wikimedia Commons / Santeri Viinamäki - CC BY-SA 4.0
Zu den vermutlich skurrilsten gesetzlichen Regelungen der Technikgeschichte gehören die so genannten Red Flag Laws, die im späten 19. Jahrhundert in Grossbritannien und Teilen der USA erlassen wurden. In ihnen wurde geregelt, dass jedem motorisierten Fahrzeug eine Aufsichtsperson vorauslaufen und dabei eine rote Fahne schwenken musste. Das zu dieser Zeit gerade erst erfundene Auto, dessen Stärke ja gerade die Geschwindigkeit war, wurde damit praktisch unbrauchbar.

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

FS
Was sich in den Unterlagen der vergangenen Jahre so findet. In diesem Fall eine Entscheidungshilfe für die Scrum Master-Community eines ehemaligen Kunden. Besagte Community hatte die Tendenz sich in ausufernden Debatten darüber zu verlieren, ob ein Probem, bzw. Impediment wichtig genug wäre um die gesammelten Kraft aller Scrum Master in Anspruch zu nehmen oder nicht. Um diese Diskussionen zu verkürzen entstand das folgende Bild:
Zu den einzelnen Verzweigungen. Bereits die erste ist weniger selbstverständlich als man denken sollte. Manche Probleme lassen sich eben gar nicht lösen, beispielsweise der Baustellen-Lärm vom Nachbargrundstück. Ist das der Fall, ist jede Diskussion vergebens und man kann sie einfach sein lassen. Sie bringt nichts. Auch an der zweiten Verzweigung halten sich manche Scrum Master länger auf als es Sinn macht. Wenn jemand anders ein Problem besser lösen kann als man selbst sollte man es vertrauensvoll dorthin übergeben, beispielsweise die Überprüfung der Eingänge auf Barrierefreiheit an den Gleichstellungs-Beauftragten. Nur wenn es niemanden gibt der besser geeignet ist sollte man selbst tätig werden.1

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.
Powered by Blogger.