Mittwoch, 28. Februar 2018

Kommentierte Links (XXXIV)

Bild: Pixabay / Bru-nO - Lizenz
  • 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)

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-kompatible Chief PO

[Edit: durch das Scrum Guide-Update 2020 wurde eine Aktualisierung dieses Absatzes nötig]
Gleichzeitig die Scrum-kompatibelste und die mit klassischem Managementverständnis am wenigsten kompatible Ausgestaltung. Auf der strategischen Ebene für die initiale Auswahl von Produkten und Produktzielen zuständig gibt ein Scrum-kompatibler Chief PO den eigentlichen Product Ownern lediglich ein abstraktes Ziel 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 im weiteren Verlauf nur Reflektion und Feedback möglich, keine Anweisung. Das erfordert von allen Beteiligten einen hohen Reifegrad und hohe Professionalität.

Der LeSS/Nexus-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 (gleiches gilt im ähnlichen Nexus-Framework). Dabei können in den Teams PO-ähnliche Rollen entstehen, allerdings ohne die damit verbundenen finalen Entscheidungskompetenzen. 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


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

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.

Donnerstag, 15. Februar 2018

Story Points, nicht Requirement Points

Bild: Freegreatpicture / Max Pixel - CC0 1.0
Es gibt im agilen Umfeld Themen die immer weitere Informationen preisgeben, je mehr man sich in sie vertieft. Story Points gehören auf jeden Fall dazu, mit ihnen kann man wesentlich mehr machen als es auf den ersten Blick scheint. Bevor es darum geht aber zunächst zum Grundsätzlichen: Story Points sind eine neutrale Schätzgröße, mit der man den Umsetzungsaufwand von Anforderungen schätzen kann ohne berücksichtigen zu müssen wer genau die Umsetzung vornehmen wird. Mehr dazu hier. Es bleibt allerdings eine Frage - warum dann der wunderliche Name? Wäre "Requirement Points" nicht passender?

Der Grund für die Benennung liegt darin, dass mit Story Points ursprünglich im Extreme Programming User Stories geschätzt wurden. Ein kurzer Exkurs: User Stories sind Anforderungen in einfacher Sprache, die (End)Anwender, Use Case und Business Value in einem Satz benennen. Mehr dazu hier. Diese exklusive Verwendung gibt es heute kaum noch, mit Story Points werden nicht mehr nur User Stories geschätzt sondern alle anderen Anforderungen genauso. Manche Teams nennen auch einfach jede Anforderung User Story, allerdings ist das dann nicht mehr das was damit beabsichtigt ist.

Um Missverständnissen vorzubeugen, Story Points als generische Schätzeinheit für alle Anforderungen zu verwenden ist nicht per se schlecht. Trotzdem kann es Sinn machen ihre Benutzung auf User Stories zu beschränken. Denn: wenn der (End)Benutzer derjenige ist für den Software gebaut wird, und wenn alles was er damit tun kann ein Use Case ist der sich mit User Stories abbilden lässt, dann kann (und sollte) man bei allem was keine User Story ist die Sinnfrage stellen.

Natürlich verfolgen auch "Nicht-User Stories" einen Zweck. Code wird bereinigt, Lastfähigkeit hergestellt, Architektur wird geradegezogen, Tests werden automatisiert und halbfertige Funktionen werden komplettiert. Der Punkt ist nur der - das kann man auch gleich machen, als Teil einer User Story die benutzbare Funktionalität liefert. Diese Tätigkeiten auf die lange Bank zu schieben ist nichts weiter als das Anhäufen organisatorischer Schulden, wodurch alles länger dauert und teurer wird.

Wenn also alles was dem Anwender Nutzen bringt als User Story formuliert werden kann, und wenn praktisch alle nichtfunktionalen Anforderungen in diesen User Stories unterkommen können, dann kann man auch sagen: User Stories sind das was Mehrwert liefern, der gesamte Rest ist Waste. Unsinnige Arbeit - oder die Folge unsinniger Arbeit.

Die Anwendung von Story Points nur auf User Stories bedeutet in diesem Fall, dass deren Durchschnittsmenge pro Sprint, die Velocity, nur Mehrwert erzeugende Arbeit anzeigt und den Rest ignoriert. Für Teams kann das sehr wertvoll sein. Ihre Velocity zeigt nicht mehr womit sie Zeit verbracht haben (🡢 Output) sondern womit sie Wert generiert haben (🡢 Outcome). Und mit dieser Erkenntnis können sie daran arbeiten den Output zu senken und den Outcome zu erhöhen.

Die Negativseite dieses Ansatzes ist natürlich, dass in Teams mit vielen "Nicht-User Stories" die Velocity nicht mehr beim Planen hilft. Allerdings - dort wo es viele organisatorische Schulden gibt ist Planung ohnehin nur eingeschränkt möglich, man bleibt zu häufig in den Spätfolgen der eigenen Versäumnisse hängen.

Montag, 12. Februar 2018

Scaled Agile: Scrum Inc veröffentlicht Scrum@Scale Guide

Bild: Wikimedia Commons / Richard Bartz - CC BY-SA 2.5
Die einfachsten und häufigsten Arten der Zusammenarbeit mehrerer Scrum Teams sind das so genannte Scrum of Scrums-Meeting (SoS) zur regelmässigen Absprache und die Einrichtung von Meta-Teams, in denen Delegierte der Einzelteams an übergreifenden Zielen arbeiten. Wie die Zusammenarbeit in SoS und Meta-Teams genau aussieht schwankt von Fall zu Fall, genau wie die Frage wie sie in die umgebende Organisation eingebettet werden. Jeff Sutherland (einer der Gründer von Scrum) versucht zwar seit einiger Zeit unter dem Namen "Scrum@Scale" die Begriffsverwendung zu strukturieren, allerdings ohne daraus ein schriftliches Regelwerk zu machen. Bis jetzt.

Vor wenigen Tagen hat Scrum Inc. (Sutherlands Firma) erstmals einen Scrum@Scale-Guide veröffentlicht, in dem die Begriffe klarer definiert werden als bisher. Der ist zwar kein offizieller Teil von Scrum, genau wie das Nexus-Framework des anderen Scrum-Gründers Ken Schwaber hat er aber allein durch seinen Urheber eine gewisse Autorität. Und mit der definiert er Folgendes:

Separate Skalierung für Scrum Master und Product Owner

Das Scrum of Scrums wird nicht mehr nur als Meeting verstanden sondern als Organisationsform, in der die Scrum Master der Teams gemeinsam an der Beseitigung organisatorischer Blocker und Hindernisse arbeiten. In großen Organisationen kann es mehrere davon geben, die sich dann wiederum in einem "Scrum of Scrums of Scrums" (SoSoS) koordinieren. Gespiegelt dazu gibt es eine vergleichbare Organisation der Product Owner, die MetaScrum-Teams (die auch auf weiteren Ebenen so heißen, Meta-MetaScrum-Teams gibt es nicht). Die jeweils höchste Skalierungsebene heisst "Executive Meta Scrum" für die POs und "Executive Action Team" für die Scrum Master. Diesen beiden Teams können ggf. die selben Personen angehören.

Fraktaler Aufbau

Auf jeder Ebene sind die Scrums of Scrums und MetaScrums als Scrum Teams organisiert, mit Sprints, Backlogs, Scrum-Events, Scrum Mastern und Product Ownern. Diese Rollen können von Mitgliedern der beteiligten Teams übernommen werden, ggf. aber auch Vollzeitstellen sein. Bei den POs wird hier der Begriff des Chief Product Owner (CPO) übernommen, allerdings mit unklaren Kompetenzen: er soll den POs keine User Stories vorgeben, aber trotzdem ein übergreifendes Backlog verantworten und priorisieren. Um eine Verwirrung um den Begriff "Scrum of Scrums" zu vermeiden bezeichnet er nur noch die Teams, die Meetings werden in "Scaled Daily Scrum" umbenannt.

Querschnittsteams

So genannte "Knowledge & Infrastructure Teams" können gebildet werden wenn es von bestimmten Spezialisten nicht genug gibt um sie in jedes Team zu setzen. Sie sollen weiterhin in ihren eigentlichen Scrum Teams bleiben, bilden aber zusätzlich dazu ein "virtuelles Scrum Team", das Aufgaben für die gesamte Organisation wahrnimmt.

Jedes Team ist ein Scrum Team, auch ausserhalb der Produktentwicklung

In einzelnen Fällen kann es Spezialisierungen geben die so stark von den Tätigkeiten der anderen Teams abweichen, dass sie nicht in die oben genannten Strukturen integriert werden können. Als Beispiele werden Customer Relations, Legal, Compliance und HR genannt. Auch diese Teams sollen nach Scrum organisiert sein.

---

So weit, so gut ...

Was man diesem Ansatz lassen muss ist, dass er unternehmensweites Scrum konsequenter umsetzt als jeder andere. Gleichzeitig lässt er aber auch bewusst Lücken: das Verhältnis von Product Owner und Chief Product Owner ist nicht genau geklärt, die Entstehung übergreifender Architekturen, Coding- und Dokumentationsstandards wird nicht angesprochen und die Mehrfachbelastung durch Mitarbeit in mehreren Ebenen wird nicht thematisiert. Die empfohlene Lösung für derartige Punkte ist ein so genanntes "Referenzmodell", mit dem jede Organisation ihren eigenen Weg definieren und für sich verbindlich machen soll. Es wäre spannend zu sehen wie diese Fragen in der täglichen Zusammenarbeit einer Scrum@Scale-Implementierung gelöst werden.

Donnerstag, 8. Februar 2018

Pinball in Progress

Bild: Wikimedia Commons / Michael Moore - CC BY-SA 3.0
Die besten Inspirationen kommen oft unerwartet. Die letzten Tage habe ich auf einem Kanban-Workshop mit Klaus Leopold verbracht und dabei einen anderen Teilnehmer kennengelernt der größte Schwierigkeiten hatte sein Kanban-System zu modellieren. Der Grund: starke Abhängigkeiten zu anderen Teams (sowohl fachlich als auch technisch) sowie eine übergriffige und erratische Unternehmenskultur sorgen dafür, dass in seinem Arbeitsalltag ständig unvorhersehbare Störungen auftreten und sich kein stabiler Arbeitsstrom herausbilden kann. Auf dem Board lässt sich deswegen lediglich eine große "In Progress"-Spalte erstellen, deren Arbeit sich fast jeden Tag anders gestaltet.

Die Beschreibung dieser Situation erinnerte mich stark an die im Inneren eines Pinball-Automaten. Auch in dem gibt es einen Eingang und einen Ausgang durch die Objekte (in diesem Fall Kugeln) das System betreten und verlassen. Aber: zwischen Ein- und Ausgang gibt es verschiedene blockierende Elemente, von denen die durchlaufenden Objekte abprallen können. Passiert das verändern sie auf unkontrollierbare Weise ihren Kurs und sind nur mit Mühe wieder in die richtige Richtung zu lenken. Genau derartige Bedingungen machten das Modellieren des Systems derartig schwierig. Nun zur Inspiration: könnte man die Analogie dafür nutzen ein Board im Pinball-Stil zu designen? Ein spontaner Erstentwurf sieht so aus:


Wie man sieht: aus der Work in Progress-Spalte wurde die "Pinball in Progress-Spalte", die mit Flippern (unten), schmalem Ausgang (oben) und Abprall-Körpern (rund und dreieckig) wie das Innere eines Pinball-Automaten gestaltet ist. Die Arbeitspakete (Post Its) fliessen durch den "Automaten" durch. So weit, so gut, nur - wozu das Ganze? Aus zwei Gründen. Zum einen wäre das ungewöhnliche Board-Design durch seine Andersartigkeit ein Aufhänger für Gespräche. Ähnlich wie im Fall des Zombie-Cage würde es für Aufmerksamkeit, Konversation und Problembewusstsein sorgen. Zum anderen würde das Kanban-Board gleichzeitig zu einem Impediment-Board. Die Abprallkörper symbolisieren schliesslich nichts anderes als organisatorische Impediments. Und da sie sich by Design bereits im In Progress-Bereich befinden kann gleich an ihrer Behebung gearbeitet werden. Die Anzahl dieser Elemente zeigt damit auch die Störanfälligkeit des Systems an.

Ist noch nicht ganz ausgereift, hat aber Potential. Jetzt muss ich nur noch ein Team überreden so etwas aufzubauen. Konstellationen in denen so etwas Sinn bringen könnte gibt es ja leider zur Genüge.

Montag, 5. Februar 2018

Continuous Delivery Excuses Debunked

Eine schöne Übersicht über Ausreden und deren Widerlegungen zum Thema Continuous Delivery. Wer die einleitende Erläuterung was Continuous Delivery ist überspringen will kann ab Minute 13.50 einsteigen.