Montag, 30. April 2018

Kommentierte Links (XXXVI)

Bild: Pixabay / Bru-nO - Lizenz
  • Mike Cohn: Defect Management by Policy

    Als ehemaliger Testmanager bin ich an dieser Stelle ganz bei Mike Cohn: der einfachste Weg Defects zu priorisieren, bzw. festzulegen wann sie gefixt werden sollen, ist eine Einordnung in Gruppen, bzw. Kategorien. Eine Einzelfall-basierte Entscheidung wäre vielleicht individuell passender, treibt aber den Wert der Cost Per Reasonable Decision in unschöne Höhen. Was mit welcher Defect-Gruppe, bzw. Kategorie passiert ist nach jeweiligem Kontext festzulegen, ich bin da bekanntermassen ein Fan von Zero Bugs und Instant Implementation. Nicht, dass ich den anderen Fall nicht auch erlebt hätte, aber gerade darum - wer schon einmal in der Quälerei einer mehrmonatigen nachgelagerten Bugfixing-Phase gewesen ist will da nie wieder hin.

  • Benjamin Fischer: Rugby für das Büro

  • Eines vorweg: wenn agile Softwareentwicklung "superhip, superinnovativ und superstressig" ist (Zitat des FAZ-Autors Benjamin Fischer) dann ist sie falsch umgesetzt. Schließlich sind die Umsetzungsteams verpflichtet nur soviel in die Sprints, bzw. in Progress zu nehmen wie realistisch machbar ist, und auch dem Management stehen verschiedene Techniken zur Verfügung um Überlastung zu vermeiden. Was Fischer aber richtigerweise auch schreibt: in Umbruchphasen zwischen klassischem Management und agilem Vorgehen kann die Situation für alle Beteiligten aufreibend sein, alleine deshalb weil sich aktueller Status und angestrebter Karrierepfad plötzlich in Luft auflösen. Ein Problem das häufig unterschätzt wird.

  • Mark Schwartz: Leading Change from the Middle

    Wenn es eine Gruppe gibt deren Leben im Rahmen agiler Transitionen schwerer wird, dann ist es das mittlere Management. Oft zu Recht und häufig zu Unrecht wird es als Teil des Problems und nicht als Teil der Lösung gesehen, weshalb nur die wenigsten Transitionsprogramme eine klare Antwort darauf haben, welche Rolle ein mittlerer Manager zukünftig spielen soll und wie er dorthin kommen kann. Vor dem Hintergrund, dass die Vordenker von Scrum in dem mittleren Management eigentlich einen zentralen Faktor gesehen haben ist das sehr zu bedauern. Um so besser, dass es vereinzelt doch Überlegungen in diese Richtung gibt, wie diese hier von Mark Schwartz. Und ganz nebenbei: dass sie auf einem offiziellen Firmenblog von Amazon veröffentlich wird zeigt, dass diese Firma vieles besser macht als die Konkurrenz.

  • Nicolas Muldon: Customer Personas - How to Write Them and Why You Need Them In Agile Software Development

    Einer meiner Lieblingstweets der letzten Zeit lautet: "Lest eure User Stories. Und stellt euch dabei vor, wie der User, den das betrifft, das GENAU SO sagt." Was dahinter steckt ist die Erkenntnis, dass User Stories in den meisten Fällen genau das nicht sind, was sie eigentlich sein sollen - aus der Sicht eines Nutzers/Anwenders geschrieben. Stattdessen sind es die alten Elfenbeinturm-Ideen, nur wunderlich formuliert. Nicolas Muldon hat völlig recht wenn er schreibt, dass Personas hier für bessere Ergbnisse sorgen können. Richtig eingesetzt helfen sie dabei, besser zu verstehen was überhaupt die Wünsche und Bedürfnisse der Menschen sind, für die man sein Produkt baut.

  • Ian Borges: Why Semco Doesn’t Want Your Company To Be Like Semco

    Noch immer ist es so, dass manche Unternehmen versuchen ihre agile Transition zu beschleunigen indem sie die erfolgreichen Ansätze von anderen Firmen eins zu eins kopieren. Einen gewissen Hype gab es zeitweise um den Spotify Way, was mittlerweile zum Glück zurückgeht. Ab und zu hört man jetzt andere zu kopierende Vorbilder, wie Zalando, ING oder Semco. Was in diesem Artikel stellvertretend für sie alle gesagt wird: das wird auch hier nicht funktionieren. Der aktuelle Stand in diesen Firmen beruht auf jahrelangem, zum Teil jahrzehntelangem kulturellen Wandel und befindet sich auch weiterhin in einem stetigen Zustand der Anpassung und Veränderung. Eine Momentaufnahme davon einzufrieren und als Blaupause zu verwenden ist nicht zielführend.

Donnerstag, 26. April 2018

Sprintziele

Bild: Wikimedia Commons / Santeri Viimäki - CC BY 4.0
Kurze Frage: welcher Begriff wird im Scrum Guide ganze 26 mal erwähnt [Edit: seit 2020 18 mal], findet sich aber in sehr vielen Scrum Teams nicht wieder? Die Antwort: das Sprintziel, bzw. Sprint Goal. Obwohl Sprintziele von offensichtlich so großer Bedeutung sind würde ich sagen, dass sie bestenfalls in der Hälfte der über 100 Teams mit denen ich über die Jahre zusammengearbeitet habe verwendet wurden. Die anderen haben einfach nur mehr oder weniger zusammenhängende Arbeit in ihre Sprints gezogen, im Normalfall die obersten User Stories / Anforderungen ihres Product Backlogs. Und das ist ein Problem, denn ohne diese Ziele sind einige Vorteile schwerer erreichbar.

Ein Sprintziel hilft dem Product Owner bei der Planung. Wie in anderen Vorgehensweisen lassen sich auch in Scrum Aufgaben vom Grossen ins Kleine herunterbrechen. Aus der Produktvision wird z.B. eine Teilvision, daraus einige Meilensteine und daraus mehrere Sprintziele. Auch die können und sollen einem Inspect & Adapt unterliegen, trotzdem (oder gerade deswegen) können sie ein gutes Werkzeug sein um Arbeit in Etappen einzuteilen, die man nach und nach planen und angehen kann.

Ein Sprintziel hilft dem Product Owner bei der Priorisierung. Was im Backlog weiter oben stehen sollte und was nicht ist oft nur schwer zu bestimmen. Ist z.B. eine bessere Exportierbarkeit von Kundendaten wichtiger als eine bessere Importierbarkeit von Stammdaten? Wer kann das sagen? Werden die einzelnen Anforderungen zu Sprintzielen gruppiert kann das einfacher sein. Wenn das nächste Sprintziel z.B. lautet, bis zum bald bevorstehenden Stichtag DSGVO-kompatibel zu sein, dann ist klarer was dazugehören sollte (Kundendaten exportieren) und was nicht (Stammdaten-Import).

Ein Sprintziel hilft einem Team dabei fokussierter und konzentrierter zu arbeiten. Gerade bei komplexen und komplizierten Themen gibt es kaum einen größeren Produktivitäts-Hemmer als häufiges Kontext Switching. Sich in kurzen Abständen in immer neue Themen eindenken und immer neue Schnittstellen und Abhängigkeiten klären zu müssen kann in absurdem Ausmass Zeit fressen. Umgekehrt kann das fokussierte Arbeiten an einem Themenkomplex für Synergieeffekte im Denken und Umsetzen sorgen, die vieles beschleunigen.

Ausserdem hilft ein Sprintziel auch bei der Erfolgsmessung, und zwar in der denkbar einfachsten Weise. Man muss sich nur fragen: Haben wir das Sprintziel erreicht, ja oder nein? Damit das möglich ist müssen die Formulierungen natürlich klar und überprüfbar sein, also nicht "Wir wollen ein besseres Nutzungserlebnis bieten" sondern "Wir wollen die Anzahl der bis zum Geschäftsabschluss notwendigen Mouseclicks unter 20 drücken". Als Nebeneffekt führen die dafür nötigen Überlegungen und Diskussionen auch zu einem besseren Verständnis dessen was mit der Anforderung eigentlich gewollt ist.

Zuletzt noch ein Hinweis der selbstverständlicher klingt als er ist - es sollte ein Sprintziel geben, nicht mehrere. Auch hier ein Beispiel: "Wir wollen die die Performance erhöhen und das Design von Rot-Blau auf Grün-Silber umstellen" ist zwar ein Satz, trotzdem sind es mehrere Ziele. Ich habe mit Teams gearbeitet, die alle Sprintziele abgelehnt haben in denen ein Komma, ein Punkt oder die Wörter "und" und "ausserdem" vorkamen. Es hat ihnen geholfen.

Montag, 23. April 2018

Schneller fertig werden, nicht schneller arbeiten

Bild: Pexels / Burst - Lizenz
Es gibt einen Satz, der ist gleichzeitig eine der grössten Verheissungen, einer der bekanntesten Werbeslogans und eines der am weitesten verbreiteten Missverständnisse im Bereich der Agilität. Um ihn zu finden muss man nicht lange suchen, er steht gross auf dem Titel eines Buches, das von Scrum-Begründer Jeff Sutherland verfasst wurde. Er lautet Doing Twice the Work in Half the Time. Wenn er im Rahmen einer agilen Transition fällt sollte man dringend über ihn reden.

Wenn klassische Manager hören, dass man in der Hälfte der Zeit die doppelte Arbeit erledigen könne kommt bei vielen sofort der Fehlschluss zu Stande, dass das durch schnellere Arbeit passieren würde. Aus ihrer Sicht nachvollziehbar: in vielen Unternehmen herrscht noch immer die Ansicht vor, dass sich Arbeit an komplexen Aufgaben detailliert bis weit in die Zukunft planen liesse. Der Umkehrschluss - wenn das so ist, dann lässt sich mehr Geschwindigkeit nur durch schnellere Arbeit erreichen.

Dass das ein gefährlicher Trugschluss ist habe ich bereits beschrieben. Im besten Fall gelingt es und man gerät in die Build Trap, baut also in hoher Frequenz an den sich ändernden Marktbedürfnissen vorbei, in den schlechteren Konstellationen entsteht die (scheinbare) Geschwindigkeitssteigerung dadurch, dass dort Arbeit eingespart wird wo das Management es nicht sehen und nicht überprüfen kann, bei Organisation, Tests, Architektur, etc. In beiden Fällen treten die Auswirkungen verspätet aber unvermeidbar ein und aus der anfänglichen Beschleunigung wird ihr Gegenteil.

Unabhängig davon ist es aber tatsächlich so, dass agile Vorgehensweisen die Produktion erstaunlich schneller machen können. Die Ursachen dafür sind bekannt und lassen sich benennen.

Ein Grund ist, dass durch das ständige Inspect & Adapt und das permanente Kundenfeedback verhindert (oder zumindest eingedämmt) werden kann, dass am Markt vorbei entwickelt wird. Da in kleinen Arbeitspaketen sofort benutzbare Funktionen geliefert werden kann die Entwicklung jederzeit beendet und an einer anderen Stelle fortgesetzt werden. Anders als in Ansätzen mit langen Planungszyklen lässt sich dadurch Arbeit in grossem Ausmass vermeiden, und das nicht nur dadurch, dass man sie unterlässt - auch Folgearbeiten wie z.B. Ausbau oder Wartung der unnötig erstellten Features entfallen.

Ein weiterer Aspekt ist die Verkürzung von Wartezeiten. In den meisten nicht agilen Teams die ich kenne besteht die Fertigstellungszeit eines Produkts zu mehr als der Hälfte daraus, dass auf die Zulieferung eines anderen Teams gewartet wird. In einer agilen Umgebung ist das anders: Scrum Teams sind per Definition crossfunktional und haben wenige Abhängigkeiten, Kanban Teams arbeiten permanent an der Beseitigung von Flaschenhälsen und der Verbesserung von Übergabeprozessen. In beiden Fällen ist eine deutliche Verkürzung der Wartezeiten die Folge, und damit eine beschleunigte Fertigstellung.1

Zuletzt tritt noch ein Effekt auf, der gewissermassen die Umkehrung des weiter oben genannten "Sparen wo es das Management nicht sieht" ist. Wenn Teams nach dem Pull-Prinzip arbeiten (einem der zentralen Bausteine aller agilen Vorgehen), dann nehmen sie neue Arbeit erst an wenn sie mit der alten wirklich fertig sind. Und zu diesem "wirklich fertig" gehört, dass getestet wurde, dass kein toter oder unverständlicher Code zurückgelassen wurde, dass alle durch Seitenauswirkungen erzeugten Bugs gefixt wurden, etc. Das macht die Arbeit zwar im Einzelfall etwas langsamer, langfristig sorgt es aber für deutlich mehr Geschwindigkeit.

Zusammengefasst: eine deutliche Geschwindigkeitssteigerung der Produktion ist durch Agilität möglich. Das bedeutet aber nicht schnelleres Arbeiten sondern intelligenteres Arbeiten. Diesen Unterschied sollten alle Beteiligten verstanden haben.


1Ein häufiger Einwand an dieser Stelle ist, dass "in unserem Fall" Crossfunktionalität und Arbeit am Prozess nicht möglich sind. Das ist in den meisten Fällen eine Ausrede, aber selbst dort wo es stimmt ist es kein Argument. Solche Teams können strukturell kaum agil arbeiten, also sollte man sie nicht agil nennen und dort auch nicht die Vorteile von Agilität erwarten.

Donnerstag, 19. April 2018

Kanarienvögel

Bild: Pixabay / jrperes - Lizenz
In der englischen Sprache gibt es die Redewendung des "Canary in a coal mine", also des Kanarienvogels im Kohlebergwerk. Hintergrund ist das bis in das 20. Jahrhundert übliche Vorgehen, solche Vögel mit unter Tage zu nehmen. Wenn in den Stollen Gase austraten oder die Luft zu kohlensäurehaltig wurde starb zuerst der auf viel Sauerstoff angewiesene Vogel, den Menschen blieb meistens noch genug Zeit um zu flüchten. Abgeleitet davon wird der Begriff des Canary in a coal mine auf alle Regeln und Praktiken angewandt, deren Verschwinden ein starker Indikator dafür ist, dass deutliche Verschlechterungen unmittelbar bevorstehen.

Auch im Kontext agiler Transitionen gibt es Kanarienvögel, deren Verschwinden ein deutliches Signal eines kommenden oder bereits stattfindenden Rollbacks sein kann. Wenn festzustellen ist, dass sie schwächer werden oder sogar ihr Leben aushauchen ist es Zeit das Weite zu suchen oder (um die Analogie weiterzutreiben) für einen neuen Zufluss frischer Luft zu sorgen, mit dem die Transition wiederbelebt wird. Zu den agilen Kanarienvögeln gehören:

Die Ausgestaltung des Scrum Masters als Vollzeitstelle

Jedem der diesen Job (oder den eines Kanban-Delivery Managers) einmal ausgeübt hat ist es klar, dass er anders als in Vollzeit gar nicht auszuüben ist. Eher noch ist es so, dass die zahlreichen Tätigkeiten im Dienst des Teams, des Product Owners und der Organisation in Überstunden ausarten oder in das Privatleben hineinwuchern können. Das zu beschneiden kann nur Dysfunktionen zur Folge haben, mit dem häufigen ersten Ergebnis, dass der ständige Anpassungs- und Verbesserungsprozess zum Erliegen kommt, da seine Stimulierung im engen Zeitplan wegpriorisiert wird. Und oft beginnen die Probleme damit erst, zum Beispiel dann wenn ein Teilzeit-Scrum Master mit einem Teilzeit-Product Owner kombiniert wird.

Das Recht der Teams, Akzeptanzkriterien und Definition of Done frei zu definieren

Ein massiver Eingriff in die Selbstorganisation der Teams liegt vor wenn versucht wird, übergreifende "Qualitätsstandards" einzuführen. Zum einen weil diese, "um auf Nummer sicher zu gehen", die Tendenz haben unnötig detailliert-bevormundend zu sein und damit fast zwangsläufig zur Entstehung einer übergreifenden, regulierenden und kontrollierenden Bürokratieschicht führen, zum anderen weil sie aufgrund der Vielzahl der Betroffenen und Verantwortlichen nur noch sehr langsam zu ändern sind, selbst wenn die Rahmenbedingungen sich schon längst geändert haben.

Die von Team zu Team unterschiedliche Bedeutung von Story Points

Einer der großen Klassiker fehlgeleiteter Management-Bemühungen. So nachvollziehbar es ist, teamübergreifende Planzahlen haben zu wollen, so schädlich ist es auf der anderen Seite sie zu erzwingen. Das führt nämlich nicht nur zu einer festen Umrechnung in Stunden oder Personentage (alleine das wäre bereits schlimm genug), es erzeugt für viele Manager auch die große Versuchung, diesen Wert "optimieren" zu wollen, mit all dem unrealistischen Erwartungs-, Kontroll- und Erzwingungs-Overhead der damit verbunden ist.

Die direkten Feedbacks von Benutzern und Stakeholdern an das Entwicklungsteam

Ohne direkte Rückmeldung von den Anwendern und Auftraggebern wird jedes Team permanent mit dem erheblichen Risiko leben müssen, am Markt vorbei zu produzieren. Wird dieses Feedback in Management-Runden, Kommittees oder vorgelagerte Fachabteilungen verlagert, sind "Stille Post-Effekte" die Folge, durch die die Rückmeldungen nur noch verzerrt, verfälscht oder reduziert bei dem Entwicklungsteam ankommen. Auch Rückfragen und Austausch sind dann nur noch verlangsamt möglich, wodurch neben der Bedarfsgerechtheit auch die Reaktionsgeschwindigkeit abnimmt.

Der Framework-Charakter von Scrum, Kanban & Co.

Dass Scrum viele Bereiche der Umsetzung wenig bis gar nicht reguliert ist volle Absicht und soll verhindern, dass zu detaillierte Vorgaben im Einzelfall nicht mehr anwendbar sind. Auch auf XP und Lean Startup trifft das zu, und Kanban hat als "open Source Methode" überhaupt kein offizielles Regelwerk. Wird um diese Ansätze herum eines der üblichen, verpflichtend zu befolgenden Prozesshandbücher verfasst, treten verschiedene Folgen auf: zum einen kann eine zu umfangreiche Stoffmenge nicht mehr in das kollektive Gedächtnis der Organisation übergehen und gerät dadurch schnell in Vergessenheit, zum anderen regt das Vorhandensein optionaler Regeln zu permanenten Sinnfragen an und damit auch Anpassungsfähigkeit und -bereitschaft. Umgekehrt geht diese zurück wenn Regeln zu einengend und detailliert sind.

---

Was allen diesen Punkten (und einigen weiteren) gemeinsam ist: sie wirken auf den ersten Blick wie nachrangige Faktoren, an denen man relativ risikolos herumhantieren kann. Wie gesagt, auf den ersten Blick. Auf den zweiten zeigt sich, dass sie alle mit der Fähigkeit eines Teams und einer Organisation in Verbindung stehen flexibel und reaktionsschnell (also agil) zu sein. Werden an ihnen trotzdem Verschlimmbesserungen durchgeführt zeigt das, dass einige für die agile Transition bedeutsame Zusammenhänge nicht erkannt (oder bewusst ignoriert) werden. Vor diesem Hintergrund sind sie als Canary in a coal mine besonders geeignet.

Montag, 16. April 2018

Lokale Optimierung

Bild: Miso Robotics
Zuerst klingt die Geschichte aus der USA Today reichlich skurril: Cali Burger (eine amerikanische Fast Food-Kette) hatte in einer Filiale einen Roboter namens "Flippy" installiert, der in der Lage sein sollte die unglaubliche Menge von 2000 Stück Burgerfleisch pro Tag zu grillen. Nach gerade zwei Tagen war das Experiment aber bereits vorbei und Flippy wurde wieder durch Menschen ersetzt. Was war passiert?

Anders als man denken könnte war nicht der Roboter selbst das Problem, zumindest nicht direkt. Er tat genau das was er sollte, nämlich im Akkord Fleisch grillen. Das Problem war seine Zusammenarbeit mit den menschlichen Kollegen: zum einen konnten die mit der Arbeitsgeschwindigkeit nicht mithalten, zum anderen funktionierten die Übergaben nicht richtig - es gelang häufig nicht, das Fleisch dort bereitzuhalten oder abzuholen wo Flippy es benötigt hätte. Um wieder funktionierende Abläufe zu haben mussten erneut Menschen an die Bratfläche.

Was hier geschehen ist, ist das perfekte Beispiel für die Probleme lokaler Optimierungen. In dem kleinen Abschnitt des Bratens und Wendens war die Automatisierung eine klare Verbesserung von Geschwindigkeit und Qualität, ausserdem waren anstrengende und stressige Jobs betroffen, die nur wenige Mitarbeiter machen wollten. Aus dieser Perspektive war die Umstellung ein voller Erfolg. Dass ein Fehlschlag daraus wurde lag an der fehlenden Gesamtsicht, durch die zwei Risikofaktoren nicht auffiehlen.

Zum einen sorgte die sprunghafte Erhöhung der Arbeitsleistung dafür, dass die vor- und nachgelagerten Arbeitsstationen zu Flaschenhälsen wurden: im Bereich vor dem Roboter sorgte die langsamere Geschwindigkeit dafür, dass er Leerlauf hatte, im Bereich nach ihm staute sich die Arbeit. Zum anderen sorgten die schlecht orchestrierten Übergaben für Effizienz- und Effektivitätsverluste - da die Schnittstellen zwischen Mensch und Roboter nicht abgestimmt und standardisiert wurden, arbeiteten sie aneinander vorbei.

Diese Faktoren (unterschiedliche Verarbeitungskapazitäten und ineffektive Übergaben) treten sehr häufig auf wenn in längeren Prozessketten nur lokale Optimierungen umgesetzt werden. Manchmal, wie im Fall von Flippy, führt das dazu, dass diese Veränderungen zurückgenommen werden müssen, manchmal sind sogar dauerhafte Verschlechterungen die Folge.

Um das zu vermeiden sollten in Digitalisierungs- und Automatisierungsprojekten Systeme immer ganzheitlich betrachtet werden, denn sonst kommt es so wie bei jetzt bei Cali-Burger: dort steht ein teurer Roboter in der Ecke, kostet Geld und erbringt keinen Mehrwert. Ein Denkmal einer fehlgeschlagenen lokalen Optimierung.

Donnerstag, 12. April 2018

Stop where you are

Bild: Pxhere - CC0 1.0
Fortschritt ist wichtig und Stillstand ist Rückschritt, so weit, so gut. Klar ist aber auch, dass Veränderung kein Selbstzweck ist, schon gar nicht dann wenn es darum geht bestimmte Methoden und Frameworks einzuführen. Wenn hinterfragt wird. welchen Mehrwert eine Veränderung bringen soll, kann es vorkommen, dass sich der aktuelle Zustand als völlig ausreichend herausstellt. Wie im folgenden Beispiel.

Ein Team bei einem Kunden hatte die Aufgabe bestimmte Services für die internen Benutzer einer Software zu erbringen - Accounts anlegen, Berechtigungen vergeben, Passwörter zurücksetzen, etc. Um das effizienter zu gestalten war versucht worden Lean Six Sigma einzuführen, was am aktiven und passiven Widerstand der Teammitglieder gescheitert war, die in der Methode einen bürokratischen Prozess-Overhead gesehen hatten1. Um das Team nicht "unmethodisch" vor sich hin arbeiten zu lassen sollte als nächstes eine Umstellung auf Kanban stattfinden. Ganz im Sinn von Start where you are stand dabei am Beginn eine Bestandsaufnahme des Ist-Standes, die das folgende Ergebnis hatte:

Die Organisation des Teams erfolgte durch eine Mischung aus Lean Six Sigma-Versatzstücken, Improvisation und "war schon immer so"-Elementen und war um eine jeden Morgen stattfindende Statusrunde organisiert. Vor dieser stellte jedes Teammitglied seine persönliche Belastungs-Ampel auf einem gemeinsamen Board auf Grün, Gelb oder Rot, je nach Arbeitslast. Ein wechselnder Moderator fragte alle deren Ampel auf Rot stand nach den Gründen und vermittelte Hilfe von weniger überlasteten Teammitgliedern. Strukturelle Probleme wurden dem Teamleiter übergeben, der dann in den nächsten Meetings berichtete wie er mit der Behebung vorankam.

Bei den Befragungen waren alle Beteiligten der Meinung, der aktuelle Prozess wäre der beste seit langem. Die Arbeit würde gerecht verteilt und schnell erledigt, Leerlauf und Überlastung kämen kaum vor, Schieflagen würden innerhalb eines Tages erkannt und behoben, die Problemlösung wäre unkompliziert und transparent. Es war zwar allen bewusst, dass die offiziellen Arbeitsanweisungen nicht eingehalten würden, aber es würde doch alles gut funktionieren. Wäre das nicht völlig ausreichend?

Das Ergebnis war dann tatsächlich ein Ratschlag an das Management, auf neue Methoden-Einführungen zu verzichten und alles so zu lassen wie es in diesem Moment war. Auf seine eigene Art hatte das Team bereits das Ziel der Firma erreicht: effektives Arbeiten mit schlanken Prozessen und schneller Reaktionsfähigkeit bei unerwarteten Entwicklungen. Jetzt noch Kanban oder irgendeinen anderen Ansatz einzuführen wäre nichts anderes gewesen als Methodismus. Viel besser war es, die Leute einfach in Ruhe arbeiten zu lassen.


1Eine feine Ironie der Geschichte.

Montag, 9. April 2018

Start where you are

Bild: Flickr / Chris Hunkeler - CC BY-SA 2.0
Es ist eine der Grundregeln von Kanban: anders als bei Scrum werden zu Beginn keine neuen Rollen und Regeln eingeführt (zumindest meistens nicht), stattdessen wird lediglich der bisherige Arbeitsablauf visualisiert. Sobald das passiert ist wird er auf Engstellen, Überkapazitäten und Probleme untersucht und dann erst nach und nach angepasst. Das scheint ein einfacher Einstieg zu sein, in Wahrheit ist er es oft aber nicht. Viele Organisationen haben grösste Probleme damit, ihren Ist-Zustand festzuhalten.

Ein Grund dafür ist, dass an vielen Stellen der offizielle Arbeitsprozess und der tatsächliche Arbeitsprozess voneinander abweichen. Im Fall eines Managers den ich vor kurzem kennenlernen durfte war der offizielle Prozess To Do 🡒 Analysis 🡒 In Progress 🡒 Done, in der Realität fand aber To Do 🡒 Analysis 🡒 In Progress 🡒 Nachträgliche Änderung der Anforderungen 🡒 Überarbeitung 🡒 Done statt. In dem Ministerium in dem ich vor langer Zeit gearbeitet habe war der offizielle Weg Entscheidungsbedarf 🡒 Entscheidungsvorlage 🡒 Entscheidung, was tatsächlich immer wieder stattfand war allerdings Entscheidungsbedarf 🡒 Entscheidungsvorlage 🡒 Verschleppen der Entscheidung 🡒 Veraltung der Vorlage 🡒 Überarbeitung der Vorlage 🡒 Entscheidung. Das Abbilden des tatsächlichen Prozesses deckt in solchen Fällen Ineffizienz und Dysfunktionalität auf und wird daher häufig aus politischen oder persönlichen Gründen bekämpft.

Was immerhin noch der Vorteil in solchen Konstellationen ist, ist die Tatsache, dass der tatsächliche Prozess zwar nicht angesprochen wird, aber jedem bekannt ist. Noch schwieriger wird es wenn Teile der Organisation glauben, dass der offizielle Prozess funktionieren würde und der tatsächliche Prozess weitgehend unbekannt ist. Ein regelmässig in diesem Zusammenhang anzutreffendes Phänomen ist die brauchbare Illegalität: Der vorgegebene Ablauf ist in sich widerspüchlich oder unrealistisch, was die Mitarbeiter dem Management aber (aus welchem Grund auch immer) nicht sagen, bzw. sagen dürfen. Um trotzdem arbeitsfähig zu sein werden unter der Hand informelle Prozesse angelegt, während die offiziellen nur noch als "Theaterstück" aufgeführt werden um gegenüber den oberen Ebenen den Schein zu wahren. Auch das ist natürlich bei einer Offenlegung hochproblematisch.

Warum auch immer sich Anspruch und Realität auseinanderentwickelt haben - das Aufdecken dieser Parallelität ist für die Beteiligten ernüchternd und schmerzvoll. Zu Beginn einer Kanban-Einführung besteht daher die Gefahr, dass es in solchen Fällen zu Auseinandersetzungen oder Verdrängungen kommt. Das zu verhindern und in konstruktive Bahnen zu lenken ist die eigentliche Herausforderung dieser Phase, die auf den ersten Blick so unproblematisch wirkt.

Donnerstag, 5. April 2018

'Was wollen wir schlecht machen?' als Thema für Retrospektiven

Bild: Wikimedia Commons / Lewis Clarke - CC BY-SA 2.0
Vor kurzem war ich wieder bei einem der Teams zu Gast die ich von Zeit zu Zeit coachen darf und habe voller Freude festgestellt, dass es seit meinem letzten Besuch angefangen hat seine Retrospektiven zu modifizieren um sie abwechselungsreicher zu gestalten. Als letztes hatte es sich eine angepasste Version der Timeline-Retro ausgedacht: statt nur die Ereignisse des letzten Sprints rückblickend auf einer Zeitleiste anzuordnen hatte es diese auch in die Zukunft führend abgebildet. Und da es ausserdem die klassischen Dimensionen gut und verbesserungswürdig gab entstanden die folgenden vier Quadranten:

Die erste Überlegung angesichts dieser Felder war, dass in der Retrospektive nur die Themenfelder links oben, links unten und rechts oben besprochen werden sollten. Das Feld rechts unten (Was wollen wir schlechter machen?) wäre widersinnig und müsste leer bleiben, schließlich würde ja niemand bewusst etwas schlechter machen wollen als in der Vergangenheit. Bei näherer Betrachtung schien das allerdings doch nicht ganz so abwegig wie zu Beginn.

Auch die besten Teams können in Situationen geraten in denen Antipattern praktisch unvermeidbar sind. In seltenen Fällen gibt es zum Beispiel eben doch Anforderungen die sich beim besten Willen nicht so klein schneiden lassen, dass sie in einem Sprint fertig werden können. Ganz bewusst wird dann in Kauf genommen, dass von Beginn an kein erreichbares Sprintziel formuliert werden kann. In anderen Konstellationen kann es sein, dass die Teammitglieder zeitweise nicht alle nötigen Skills haben die sie eigentlich bräuchten, etwa weil der Experte für das Thema Penetrationstests oder Verbraucherschutz in Elternzeit geht. In solchen Fällen die Produktion anzuhalten wäre keine realistische Option, der einzige Weg besteht dann mitunter darin, dass bestimmte Antipattern nicht nur toleriert sondern mangels Alternativen sogar eingeplant werden. Das eigentlich Widersinnige tritt ein: bewusst wird etwas schlechter gemacht als in der Vergangenheit.

Im Fall der oben erwähnten Retrospektiven-Variante sind genau das die Themen die in das Feld rechts unten eingetragen werden würden. Und sobald sie dort stehen kann man sich proaktiv Gedanken machen wie man die unausweichlichen negativen Folgen und Begleiterscheinungen frühzeitig entdecken und in Grenzen halten kann. Letztendlich ist das auch eine Möglichkeit wieder mehr Kontrolle über die Situation zu erhalten - man kann Verschlechterungen nicht verhindern, man kann sie aber dafür sorgen, dass sie sich nicht dorthin ausdehnen wo das vermeidbar ist. So gesehen ist es also sehr anzuraten, im Werkzeugkasten ein Retro-Format zu haben das explizit die Frage stellt was man zukünftig schlechter machen will.

Montag, 2. April 2018

Das agile Altersheim

Ich bin nicht sicher ob dieses Video hier ein Aprilscherz oder ein Rant ist. Vermutlich beides. Aber es ist sehr witzig. Und sehr wahr.