Mittwoch, 31. Oktober 2018

Kommentierte Links (XLII)

Bild: Pixabay / Bru-nO - Lizenz
  • Tim Harford: Why Big Companies Squander Brilliant Ideas

    Ein langer Text, aber lesenswert. Mit mehr als 20.000 Zeichen führt Tim Harford aus warum sich große Organisationen mit Innovationen schwer tun: zum einen weil neue, zu Beginn noch nicht profitable Ideen sich im internen Wettbewerb um Ressourcen nicht gegen die etablierten, seit langem Gewinn abwerfenden Cash Cows durchsetzen können, zum anderen weil die bestehenden Organisationsstrukturen so stark auf die bestehenden Produkte zugeschnitten sind, dass neue Produktideen nur umgesetzt werden wenn sie ebenfalls diesen Strukturen entsprechen - was häufig nicht der Fall ist. Der dritte Grund dagegen ist wesentlich polemischer und darum mit Vorsicht zu geniessen: "Because people are idiots."

  • Dennis Willkomm: Am Scheitern scheitern – Gefahren der Fehlerkultur

  • Ich freue mich ja immer wenn ich merke, dass ich nicht der erste aus der lokalen Agile-Community bin der dieses Internet vollschreibt. Dennis Willkomm hat sich hier eines selten behandelten Themas angenommen, nämlich dem, dass nicht nur die Einführung von Methoden sondern auch die Veränderung einer Unternehmenskultur im Cargo Cult enden kann. Mit Exkursen in die Psychologie unterfüttert wird eine Erkenntnis herausgearbeitet die man vielen Change Management-Abteilungen nur wünschen kann: wer glaubt seinen Mitarbeitern eine neue Kultur einfach überstülpen zu können wird damit alles mögliche erreichen, nur nicht das was er eigentlich beabsichtigt hat.

  • Alice Newton Rex: Escape From the Feature Roadmap to Outcome-driven Development

    Ein Thema das ich in letzter Zeit immer wieder in Product Owner-Workshops besprochen habe findet sich auch hier wieder: gegenüber Stakeholdern/Management/Kunden/Auftraggebern sollte sich ein Product Owner nicht zur Lieferung bestimmter Funktionalitäten verpflichten sondern zur Lieferung abstrakt formulierter Kundenmehrwerte, deren bester Umsetzungsweg sich erst im Rahmen der Umsetzung selbst ergeben wird. Dieser Ansatz widerspricht zwar dem üblichen Verhalten in vielen Organisationen (Alice Newton Rex erklärt gut warum), führt aber bereits mittelfristig zu besseren Ergebnissen als die vordefinierte Roadmap, die zuverlässig zu einem Ziel führt das von der Zielgruppe mittlerweile längst verlassen worden ist. (Siehe auch: agile Roadmaps)

  • Joe Crick: It Doesn’t Have to be Perfect

    Einige gute Gedanken zum Thema Legacy Code, nicht zuletzt deshalb weil sie nicht aus einer technischen sondern eher aus einer soziologischen Perspektive geschrieben wurden. Folgende Aspekte sind für Joe Crick im Umgang mit Legacy Code wichtig:
    • Respektiere das was er tut: er mag nicht den Standards entsprechen, aber die aus ihm bestehende Anwendung sichert Dein Einkommen.
    • Verstehe wie er entstanden ist: die Organisationsstruktur zur Zeit seiner Entstehung spiegelt sich im Code wieder (→ Conway's Law). Damals hat er vielleicht mehr Sinn ergeben als heute.
    • Lege realistische Standards an: die Aussage aus der Überschrift. Code muss nicht perfekt sein, es reicht wenn er gut ist. Beziehungsweise - gut genug für den Zweck den er erfüllen soll.
    • Sei massvoll in der Beurteilung: in den seltensten Fällen ist Legacy Code der unbrauchbare Mist als der er häufig beschimpft wird. Er mag buggy, kompliziert und umständlich sein, aber dann sollte man ihn auch nur so nennen.
    • Gehe gelassen mit ihm um: Kein Mensch ist perfekt, alle machen Fehler. Und umgekehrt und nicht alles ein Fehler was man selbst nicht versteht. Wer das akzeptiert kann besser mit den Hinterlassenschaften anderer umgehen.
    Gedanken wie diese sind praktisch immer hilfreich, und zwar nicht nur beim Schreiben von Software. Auch im Change- oder Prozessmanagement können sie von Nutzen sein, denn letztendlich ist auch die Struktur einer Firma nichts anderes als organisatorischer Legacy-Code.

  • Department of Defense, Defense Innovation Board: Detecting Agile BS

    Unter allen möglichen Orten an denen man nach einem Leitfaden zur Überprüfung von Agilität suchen würde ist eine Behörde so ziemlich einer der letzten. Und doch - wenn man es wagt wird man überrascht. Das amerikanische Verteidigungsministerium hat ein nicht nur brauchbares sondern sogar wirklich gutes Dokument entwickelt, das sich auch quer durch alle Branchen anwenden lässt. Statt Formalien abzufragen konzentriert es sich auf das Wesentliche - wird in kurzen Zyklen Mehrwert geliefert? Wird Feedback von den Anwendern (den echten, nicht deren Vorgesetzten) eingeholt? Sind wiederkehrende Tätigkeiten automatisiert? Etc. Besonders schön: um den in der Überschrift genannten "Agile Bullshit" auszufiltern sind auch typische falsche und ausweichende Antworten auf die Überprüfungsfragen vorhanden. Und jedem der in grossen Organisationen gearbeitet hat werden die sehr bekannt vorkommen.

Montag, 29. Oktober 2018

Der rotierende Scrum Master

Bild: Pixabay/MoreLight - Lizenz
Ein Phänomen das man in manchen Unternehmen beobachten kann ist der "rotierende Scrum Master". Die Rolle ist in diesem Fall nicht fest mit einer Person besetzt sondern wird in jedem Sprint von einem anderen Teammitglied wahrgenommen. Für die Dauer dieser Zeit arbeitet diese Person nicht an der Produktentwicklung mit sondern unterstützt das Team und beseitigt Impediments. Da eine solche Konstellation fast immer kontrovers diskutiert wird, lohnt es sich, einen genaueren Blick darauf zu werfen.

Zunächst die naheliegendste Frage: ist eine Rotation im Rahmen der Methodik überhaupt zulässig? Die Antwort: implizit ja. Der Scrum Guide definiert zwar die drei Rollen des Product Owners, des Scrum Masters und des Teams, legt aber nicht fest, dass es immer die selbe Person ist die sie besetzen muss. So lange alle Rollen besetzt sind ist den Formalien genüge getan.

Es gibt auch gute Gründe für ein Wechseln der Rolle zwischen den Teammitgliedern. Dadurch dass sie früher oder später von jedem ausgeübt wird liegt die Verantwortung für Prozess und Methodik bei allen und nicht nur bei einem. Gleichzeitig steigt auch die Ausfallsicherheit - ein Urlaub oder eine Krankheit des Scrum Masters lässt keine Lücke entstehen, da alle anderen in der Rolle geübt sind und sie übernehmen können.

In vielen Fällen kommt noch dazu, dass sich kein Teammitglied findet, das dauerhaft seinen bisherigen Job aufgeben möchte. Selbst wenn die Sinnhaftigkeit eines Scrum Masters eingesehen und hochgehalten wird finden viele Menschen in der Produktentwicklung eine wesentlich grössere Erfüllung. Muss das nur vorübergehend aufgegeben werden kann das die Besetzung deutlich einfacher machen.

Auf der anderen Seite gibt es auch Gegenargumente. Das naheliegendste ist, dass die Beschäftigung mit Methodik, Moderation, Coaching, etc. erstaunlich viel Zeit in Anspruch nehmen kann, und zwar nicht nur in der Durchführung sondern auch im Lernen, Weiterbilden, Reflektieren und Perfektionieren. Wird das nicht auch dann vorangetrieben wenn die Rolle gerade nicht ausgeübt wird  kommt es zu kurz um wirksam zu sein (und damit stellt sich auch die Frage nach der dafür verfügbaren Zeit).

Ebenfalls nicht zu vernachlässigen ist, dass durch eine Rotation Neutralität verloren geht. Wer bestimmte Entscheidungen der Produktstrategie oder -umsetzung (mit)verantwortet hat wird sich schwer tun Konflikte zu diesen Themen unbefangen zu moderieren. Schlimmstenfalls wird er selbst als Teil einer Konfliktpartei gesehen und nicht als Vermittler akzeptiert. Um das zu vermeiden ist eine hohe Konflikt- und Meetingkultur aller Beteiligten nötig.

Zuletzt ist es in grösseren Organisationen meistens so, dass die Einheiten und Personen ausserhalb des Scrum Teams sich einen festen Ansprechpartner wünschen. Ist dieser nicht gegeben kann ggf. das Beziehungs- und Vertrauensnetzwerk nicht entstehen, das zur schnellen und unkomplizierten Beseitigung von Impediments nötig ist. Auch das oft praktizierte Geben, Nehmen und Verrechnen von Hilfen und Gefälligkeiten wird schwerer.

Eine immer richtige Entscheidung für oder gegen einen rotierenden Scrum Master kann es aus den genannten Gründen nicht geben, wohl aber eine Entscheidungshilfe: diese Konstellation wird vor allem da funktionieren wo sowohl das Scrum Team als auch die umgebende Organisation Scrum samt des dazugehörenden Mindset sehr gut verstanden haben und es aus intrinsischer Motivation heraus befolgen. Da wo das (noch) nicht gegeben ist kann eine dauerhafte Rollenbesetzung mehr Sinn machen.

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
Fünfter Teil der Deine Muda-Serie. Die vierte Art der Mudas (無駄), also der nicht gewinnbringenden (und aus diesem Grund zu vermeidenden) Tätigkeiten des Toyota Production System ist das Warten. Ein interessanter Aspekt - auch das erzwungene Nichtstun kann demnach eine zu vermeidende Tätigkeit sein. Max Weber wäre begeistert.

Ä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
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)

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

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

Bild: Pexels / Fauxels - Lizenz
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.