Donnerstag, 9. Juli 2020

Sprint Backlogs

FS
Bild: Pexels / Bruno Bueno - CC0 1.0
Das Sprint Backlog ist ein kleines Mysterium. Eigentlich ist es ein so zentraler Teil von Scrum (und ähnlichen Ansätzen), dass jeder der schon einmal mit diesem Framework gearbeitet hat es kennen sollte, andererseits dürfte man aber bei den meisten Teams eher Ratlosigkeit verursachen wenn man danach fragt. Bestenfalls kommt irgendwann die Erkenntnis, dass das die Arbeit ist "die man in den Sprint zieht". Das ist auch nicht falsch, aber auch nicht ganz richtig. Es ist mehr als nur das.

Um mit dem Offensichtlichsten zu beginnen: genau wie im Fall des Product Backlog hat auch das Sprint Backlog im Englischen eine Bedeutung die sich problemlos ins Deutsche übersetzen lässt. Es ist das Backlog des Sprints, also der Rückstau (→ Backlog) unerledigter Arbeit, der während des nächsten Umsetzung-Zeitraums (→ Sprint) abgearbeitet werden muss. Das klingt zunächst banal, hat bei näherer Betrachtung aber Folgen, und zwar sowohl in Bezug auf die Größe als auch in Bezug auf die Darstellung.

Beginnen wir mit der Grösse. Um im nächsten Sprint abgearbeitet werden zu können darf der Rückstau nicht grösser sein als die Arbeitskapazität des Team in dieser Zeit. Auch das klingt banal, hat aber weitreichende Implikationen. Es verhindert, dass Wunschlisten undefinierbarer oder ausufernder Grösse in die Umsetzung gegeben werden und erzwingt eine Reduzierung auf das Wesentliche, da ja am Sprintende ein benutzbares Ergebnis stehen soll. Das gilt zwar theoretisch auch im klassischen Projektmanagement, in dessen grossen Releaseplanungen fällt "die eine zusätzliche Anforderung" aber oft nicht auf. Die maximal vierwöchigen Sprints erzwingen eine wesentlich grössere Disziplin.

Nun zur Darstellung. Selbst wenn Teams den Begriff des Sprint Backlogs kennen verwechseln sie ihn häufig mit der Summe aller Arbeit die im Sprint ist. Auch hier hilft eine Erinnerung an die Übersetzung: der Rückstau (→ Backlog) ist eben nicht "alles auf dem Board" sondern lediglich das was noch unberührt auf seine Erledigung wartet. Vereinfacht gesagt könnte man demnach alles was noch im To Do-Bereich ist als das Backlog bezeichnen, oder noch stärker vereinfacht - das Sprint Backlog ist der linke Teil des Boards.


Zusammengenommen ergibt sich aus diesen beiden Aspekten noch ein dritter, nämlich der der Planbarkeit, bzw. Prognostizierbarkeit. Da von einem Sprint mit fortschreitender Zeit immer weniger Tage übrigbleiben muss zwangsläufig auch das Backlog immer weiter schrumpfen wenn es noch umsetzbar bleiben soll. Das kann entweder dadurch passieren, dass nach und nach immer mehr Arbeit erledigt (und damit aus dem Rückstau/Backlog entfernt) wird, es kann aber auch heissen, dass Aufgaben wieder aus dem Sprint herausgenommen werden müssen1 um ihn wieder erfolgreich abschliessbar zu machen.

Wer schon einmal in komplexen Entwicklungsprojekten gearbeitet hat dürfte mittlerweile ahnen, dass ein Sprint Backlog durchaus anspruchsvoll zu erstellen ist. Es soll in wenigen Wochen umsetzbar sein, ein brauchbares Ergebnis erzeugen, schrittweise abzuarbeiten sein und eine im Zweifel modifizierbare Grösse haben? Wie soll das gehen? Die kurze Antwort: durch schlankes, flexibles, ergebnisorientiertes und in Kommunikation eingebettetes Formulieren von Anforderungen. Mögliche lange Antworten stehen hier, hier, hier und hier.


1Bei einer korrekten Umsetzung von Scrum nur so, dass das Sprintziel erreichbar bleibt. Geht das nicht sollte der Sprint abgebrochen werden.

Montag, 6. Juli 2020

Fewer things, more done

FS
Dass auch Konferenzen jetzt remote stattfinden scheint den Nebeneffekt zu haben, dass die Vorträge kürzer werden. Statt der vorher meistens üblichen Stunde redet Randy Shoup hier nur knapp zwanzig Minuten zum Thema Agile at Scale - und das ohne dass es gehetzt und unvollständig wirkt.



Angesichts der Länge und des Themas ein guter Kandidat um es dem eigenen Management zu empfehlen, denn so selbstverständlich die Inhalte (Crossfunktionale Teams, kurze Lieferzyklen, psychologische Sicherheit) einem Agile Coach auch erscheinen mögen - für die meisten Firmen sind sie noch immer revolutionär,

Freitag, 3. Juli 2020

Die vier Varianten der agilen Hardware-Produktentwicklung

FS

Bild: Wikimedia Commons / Jonathan Juursema - CC BY-SA 3.0

Das Thema der Agilität im Hardware-Bereich hat leicht mythische Züge. Obwohl es sich um die älteste Variante der agilen Produktentwicklung handelt (dazu gleich mehr) gibt es in der von Softwareentwicklung und Organisationsentwicklung geprägten Community kaum jemanden der schon einmal daran beteiligt gewesen wäre. Die Folge ist die erwähnte Mythologisierung: irgendwie geht es, irgendwo findet es bereits statt, irgendwie ist es aber unklar wie es gehen soll. Die Wahrheit ist dabei viel profaner - ganz im Sinn der alten Erkenntnis, dass Agilität einfach zu verstehen aber schwer umzusetzen ist, sind die wesentlichen Erscheinungsformen der agilen Hardware-Herstellung einfach zu beschreiben - und schon oft beschrieben worden.

Prototyping

Die gerade erwähnte älteste Erscheinungsform agiler Produktentwicklung überhaupt. Bereits 1986 beschrieben Hirotaka Takeuchi und Ikujiro Nonaka in ihrem bahnbrechenden Artikel The New New Product Development Game wie crossfunktionale, selbstorganisierte, End to End-verantwortliche Teams bei Canon, NEC, Xerox und Honda in kurzen Zyklen neue Produkte entwickelten - Foto-Apparate, Computer, Kopierer und Autos. Wichtig ist in diesem Fall, dass es sich noch nicht um Serienfertigung handelte sondern um die Erstellung von Prototypen oder Vorserien-Modellen, deren Neuartigkeit und geringe Stückzahl den relativ hohen Handarbeits- und Abstimmungsaufwand nötig (und vertretbar) machte. Vergleichbare Vorgehensweisen gibt es in frühen Produktentwicklungsphasen bis heute.

Computer-aided Design

Ein anderer Ansatz um möglichst früh zu benutzbaren Ergebnissen zu kommen. Basierend auf den Erfahrungen der Vergangenheit werden neue Ideen durch eine IT-gestützte Machbarkeitsanalyse geschickt. Das ersetzt natürlich nicht die menschliche Kreativität (und das soll es auch nicht), es ermöglicht aber ein "fail fast, learn fast, try again" in sehr kurzen Zyklen. Wenn die Berechnungen z.B. zeigen, dass das Material eines Bauteils einer angedachten Belastung nicht standhalten würde, dann kann man direkt mit der Entwicklung einer verbesserten zweiten Version beginnen ohne von der ersten auch nur einen Prototypen erstellt zu haben. Beeindruckend ist auch die Spannbreite der möglichen Einsätze, sie reicht vom Hausbau bis zum Turnschuh.

3D-Druck

Ein erster Ansatz um auch die serielle Fertigung flexibler und anpassungsfähiger zu machen. Obwohl der 3D-Druck zunächst wie eine blosse Fertigungs-Art wirkt (z.B. im Bild oben) ist das wesentliche Element auch hier die Verbindung mit der IT. Moderne 3D-Drucker können mit einer einzigen Fertigungsanlage praktisch jede statisch mögliche Form erstellen ohne dafür umgebaut werden zu müssen, nötig ist dafür nur noch das Einspielen einer neuen Bauvorlage. Auf diese Art können in kurzer Zeit alle nötigen Einzelteile selbst für komplizierte Maschinen gebaut werden, zum Beispiel für Flugzeuge. Und auch von denen kann dann jedes Einzelne nochmal individuell angepasst werden.

Modulare Montage

Ein anderer Ansatz für die serielle Fertigung, diesesmal einer der darauf aufbaut, dass die zusammenzubauenden Einzelteile zwar immer gleich sind, es aber möglich ist sie in unterschiedlichen zusammensetzungen zu kombinieren. Konkret geschieht das dadurch, dass die lineare Fertigungsstrasse abgelöst wird durch verschiedene automatisierte "Montage-Inseln", die von einem (das Fliessband ersetzenden) Montage-Roboter in unterschiedlicher Reihenfolge angefahren werden können. Auch hier ermöglicht eine IT-Steuerung schnelle individuelle Ergebnisse, ohne dass die Fertigungsanlage dafür umgebaut werden müsste.

Rocket Science

Wie oben gesagt, Hardware-Agilität ist einfach zu verstehen aber schwer umzusetzen, tatsächlich so schwer, dass man immer wieder hört, dass das Ganze nur in der Theorie möglich wäre. Das es sehr wohl geht zeigt ausgerechnet eine Firma deren Tätigkeit (die Raumfahrt) im Englischen sprichwörtlich für extrem schwierige Herausforderungen steht. SpaceX ist nicht das einzige, vermutlich aber das prominenteste Beispiel dafür, dass sogar alle vier Varianten der agilen Hardware-Produktentwicklung gleichzeitig einsetzbar sind. Und eine Schlusspointe wird auch möglich - wer Hardware-Agilität meistert kann nach den Sternen greifen.

Dienstag, 30. Juni 2020

Kommentierte Links (LXIII)

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

    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

FS
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

FS
Bild: Wikimedia Commons / Hunini - CC BY-SA 4.0
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.

Donnerstag, 18. Juni 2020

Endspurt, Design Sprint, Sprint

FS

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)

FS

Powered by Blogger.