Dienstag, 30. Juni 2020

Kommentierte Links (LXIII)

Bild: Unsplash / Dayne Topkin - Lizenz

  • Tendayi Viki: Do Entrepreneurs Really Create More Transformative Innovations Than Intrapreneurs?

    • Es gibt Zahlen die überraschen, und die die Tendayi Viki hier aus einer älteren Studie ausgegraben hat gehören dazu: es waren keine Startups in denen die meisten bahnbrechenden Innovationen zwischen 1980 und 2010 gemacht wurden sondern Konzerne (auch für die 10 Jahre danach lässt es sich feststellen - das Meiste was unsere Welt verändert hat kommt aus den "Big Companies" der amerikanischen Westküste und asiatischen Ostküste). Was sich daraus ergibt: anders als in der öffentlichen Wahrnehmung verankert ist es nicht der Entrepreneur, also der genialisch veranlagte Erfinder/Unternehmensgründer, der unsere Art zu Leben und zu Arbeiten verändert. Wichtiger ist stattdessen der Intrapreneur, der als Teil einer grossen Organisation für deren bestehende Kunden Neues erschafft und Bestehendes verbessert. Ein Grund mehr den eigenen Mitarbeitern Raum zur Selbstorganisation und Selbstentfaltung zu geben. (siehe auch Vikis zweiten Artikel zu dem Thema: Why Intrapreneurs Are Not Just Entrepreneurs Working Inside Large Companies)

  • Yuri Malishenko: How visual thinking can make you a better agile coach

    Dass es hilfreich ist neue Informationen auch mit einfachen Bildern zu visualisieren um sie mit verschiedenen Sinnen aufnehmen zu können ist nichts was die "agile Bewegung" erfunden hätte, schon die Jahrtausende alten Höhlenmalereien beruhen auf diesem Prinzip. Mit dem Aufkommen von Flip-Charts und Post-Its auch im Büro-Kontext anwendbar geworden sind diese schnell erstellten Zeichnungen aber zu einem Erkennungszeichen agiler Teams und Coaches geworden und tragen zur Soft Power der Agilität bei. Yuri Malishenko gibt mit seinem Artikel einen interessanten Einblick in diese "Kleinkunst", sowohl in Bezug auf die verschiedenen möglichen Anwendungsgebiete als auch in Bezug auf die digitale Wieder- und Weiterverwendung. Gerade letzteres dürfte in einer Zeit zunehmender Remote-Arbeit immer wichtiger werden.

  • Ellen Merryweather: The Difference: Prototype vs MVP [Edit: Link ist mittlerweile tot]

    Nicht nur im Startup-Umfeld, auch in mittleren und grossen Unternehmen gibt es den zunehmenden Trend Produktentwicklungen mit einem Prototypen oder MVP zu beginnen statt von Beginn an umfangreiche "fertige" Versionen zu entwickeln von denen sich dann beim Release herausstellt, dass kein Kunde sie so will. Das ist für sich genommen erstmal gut, das zu beobachtende Problem ist aber eine Verwirrung was denn mit diesen Begriffen genau gemeint sein soll. Ellen Merryweathers Differenzierungsversuch ist hier sehr hilfreich, vor allem weil sie sich nicht darauf konzentriert zu beschreiben was Prototyp und MVP sind sondern wofür sie ihrer Meinung nach gedacht sind: das eine für interne Machbarkeits-Analysen, das andere für das Einholen von frühem Feedback potentieller Benutzer.

  • GeePaw Hill: An Intro to Spikes

    Passend zum letzten Thema: Michael Hill aka GeePaw Hill gehörte zu den ersten Extreme Programming-Coaches und dürfte daher wie kaum ein anderer geeignet sein die dazugehörigen Konzepte und Begriffe zu erklären. Der dessen er sich hier annimmt ist einer der etwas unbekannteren - der Spike. Pawhill definiert ihn hier als spezifische Anforderung eines Proof of Concept oder eines Prototypen. Ganz wichtig in seiner Definition: egal was das Ergebnis ist, es darf nicht in das Produkt eingebaut werden. Würde das doch passieren wäre das Risiko zu gross, dass das im Anschluss nötige Refactoring immer weiter nach hinten priorisiert wird und der (von Natur aus rudimentäre) PoC-Code in Live-Betrieb und Weiterentwicklung die Produktqualität, Architektur, Performance und andere wichtige Aspekte negativ beeinflusst.

  • Mike Cohn: Can a Team Vote Someone Off the Team?

    Ein schönes Bespiel für eine Frage die scheinbar mit Ja oder Nein zu beantworten ist, dann aber ein grosses "Kommt darauf an" nach sich zieht. In diesem Fall: es kommt darauf welchen Grad an Autonomie dieses Team hat. Mike Cohn übernimmt dazu die Abstufung von Richard Hackmann, bestehend aus Manager-Led (fremdbestimmt), Self-Organizing (selbstorganisiert), Self-Designing (sich selbst zusammenstellend) und Self-Governing (den eigenen Zweck bestimmend). Naheliegenderweise ist das Entfernen eines Teammitglieds durch das Team ab Stufe drei möglich. Was Cohn ausserdem zu Recht betont: in der Realität findet man solche Teams sehr selten.

Donnerstag, 25. Juni 2020

Paper Prototyping

Bild: Flickr / Rosenfeld Media - CC BY 2.0
In Ansätzen wie Lean Startup und Design Thinking stehen MVPs und Prototypen im Vordergrund, also frühe, mit möglichst wenig Aufwand erzeugte Arbeitsergebnisse, die aber trotzdem schon einen so guten Eindruck vom späteren Produkt geben, dass auf dessen Basis ein erstes Benutzerfeedback eingeholt werden kann. Diese Gleichzeitigkeit von möglichst wenig Aufwand und möglichst gutem Eindruck ist natürlich eine Herausforderung, die nur mit bestimmten Techniken gemeistert werden kann. Eine der bekanntesten unter ihnen ist das Paper Prototyping.

Die grundlegende Idee ist simpel - statt mit relativ viel Arbeit irgendetwas Vorzeigbares in digitalen Design-Tools zu entwerfen, es zu programmieren und es dann auf ein Vorführgerät oder eine Vorführumgebung zu bringen wird einfach ein Entwurf mit Stiften auf ein Papier gemalt und der dann der Zielgruppe vorgelegt. Die muss dann nur noch die Frage beantworten ob er ihr gut genug gefällt um mit mehr Aufwand in eine echte Umsetzung zu gehen. Wenn nicht kann man verbessern - oder abbrechen ohne Investitionen zu verlieren.

Für jemanden der einen solchen Papier-Prototypen noch nie gesehen hat (oder nur solche die dilettantisch erzeugt wurden) wird dieser Ansatz zuerst merkwürdig klingen. Ein bemaltes Papier soll ausreichend sein um verwertbares Nutzerfeedback zu erzeugen? Die Skepsis ist berechtigt, wie so oft gilt auch hier, dass man eine gelungene Anwendung gesehen haben muss bevor man sich etwas darunter vorstellen kann. Glücklicherweise gibt es im Internet genug gute Beispiele, wie etwa dieses Video (nur eine Minute lang):



Gut sichtbar sind hier einige Erfolgsfaktoren: die hier gezeigten Prototypen sind durch Color Coding und minimalistisches Design so übersichtlich gestaltet, dass eine Konzentration auf die zentralen Funktionen stattfindet, die aufeinanderfolgenden "Screens" simulieren einen Bedienungsablauf (was dann durch den "Vorführ-Rahmen" noch besser erfahrbar wird) und durch Elemente wie die Klappmeüs und die Post It-Schnipsel ist bereits eine echte Interaktion möglich.

Anhand dieses Beispiels kann man es sich schon besser vorstellen wie ein Paper Prototype zu Vorführzwecken verwandt wird. Auch von der dadurch möglichen Geschwindigkeit bekommt man eine Vorstellung - ein geübter Zeichner wird in der Lage sein das Feedback der Testgruppe innerhalb von Minuten in einen verbesserten und direkt wieder testbaren Prototypen einzuarbeiten, ein Tempo mit dem kein noch so guter digitaler Entwurf mithalten kann.

Natürlich gibt es bei diesem Vorgehen auch Risiken, von denen als wichtigstes die Illusion einer einfachen Umsetzbarkeit zu nennen ist (ich durfte einmal miterleben wie ein Team aus UX-Designern einen vom Kunden gefeierten Prototypen einer Website erstellte, nur um nachher zu erfahren, dass die Umsetzung die halbe IT ein Jahr lang beschäftigt halten würde). Durch eine frühe Einbindung der IT in den Prototyping-Prozess lässt sich die Wahrscheinlichkeit solcher Missverständnisse aber reduzieren.

Trotz dieses Risikos ist Paper Prototyping aufgrund der genannten Vorteile vor allem in den frühen Phasen einer Produktentwicklung wärmstens zu empfehlen, das schnelle Feedback und die Möglichkeit einer extrem frühen Verbesserung des Produkts wiegt die möglichen Nachteile klar auf. Und im schlimmsten Fall muss man nichts verwerfen ausser den ersten Blättern eines Papierblocks, bevor man mit den nächsten Blättern den nächsten Prototypen baut.

Montag, 22. Juni 2020

Das Problem mit Jira, Trello, Leankit & Co

Bild: Pixabay / 12222786 - Lizenz
Wenn man Teil eines durchgängig aus dem Homeoffice arbeitenden agilen Projekts ist, ist es in den meisten Fällen nicht mehr die Frage ob man eines der zahlreichen digitalen Arbeitsmanagement-Tools benutzt, es geht nur noch darum welches - Jira, Trello, Leankit, Octane, den Teams Planner oder eines der eher unbekannten Nischen-Tools. Sie alle haben aber zwei Dinge gemeinsam: sie verändern die Art wie wir Arbeit (und Arbeits-Management) wahrnehmen und sie bringen eigene Prozessabläufe mit sich die man zwangsläufig zu den eigenen machen muss. Man sollte ihnen daher mit Vorsicht und bewusstem Herangehen begegnen, immer mit der klassischen Coaching-Frage im Hinterkopf - was macht das mit mir?.

Die offensichtlichste Folge ist, dass die Sichtbarkeit der Arbeit abnimmt. während man vorher auf einer Wand den Überblick über alle wichtigen Informationen haben konnte (Sprint-Board, Burndown, Impediments, Personas, etc.) sind diese zwar immer noch da, allerdings verstreut über verschiedene Websites. Um von einer zur anderen zu wechseln muss man sich durch Tabs klicken oder Seitenabschnitte durchscrollen. Das Big Picture geht verloren.

Was ausserdem häufig unterschätzt wird: das physische Board ist unübersehbar präsent und erinnert an To Dos und Missstände, das digitale Board wird in der Regel nur während der Meetings aufgerufen und ist sonst unsichtbar. Und selbst wenn man es auf grossen Wandbildschirmen präsentiert sind die meisten Tools so aufgebaut, dass wichtige Informationen innerhalb der Tickets gespeichert werden und erst sichtbar werden wenn man diese separat öffnet.

Ein ebenfalls erst auf den zweiten Blick sichtbarer Effekt ist der, dass digitale Tools oft zu einer starken Aufblähung des Informationsumfangs führen. Jedes Ticket enthält eine Vielzahl von potentiell nutzbaren Freitextfeldern, Labels, Attachements und Verlinkungen, die zum einen ein schlechtes Gefühl erzeugen können wenn man sie frei lässt (→ Horror Vacui), zum anderen aber auch keine Obergrenze setzen, so dass in Summe aller Tickets eine nicht mehr aktuell zu haltende Umfangsmenge entstehen kann.

Offensichtlicher als die zuvor genannten Punkte ist das Phänomen, dass die Tools ihren Nutzern Prozesse aufzwingen (bzw. bisherige Prozesse nicht abbilden können). Häufig genannt wird z.B., dass Tickets sich immer nur einer Person zuordnen lassen, was im Widerspruch zu der verbreiteten Praktik des Pairings steht. Auch die Aufteilung von Arbeit/Anforderungen in mehr als drei Hierarchie-Ebenen (Epic, Story, Subtask) ist in praktisch keinem Tool möglich, selbst wenn der eigene Planungsansatz es eigentlich erfordern würde.

Was zuletzt fast immer unterschätzt wird ist der mit digitalen Tools verbundene Administrationsaufwand. Dieser umfasst nicht nur die Einrichtung und Berechtigung der Accounts (wobei alleine das schon erstaunlich arbeitsintensiv sein kann) sondern auch das Anlegen und Verwalten von Projekten, Boards, Filtern, etc. Ein verbreitetes Phänomen ist die Wahrnehmung dieser Aufgaben durch die Scrum Master, was einerseits verständlich ist (die Teams werden entlastet) auf der anderen Seite aber dazu führt, dass für seine eigentlichen Aufgaben weniger Zeit bleibt.

Wie zu Beginn gesagt, ganz wird man im Rahmen verteilter Arbeit nicht um die Nutzung digitaler Arbeitsmanagement-Tools herumkommen. Aufgrund der genannten Phänomene sind Teams und Unternehmen aber gut beraten wenn sie sich reflektiert und regelmässig mit der Frage auseinandersetzen welche Auswirkungen das auf ihre Arbeitsweisen hat. Dadurch kann zwar nicht verhindert werden, dass diese durch die Tools beeinflusst werden, man kann aber versuchen das in Bahnen zu lenken die nicht gegenläufig zum grundlegenden Zusammenarbeitsmodell sind.


Nachtrag 01.01.2021:
Da mehrfach nach dem Sinn des Symbolbilds gefragt wurde - Jira ist die Abkürzung für Gojira, den ursprünglichen japanischen Namen von Godzilla.

Donnerstag, 18. Juni 2020

Endspurt, Design Sprint, Sprint


Bild: Flickr / A Healthier Michigan - CC BY-SA 2.0
Gerade dann wenn die Bedeutung eines Begriffs für alle Beteiligten scheinbar selbstverständlich ist lohnt sich ein näherer Blick. Das gilt natürlich auch für die Fachsprache die sich über die Jahrzehnte im Rahmen der agilen Arbeitsweisen entwickelt hat. Ein Fall an dem sich das aufzeigen lässt ist der Sprint. Je nach Kontext können sich hinter diesem Wort stark unterschiedliche Ausprägungen verbergen, derer man sich bewusst sein sollte wenn man es benutzt.

Die in der Realität am häufigsten anzutreffende Variante lässt sich am besten als "Endspurt" beschreiben. Nach längeren Anforderungserhebungs- und Planungsprozessen geht es hier nur noch darum das definierte Ergebnis in kurzen Schüben umzusetzen (häufig anzutreffen in SAFe). Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse relativ klar und stabil sind, die Umsetzung aber technisch oder organisatorisch anspruchsvoll ist. Der Inspect & Adapt-Zyklus dient dann nur noch der Überprüfung und Anpassung des Umsetzungsvorgehens. Das mit diesem Ansatz verbundene Risiko ist, dass er entgleisen kann wenn die Anforderungen sich ändern.

Auch der umgekehrte Fall existiert, es sind die so genannten "Design Sprints". In ihrer bekanntesten Variante enthalten sie nicht nur das blosse Anforderungsdesign sondern auch die Erstellung erster Prototypen oder Vorführ-Versionen und deren Validierung an einer echten Anwender-Zielgruppe. Sobald diese positiv reagiert erfolgt die Übergabe an die eigentliche Umsetzung. Sinn macht ein derartiges Vorgehen vor allem dann wenn die Anforderungen und Nutzerbedürfnisse noch unklar oder instabil sind. Der Inspect & Adapt-Zyklus dient vor allem dem Erstellen und Verwerfen von Bedarfs- oder Anwendungs-Hypothesen. Das mit diesem Ansatz verbundene Risiko ist, dass seine Ergebnisse sich als nur schwer umsetzbar herausstellen können.

Der dritte Typ entspricht den Sprints in Scrum oder den Iterationen in Extreme Programming. Der Anspruch dieses Ansatzes ist, auf der Basis einfach formulierter Anwender-Bedürfnisse sowohl das Design als auch die Umsetzung einer Funktionserweiterung in einem (!) Intervall umzusetzen. Sinn macht dieses Vorgehen wenn sowohl die Anforderungen und Nutzerbedürfnisse als auch die Bedingungen der Umsetzung sich ändern können. Der Inspect & Adapt-Zyklus sollte alle dieser Aspekte berücksichtigen. Das mit diesem Ansatz verbundene Risiko ist, dass er bei vielen Abhängigkeiten und hohem Abstimmungsbedarf unverhältnismässig viele Ressourcen für diese Themen verwendet.1

Was anhand dieser verschiedenen Ausprägungen erkennbar ist: abhängig von Verständnis und Erfordernissen kann sich jeweils etwas Unterschiedliches hinter dem scheinbar klaren Begriffs des Sprints verbergen (dazu kämen noch Antipattern wie z.B. der Konzeptions-Sprint", der "Test-Sprint" oder der "Gewaltmarsch"), es macht also grossen Sinn sich zu vergewissern welches im eigenen Fall vorliegt.


1Der übliche Lösungsansatz im agilen Vorgehen wäre die Vermeidung oder Auflösung von Abhängigkeiten, z.B. durch crossfunktionale Teams oder shared Code.

Montag, 15. Juni 2020

Ein Bild sagt mehr als 1000 Worte (XXVIII)

Grafik: Vincent Déniel - CC BY-NC 4.0

Freitag, 12. Juni 2020

Die Grundlagen-Dokumente von Scrum

Bild: Pxfuel - Lizenz

Update 05.02.2021: da es neue Versionen von Scrum Guide, Nexus Guide und Scrum@Scale Guide gibt, gibt es auch eine neue Version dieser Seite.

---

Scrum ist sich selbst in einer Hinsicht sehr treu: es findet ein kontinuierlicher Verbesserungsprozess statt, in dessen Rahmen seine Regeln ständig überarbeitet, ausdifferenziert aber zum Teil auch wieder verschlankt werden. Da dieser Prozess seit über 30 Jahren anhält ist es nicht immer einfach nachzuverfolgen was zu welchem Zeitpunkt hinzugefügt oder verändert wurde. Dem kann abgeholfen werden - hier sind die wichtigsten Grundlagenwerke auf denen das Scrum-Framework beruht und die es immer weiter entwickelt haben:

1986: The New New Product Development Game (Hirotaka Takeuchi, Ikujiro Nonaka)

Dieser von von den Wissenschaftlern Takeuchi und Nonaka verfasste Artikel über die Arbeit japanischer Fabrikteams ist das einzige Grundlagenwerk an dem die "Scrum-Väter" Jeff Sutherland und Ken Schwaber nicht beteiligt waren (statt Scrum wird auch noch vom "Rugby Approach" gesprochen). Aus heutiger Sicht beschreibt es noch nicht Scrum selbst sondern einige Prinzipien auf denen es beruht, u.a. crossfunktionale Teams und iterativ-incrementelles Arbeiten. Die 1990 erfolgte Übertragung des New New Product Development Game auf die IT durch DeGrace und Stahl war damit die Inspiration für die Entwicklung von Scrum in seinem heutigen Sinn, was Sutherland und Schwaber auch selbst betont haben.

Nachdem Sutherland und Schwaber Scrum in den ersten Jahren nur im Rahmen ihrer eigenen Software-Projekte einsetzten führte der Wunsch es bekannter zu machen zur Vorstellung durch die beiden auf der OOPSLA-Konferenz im Jahr 1995. Das Konferenz-Paper gilt als Initialzündung der weltweiten Verbreitung von Scrum, enthält aber vieles noch nicht was heute zentral ist. Umgekehrt sind noch Elemente vom Wasserfall-Vorgehen enthalten, etwa die Phasen "Pregame", "Game" und "Postgame". Anderes, wie der Sprint, das Sprint-Ziel, das Sprint Planning, das Sprint Review oder der Product Owner (noch als Product Manager), existieren bereits. Scrum ist in dieser (und den nächsten) Versionen explizit ein Ansatz der Software-Entwicklung.

Dieses leicht despektierlich "Scrum-Plop" abgekürzte Gemeinschaftswerk einer ganzen Reihe verschiedener Autoren erwähnt zum ersten mal die Rolle des Scrum Masters, wenn auch noch als eine spezifische Form des Teamleiters, dem auch leitende und kontrollierende Funktionen zugeschrieben werden. Besonders interessant: zusätzlich zum Scrum Master wird auch ein (nicht genauer beschriebener) Coach erwähnt, der anscheinend zu dieser Zeit noch eine eigene Rolle war. Auch das 15-minütige Daily Scrum-Meeting taucht hier erstmals auf, genau wie das Commitment des Teams das Sprint-Ziel zu erreichen.

Das erste Buch über Scrum, gleichzeitig aber auch ein Werk das im Rückblick leicht wunderlich wirkt. Statt Scrum als eigenständigen Ansatz vorzustellen stellten Schwaber und Beedle in den Vordergrund, dass ein anderer methodischer Ansatz, Extreme Programming (XP), sich mit Hilfe von Scrum besonders gut umsetzen liesse. Hintergrund ist, dass XP um das Jahr 2000 herum populärer war als Scrum und die Verbindung dieser beiden Ansätze Scrum schneller bekannt machen konnte. Zusätzlich kannten und respektierten sich die Urheber von Scrum und XP (u.a. waren sie 2001 gemeinsam an der Enstehung des agilen Manifests beteiligt). Der halboffizielle Status einiger XP-Elemente in Scrum (User Stories, Story Points, Pair Programming) erklärt sich aus dieser Zeit.

In dieser Übersicht über die Scrum-Einführung in verschiedenen Unternehmen tauchen erstmals Skalierungs-Elemente auf. Zum Einen findet sich hier die Idee, dass auch Management-Teams nach Scrum arbeiten können, zum Anderen wird hier zum ersten mal das Scrum of Scrums vorgestellt, ein wöchentliches Scrum-Meeting in dem sich Vertreter verschiedener Teams treffen um sich untereinander abzustimmen und die Arbeit an übergreifenden Themen zu koordinieren. Aus diesen Ansätzen entstand später das Skalierungsframework Scrum@Scale (siehe unten).

Im Vergleich zu den anderen Texten ein eher wenig wichtiger, es wird nicht wirklich etwas Neues hinzugefügt. Interessant ist aber, dass Ken Schwaber in ihm einen weiteren Aspekt aus dem Extreme Programming aufgreift: den Team-Raum (angelehnt an den Extreme Space, in dem alle Teammitglieder zusammensitzen). Mittlerweile aus dem offiziellen Teil von Scrum verschwunden ist er noch immer ein wichtiger Teil in vielen Umsetzungen.

Ein weiterer Artikel von Ken Schwaber, der diesesmal aber grössere Änderungen beschreibt. Das Sprint Planning wird unterteilt in Planning I (was machen wir?) und Planning II (wie machen wir es?). Im Daily werden die drei Fragen gestellt was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind. Erstmals findet am Ende des Sprints eine Retrospektive statt, die mittlerweile der zentrale Antrieb für den kontinuierlichen Verbesserungsprozess geworden ist und als das Scrum Meeting schlechthin gilt. Auch die später zum zentralen Abnahme-Kriterium gewordene Definition of Done wird hier erstmals erwähnt, allerdings noch eher beiläufig an verschiedenen Stellen im Fliesstext. Diese zentralen Änderungen tauchen dann auch 2004 in Schwabers Buch Agile Project Management with Scrum auf.

Ein Dokument das erst rückwirkend zum ersten Scrum Guide erklärt wurde, Sutherland und Schwaber veröffentlichten es zuerst unter dem schlichten Namen "Scrum". Es ist die letzte Version von Scrum in der sich Wasserfall-Elemente finden: zusätzlich zu den Sprint Plannings können langfristige "Release Plannings" durchgeführt werden und es gibt noch die Möglichkeit Integration und Testing in separate Sprints auszulagern. Auch die kontrovers benannten Rollen "Pig" (Teammitglied) und "Chicken" (Stakeholder) tauchen ein letztes mal auf. Positiv zu benennen ist, dass der Scrum Master als helfender und coachender "Servant Leader" beschrieben wird, was seitdem unverändert gilt. Mit der Festlegung, dass mehrere Teams ein gemeinsames Backlog haben können taucht ein weiterer Skalierungs-Aspekt auf.

Die letzten Wasserfall-Elemente verschwinden aus dem Scrum Guide, ausserdem alle spezifischen Bezüge zur Softwareentwicklung, womit Scrum auch auf andere Bereiche anwendbar wird. Auch die Pig- und Chicken-Rollen verschwinden. Das Grooming wird dagegen zu einem festen Bestandteil und die Rollen werden ausführlicher beschrieben als vorher. Im Wesentlichen entspricht diese Version von Scrum der die bis heute gültig ist, die späteren Änderungen sind kleiner.

Eher redaktionelle Bearbeitungen, nennenswerte inhaltliche Veränderungen finden nicht statt.

Es werden Neuerungen und Ergänzungen in verschiedenen Bereichen eingeführt: die Teammitglieder sollen sich in den Daily Scrums nicht mehr nur fragen was gestern gemacht wurde, was heute gemacht werden wird und wo Hindernisse aufgetreten sind, sondern auch welchen Einfluss das auf das Erreichen des Sprint-Ziels haben wird. Das (in manchen Ländern anstössige) Wort Grooming wird durch Refinement ersetzt. In diesem Zusammenhang wird es auch möglich Backlog-Einträgen den Status Ready zu geben, woraus die inoffizielle Definition of Ready abgeleitet werden kann. Die Teilung des Sprint Plannings in Planning I und Planning II wird aufgehoben, das Was und das Wie können jetzt beliebig erarbeitet werden. Eine kleinere Ergänzung kommt bei den Skalierungs-Aspekten dazu: mehrere Teams können eine gemeinsame Definition of Done haben.

Das erste offizielle Skalierungsframework von Scrum. Grundlage sind die beiden Skalierungs-Aspekte des Scrum Guide, die gemeinsame Definition of Done und das gemeinsame Backlog für Teams die an einem gemeinsamen Produkt arbeiten. Da gleichzeitig vorgegeben ist dass es nur einen Product Owner für ein Backlog geben darf wird daraus abgeleitet, dass der auch für alle derartigen Teams zuständig ist. Weitere Elemente sind die Aufteilung der Scrum-Meetings in jeweils einen übergreifenden und einen teamspezifischen Teil und die zusätzliche Mitgliedschaft von Experten und ausgewählten Teammitgliedern in einem übergreifenden Integration-Scrum Team, dass den anderen Teams dabei hilft sich selbst zu koordinieren. Ein sehr ähnliches, halboffizielles Framework ist Large Scale Scrum (LeSS).

Die "Scrum-Werte" Respekt, Commitment, Fokus, Offenheit und Mut werden in den Scrum Guide aufgenommen. Das ist keine vollständige Neuerung, da sie bereits 2001 im Buch Agile Software Development with Scrum von Ken Schwaber und Mike Beedle enthalten waren. Ihre Wiedereinführung ist der bisher prominenteste Fall einer Scrum-Regeländerung die auf Wünsche aus der Anwender-Community zurückgeht.

Neben verschiedenen redaktionellen Änderungen gibt es drei grössere: die berühmten drei Fragen im Daily Scrum sind jetzt optional, der Scrum Master bewegt sich mehr Richtung Coach, da er nicht mehr für die Einhaltung der Scrum-Regeln sorgt sondern deren Verständnis fördert, und zuletzt muss in jeden Sprint mindestens eine Massnahme zur Verbesserung der eigenen Arbeitsweisen aufgenommen werden.

Eine vergleichsweise kontroverse Neuerung. Anders als der oben erwähnte Nexus-Ansatz geht Scrum@Scale davon aus, dass das eigentliche Scrum Framework nur für einzelne Teams gedacht ist und nicht für grössere Organisationen. Skalierung funktioniert daher in diesem Modell nicht durch die Gruppierung von Teams um Backlogs und Product Owner sondern dadurch, dass es zwar übergeordnete Hierarchie-Ebenen gibt, diese aber aus Delegierten der jeweils nächstunteren Ebene bestehen, die sich auch als Scrum Teams organisieren. Dabei gibt es zwei parallele Hierarchien: die Scrum of Scrums, Scrum of Scrum of Scrums, etc. für die Scrum Master und die gleichartig gestaffelten Meta-Scrums für die Product Owner. Auf diesen höheren Ebenen entstehen auch die neuen Rollen des "Scrum of Scrums Master" und des "Chief Product Owner" (samt deren Steigerungen).

---

Honorable Mentions

Natürlich gibt es noch weitere Quellen die wertvoll für das Verständnis von Scrum sind, vor allem in Buchform. Von Schwaber und Sutherland sind das vor allem die ikonisch benannten Titel Software in 30 Days und The Art of Doing Twice The Work In Half the Time, es gibt Scrum and XP from the Trenches von Henrik Kniberg, Agile Product Management with Scrum von Roman Pichler, die Bücher von Mike Cohn, die Bücher von Craig Larman und Bas Vodde und viele mehr. Sie alle haben Scrum aber nicht verändert sondern beschreiben lediglich seine Anwendungsmöglichkeiten und vermitteln bewährte Techniken und Praktiken, weshalb sie keine Grundlagen-Dokumente im eigentlichen Sinn sind (lesenswert sind sie natürlich trotzdem).

Montag, 8. Juni 2020

Story Points in Kanban

Bild: Freegreatpicture / Max Pixel - CC0 1.0
Wenn es darum geht Aufwands- oder Komplexitätsschätzungen zu machen raten die meisten in agilen Vorgehensweisen erfahrenen Entwickler zu Story Points, unter anderem wegen der Vorteile relationaler Schätzungen, aber auch aus anderen Gründen. Was dabei fast alle gemeinsam haben ist aber eine Einschränkung auf nur ein oder zwei Frameworks, nämlich Scrum und Extreme Programming. Eine Anwendung im Rahmen von Kanban (des dritten grossen agilen Ansatzes) wird von den meisten nicht erwogen. Dabei wäre sie auch hier durchaus möglich.

Ähnlich wie im Fall der iterativen Ansätze Scrum und XP ist ein Story Point auch in Kanban eine neutrale (d.h. personenunabhängige) Schätzgrösse, die je nachdem wer an der Anforderung arbeitet eine etwas schnellere oder langsamere Umsetzungsdauer bedeuten kann, aber trotzdem eine gemeinsame Schätzung des Teams ermöglicht. Was im Vergleich zur klassischen Anwendung dagegen anders ist, ist die Art des Einsatzes zu Planungs-, Forecast- oder Prognosezwecken.

In Scrum und XP dienen die in der Vergangenheit gelieferten Story Points als Grundlage für die Velocity, also die durchschnittliche Menge an Arbeit die das Team bisher pro Sprint oder Iteration erledigen konnte1. Diese ist dann wiederum ein Indikator dafür was voraussichtlich in zukünftigen Sprints fertiggestellt werden kann. Da in Kanban an die Stelle der festen Lieferzyklen eine beständige Lieferung tritt ist diese Art der Prognose hier nicht möglich, es wird anders vorgegangen.

Was stattdessen passiert ist eine Einteilung der Anforderungen in Äquivalenzklassen, deren durchschnittliche Lead- oder Cycle-Time gemessen wird. Wenn z.B. in der Vergangenheit Anforderungen mit 5 Punkten im Durchschnitt 4 Tage gebraucht haben, dann kann angenommen werden, dass das in Zukunft vergleichbar sein wird. Allerdings - ist das nicht doch wieder eine Schätzung in Zeiteinheiten? Ja, schon, wenn man es dabei belässt. Aber es steckt noch mehr dahinter.

Bedingt durch verschiedene Unsicherheitsfaktoren (Erfahrung des Bearbeiters, Neuartigkeit des Themas, etc.) kommt es normalerweise bei einem Teil der umgesetzten Anforderungen zu Abweichungen nach oben und unten, meistens in Form einer Gauss-Kurve. Das kann z.B. heissen, dass etwa 20 % der Fälle früher als gedacht fertig werden, etwa 60 % ungefähr rechtzeitig2 und etwa 20 % später als gedacht. Diese Zahlen ermöglichen eine Ausdifferenzierung der Prognose.

Beim oben genannten Beispiel von 5 Punkten könnte dass etwa bedeuten3, dass man eine praktisch sichere Ablieferung nach 6 Tagen zusichern kann, eine sehr wahrscheinliche nach 4 Tagen und eine unwahrscheinliche aber theoretisch mögliche nach 2 Tagen. Für die abnehmende Einheit ergibt sich dadurch die Möglichkeit verschiedener Planungsvarianten um flexibel reagieren zu können, mit verbesserter Anpassungsfähigkeit über verschiedene Stationen der Lieferkette als Folge.

Man muss sich bewusst sein: diese Art der Business Agility erfordert Arbeit und Disziplin beim Erheben und Auswerten der Statistiken, man sollte sich also fragen welcher Mehrwert so entstehen soll und ob er in erträglicher Relation zu den Aufwänden steht. Wenn man das mit Ja beantworten kann steht dem Einsatz von Story Points in Kanban aber nichts mehr im Weg.



1Nur zur Klarstellung: man kann in Scrum und XP Story Points benutzen, muss es aber nicht
2Auch hier gibt es noch kleinere Abweichung in einigen Fällen
3Abhängig vom Umfang der Abweichungen

Freitag, 5. Juni 2020

Der 'Gesellschaftsvertrag' als Grundlage der Selbstorganisation in Unternehmen


Bild: Wikimedia Commons / Peter Bircks - Public Domain
Es ist mal wieder Zeit für ein bisschen Meta-Betrachtung, diesesmal mit einem Exkurs in Richtung eines soziologischen Konstruktes, das sich auch auf autonom arbeitende Teams anwenden lässt. Die Rede ist von der Vertragstheorie, hinter der sich die Vorstellung verbirgt, dass alle nicht erzwungenen Zusammenschlüsse von Menschen auf gegenseitigen Übereinkünften beruhen, entweder in Form schriftlicher Dokumente oder in Form stillschweigender Annahmen und Zustimmungen - häufig auf einer Mischform aus beidem. Am häufigsten wird die Vertragstheorie zwar in Staatsrecht und Politkwissenschaft angewandt (das bekannteste Beispiel ist der Gesellschaftsvertrag von Rousseau), eine Übertragung auf andere Bereiche ist aber möglich.

Einer bei dem sich das im Wortsinn anbietet sind wirtschaftlich tätige Unternehmen. Das G in OHGs, GmbHs, AGs und UGs steht schliesslich für Gesellschaften, und selbst wenn es für den Gesellschaftsvertrag schon eine juristische Bedeutung gibt, so ist die andere, implizite auch immer vorhanden. Gerade in einem Selbstorganisations-Kontext ist sie sogar von essentieller Bedeutung. Warum das so ist erschliesst sich bei einem Blick auf die drei wichtigsten dieser informellen Übereinkünfte, die zwar praktisch nirgendwo so festgehalten werden, aber fast überall die unausgesprochene Grundlage für eine Zusammenarbeit auf Augenhöhe bilden:

1. Wir, das Management, geben unseren Mitarbeitern das Recht sich selbst zu organisieren und wir, die Mitarbeiter, werden diese Freiheit nicht nutzen um gegen die Interessen der Firma zu arbeiten

Wer den Übergang von klassischer Unternehmensführung zu Scrum, Kanban, o.ä. schon einmal miterlebt hat kennt die Ängste des Managements. Werden selbstorganisierte Teams überhaupt noch ernsthaft arbeiten und wenn ja woran? Und was ist wenn das was die machen wollen überhaupt nicht zielführend ist? Diese Sorgen muss man ernstnehmen wenn man das Einverständnis der Managementebene zur agilen Transformation haben möchte. Dann ist aber auch viel möglich: sobald allen Beteiligten klar ist, dass es sich dabei um keinen grenzenlosen Freifahrtschein handelt sondern es auch Grenzen der Selbstorganisation geben muss sinkt die Hemmschwelle das zuzulassen deutlich. Und umgekehrt ist so auch jedem Mitarbeiter vermittelbar, dass Selbstbestimmung nicht in der Firmen-Insolvenz oder dem Bruch von Verträgen enden kann sondern schon vorher aufhört.

2. Wir, die Mitarbeiter, gewähren einen offenen Einblick in alle Arbeit die wir tun und wir, das Management, werden diese Transparenz nicht für Micro-Controlling und Micro-Management ausnutzen

Auch die Ängste von der Mitarbeiterseite gibt es. Wenn wir jeden einzelnen Tag zeigen womit wir gerade beschäftigt sind, wird dann nicht die Versuchung für "die Chefs" übermächtig, von oben auf Detailebene hineinzuregieren und "die Auslastung zu optimieren"? Endet das nicht in permanentem Rechtfertigungszwang für jeden Fehler und jeden Moment der Untätigkeit? Auch das muss ernst genommen werden, gerade vor dem Hintergrund, dass es in der Vergangenheit schon zu derartigen Kontroll- und Detailsteuerungs-Versuchen gekommen ist. Die Wahrheit ist aber auch, dass das in fast allen Fällen eher zu Selbstlähmung als zu Hochleistung geführt hat, was den meisten Managern auch bewusst ist, und weshalb sie Derartiges auch nicht anstreben. Wenn sie das glaubwürdig vermitteln können verliert die Transparenz ihren Schrecken.

3. Wir, Management und Mitarbeiter, sind uns bewusst, dass die verschiedenen Teile unseres Gesellschaftsvertrages sich gegenseitig bedingen und dass die Aufkündigung eines Teils immer auch den Rest ungültig macht

Man muss sich nichts vormachen, die Versuchung ist gross, denjenigen Teil der gegenseitigen Abmachung der einen selbst bindet zeitweise aufheben zu wollen "wenn es dringend ist" oder "wenn es ein wichtiges Thema ist". Das ist menschlich, es ist aber nicht folgenlos. Ein sich betrogen fühlendes Management wird sofort Teile der Selbstorganisation abschaffen und eine sich ausgenutzt fühlende Belegschaft wird Transparenz fortan nur noch simulieren statt sie wirklich zu bieten. Und da alle sozialen Gruppen über ein kollektives Gedächtnis verfügen darf auch niemand darauf hoffen, dass solche "Ausrutscher" in Vergessenheit geraten. Vertrauen ist sehr schnell verspielt und lässt sich dann nur sehr schwer wieder herstellen.

Wie oben gesagt, ausformuliert und aufgeschrieben findet man diesen Vertrag in praktisch keiner OHG, GmbH, AG oder UG, dort wo selbstorganisierte Teams samt der damit verbundenen Vorteile (Flexibilität, Bürokratieabbau, etc.) Zielbild der Organisation sind wird er aber immer implizit in den Köpfen der Menschen vorhanden sein. Vermutlich wäre es eine spannende Idee daraus etwas Explizites zu machen, eben durch Ausformulieren und Aufschreiben. Sichtbar auf eine Wand geschrieben dürfte es jedenfalls deutlich wirksamer sein als alle "Firmenwerte" und "-missionen" zusammen.

Dienstag, 2. Juni 2020

Eine kleine Typologie der Software-Architekten


Ein guter Vortrag, und das aus mehreren Gründen: zum einen hilft er dabei "den Software-Architekten, das unbekannte Wesen" besser zu verstehen, zum anderen wegen der Parallelen zu anderen Berufen. Ggf. bietet sich irgendwann man eine kleine Typologie der Scrum Master und Agile Coaches an.