Agile Workshops

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?

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.

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.

Warum niemand zum Sprint Review kommt

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.

Red Flag Laws

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?

Eine Entscheidungshilfe für Scrum Master-Communities

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.¹

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.


¹Es sei denn, der besser Geeignete hat keine Zeit.

Kommentierte Links (XXXXI)

• Markus Raitner: Die modernen Hofnarren

  Einerseits ist das was Markus Raitner hier schreibt absolut richtig - dadurch dass ein Scrum Master (bis zu einem gewissen Grad) von den Konventionen und sozialen Barrieren eines Unternehmens entbunden ist kann er Dinge ansprechen die von anderen nicht angesprochen werden können. Andererseits ist eine Konstellation in der das zutrifft hochgradig dysfunktional, bedeutet es doch, dass "normale Angestellte" eben nicht die Erlaubnis haben Kritik zu üben. Der Scrum Master-Hofnarr kann demnach zwar in einer Übergangsphase seine Berechtigung haben, als ständige Institution wäre er aber ein Anzeichen dafür, dass die agile Transition gescheitert ist.
  

• Trish Khoo: Make a technical debt payment plan

Eine grossartige Idee! Wenn die finanziellen Schulden eine passende Inspiration für die Metapher der technischen Schulden sind, dann kann auch der Abbau technischer Schulden mit einem Begriff aus dem finanziellen Umfeld beschrieben werden. Ein Rückzahlungsplan wie man ihn für die Befreiung aus erdrückenden Verbindlichkeiten benötigt macht in der IT genau so viel Sinn wie bei der Haushaltsplanung: welche Schulden sind die drängendsten und dringensten, mit welchen Schritten kann ihr Abbau angegangen werden und wer wird sich dieser Schritte annehmen? Peter Zwegat wäre begeistert.

• Krishna Kandala: Business agility for speed to market - Applying design & agile thinking to drive consumer value

  Der beste Weg in Richtung Zukunft ist die beständige Lieferung kleiner, funktionsfähiger, Mehrwert stiftender Neuerungen und Erweiterungen. Der Versuch in wenigen, grossen, seltenen Schritten riesige Fortschritte zu erzielen macht schwerfällig und vervielfacht das mit Fehlentscheidungen einhergende Risiko. Was in der IT Common Sense ist versucht Krishna Kandala auf die Business-Welt zu übertragen. Ein zentraler Punkt seiner Überlegungen: grosse Unternehmen haben in der Regel kein Problem mit der Entwicklung neuer Ideen, sie tun sich aber sehr schwer damit, daraus vermarktbare Produkte zu machen - und zwar weil sie ihre grossen Visionen nicht in kleine Incremente herunterbrechen können.
  

• Mike Cohn: What Does It Mean to Be Potentially Releasable?

  Einer der wichtigsten Sätze im Scrum Guide ist: "The increment must be in useable condition regardless of whether the Product Owner decides to release it." Was für diesen Zustand nötig ist und was nicht ist Gegenstand umfassender und beständig wiederkehrender Debatten. Die Gedanken die sich Mike Cohn hier macht umfassen vieles davon und gehen an einer wichtigen Stelle noch einen Schritt weiter - was sollte man tun wenn man merkt, dass ein Increment nicht "potentially releasable" sein wird? Sein Ratschlag: die Arbeit daran unterbrechen, bzw. beenden. Interessant ist auch was er nicht empfiehlt: den Sprint-Abbruch.

• Ron Jeffries: XP revisited

  Einmal mehr ein typischer Ron Jeffries-Text. Sehr lang, sehr gehaltvoll, sehr zu empfehlen. Im Mittelpunkt die Frage: wenn Extreme Programming heute neu erfunden, bzw. neu eingeführt werden würde - was wären seine Kernelemente?

Warum Agile/Scrum ohne Testautomatisierung nicht funktioniert (III)

Bild: NASA - Public Domain

Mitunter bekommt man als Agile Coach die aberwitzigsten Probleme mit. Ein derartiger Fall ist mittlerweile schon etwas her aber immer noch bemerkenswert: er dreht sich um eine Anwendung eines grossen Konzerns, deren Entwicklung irgendwie agil werden sollte, wobei aber ein nicht ganz unwesentliches Hindernis im Weg stand - die Regressionstests wurden noch weitgehend manuell durchgeführt. Es waren viele. Sehr viele.

Es handelte sich um ein System mit mehreren über die Jahrzehnte zugekauften und integrierten Teilsystemen, die durch zahlreiche Schnittstellen verbunden waren. Insgesamt 75.000 Testfälle (!) mussten jedes mal durchgeklickt werden um sicherzustellen, dass neuentwickelte Features nicht versehentlich bestehende Anwendungsteile beschädigt hatten. Eine ungeheuerliche Zahl, deren Bewältigung nur möglich war weil Offshore-Testing in irgendeinem asiatischen Land mit niedrigen Löhnen betrieben wurde.

Die Durchführung eines solchen Regressionstestzyklus dauerte etwa ein Jahr, bei den letzten Malen waren dabei jeweils knapp 7000 kritische Bugs (→ funktionale Fehler ohne möglichen Workaround) entdeckt worden. Da nach dem Beheben dieser Bugs ein weiterer Regressionstestzyklus zu lange gedauert hätte wurden die Bugfixes gleichzeitig mit neuen Features eingecheckt, was natürlich Merge-Konflikte verursachte. Die Folge war das erneute Auftreten tausender Fehler, womit der Kreislauf von neuem begann.

Warum in diesem Fall nicht einmal im Entferntesten an agile Softwareentwicklung zu denken war ist offensichtlich: ein einziges, dazu noch Bug-verseuchtes, Grossrelease pro Jahr? Das ist weit, weit, weg von der Auslieferung nutzbarer Inkremente mehrfach pro Monat. Um weitgehend fehlerfreie Anwendungen auszuliefern hätte man sogar mindestens einen Regressionstestzyklus einer Bugfix-Welle abwarten müssen, in Summe hätte es dann zwei Jahre gedauert.

Wie man denn aus dieser Situation hauskommen könnte, war die Frage. Ein nachträgliches Automatisieren der Testfälle wäre wegen fehlendem Budget nicht möglich, ob es denn andere Wege gäbe agil zu arbeiten? Als das verneint wurde war relativ schnell klar, "dass Agil wohl nicht das Richtige für uns ist." Quod erat demonstrandum. Zwei Jahre später kam es zu einem zufälligen Treffen mit einem Kollegen des Testmanagers, der sich so geäussert hatte. Mittlerweile waren es keine 75.000 Testfälle mehr. Die Zahl war deutlich höher.