Donnerstag, 17. Mai 2018

Decision Stories

FS
Bild: Pixabay / Qimono - CC0 1.0
Eine der eher nervtötenden Tätigkeiten in Organisationen jeglicher Grösse ist das Nachvollziehen von Entscheidungen, die vor längerer Zeit getroffen worden sind. Selbst wenn alle Beteiligten noch immer anwesend sind kann es zu einer echten Herausforderung werden rückwirkend zu klären warum und unter welchen Bedingungen ein Beschluss gefasst wurde. Grundsätzlich ist das erklärbar, gerade in einem agil arbeitenden Umfeld sind Entscheidungen so häufig nötig, dass der Einzelfall in der Erinnerung verschwimmt. Man muss also dokumentieren. Und damit beginnen weitere Probleme.

Im besten Fall wird die Entscheidung im Rahmen eines Meeting-Protokolls festgehalten. Diese sind in der Regel knapp gehalten und Ergebnis-orientiert, was dann so aussehen kann (angelehnt an einen echten Fall):
Man sieht - die Entscheidung ist festgehalten, es sind auch die an der Diskussion beteiligten Personen genannt und es wird sogar auf die besprochenen Them eingegangen. Trotzdem ist im Rückblick völlig schleierhaft was letztendlich den Ausschlag für eine Option gegeben hat. Und wie gesagt, das ist noch ein gutes Beispiel. Schlimmer sind Fliesstexte, die häufig so aussehen:
Die Ausschreibung erfolgte unter den im Vergabeportal registrierten Preferred Suppliern mit Fristende auf dem letzten Tag von Q4. Basierend auf den in der Evaluierungsphase gesammelten Kriterien (vergleiche Kriterienkatalog PA30005 in der Version vom 26.11. und Procurementrichtlinie ITBesT28, Version 32.05) konnte die Auswahl auf drei Bieter eingeengt werden (siehe Entscheidungsvorlage Bieter Q4 final mit Aufschlüsselung auf die 49 als relevant identifizierten Schlüsselkriterien). Basierend auf der im Vergleich höheren Fach- und Branchenexpertise der QWERT AG und im Hinblick auf zu erwartende Synergieeffekte mit dem vom selben Bieter unterstützten Oktopus-Projekt konne in einem ersten Pitch der postive erste Eindruck bestätigt werden ...
Und so kann es über mehrere Seiten weitergehen. Schwer zu lesen, schwer zu ertragen und schwer nachzuvollziehen. Letztendlich wird die Entscheidung hier eher verschleiert als nachvollziehbar gemacht. So sollte es also nicht sein. Aber wie dann?

Eine bessere Möglichkeit die in den letzten Tagen durch meinen Newsfeed gerauscht ist greift die Idee hinter der User Story und der Vision auf und überträgt sie: wenige, in verständlicher Sprache verfasste Sätze fassen sowohl die Entscheidung als auch die dazugehörenden Kontextinformationen zusammen. Ein Beispiel:
Basierend auf der Annahme, dass der Personalbestand weiterhin um 10 % pro Quartal wächst wird die angemietete Bürofläche um 500 m2 erweitert, um während des gesamten Folgejahres eine Co-Location mit 12 m2 je Mitarbeiter gewährleisten zu können. Ein Plan-Ist-Abgleich findet einal pro Quartal statt, um ggf. Anpassungen der Flächengrösse vornehmen zu können.
Sechs Informationen sind hier enthalten: zugrundeliegende Hypothese, abgeleitete Massnahme, erwarteter Mehrwert, Prüfkriterien, Überprüfungsintervall und mögliche Korrekturmassnahme. Eine auf diese Weise dokumentierte Massnahme ist jederzeit nachvollziehbar, validierbar und bei Bedarf korrigierbar, ohne dass gross diskutiert oder überlegt werden müsste. Würden Entscheidungen durchgehend nach diesem Format dokumentiert würden die Unklarheiten deutlich abnehmen.Und falls das Ding einen Namen braucht - analog zur User Story würde sich die Decision Story anbieten.

Montag, 14. Mai 2018

On Site Customer

FS
Bild: Pexels / Rawpixel - CC0 1.0
Nicht alles was im agilen Kontext Sinn macht muss notwendigerweise aus Scrum oder Kanban kommen. Auch andere Ansätze haben Good Practices herausgebildet, die grossen Mehrwert stiften können. Einer davon ist der sogenannte On Site Customer aus dem Extreme Programming, bzw XP. Ein Vertreter der Kunden oder Anwender der beim Umsetzungsteam anwesend ist und mit ihm zusammenarbeitet.

Wie häufig in derartigen Fällen ist die Einrichtung des On Site Customers die Reaktion auf einen Missstand. Bedingt dadurch, dass komplexe Themen nicht immer einfach zu erklären sind und verstärkt dadurch, dass Kunde und Entwickler so unterschiedliche Hintergründe haben können, dass sie quasi verschiedene Sprachen sprechen, sind in der Produktentwicklung Missverständnisse praktisch unvermeidbar. Diese zu beheben kostet dann Zeit und Geld. Der einfachste (und in vielen Fällen einzige) Weg um diese Situation aufzulösen ist die Anwesenheit eines Kunden, bzw. Endanwenders vor Ort, der unmittelbares Feedback geben kann ob die Umsetzung den Bedürfnissen entspricht.

Was dabei zu beachten ist: dieser Kundenkontakt sollte nicht nur in den Rewiew- oder Demonstrationsmeetings erfolgen (wobei das zumindest besser ist als nichts) sondern auch darüber hinaus. Ein Kunden- oder Benutzervertreter kann in Refinements seine Sicht der Dinge erläutern, kann Teams und Product Owner beraten welche Anforderungen dringend sind, welche einen hohen Business Value haben oder ein grosses Risiko beseitigen, kann MVPs und Prototypen begutachten, sich an Akzeptanztests beteiligen, eine Schnittstelle zu anderen Teilen seines Unternehmens bilden, etc.

Um das Verständnis zu klären: der On Site Customer ist nicht notwendigerweise eine immer gleiche Person, es kann auch sein, dass es mehrere gibt die sich in dieser Rolle abwechseln oder gemeinsam erscheinen. Es kann sogar sein, dass das Umsetzungsteam komplett zu den Kunden/Nutzern zieht und dort eingebettet arbeitet. Im Grunde sind die Konstellationen nicht begrenzt, alles was möglich ist kann ausprobiert werden. Nur von einer Idee ist abzuraten - davon, dass nicht die eigentlichen Benutzer des Produkts zu On Site Customern werden sondern deren Vorgesetzte. Das schafft erfahrungsgemäss direkt wieder neue Kommunikationsprobleme.

Ein Sonderfall tritt ein wenn das mit der Umsetzung betraute Team ein verteiltes Team ist, also eines das nicht an einem Ort sitzt sondern geografisch verstreut angesiedelt ist. Da solche Teams in der Regel über Videokonferenzen und Screensharing kommunizieren kann man einen On Site Customer auch auf diese Weise einbinden. Dass damit Effektivitäts- und Effizienzverluste verbunden sind ist zwar richtig, allerdings sind diese dann durch Teamstruktur verursacht und nicht durch die Kunden-Kooperation.

Donnerstag, 10. Mai 2018

Minimum Work in Progress

FS
Bild: Flickr / Vic - CC BY 2.0
Jeder der sich etwas mit den Themen Kanban oder Lean beschäftigt hat dürfte vom Konzept des Limited WIP (Limited Work in Progress) bereits gehört haben. Es ist von entscheidender Bedeutung wenn es darum geht Durchlaufzeiten zu erhöhen und Störungen des Arbeitsflusses zu vermeiden. WIP-Limits gelten als eines der zentralen Erkennungsmerkmale von Kanban-Systemen, und doch wird praktisch immer nur eine ihrer möglichen Dimensionen betrachtet, die andere wird weitgehend ignoriert.

Die überall bekannte Dimension, die oft auch mit dem generellen Begriff des Limited WIP gleichgesetzt wird ist die des Maximum Work in Progress. Diese Obergrenze und ihren Sinn näher zu betrachten wäre ein Thema für sich, verkürzt gesagt verhindert sie Multitasking und trägt dazu bei, dass Arbeit nicht unkontrolliert einfliessen und sich irgendwo im System stauen kann. Auch für sich alleine erbringt sie einen Mehrwert, kann aber nur einem Teil der möglichen Fehlentwicklungen auffangen.

Was durch eine WIP-Obergrenze nur eingeschränkt reguliert werden kann ist die Gefahr, dass irgendwo im System Leerlauf entsteht. Die tritt unter anderem dann auf, wenn zeitweise alle verfügbaren Kräfte auf eine einzige Stelle des Wertstroms konzentriert werden, etwa auf das Releasen. Wenn infolgedessen die Arbeit in einem früheren Abschnitt (etwa der Software-Entwicklung) vorübergehend eingestellt wird, kann es sein, dass ein mittlerer Teil (z.B. die Qualitätssicherung) plötzlich nichts mehr hat was er verarbeiten kann. Bis von weiter vorne neue Zwischenergebnisse kommen herrscht dann an dieser Stelle Stillstand.

Ein Mittel um einen solchen kostspieligen Leerlauf zu verhindern (auch im Stillstand müssen Gehälter bezahlt werden), ist die Einrichtung weiterer WIP Limits, nur in diesem Fall an der Untergrenze. Ein solches Minimum Work in Progress sorgt dafür, dass bei ihrem Erreichen sofort neue Arbeit nachgezogen werden muss, selbst wenn das auf den ersten Blick nicht dringend erscheint. Die nachfolgende Station ist dadurch ebenfalls immer in der Lage Arbeit nachzuziehen sobald sie freie Kapazitäten hat.

An dieser Stelle muss auch klar sein, dass ein Minimum WIP nicht nur Probleme lösen sondern sie im schlimmsten Fall sogar erzeugen kann. Wenn es dazu führt, dass einer oder mehrere Abschnitte eines Produktionsprozesses zu 100 Prozent ausgelastet sind, sind mitunter verstopfte Warteschlangen die Folge. Optimalerweise sorgt es daher nicht nur dafür, dass jederzeit Arbeit nachgezogen werden kann, sondern es lässt auch Spielraum für neue, ungeplante Arbeit. Minimum WIP und Maximum WIP sollten nicht gleich groß sein, sondern immer einen Korridor dazwischen freilassen.

Montag, 7. Mai 2018

Eine Hilfe für die (De)Zentralisierung von Entscheidungen

FS
Bild: Pxhere - CC0 1.0
Da das Thema der Skalierung von agilen Vorhaben bei fast allen meinen Kunden eine Rolle gespielt hat, komme ich nicht daran vorbei, mich mit den verschiedenen gängigen Skalierungsframeworks zu beschäftigen, unter anderem mit SAFe. In diesem Zusammenhang bin ich an dessen Dezentralisierungs-Prinzip hängengeblieben, bzw. an einem dort empfohlenen Tool. Mit seiner Hilfe kann geklärt werden ob eine Entscheidung zentral oder dezentral getroffen werden sollte.

Nun kann man in Bezug auf SAFe geteilter Meinung sein, das Tool ist aber tatsächlich hilfreich, vor allem in Organisationen in denen Agilität noch nicht sehr tief verwurzelt ist. Ins Deutsche übersetzt (und leicht angepasst) sieht es so aus:
Die drei Entscheidungskategorien sind schnell erklärt: häufige Entscheidungen würden zentrale Instanzen überlasten, was zu langen Wartezeiten führen würde. Zeitkritische, also dringende Entscheidungen würden in der zentralen Instanz weniger dringende, aber in der langfristigen Betrachtung wichtigere Themen verdrängen. Kontextabhängige Entscheidungen würden einen zeitaufwändigen Wissenstransfer zur zentralen Instanz erfordern oder müssten uninformiert getroffen werden. Um diese negativen Auswirkungen zu vermeiden bleibt nur eine Delegation nach unten, in die Teams.

Wie genau die drei Faktoren ermittelt werden können kann von Fall zu Fall unterschiedlich sein, ein denkbarer Weg wäre z.B., dass alle Beteiligten sich zusammenfinden und durch das Hochhalten von Fingern oder Planning Poker Karten ihre Einschätzung abgeben. Das hätte den zusätzlichen Vorteil, dass verschiedene Sichtweisen eingebracht werden können. In anderen Fällen ist das Ergebnis vielleicht so offensichtlich, dass es keiner grossen Diskussion mehr bedarf.

Zuletzt empfiehlt es sich, das Tool in gewissen Abständen immer wieder einzusetzen, da die Faktoren sich mit der Zeit ändern können. Beispielsweise kann es sein, dass der Austausch mit einem Kunden zuerst auf Geschäftsführer-Ebene stattfindet, sich aber mit der Zeit zu einem intensiven Austausch zwischen Produktentwicklung und Endanwender entwickelt. In einem solchen Fall wäre eine nachträgliche Dezentralisierung sinnvoll.

Siehe auch: Subsidiarität.

Donnerstag, 3. Mai 2018

Brainstorm Hole

FS
Es ist nicht so, dass Brain Stormings per se schlecht wären. Man muss sich aber bewusst machen: der Grundsatz, dass jeder alles sagen darf ohne kritisiert zu werden kann dazu führen, dass auch viel Unsinn dabei ist. Dass sollte von Beginn an jedem klar sein. Ohne gute Moderation entstehen dann Situationen wie die hier.

Montag, 30. April 2018

Kommentierte Links (XXXVI)

FS
  • 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.

  • FAZ: 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

FS
Bild: Wikimedia Commons / Santeri Viimäki - CC BY 4.0
Kurze Frage: welcher Begriff wird im Scrum Guide ganze 26 mal (!) erwähnt, 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

FS
Bild: Pexels / Burst - CC0 1.0
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

FS
Bild: Pixabay / jrperes - CC0 1.0
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

FS
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

FS
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

FS
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

FS
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

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

Donnerstag, 29. März 2018

Kommentierte Links (XXXV)

FS
  • Peter Lee: My Ideal Agile Delivery Report

    Die Frage nach regelmässigen Status Reports ist fast unabwendbar wenn agile Teams in einer nicht- oder teil-agilen Unternehmensumwelt arbeiten. Wenn das zur Folge hat, dass das Team beginnt die "traditionellen" Reportingpflichten zu erfüllen, führt das häufig zurück in die alten Management-Verhaltensweisen von Detailkontrolle und Micromanagement. Dahinter steckt keineswegs immer eine böse Absicht - häufig ist es der Wunsch der jeweiligen Manager "Dinge anschieben zu können". Wenn aber die "klassischen" Metriken die einzige verfügbare Einsicht sind, dann erfolgt die "Optimierung" eben darüber. Die von Peter Lee zusammengetragenen agil-relevanten Metriken können in solchen Konstellationen einen anderen Blickwinkel bieten und den Management-Tatendrang in konstruktivere Richtungen lenken.


  • Harvard Business Review: HR Goes Agile

    Beim Thema Agile HR würde ich differenzieren. Es gibt auf der einen Seite die Prinzipien und Verhaltensweisen die eine HR-Abteilung braucht um selbst agil zu arbeiten. Dazu hatte ich bereits etwas geschrieben. Und es gibt auf der anderen Seite Massnahmen die HR-Abteilungen ergreifen können um Agilität im restlichen Unternehmen zu befördern. Darum geht es im hier verlinkten Artikel. An den Beispielen Leistungsbeurteilung, Coaching, Teamfokussierung, Gehaltsanpassung, Personalgewinnung und Weiterbildung gehen Peter Capelli und Anna Tavis Herausforderungen und Möglichkeiten durch und schliessen mit einem bemerkenswerten Fazit: nachdem HR-Abteilungen jahrzehntelang darauf fokussiert waren andere zu ändern sind es jetzt sie selbst die sich ändern müssen, wenn sie dazu noch in der Lage sein wollen.

  • Agile Verwaltung: Agiles Projektmanagement in der Öffentlichen Verwaltung - Wie muss Scrum angepasst werden?

    Sollte jemand ein Beispiel für Cargo Cult suchen - hier ist es. Hier wird Scrum so verbogen, dass es nicht mehr richtig funktionieren kann. Und das nicht etwa weil hier an Länge und Frequenz der Meetings herumgedoktort wird, sondern weil bewusst darauf verzichtet wird, die durch die Methode offensichtlich werdenden Root Causes ineffektiven Arbeitens anzugehen und zu beheben. Strukturelle Überplanung der eigenen Mitarbeiter, permanentes Multitasking und fehlende Meetingdisziplin sind keineswegs gottgegebene Schicksale denen man nicht entkommen kann, als solche werden sie hier aber behandelt. Gerade als jemand der seine Berufslaufbahn in einer Behörde begonnen hat weiss ich, dass hier Verbesserungen möglich sind. Wer darauf verzichtet und stattdessen Symptome behandelt hebelt das Inspect & Adapt aus, so dass aus Scrum Cargo Cult wird.

  • FAZ: Warum aus Einzelkämpfern selten gute Manager werden

    Spoiler: weil sie nicht teamfähig sind. Die hier erläuterte wissenschaftliche Studie ist angeblich die erste, die das Peter-Prinzip (Menschen werden so lange befördert bis sie eine Position erreichen die sie überfordert) validiert. Der interessante Aspekt ist, dass zu Beginn der Karriere besonders die erfolgreichen Einzelkämpfer befördert werden, weil sich deren Leistungssteigerungen am einfachsten messen lassen. Da in Führungspositionen aber Teamfähigkeit gefordert ist gelangen so häufig die falschen Menschen in diese Jobs.

Montag, 26. März 2018

Mother Tongue

FS
Bild: Flickr / Nicolas Raymond (1, 2, 3) - CC BY 2.0
Dass verschiedene Personen sich mit dem Erlernen agiler Frameworks unterschiedlich schwer tun dürfte keine besondere Überraschung sein. Wer Jahrzehnte in einem stark hierarchischen Umfeld verbracht hat, wird sich mit Selbstorganisation schwerer tun als jemand der es von Anfang an gewohnt ist. Wer beruflich in einer offenen Feedbackkultur sozialisiert wurde wird Verbesserungspotentiale offener ansprechen als einer der im Job nur Konfliktvermeidungskulturen kennt. Etc. All das ist erwartbar und nachvollziehbar. Auf den ersten Blick überraschend ist aber ein weiterer Faktor: die Muttersprache.

Über die Jahre habe ich mit Menschen aus verschiedenen englischsprachigen Ländern zusammenarbeiten dürfen - aus England, Irland, den USA, Kanada und Neuseeland. Auch hier gab es Ausreisser nach oben und unten, im Großen und Ganzen taten sich diese Damen und Herren aber deutlich leichter mit dem Verständnis von Kanban, Scrum & Co als die aus anderen Herkunftsländern. Während bei den deutschen Kollegen häufig recht abenteuerliche Missverständnisse über den Sinn und Zweck von Meetings und Rollen bestanden, war das bei den englischen Muttersprachlern deutlich seltener der Fall.

Der banale Hintergrund: viele Begrifflichkeiten der agilen Frameworks sind normale Begriffe der englischen Berufs- und Alltagssprache und ergeben für den der sie kennt ganz intuitiv den richtigen Sinn. Replenishment und Refinement, Product Owner und Retrospektive, Servant Leader und Backlog sind gute Beispiele dafür. Für jeden der Englisch nur als Fremdsprache spricht sind diese Begriffe dagegen unklar oder vielleicht sogar unbekannt. Bedingt dadurch können sie versehentlich oder absichtlich mit neuen (z.T. falschen) Bedeutungen aufgeladen werden, selbst wenn diese dem eigentlichen Wortsinn widersprechen.

Was häufig gefordert wird um derartige Fehldeutungen zu vermeiden ist eine Übersetzung ins Deutsche, was im Anwendungsfall aber schwierig ist. Zum einen würde vieles künstlich klingen (der Produkt-Eigner, die Arbeitsspeicher-Verbesserung), zum anderen bestünde die Gefahr, dass die Begriffe in den unterschiedlichen Sprachen beginnen sich auseinanderzuentwickeln (wie im Fall des im Lean/Kanban-Umfeld häufig verwandten Wortes "Verschwendung", das im Deutschen einen anderen Bedeutungsinhalt hat als das japanische Ursprungswort "Muda").

Eine bessere Lösung kann sein, im Rahmen des Coaching und Reflektionsprozesse immer wieder darauf hinzuweisen was hinter diesen Worten steht, eine andere wären gut sichtbar angebrachte Erläuterungen zentraler Begriffe in den Teamräumen (z.B. Replenishment 🡒 Aufnehmen neuer Anforderungen). Fehldeutungen lassen sich dadurch zwar nicht verhindern, dafür aber erkennen und korrigieren.

Donnerstag, 22. März 2018

Die Klagemauer

FS
Bild: Flickr / Israeltourism - CC BY-SA 2.0
Gerade in grossen Organisationen oder im Rahmen agiler Transitionen können häufig Situationen auftreten die für Teams frustrierend sind. Schwierig ist das vor allem dann wenn die Ursachen dieser Frustration in einem Bereich liegen, der vom Team selbst nicht beeinflusst werden kann. Selbst wenn der Scrum Master und das Management an Verbesserungen arbeiten kann es in Konzernen mitunter Monate dauern bis spürbare Verbesserungen eintreten. In solchen Zeiträumen besteht die Gefahr, dass die Retrospektiven so stark von diesen Situationen überlagert werden, dass sie zu reinen "Jammer-Meetings" werden. Ein kontinuierlicher Verbesserungsprozess ist dann nur schwierig am Leben zu halten.

Die naheliegende Lösung ist es, derartige Themen wegzumoderieren und den Focus der Meetings auf Themen zu legen in denen das Team bereits die Ressourcen und Kompetenzen hat um selbst für Verbesserungen zu sorgen. Das Risiko bei diesem Vorgehen ist, dass bei den Teammitgliedern der Eindruck entstehen kann, dass für sie wichtige Themen nicht zugelassen würden. Letztendlich eine Zwickmühle: entweder die Retrospektive wird von fruchtlosem Jammern geprägt oder das Team ist unglücklich weil ihm ein Ventil zum Ablassen der aufgestauten Frustration fehlt.

Ein Lösungsansatz den ich in einem meiner Teams umgesetzt habe war eine so genannte Klagemauer. Zu Beginn der Retrospektive versammelte sich das Team vor einer der Wände des Meetingraums, über der auch ein Banner mit eben diesem Namen hing. Ähnlich wie im Fall der echten Klagemauer konnte hier den eigenen Gefühlen freier Lauf gelassen werden. Aus Praktikabilitätsgründen wurde zu diesem Zweck allerdings nicht wie in Jerusalem üblich die eigene Kleidung zerrissen, stattdessen wurden die (im Moment noch) nicht zu verändernden Ärgernisse bekanntgegeben und auf Zetteln an die Wand gehangen. Nachdem jeder auf diese Weise Druck ablassen konnte ging es weiter mit dem eigentlichen Meeting.

Was bei einem solchen Ansatz zu beachten ist: er sollte nicht zu einem Dauerzustand werden. Wenn sich über einen längeren Zeitraum nichts ändert wird die immer weiter anwachsende Menge an "Klage-Zetteln" irgendwann eine deprimierende Wirkung ausüben. Wenn es hingegen irgendwann gelingt größere Impediments zu beseitigen kann das gemeinsame Abnehmen der über die Zeit gesammelten Post Its zu einem Gemeinschaftsereignis werden bei dem das Team symbolisch von einer Last befreit wird. Es kann sprichwörtlich zusehen wie die gesammelten Impediments verschwinden. Für die Moral im Team und den Glauben daran, dass Verbesserungen möglich sind ein nicht zu unterschätzender Faktor.

Montag, 19. März 2018

Marxismus und Leninismus

FS
Bild: Flickr / Kent Wang - CC BY-SA 2.0
Da agilen Vorgehensweisen nachgesagt wird, sie würden die Arbeitswelt revolutionieren - was läge näher als Revolutionstheorien auf sie anzuwenden? Und mit wem wenn nicht mit anderen Scrum Mastern und Agile Coaches sollte man das diskutieren? Folgerichtig fand vor Kurzem ein Gespräch mit zweien von ihnen statt, das Gesprächsthema waren Marxismus und Leninismus. Das Ganze natürlich nicht dahingehend, dass Agilität gleich Kommunismus wäre, sondern darauf abzielend, die Gesetzmässigkeiten revolutionärer Bewegungen (unabhängig von der dahinterstehenden Ideologie) auf agile Transitionen anzuwenden.

Zunächst zum Marxismus. Marx ging davon aus, dass die Revolution aufgrund von Sachzwängen unvermeidbar sein würde. Sein berühmter Satz aus dem Werk "Kritik der Politischen Ökonomie" wird häufig zitiert: "Es ist nicht das Bewußtsein der Menschen, das ihr Sein, sondern umgekehrt ihr gesellschaftliches Sein, das ihr Bewußtsein bestimmt." Er bedeutet, dass eine Umwälzung unabwendbar stattfinden muss, sobald die wirtschaftlichen Rahmenbedingungen eine bestimmte Entwicklungsstufe erreicht haben. An dieser Stelle gibt es Parallelen zu den agilen Vordenkern: diese gehen davon aus, dass volatile und sich rapide ändernde Märkte und Technologien gar keine andere Lösung zulassen als eben die Agilität.

Das Problem an dieser Stelle: bis die Veränderung stattfindet kann es dauern. Vielleicht ist die notwendige Ausgangslage noch nicht zur Gänze erreicht, vielleicht ist das Beharrungsvermögen der bisherigen Ordnung (noch) zu groß, vielleicht findet eine Gegenbewegung statt. Was immer es auch im Einzelfall ist, das Ergebnis ist, dass der Umschwung nicht richtig vorankommt, im schlimmsten Fall sogar stagniert. Sowohl in Revolutionen als auch in agilen Transitionen ein bekannten Phänomen. Marx' Lösung: abwarten. Die Revolution lässt sich nicht aufhalten, sie kommt ggf. nur etwas später.

Nun hat nicht jeder diese Geduld, wie in praktisch jedem anderen Bereich gab und gibt es auch hier Menschen die gerne alles beschleunigen würden. Unter ihnen ist vor allem Lenin zu nennen, der sich in seinem Werk "Was tun?" zuerst über die geringen Erfolge der Vergangenheit beklagte um dann das Konzept der "revolutionären Avantgarde" zu entwickeln, einer Gruppe die in ihrer geistigen Entwicklung schon weiter ist als der Rest der Bevölkerung und diese durch Organisation und Agitation dazu bringt weiter zu gehen als sie es von sich aus tun würde. Aus diesem Blickwinkel betrachtet kann man in vielen agilen Transitionsprogrammen "Leninisten" finden, und zwar sowohl im Management als auch unter den Agile Coaches.

Ohne historische Parallelen zu sehr strapazieren zu wollen - der Ansatz der revolutionären Avantgarde war kein Erfolg. Gefangen in der Idee, dass Unverständnis und Widerspruch nur Symptome geistiger Rückständigkeit sein können begannen die selbst ernannten Vorreiter der Revolution die anderen Menschen zu bevormunden und zu entmündigen, was dazu führte, dass diese sich abwandten und in die innere oder äussere Emigration gingen. Die angestrebte neue Welt bestand nur als Fassade und kollabierte schließlich.

Ein ähnliches Schicksal haben viele agile Transitionen vor oder hinter sich. Sobald das Gefühl um sich greift für dumm gehalten und bevormundet zu werden wird die Veränderung (egal wie gut sie gemeint ist) zu einem nur noch durch Befehl und Gehorsam am Leben gehaltenen Fremdkörper, der bei der nächsten Gelegenheit abgestossen wird. Bis dahin greifen Konzern-Anarchismus und brauchbare Illegalität um sich. Aus diesem Grund sollte "Leninismus" sobald er erkannt wird angesprochen und mitsamt des dahinterliegenden Menschenbildes aufgearbeitet werden. Geschieht das nicht besteht das hohe Risiko, dass das ganze Transitionsvorhaben scheitert.

Donnerstag, 15. März 2018

Kreislauf, Thromben und Embolien

FS
Bild: Pixabay / Quimono - CC0 1.0
Ein schönes Beispiel für Systeme in denen sich alles im permanenten Fluss befindet ist der menschliche Körper, bzw. dessen Blutkreislauf. Ähnlich wie in einem idealen Produktionssystem befindet er sich in einem Zustand der permanenten Bewegung und sorgt dafür, dass sich bestimmte Stoffe in einem immerwährenden Strom von einem Teilsystem zum anderen bewegen. Umgekehrt betrachtet kann man auch den Arbeitsfluss eines Unternehmens als dessen Blutkreislauf betrachten, der es versorgt und am Leben hält.

Um die Parallelen weiterzutreiben: sowohl für den Körper als auch für ein Unternehmen ist es von existentieller Bedeutung, dass der Fluss nicht ins Stocken gerät. Sobald das der Fall ist besteht die Gefahr, dass sich Verklumpungen bilden, im Körper in Form von geronnenem Blut (Thrombose), im Unternehmen in Form von Bürokratie. Beides sogt dort wo es sich bildet dafür, dass Verengungen und Flaschenhälse entstehen, vor denen der Fluss sich aufstaut.

Allein das wäre bereits bedenklich, die wirkliche Gefahr steht aber erst noch bevor. Dann nämlich wenn sich aus den Engstellen Thrombosen lösen und sich im Blutstrom auf die Wanderung durch das System begeben. Im Kontext der Organisation: wenn ein Bürokrat in einen anderen Bereich versetzt wird, z.B. weil er im Rahmen der Versetzung eines Vorgesetzten "mitgetrieben wird". Sobald das passiert besteht das unmittelbare Risiko von Embolien.

Eine Verklumpung die in einem größeren Durchlass noch unbedenklich ist kann nämlich einen kleineren vollständig verschliessen. Die Folge: die dahinter liegenden Teilsysteme werden vom Versorgungskreislauf abgeschlossen und sterben ab. Im Fall des Körpers durch Infarkte, in Organisationen durch ausbleibende Aufträge oder Vorprodukte, wodurch das Produktionsvermögen der betroffenen Abteilung verkümmert, bis hin zur dauerhaften Dysfunktion.

Um derartige schwere Schäden zu vermeiden sollte es sowohl im Körper als auch in Unternehmen oberste Priorität sein den Fluss an keiner Stelle ins Stocken geraten zu lassen, selbst dort nicht wo eine kleine Verklumpung auf den ersten Blick unproblematisch erscheint. Denn wenn eine Thrombose sich erst auf dem Weg durch das System befindet sollte man sich auf unkalkulierbare Auswirkungen gefasst machen. Für Gegenmassnahmen ist es dann meistens zu spät.

Montag, 12. März 2018

Agile Product Ownership kurz zusammengefasst

FS
Hätte ich das früher gewusst. Jahrelang habe ich auf die Frage ob es das Video Agile Product Ownership in a Nutshell auf deutsch gibt mit leider nein geantwortet. Dabei gibt es die Übersetzung schon seit 2013. Und jetzt auch hier.

Donnerstag, 8. März 2018

Die richtigen Helden belohnen

FS
Bild: Flickr/W_Minshull - CC BY 2.0
Eines der Teams bei einem meiner Kunden hatte den Ruf, dass es am Rand des Scheiterns stehende Projekte auf den letzten Metern "herumreissen" konnte. Wenn die Deadline bedrohlich nah gerückt war und den Managern bereits der Schweiss auf der Stirn stand beschlossen die Teammitglieder, dass es mal wieder an der Zeit wäre "ein paar Nächte durchzumachen". Das Team schloss sich irgendwo ein, arbeitete praktisch rund um die Uhr und schaffte es tatsächlich auch jedesmal irgendetwas abzuliefern was dem ursprünglich geplanten Ergebnis zumindest nahe kam. Regelmässig bekam es dafür vom Management öffentliches Lob und gewisse Privilegien, sei es in Form flexiblerer Arbeitszeiten oder durch größere Freiheiten bei Coding Standards und Methodentreue.

"Von solchen Leuten brauchen wir mehr", meinte das Management, und Teil meines ursprünglichen Auftrages war es, einen derartigen Geist auch in anderen Teams zu fördern. Die Überraschung war groß als ich nach kurzer Zeit einen genau gegenteiligen Ratschlag gab - diesem Team sollten seine Privilegien genommen werden, Hauruck-Aktionen sollten nach Möglichkeit vermieden werden und vor allem sollte nach dem "Herumreissen" öffentliches Lob nur noch sehr sparsam verteilt werden.

Der Hintergrund war, dass die so heldenhaft bewältigten Krisensituationen grösstenteils selbst verursacht waren, und zwar zum einen eben durch die Befreiung von Coding Standards (Qualitätssicherung) und Methodentreue (Verbesserungsprozessen), zum anderen aber auch durch Schlampigkeit und Prokrastination. Im Bewusstsein gegen Ende finale Rettungsaktionen durchführen zu können war die Arbeitsmoral in den Vorwochen auf niedrigem Niveau, "flexible Arbeitszeiten" bedeutete in dieser Zeit spät zu erscheinen, lange Pausen zu machen und früh zu gehen.

Besonders verheerend wirkte in diesem Zusammenhang, dass andere Teams zwar deutlich professioneller arbeiteten, dafür aber kein Wort der Anerkennung bekamen. Im Gegenteil, wer realistisch plante, kontinuierlich lieferte und sicherheitshalber ein kleines Zeitpolster am Ende vorsah musste sich öffentlich fragen lassen warum er nicht sein konnte wie der Haufen Helden Chaoten, dessen hektische nächtliche Rettungsaktionen Büro und Code in einem Zustand wilder Unordnung hinterliessen. Entsprechend schlecht war es in den professionell arbeitenden Teams um die Motivation bestellt.

In den folgenden Team- und Review-Meetings wurden Belohnungen anders verteilt als bisher. Die kontinuierlich liefernden Teams wurden gelobt und erhielten mehr Zeit für Innovation und Verbesserung, dem Hauruck-Team wurde zwar gedankt, es wurde aber auch gebeten auf mehr Struktur zu achten und regelmässige Lessons Learned-Sessions abzuhalten um die eigenen Prozesse so zu verbessern, dass nicht erst gegen Ende alles fertig wurde. Zudem erhielt es eher unkritische, dafür aber auch weniger spannende Aufgaben, bei denen es nicht auf die Fertigstellung zu bestimmten Zeitpunkten ankam.

Die Folgen dieses geänderten Vorgehens waren deutliche Verbesserungen in verschiedenen Bereichen: die Moral in den Teams (mit der einen Ausnahme) ging hoch, die Lieferung neuer Features erfolgte gleichmässiger und weniger schubweise, der für Bugfixing und Refactoring notwendige Zeitaufwand ging zurück. Und nicht zuletzt entstand im Management eine klare Vorstellung davon welches Verhalten man besser fördern sollte und welches besser nicht.

Konstellationen wie diese finden sich in vielen großen Organisationen, und es lohnt sich sie anzusprechen sobald sie entdeckt werden. Die richtigen Helden zu finden, zu loben und zu belohnen kann eines der wirkungsvollsten Management-Werkzeuge sein um positive Veränderungen herbeizuführen. Man sollte es nutzen.

Montag, 5. März 2018

Ein Bild sagt mehr als 1000 Worte (XXI)

FS

Mittwoch, 28. Februar 2018

Kommentierte Links (XXXIV)

FS
  • C. Kyle Jacobsen: The Why and How of Creating a Product Wall

    In dieser Woche habe ich mit zwei Teams ihr erstes Kanban-Board aufgebaut und wie so oft sind sie zu Beginn solide, praktikabel und noch recht unspektakulär. Welche Ausmasse so etwas irgendwann annehmen kann zeigt dieses Beispiel von einer Firma namens teem, die freundlicherweise die Bilder samt erklärendem Artikel veröffentlicht hat. Schön ist vor allem der holistische Ansatz: von der globalen Vision bis hin zum finalen Release wird der gesamte Wertstrom abgebildet, zusätzlich dazu haben sich erweiterte Boards auf die danebenliegenden Wände des Raumes ausgebreitet. Im Grunde ein zusammenhängendes Kanban-Ökosystem, das von der ganzen Firma gepflegt wird.

  • Dylan Walsh: Look Beyond “Culture Fit” When Hiring

  • "Hire for attitude, train for talent" ist ein beliebtes Sprichwort in agil arbeitenden Firmen. Was genau diese "Attitude" ist wird allerdings seltener besprochen. Häufig wird davon ausgegangen, dass die neuen Mitarbeiter möglichst gut zur Firmenkultur passen sollten, was aber zu einem Problem werden kann: da auch die sich in einem agilen Unternehmen entwickelt und ändert kann eine kulturelle Übereinstimmung sich schnell wieder verlieren. Wichtiger ist daher die Fähigkeit sich zu entwickeln, anzupassen und kulturelle Muster zu übernehmen. Diese an sich naheliegende Annahme wird hier nochmal durch Empirie untermauert. Es lebe die Wissenschaft!

  • Lisa Crispin: Retrospectives for large teams with many sub-teams

    Eine der am häufigsten gestellten Fragen in skalierten agilen Projekten ist die nach teamübergreifenden Retrospektiven. Auf der einen Seite sind sie notwendig, um auch im Ganzen eine selbstlernende Organisation zu sein, auf der anderen Seite sind sie schwierig, da sie schnell in Unübersichtlichkeit und Anonymität enden. Ein hundertprozentig zufriedenstellender Weg derartige Veranstaltungen durchzuführen wurde noch nicht gefunden, es gibt aber immer wieder vielversprechende Experimente. Das hier vorgestellte hat mit einem geografisch verteilten, in funktionale Silos geteilten Team nochmal besonders anspruchsvolle Ausgangsbedingungen und ist gerade deshalb eine interessante Fallstudie.

  • Leon Tranter: Agile Metrics - the Ultimate Guide

    Die Erhebung sinnvoller Metriken gehört zu den Königsdisziplinen agiler Teams. Trotz mittlerweile jahrzehntelanger Erfahrung wird immer wieder diskutiert wer was mit welchem Ziel messen sollte. Dieser Artikel gibt zentrale Antworten: Metriken sollten von und für die Teams sein, sie machen nur mit Kontextinformationen Sinn und sollten immer Teil einer empirisch validierbaren Aufgabe oder Fragestellung sein. Mit anderen Worten - sie können sich in Art, Bedeutung und Verwendung von Team zu Team stark unterscheiden. Im Einzelnen werden viele verschiedene Metriken ausführlich besprochen und von verschiedenen Blickwinkeln aus erörtert. Eine gute Übersicht mit einem guten Schlusswort: "Not everything that can be counted counts, and not everything that counts can be counted."

  • Sofia Quintero: The Product Manager’s Guide to Change Management

    Ein langer und guter Artikel zum Thema Change Management. Zwar nichts grundlegend Neues, aber sehr gut aufbereitet und mit sehr anschaulichen Bilder und Metaphern erklärt. Besonders gut gefallen hat mir das Bild vom Elefantenreiter, das anhand von Reiter, Reittier und Reitweg die Notwendigkeiten von rationalem, emotionalem und systemischem Handeln aufzeigt. Und natürlich darf auch das Kübler-Ross-Modell nicht fehlen, so viel Klischee muss sein.

Montag, 26. Februar 2018

Scaled Agile: Chief Product Owner (II)

FS
Bild: Wikimedia Commons / Fredrick W. Glasier - Public Domain
Spätestens mit dem Scrum@Scale-Guide ist die Frage noch einmal aktuell geworden wie die Rolle eines Chief Product Owner (oder Lead PO, Head PO, etc.) definiert ist. Die Diskussion ist in sofern von Bedeutung, da der Chief PO eines der klassischen Einfalltore ist, über das vom mittleren Management versucht werden kann die Autonomie und Selbstorganisation der Scrum Teams auszuhebeln1. Es lohnt sich also ein Blick auf die verschiedenen Ausgestaltungen.

Der Scrum-puristische Chief PO

Gleichzeitig die authentischste und die mit klassischem Managementverständnis am wenigsten kompatible Ausgestaltung. Auf der strategischen Ebene für die Produktvision und Unternehmensmission zuständig gibt ein Scrum-puristischer Chief PO den eigentlichen Product Ownern lediglich ein abstraktes Leitbild vor, das sie nach eigenem Ermessen in Produkte umwandeln können. Er füllt damit eine der Lücken aus die Scrum bewusst freigelassen hat um individuelle Lösungen zu ermöglichen. Um die Product Ownerships der Teams nicht zu untergraben ist in Richtung der POs nur Reflektion und Feedback möglich, keine Anweisung. Das erfordert von allen Beteiligten einen hohen Reifegrad und hohe Professionalität.

Der LeSS-Product Owner

Im Grunde kein Chief Product Owner im eigentlichen Sinn, da es keine weiteren Product Owner ausser ihm gibt. Im LeSS-Skalierungsframework kann eine Person Product Owner mehrerer Teams sein, die diese Mehrfachbelastung dadurch ausgleichen, dass sie ihn unterstützen. Dabei können in den Teams PO-ähnliche Rollen entstehen, allerdings ohne die damit verbundenen Kompetenzen. Diese Konstellation lässt sich auch aus dem Scrum Guide ableiten, der einerseits klarstellt, dass der PO die einzige für das Backlog-Management zuständige Person ist, andererseits aber zulässt, dass mehrere Teams ein gemeinsames Backlog haben.

Der Risikokapital-Investor

Ein Typ der eher in ein Startup-Umfeld passt. Die eigentlichen POs sind zwar frei in der Entscheidung was sie in ihren Backlogs haben und wie diese priorisiert werden, sie müssen mit ihren Produktideen allerdings in einen Pitch bei ihrem Chief-PO gehen, der dann entscheidet ob er diese Ideen finanziert oder nicht. Um (auch nur versehentliches) Micromanagement zu vermeiden sollten diese Finanzierungen jeweils für einen längeren Zeitraum vorgenommen werden, z.B. für zehn Sprints.

Der Scrum@Scale Chief Product Owner / Epic Owner

Die erste problematische Rollendefinition. Im Scrum@Scale-Framework wird der Chief PO so beschrieben, dass er ein übergreifendes Backlog definiert, dessen Einträge aber zu groß sind um in Sprints umgesetzt zu werden. Um das möglich zu machen werden sie von den eigentlichen POs in kleinere Arbeitspakete zerteilt. Da diese zu großen Aufgaben der gängigen Definition eines Epic entsprechen (eine Anforderung die zu groß für einen Sprint ist) ist in manchen Unternehmen auch der Begriff des Epic Owners üblich. Schwierig ist das, weil es die Scrum Teams sehr stark in ihrer Product Ownership einengen kann wenn ihnen auf höherer Ebene Vorgaben gemacht werden. Bei sehr großen Aufgaben/Epics kann das zwar irgendwie funktionieren, die Wahrscheinlichkeit von Dysfunktionalitäten ist aber sehr hoch.

Der SAFe-Product Manager / Solution Manager

Ebenfalls problematisch. Im Scaled agile Framework (SAFe) wird unterschieden zwischen dem Product Owner, zuständig für Technologie und Team und dem ihm übergreordneten Product Manager, zuständig für Markt- und Kundenkontakt. Gegebenenfalls befindet sich als weitere Ebene darüber noch der Solution Manager. Das passt zwar sehr gut mit klassischen Unternehmensstrukturen zusammen, macht aber einen der zentralen Vorteile von Scrum rückgängig, die enge Zusammenarbeit zwischen dem Kunden/Benutzer und dem Umsetzungsteam.

Der Cargo Cult Chief PO

Leider viel zu häufig anzutreffen - ein direkter Vorgesetzter der einzelnen Product Owner, der ihnen Anweisungen geben und Micromanagement durchführen kann. Führt sehr schnell zu Reporting-Overhead, Bürokratie und Ineffizienz. Wie gesagt, Cargo Cult.

---

Im Einzelfall finden sich noch zahlreiche weitere Variationen, die wichtigen Typen sind aber hier erfasst. Grundsätzlich gilt aber beim Product Owner das gleiche wie für agile (und nicht-agile) Produktentwicklung im Ganzen: Skalierung macht Strukturen zwar größer aber nicht notwendigerweise leistungsfähiger. Man sollte sich also gut überlegen ob man sie wirklich braucht.


1Die Gründe dafür sind nochmal ein Thema für sich, sie sind aber keineswegs immer so sinister wie es mitunter den Anschein hat.

Donnerstag, 22. Februar 2018

Selbstorganisation auf der grünen Wiese

FS

Eine Anekdote aus dem Leben eines Agile Coaches: in einem Unternehmen welches sich inmitten einer Transition befand waren die Parkplätze knapp. Um diesem Missstand abzuhelfen wurde der Bau eines Parkhauses beschlossen, und zwar genau auf der Stelle an der sich bis zu diesem Zeitpunkt der Parkplatz befunden hatte. Die unschöne Nebenwirkung - für die Dauer der Bauzeit wurden die Parkplätze nochmal knapper. Bis zum nächsten Parkplatz war es ein längerer Weg durch Matsch und Kälte. Und an dieser Stelle begann das Wunder der Selbstorganisation.

Als erstes entschied sich ein Mitarbeiter, auf dem Rand der Wiese neben der Strasse zu parken. Zunächst stiess es damit auf große Skepsis, schließlich befinden sich an der Strasse Halteverbotsschilder. Seine Argumentation war aber die: da die Wiese kein Teil der Strasse ist sondern Privatgrund gilt die Strassenverkehrsordnung dort nicht, Parken ist also erlaubt. Und da niemand auf dieser Wiese je einen Strafzettel bekommen hatte schien er recht zu haben. Bald war der Streifen entlang der Strasse zugeparkt.

Zu Beginn war das zwar eine kleine Verbesserung, es gab allerdings noch immer zu wenige Parkplätze. Irgendwann kam ein anderer Mitarbeiter auf eine weitere Idee: bis dahin hatten alle Autos längs zur Strasse am Wiesenrand geparkt, wenn sie stattdessen quer zur Strasse parken würden gäbe es mehr als doppelt so viele Parkmöglichkeiten. Also drehte er seinen inoffiziellen Parkplatz um 90 Grad. Sobald die anderen Mitarbeiter das sahen erkannten sie den Sinn und handelten genauso. Und bald parkten alle Autos quer zur Strasse.

Die beiden Notlösungen, das Parken an der Strasse und das Drehen der Behelsparkplätze um 90 Grad, waren nie ein Teil einer offiziellen Verkündung. Es gab keine Rundmail, keine Aushänge und keine Intranetseiten. Und trotzdem fanden sie beide im Abstand von ca. einem Monat statt, alleine dadurch, dass sich die Mitarbeiter selber organisierten. Zum Teil durch Gespräche untereinander, zum Teil einfach dadurch, dass sie dem Beispiel der anderen folgten.

Immer dann wenn in dieser Zeit ein Manager behauptete, dass seine Mitarbeiter nicht zur Selbstorganisation in der Lage seien trat der Agile Coach mit ihm an das nächste Fenster, zeigte auf die Autos und erzählte was es damit auf sich hatte. Das ging so weit, dass irgendwann ein Manager lachend abwinkte und sagte: "Ja, ja, die Autos. Ich sehe es ein, unsere Mitarbeiter können sich selber organisieren, man sieht es vor dem Fenster."

In vielen Unternehmen gibt es vergleichbare Beispiele für Selbstorganisation. Wenn man sie findet können sie als mächtige Metaphern dienen, mit denen sowohl das Management als auch die Mitarbeiter selbst von dem in ihnen vorhandenen Potential überzeugt werden können. Es lohnt sich also danach zu suchen.

Montag, 19. Februar 2018

That's what they said

FS
Bild: Flickr / J. D. Falk - CC BY-SA 2.0
Von Zeit zu Zeit werde ich bei meinen Kunden nach inspirierenden Gedanken, Aussagen oder Dokumenten agiler Vordenker und Unternehmer gefragt, von denen man sich für die eigenen Zielbilder inspirieren lassen kann. Die gibt es tatsächlich, hier sind einige die ich immer wieder nenne:

Jeff Bezos - Amazon: Letter to Shareholders, 1997

Dieser Brief an die Anteilseigner von Amazon beinhaltet mehrere Gedankenstänge, von denen aber einer im Vordergrund steht: auch und gerade gegenüber den Shareholdern wird betont, dass nicht kurzfristige Gewinnausschüttungen das Ziel sind sondern langfristige Entwicklungen. Obwohl kurzfristige Flexibilität und Agilität gewünscht ist soll sie auf das langfristige Ziel einzahlen. Genau das also was agiles Produktmanagement ist - beweglich bleiben um trotz aller Hindernisse immer wieder das Fernziel ansteuern zu können. Gleichzeitig wird herausgestrichen, dass diese Reise gerade erst beginnt, dass erst "Tag eins" ist, weshalb noch keine Zeit zum Ausruhen und zum Routinen entwickeln sein kann. Auch zwei Jahrzehnte später ist das noch immer der Ansatz nachdem dieses Unternehmen geführt wird.

Larry Page, Sergey Brin - Google: Code of Conduct, 2000

Oft als esoterisch belächelt steht in diesem Dokument die vermutlich prägnanteste Beschreibung einer positiven Unternehmenskultur: "Don't be evil". Auch wenn der Text weiter unten formaler wird und an einigen Stellen sehr ins Detail geht (z.B. bei der Frage wann man seinen Hund mitbringen darf) steht doch dieser erstaunlich einfache Satz über allem, mit der Aufforderung sich nicht nur an den einzelnen Formulierungen sondern am Großen Ganzen zu orientieren. Und falls ein Mitarbeiter das Gefühl haben sollte, dass irgendwo das "Don't be evil" nicht befolgt wird, wird eine aktive Widerspruchs- und Feedbackkultur ermutigt und eingefordert.


Reed Hastings et al. - Netflix: Culture Presentation, 2009

Die Facebook-Geschäftsführerin Sheryl Sandberg hat diese schlichte Powerpoint-Präsentation einmal als das wichtigste im Silicon Valley entstandene Dokument bezeichnet. Den Inhalt ihrer 125 Seiten hier zu beschreiben würde zu weit führen, da sie auf wirklich viele Faktoren eingeht, es lohnt sich aber auf jeden Fall sie zu lesen. Man bekommt eine Idee wie weit eine auf Freiheit, Verantwortung und Vertrauen beruhende Unternehmenskultur gehen kann. In vielen Bereichen weicht sie stark von dem ab was in anderen Unternehmen auch nur für möglich gehalten wird, und doch beschreibt sie nur was bei Netflix bereits funktioniert.

Elon Musk - Tesla: Communication Within Tesla, ca. 2010

Ein sehr spezifischer aber sehr wichtiger Aspekt einer Unternehmenskultur ist die Frage wer auf welchem Kanal mit wem kommuniziert. Die Antwort von Elon Musk ist: jeder mit jedem, und das möglichst direkt. Obwohl er das explizit von klassischen prozessgetriebenen Vorgehen abgrenzt nennt er nicht alle damit verbundenen Effekte und Voraussetzungen, die werden in dem verlinkten Artikel aber zum Teil nachgeliefert. Ein wichtiger Punkt der dort nicht genannt wird: um immer ansprechbar zu sein und andere ansprechen zu können muss man dafür offene Zeitfenster einplanen, sonst ist es nicht ernst gemeint.

Mark Zuckerberg - Facebook: Founder’s Letter, 2012

Zu Beginn noch sehr ins Allgemeine gehend steht im unteren Teil dieses Briefes das, was nach allem was man hört tatsächlich die bei Facebook vorherrschende Einstellung ist. "The Hacker Way" bedeutet, dass Ideen möglichst schnell und in vielen kleinen Schritten umgesetzt werden und dass sie niemals fertig, niemals alternativlos und niemals von Anfang an klar sind. Was sich beim ersten Überfliegen noch nicht so besonders anhört enthält radikale Konsequenzen, wie z.B. die, dass auch Manager in der Lage sein müssen Code zu schreiben. In der Tat ein sehr naheliegender Weg um zu verhindern, dass die Fachabteilung die IT-Produktentwicklung nicht versteht.

---

Vermutlich würden sich noch weitere derartige Texte finden lassen, die hier nehme ich weil fast jeder die dahinterstehenden Firmen kennt. Und die Reaktion von (Change-)Managern nach dem Lesen ist ein guter Indikator dafür wieviel Veränderung in einem Unternehmen wirklich möglich ist.
Powered by Blogger.