Freitag, 29. Dezember 2017

Kommentierte Links (XXXII)

FS
Normalerweise sammele ich in den kommentierten Links die jeweils interessantesten oder amüsantesten Artikel die ich im letzten Monat gelesen habe. Von Zeit zu Zeit kommt es aber vor, dass ich einen vorübergehend vergesse oder ihn erst entdecke Monate nachdem er erschienen ist. Hier sind die besten dieser "verpassten" Texte aus dem letzten Jahr.

  • Brand Eins: Wo Strategie draufsteht, ist meist nur Planung drin

    Einer der großartigen Texte in denen (unbewusst?) von Agilität die Rede ist, ohne dass sie bei diesem Namen genannt wird. Die Quintessenz: statt zu planen (eine Abfolge von Vorgängen zu definieren und sich dann stur daran zu halten) ist das Erarbeiten einer Strategie sinnvoller - "weiter reichendes Denken auf Vorrat, bei dem man ein festes Ziel mit unterschiedlichen Mitteln flexibel ins Auge fasst", wie Wolf Lotter, der Autor dieses Artikels, es mit unvergleichlicher Wortwahl nennt. Letztendlich findet sich hier, mit Verweisen auf Sun Tzu, Peter Drucker, Moltke, Clausewitz und einige andere, der Kern dessen was Agilität von Chaos unterscheidet: ständige Anpassung an sich ändernde Umstände bei gleichzeitigem konsequenten Verfolgen eines übergeordneten Ziels.

  • Niels Pflaeging: Change ist so wie Milch in Kaffee geben

  • Ich beschreibe Change bei meinen Kunden immer wie das Salzen des Essens: wenn das Salz einmal drin ist bekommt man es nicht mehr heraus. Die Metapher mit Kaffee und Milch hat mich darum sofort angesprochen. Auch in den anderen hier geäusserten Ideeen erkenne ich Überzeugungen von mir wieder, vor allem in der, dass es für effektive Veränderung sinnvoller ist bestehende Regeln zu entfernen statt neue einzuführen. Sobald den Menschen in sich ändernden Organisationen klargeworden ist welche befreiende Wirkung ein derartiges Entfesseln hat werden sie von sich aus auf die Abschaffung weiterer Regeln drängen und so selbst für ein Aufrechterhalten des permanenten Wandels sorgen. Die Einführung immer neuer Regeln (selbst wenn sie noch so gut sind) führt dagegen früher oder später zu Verschlechterungen, zu versalzenem Essen gewissermassen.

  • Engadget: Robot chefs and en route baking could be the future of pizza delivery

    Beim hochinnovativen IT-Unternehmen aus dem Silicon Valley denken die Menschen an alles mögliche, ganz sicher aber nicht an einen Pizza-Lieferservice. Das Beispiel von Zume Pizza ist ein hochinteressantes Beispiel für viele Aspekte von Innovations- und Optimierungsmanagement: manuelle Prozesse werden automatisiert, aber nur dort wo es zielführend ist, kreative oder ästhetische Arbeiten werden weiter von Hand ausgeführt. Und besonders beeindruckend: die Trennung von Produktions- und Lieferprozessen wird aufgehoben und sogar je nach Nachfrage modifiziert - der Lieferwagen verfügt über mehrere Öfen und kann zu Zeitpunkten hoher Nachfrage als temporäres Back- und Logistikzentrum genutzt werden. Disruption in einer Branche in der sie keiner vermuten würde. (den Beitrag gibt es auch als Video

  • Jo Szczepanska: Design thinking origin story plus some of the people who made it all happen

    Zur Abwechselung ein bisschen Geschichtsunterricht. Genau wie im Fall von Lean und Agile können auch die Ursprünge von Design Thinking über mehrere Jahrzehnte zurückverfolgt werden. Dieser Beitrag ist wunderbar geeignet um ihn allen zu schicken die das Ganze als neumodischen Hype abtun wollen, denn er enthält neben Darstellungen verschiedener Denkschulen und Vordenker auch eine grafisch aufbereitete Zeitleiste und ein umfangreiches Literaturverzeichnis. Wer weiter nach unten scrollt kommt auf noch mehr Inspirationen, denn in den Kommentaren werden weitere historische Stränge und Personen genannt.

  • Karin Dames: The Biggest Waste in Agile

    Es gibt Blogs die wie Sternschnuppen sind - sie tauchen plötzlich auf, strahlen für einen kurzen Moment und verglühen wieder. Everyday Agile ist, bzw. war ein solcher Blog, er wurde leider nur von Februar bis Juni betrieben, gehörte aber in dieser kurzen Zeit sowohl optisch als auch inhaltlich zu den besseren. The Biggest Waste in Agile steht stellvertretend für die ingesamt gerade einmal zehn Beiträge die hier verfasst worden sind, die anderen sind ebenfalls lesens- und sehenswert. Und da der Titel schon sehr effektheischend ist kommt hier der vorgeschaltete Spoiler: die größte Verschwendung im agilen Kontext sind Informationen die bei der Kommunikation zwischen zu stark arbeitsteiligen Teams oder Personen verlorengehen.

  • Alexandre Magno: Don’t copy the Spotify Model. Do copy the Spotify attitude.

    Dass das so genannte "Spotify Model" nur eingeschränkt zur Nachahmung empfohlen ist wird von den Beteiligten selbst immer wieder betont. Es beruht zu sehr auf organisatorischen, technischen und kulturellen Besonderheiten dieser Firma, die in dieser Konstellation praktisch nicht reproduzierbar sind. Da immer mehr Firmen trotzdem genau das versuchen (die meisten davon lediglich auf Basis der beiden berühmten Engineering Culture-Videos) gab es dieses Jahr gleich mehrere Konferenz-Auftritte von Spotify-Mitarbeitern auf denen davor gewarnt wurde, unter anderem auf der Agile 2017, der Lean Agile Scotland und der Agile Bangkok. Dass man das unreflektierte Kopieren unterlassen und sich trotzdem von dieser Firma inspirieren lassen kann zeigt Alexandre Magno, der zurecht darauf hinweist, dass das eigentlich Besondere hier die Bereitschaft war durch ständiges Lernen einen eigenen Weg abseits der etablierten Frameworks zu entwickeln. Das kann in der Tat als Vorbild empfohlen werden.

  • Steve Denning: What Is Agile? The Four Essential Elements

    Steve Denning steht mittlerweile seit Jahren als kluger und interessierter Beobachter am Rand bzw. leicht ausserhalb der agilen Filterblase und notiert wie agile Praktiken langsam in die Welt der großen Unternehmen eindringen. Am Beispiel der Firmen des SD Learning Consortium beschreibt er einen neuen Versuch die Inhalte des agilen Manifests konzerntauglich zu machen. Die dabei entstandenen Grundsätze sind:
    • Delighting customers
      Eigentlich eine Selbstverständlichkeit: alles was ein Unternehmen unternimmt sollte darauf ausgerichtet sein, bei den Kunden Erfolg zu haben. In der Realität leider häufig nicht gegeben.
    • Descaling work
      Die Bewältigung von Volatilität und Ungewissheit durch die Dekonstruktion von großen Vorhaben in kleine Arbeitspakete, durch die schnelle Markterfolge und Lerneffekte möglich sind.
    • Enterprise-wide Agility
      Die Übertragung von schlanken und reaktionsschnellen Organisationsformen auf die ganze Firma statt der häufig zu findenden dysfunktionalen Hybridlösung aus agilen Umsetzungsteams und Command & Control-orientiertem Management.
    • Nurturing culture
      Das vermutlich Schwierigste von allem: die Veränderung der Unternehmenskultur in Richtung eines ganzheitlichen Innovations- und Unternehmer-Ansatzes auf allen Ebenen.
    Interessant ist auch die Begründung für diese Neuformulierungen: das ursprüngliche Manifest aus vier Gegensatzpaaren und zwölf Prinzipien wäre zu umfangreich um in Großunternehmen kommuniziert zu werden. Honi soit qui mal y pense.

  • John Cutler: The Way of Ways

    Mit mehreren hundert Artikeln alleine im Jahr 2017 (!) dürfte John Cutler einer der produktivsten Agile-Blogger sein, vielleicht sogar der produktivste von allen. Auf den ersten Blick ist dieser Artikel von ihm einer von mittlerweile unzähligen die die Entstehung und den Aufstieg der Agile-Bewegung nacherzählen. In dieser Hinsicht ist er nicht einmal besonders, andere, z.B. der von Caroline Mimbs in The Atlantic sind wesentlich besser geschrieben. Was ihn einzigartig macht ist die Erzählperspektive: stichwortartig notiert aus der Sicht der ersten Pioniere erkennt man den Zwiespalt aus der Begeisterung über die immer größere Verbreitung und der Verzweifelung angesichts von zunehmendem Kontrollverlust und Missbrauch. Am Ende steht die selbe Erkenntnis wie am Anfang - irgendetwas stimmt hier nicht, wir müssen an Verbesserungen arbeiten. Ein ewiger, sich selbst stimulierender Zyklus.

Montag, 25. Dezember 2017

Das Increment als Geschenk

FS

Reden wir über Geschenke. In meinem beruflichen Alltag als Scrum Master und/oder Agile Coach sind sie zwar nicht alltäglich, tauchen aber immer wieder auf, dann nämlich wenn ich im Rahmen von Workshops den Scrum-Flow mit seinen Rollen und Events auf ein Flipchart zeichne. An seinem Ende steht fast immer das Increment, also das benutzbare (Teil)Produkt. Und fast immer hat dieses Increment die Form eines Geschenks.

Dass ich meistens diese Darstellung wähle hat zum einen seinen Grund darin, dass viele Kunden, Auftraggeber und Stakeholder die regelmässige Auslieferung tatsächlich als Geschenk empfinden. Mit den Worten eines Managers eines DAX-Konzerns mit dem ich früher zusammenarbeiten durfte: "Früher haben wir zum Teil jahrelang warten müssen bevor irgendetwas zurückkam, jetzt habe ich das Gefühl als wäre alle zwei Wochen Weihnachten."

Der andere Grund ist der, dass ein Geschenk auch immer mit einer Erwartungshaltung an den Schenkenden verbunden ist. Ein Geschenk soll so ausgesucht sein, dass der Beschenkte es brauchen kann. Etwas das er noch nicht hatte und nach den er vielleicht schon länger vergeblich gesucht hat. Im besten Fall etwas das ihm Möglichkeiten aufzeigt an die er selbst noch gar nicht gedacht hat, die ihm aber sofort gefallen. Eigenschaften die sich idealerweise auch in jeder Produktneuerung wiederfinden sollten.

Zuletzt steckt im Geschenk auch implizit der Moment des Überreichens. Sei es mit oder ohne Geschenkpapier, das persönliche Geben und Entgegennehmen gehört dazu. Und mit der Zeit lernen wir durch die direkte Reaktion der Beschenkten wie es angenommen und bewertet wird, so dass wir beim nächsten mal eine noch bessere Auswahl treffen können. Auch das ist etwas was in den Beziehungen mit Auftraggebern und Kunden hochgradig Sinn macht.

In diesem Sinn: Schöne Bescherung.

Donnerstag, 21. Dezember 2017

Merit-Kalender

FS
Bild: Pixabay / Hans Braxmeier - CC0 1.0
Zu den faszinierendsten Ideen aus dem Management 3.0-Bereich gehört das so genannte Merit Money. Statt finanzielle Boni auf "traditionelle" Art und Weise an von Managern definierte Ziele zu binden entstehen sie durch die Beziehungen zwischen den Teammitgliedern. Jedes Teammitglied kann in definierten Intervallen bestimmte Mengen einer virtuellen Einheit (Punkte, Kudos, etc.) öffentlich an andere Teammitglieder vergeben (nicht an sich selbst), woraus sich in Summe die ausgezahlten Boni ergeben. Statt Egoismen wird so Teamwork gefördert.

Trotzdem tun sich viele Teams mit diesem Ansatz schwer. Es wird befürchtet, dass Beliebtheitswettbewerbe oder Klüngelrunden entstehen, dass manche Kollegen gar nicht belohnt werden oder dass sonstige Probleme auftreten. Um diese Sorgen zu zerstreuen kann es hilfreich sein zunächst einen Probelauf einzulegen, in dem ein Team noch ohne die finanziellen Folgen ein Merit-System ausprobieren kann. Ein Beispiel für einen solchen Lauf habe ich vor einiger Zeit mit einem von mir gecoachten Team durchgeführt - mit einem Adventskalender.

Es handelte sich genaugenommen nicht um nur einen Kalender sondern um mehrere (einen pro Teammitglied) hinter deren Türen sich Süßigkeiten befanden. Vor dem Daily Standup konnte jeder seine Süßigkeit des Tages an einen anderen vergeben, immer verbunden mit einer Begründung warum der sich das an diesem Tag verdient hatte. Bedingt durch den geringfügigen Wert war die Hemmschwelle deutlich geringer als sie es bei echten Boni gewesen wäre, gleichzeitig sorgte die tägliche Frequenz für einen schnellen Gewöhnungseffekt.

Selbst wenn sich die Weihnachtszeit durch den hohen Bekanntheitsgrad der Adventskalender besonders für solche Experimente anbietet kann man sie natürlich auch im restlichen Jahr durchführen. Und statt Süßkram können auch andere Belohnungen vergeben werden, von der Ernennung zum Mitarbeiter der Woche bis hin zu Wildcards mit denen Refactorings im Backlog hochpriorisiert werden können.

Letztendlich werden sich viele Teams auch nach erfolgreichen Probeläufen trotzdem gegen Merit Money-basierte Boni entscheiden, was auch in Ordnung ist. Mitunter behalten sie dann aber Elemente bei mit denen sie vorher experimentiert haben. Auch das ist dann bereits ein Mehrwert der sich gelohnt hat.

Montag, 18. Dezember 2017

Kontrollierte Experimente

FS
Bild: Wikimedia Commons / Giorgio Selvini - CC BY 4.0
Ein kontinuierlicher Verbesserungsprozess klingt immer gut, in der Realität stellt sich aber immer wieder die Frage wie er konkret aussehen soll. Wer beschließt Verbesserungsmassnahmen? Wann werden sie beschlossen? Ab wann kann man mit einer erreichten Verbesserung zufrieden sein? Diese und weitere Fragestellungen werden immer wieder diskutiert. Ein Weg um hier mehr Klarheit zu bekommen sind kontrollierte Experimente, die jedes Team selber durchführen kann.

Ausgangspunkt eines solchen Experiment ist eine Verbesserungsidee, die irgendwann identifiziert wurde, z.B. in einer Retrospektive. Eine solche Idee könnte etwa sein, dass durch Pair Programming die Qualität einer Anwendung verbessert wird. Unerfahrene Teams setzen das häufig so um, dass sie sich einfach vornehmen mehr Pairing zu machen. Fragt man dann nach einiger Zeit ob es Verbesserungen gegeben hat kommen meistens unklare Antworten wie "vom Gefühl her ja, genau belegen kann ich es aber nicht".

Um derartige Situationen zu vermeiden hilft es, wenn man sich zu Beginn einige Gedanken macht: Welche Maßnahmen wollen wir konkret umsetzen? Wie wollen wir die Erreichung messen? Wann wollen wir die Messung vornehmen? Was passiert wenn wir unser Ziel erreicht, bzw. nicht erreicht haben? Am weiter oben genannten Beispiel würde das bedeuten: Um die Qualität der Anwendung zu verbessen wollen wir mindestens zwei Pairing Sessions pro Woche durchführen. Wir messen die bessere Qualität anhand der Zahl der nötigen Anpassungen die sich aus den folgenden Code Reviews ergeben, diese Zahl wollen wir halbieren. Wir überprüfen nach einem Monat wie sich diese Zahlen entwickelt haben. Wenn keine Veränderung sichtbar ist beenden wir das Pairing, wenn es zwar eine Verbesserung gibt aber nicht in der angestrebten Größenordnung diskutieren wir nochmal darüber.

Neben der besseren Überprüfbarkeit des Erfolgs ist bei diesem Vorgehen noch ein zweiter Vorteil hervorzuheben: wirkungslose Verbesserungsmassnahmen können einfach wieder rückgängig gemacht werden. Einer der häufigsten Einwände gegen Prozessverbesserungen ist, dass man die neu eingeführten Schritte nie wieder los werden kann. In dem Moment in dem klar wird, dass das im Misserfolgsfall sehr wohl geht gehen die Widerstände dagegen zurück.

Donnerstag, 14. Dezember 2017

Stillarbeit

FS
Bild: Freegreatpictures / Max Pixel - CC0 1.0
Ein Fall aus der Praxis: im Team eines von mir gecoachten Scrum Masters war eine spürbar steigende Unzufriedenheit mit den Retrospektiven spürbar. Der Grund lag in den unterschiedlichen Charakteren der Teammitglieder - während die einen eher extrovertiert und impulsiv waren handelte es sich bei den anderen eher um stille Menschen. Infolgedessen verteilten sich die Redeanteile sehr ungleich, die Introvertierten hatten das Gefühl nicht zu Wort zu kommen, die Extrovertierten fühlten sich als wären sie die einzigen die Dinge ansprechen. Schwierig.

Auch die Moderationsversuche des Scrum Masters hatten nicht das gewünschte Ergebnis sondern führten dazu, dass das Team jetzt auch mit ihm unzufrieden war. Die Extrovertierten nahmen es so wahr als würde er ihnen ständig ins Wort fallen, die Introvertierten fühlten sich auf unangenehme Weise bedrängt und ins Scheinwerferlicht gestellt. Moderation war also auch nicht die Lösung, zumindest nicht mit einem darin noch relativ unerfahrenen Moderator.

Der Ansatz der die Situation spürbar verbessern konnte war die so genannte Stillarbeit. Jeder Teilnehmer der nächsten Retrospektive wurde gebeten zunächst in Ruhe seine Themen auf Post Its zu schreiben. Danach wurden sie der Reihe nach vorgestellt (Diskussionen wurden an der Stelle noch wegmoderiert), gemeinsam priorisiert und erst danach der Reihe nach diskutiert. Bei der kurzen "Retro der Retro" am Ende gab es für diese Art der Durchführung durchweg positives Feedback.

Die Diskussion hatte zwar immer noch ein gewisses Ungleichgewicht, allerdings hatte jeder Teilnehmer seine Themen in Ruhe vorstellen können, so dass die Introvertierten sich weniger übergangen fühlten und die Extrovertierten nicht mehr das Gefühl hatten alleine Input liefern zu müssen. Für den Scrum Master wurde ausserdem die Moderation einfacher, da er die bereits vorgestellten Themen als Ausgangspunkt für weiterführende Fragen nutzen konnte und nicht mehr ständig darum bitten musste, dass überhaupt Beiträge geliefert wurden.

Natürlich ist diese Art der Themensammlung nicht immer die passende, in diesem und in anderen Fällen hat sie von mir gecoachten Teams aber sehr geholfen und ist später auch in andere Meetings übernommen worden.

Montag, 11. Dezember 2017

Kick the ball out of the tent

FS
Ein Parforce-Ritt durch eine ganze Reihe von Aspekten: Wasserfall, Komplexität, Lean, Agile, Flow, Prinzipien, Prognosen und vieles mehr. Erkennbar für ein Publikum ohne vertiefte Vorkenntnisse gedacht und gerade deshalb geeinet für jeden der Inspirationen für seine eigenen Einführungsworkshops braucht.



Ähnlich wie ich experimentiert Kniberg anscheinend mit seinen Vorträgen und verändert sie immer wieder, im wesentlichen sind die Folien aber mit diesen hier identisch.

Donnerstag, 7. Dezember 2017

User Stories

FS
Bild: Pxhere - CC0 1.0
Wenn immer es möglich ist sollten Scrum Teams versuchen ihre Anforderungen in Form von User Stories zu verfassen. Das ist zwar nicht im Scrum Guide vorgeschrieben und es muss auch nicht immer in der klassischen Form Als [Benutzer mit Rolle ...] möchte ich [Aktion ... durchführen können] um [Mehrwert ... zu haben] sein (es gibt auch andere), es empfiehlt sich aber trotzdem so vorzugehen. Die Vorteile sind unverkennbar.

Um im Sinn des agilen Prinzips Maximizing the amount of work not done vozugehen lohnt es sich darüber nachzudenken wie man die Menge neu implementierten Codes so gering wie möglich halten kann. Ein weithin beliebter Ansatz ist dabei die Fokussierung auf den (End)Anwender. Nur was der tatsächlich benutzen kann ist von Wert, alles andere kann im Zweifel weggelassen werden. Folgerichtig sollten Anforderungen idealerweise auf Use Cases (Anwendungsfällen) beruhen.

User Stories greifen diese Idee auf und reichern sie um weitere Elemente an: in verständlicher Sprache erklären sie wer der Anwender ist, welche neue Funktion er braucht/bekommt und welcher Mehrwert damit verbunden ist. Neben dem oben genannten häufigsten Muster gibt es auch andere Variationen, etwa Um [Ziel ... zu erreichen] ermöglichen wir [Benutzer mit Rolle ...] die Aktion [...] durchzuführen oder ganz schlicht Nutzer: [...], Aktion: [...], Mehrwert: [...].

Natürlich werden trotzdem immer wieder Anforderungen auftauchen die nicht in dieses Muster passen: Arbeit an technischen Komponenten, Anpassungen an Architekturvorgaben, Bugfixes, Absicherung durch Tests, Code Cleaning, Abbau technischer Schulden, etc. Da viele von ihnen ein Zeichen von fehlender Anwender-Zentrierung oder (Spät)Folgen nachlässiger Arbeit sind kann es hilfreich sein das Verhältnis zu tracken: wieviel Prozent der umgesetzten Anforderungen sind User Stories und wie viele nicht? Bei einem zu niedrigem User Story-Anteil kann sich ggf. eine Retrospektive lohnen.


PS: es gibt leider auch Teams in denen der Begriff User Story ein generisches Synonym für Anforderungen aller Art ist. Mitglieder dieser Teams mögen sich bitte zur Behandlung in der nächsten Coach-Klinik melden.

Montag, 4. Dezember 2017

Scaled Agile: Chief Product Owner

FS
Bild: Flickr / Rod Waddington - CC BY-SA 2.0
Wenn Teams nach Scrum arbeiten gilt in Bezug auf die Rolle des Product Owners das Highlander-Prinzip: Es kann nur einen geben. Der Scrum Guide formuliert das an gleich zwei Stellen sehr eindeutig: "The Product Owner is the sole person responsible for managing the Product Backlog." und "The Product Owner is one person, not a committee." Für ein einzelnes Team ist das auch nachvollziehbar, aber was passiert wenn mehrere Teams an einem gemeinsamen Produkt arbeiten?

Passend zum teamübergreifenden Konstrukt des Tribes findet man in vielen Organisationen die Rolle des Chief Product Owners oder CPO (auch Head PO, Lead PO, o.ä.) der die übergreifende Produktvision verantworten soll. Er gibt damit das Fernziel vor, das erreicht werden soll und aus der die Product Owner nach dem Pull-Prinzip die Arbeit der Teams ableiten können. Diese Konstellation ist im Rahmen des Frameworks zulässig, da die Vision zwar erwähnt wird, aber nicht festgelegt ist, wer ihr Owner ist. Es kann also auch jemand anderes als der PO sein. Wie aus ihr allerdings konkrete Arbeit (an einem Increment) abgeleitet wird liegt sehr wohl bei ihm.

Was explizit nicht zum Aufgabenbereich des CPO gehören kann ist die Arbeit an den Backlogs, er soll also weder Arbeitsaufträge an die Teams vergeben noch deren Reihenfolge oder Priorität festlegen. Das bleibt dem PO vorbehalten, der dafür auch Teil mehrerer Scrumteams sein kann. Dass lässt sich indirekt aus dem Scrum Guide ableiten, der zum einen festlegt, dass nur der PO das Backlog verantwortet, zum anderen aber auch, dass mehrere Teams aus einem Backlog arbeiten können.

Diese Aufteilung in CPO (Produktvision) und PO (Product Backlog) kann in der Anwendung schnell künstlich wirken und im schlimmsten Fall zu Konflikten führen, durch die Ressourcen gebunden und die Organisation gelähmt werden. Im Rahmen des Scrum-Frameworks ist es aber die einzige mögliche Aufteilung. Das heisst zwar nicht, dass man nicht alles anders organisieren könnte - aber dann ist es kein Scrum mehr.

Nachtrag 26.02.: 
Eine Übersicht über andere Interpretationen der Chief PO-Rolle gibt es hier.
Powered by Blogger.