Donnerstag, 15. Februar 2018

Story Points, nicht Requirement Points

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

Fraktale Skalierung (Scrum@Scale)

FS
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

FS
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

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

Powered by Blogger.