Die User Story als Einladung zu einer Diskussion

Viele meiner Kunden fragen, wie viele Anforderungen eine User Story beinhalten sollte und wo denn die „anderen“ Anforderungen abgespeichert werden sollen.
Diese Frage ist meiner Meinung nach ein Widerspruch in sich. Denn eine User Story besteht ja nicht nur aus dem berühmten Satz „Als <Rolle> möchte ich <Funktion>, um <Nutzen> zu haben“, sondern enthält einiges mehr an Informationen.
Zunächst mal: Was braucht man, um ein Produkt zu entwickeln? Natürlich das Wissen darüber, wie dieses Produkt am Ende aussehen soll. Was *braucht* der User? Was *will* der User? Was sind die Rahmenbedingungen (Budget/Ressourcen, Gesetze etc.)?
Um all diese Fragen zu beantworten, sollte also eine User Story diese Informationen beinhalten:

Wie umfassend soll diese „Dokumentation“ sein? Ich beobachte, wie lange mein Team beim Refinement darüber geredet hat – das ist mein Richtwert. Denn das ist genau das, was in diesem Meeting passieren soll: darüber reden. So lange bis jeder weiß, was diese Funktionalität können muss.
Jetzt werden viele sagen: „Wir arbeiten ja nur mit Kärtchen, da passt das alles nicht drauf.“ Das ist schon richtig. Es spricht allerdings nichts dagegen, zusätzlich zum Kärtchen auch andere Medien zu verwenden, die separat geführt werden. Ein Flipchart reicht oft völlig aus.
Wie sieht bei Ihnen eine User Story aus?

Strategie und Wettervorhersage: der Wunsch nach der Einschränkung von Möglichkeiten

Erst neulich saß ich abends mit dem Manager eines Kunden zusammen, um ein Managementmeeting vorzubereiten. Er ist wohl einer der innovativsten Köpfe seines Unternehmens, agil im Handeln und Mindset. Klar in der Kommunikation, gewitzt im Manövrieren durch die im Umbruch befindlichen Hierarchien und Schwärme seines Konzerns. Als wir über Strategie sprechen, erzählt er mir begeistert von seinem Chef. Der würde mit einer klaren Strategie und überzeugenden Ansagen genau zeigen, wo es langgehe. Für mich hörte sich das im ersten Schritt wie ein Widerhall aus der Vergangenheit an.
Die Strategie im Sinne einer strategischen Planung ist hier am Werk. Strategie, Handlungsfelder, Aktionen, geplante Ergebnisse, Ziele, Zeitleisten und Fortschrittsmonitoring. Kurz denke ich mir: „Huch, was ist denn hier los? Wie passen Mindset und Handeln meines Gegenübers mit seiner Affinität zu dieser Form und Denke von Strategie zusammen?“ Nun, ich musste nicht lange warten. Die Antwort kam postwendend: „Da gibt es Klarheit und Richtung. Mag ich das, wie das daherkommt? Nicht immer. Aber das, was es tut schon. Wir haben Richtung und die Dinge entwickeln sich. Trotz der unsicheren und sehr veränderlichen Umwelt.“  Und das sei, so meinte mein Gegenüber, auch notwendig. Es sei besser als so manch andere, vage und nur „highlevel“ dargestellten Strategieansätze, die er jüngst in anderen Kontexten kennengelernt habe. Dann wendete er sich an mich: „Du hast mir die Frage nach der Strategie gestellt. Ganz ehrlich. Eigentlich müsstest Du uns sagen, wie es geht. Was eine Strategie braucht.“

Strategiearbeit: Die Suche nach Sicherheit

Dieses Gespräch geht mir nach. Erst jüngst hatte ich einen Strategieprozess entlang des Golden Circle von Simon Sinek geführt, einen reflexiven Diskurs über die Gesamtorganisation meines Kunden. Ein Strategieteam aus Freiwilligen hatte die Vorarbeiten gemacht und war mit Denkanstößen und Fragestellungen in die Organisation gegangen. Zuerst hatten wir uns die umgebende Rahmenstrategie auf Unternehmens- bzw. Divisionsebene angesehen. Dann haben wir unser „WHY“ erarbeitet, das „HOW“ beleuchtet und zum Schluss im „WHAT“ die Handlungsfelder herausgearbeitet, die nun mit Zielen und Roadmaps in drei Fristigkeiten beantwortet wurden. Das Ganze in wiederholten Reflexionsschleifen mit Kollegen, Managementlevels und Peers. In einer Townhall.
Was verbindet die Schilderungen meines Gesprächspartners mit den Erfahrungen aus dem oben geschilderten Prozess? Auch in der Reflexionsarbeit kam wiederholt das Anliegen zum Vorschein, alle Aspekte möglichst zu reduzieren, zu vereinfachen – so dass sie für alle Mitarbeiter klar und umsetzbar wären. Es gab also den Wunsch nach einem Plan, den man befolgen und damit die Stärke der Ausführung ausspielen könnte.
Dieses Begehren an die Strategie ist wie jenes an die Wettervorhersage: Wie sicher können wir uns sein, dass das angenommene Szenario auch wirklich eintritt? Zu wie viel Prozent wird es Sonne geben oder der Schnee genau da fallen, wo wir ihn für die Winterferien brauchen? Wie können wir die Anzahl der möglichen Zukünfte einschränken, oder zumindest jener, die in ihren Attributen allzu unterschiedlich sind? Wie können wir Anzahl und Komplexität der möglichen Zukünfte reduzieren, um wirtschaftlich vertretbare Vorbereitungen – also strategisches Handeln – zielführend und erfolgssicher auszurichten?
Es geht immer um Sicherheit, die wir ausbauen wollen, für uns selbst und damit auch für unsere Unternehmen. Vielleicht halten Sie diesen Ansatz für unzulänglich. Dennoch möchte ich Sie einladen, mir in den nachfolgenden Vergleich zwischen Produktentwicklung und strategischer Führung zu folgen. Nach den folgenden Absätzen können Sie dann ja entscheiden, ob Sie diesem Gedanken eine Chance auf ein Experiment geben möchten.

Projektion der Vergangenheit oder Entwicklung mit den Gegebenheiten?

In der Produktentwicklung haben wir über viele Jahrzehnte immer ausgeklügeltere Verfahren entwickelt: Über Vorprojekte, Research und Analysen werden die Anforderungen an ein künftiges Produkt gesammelt, verschriftlicht, organisiert und gemanagt. Umfangreiche Sondierungs- und Erforschungsprozesse, die in voluminösen, präzisen und detaillierten Beschreibungen endeten – den Product Requirements. Auf dieser Basis wurde dann die Produktentwicklung geplant und ausgeführt. Die Planabweichungen und Learnings aus der Realisierung haben dann Eingang in das so genannte Change Management gefunden. In Kürze: Lang laufende Konversationen und Erkenntnisprozesse, die in einem Dokument resultierten.
Anders in der agilen Produktentwicklung. Ausgangspunkt ist die Produktvision – der Leitstern für eine Produktidee. Bereits die Idee wird mit Anwendern und Kunden verprobt. Über Prototypen und Minimum Viable Products werden die Akzeptanz und Tauglichkeit erster Produktansätze untersucht und das Produkt dann über eine Liste an Features (User Stories im Backlog) grob skizziert. Jede Beschreibung passt auf eine Karte im Format A5 und umfasst gerade mal einen Satz: „Als Nutzer möchte ich folgende Funktionalität, um daraus folgenden Nutzen zu erhalten.“ Dazu noch ein paar Constraints – das war es. Unmöglich für ein Team, damit schon loszulegen. Aber genug, um zu verstehen, worum es bei einem Produkt geht.
Sukzessive nehmen Teams und Product Owner die User Stories unter die Lupe und besprechen sie, entwickeln dabei das Kontextverständnis weiter und auch die User Story selbst – je nachdem, wie sie diese verstehen und den Möglichkeitsraum in jeder einzelnen erkunden. Dann wird gebaut – in kurzen Zyklen und mit viel Reflexion. Entlang des Erkenntnisgewinns aus der Realisierung werden die weiteren User Stories konkretisiert und weiterentwickelt. Stück für Stück. Zur User Story heißt es: „Jede User Story ist ein Versprechen auf eine nachfolgende Konversation.“ Nicht das Artefakt „User Story“, sondern die dazugehörige Konversation ist der Schlüssel zur erfolgreichen Produktentwicklung. Den restlichen (Scrum)Prozess spare ich mir hier, er ist hinlänglich bekannt und beschrieben.

Die Entwicklung ist gleichzeitig der Rollout

So steht die klassische strategische Planung der agilen Strategieentwicklung gegenüber. Beide benötigen Artefakte und Prozesse. Für die agile Hemisphäre nehme ich in Anspruch, dass der Entwicklungsprozess gleichzeitig der Rollout-Prozess ist. Strategie als emergentes Kommunikationsgeflecht, das seine Wirkung im Hier und Jetzt entfaltet und die Komplexität möglicher Zukünfte über den Umgang damit im Heute managt. Emergent und reflexiv. Sicher keine Anleitung zum Weiterreichen, die einfach umgesetzt werden muss. Eine solchermaßen entwickelte und umgesetzte Strategie befähigt jedenfalls alle Organisationsteilnehmerinnen, den eigenen Beitrag entsprechend auszurichten.
Diese Sichtweise und Herangehensweise  mag nicht für alle Unternehmensformen und -kulturen gleichermaßen möglich sein. Für agile, selbstorganisierte Netzwerkplayer und Plattformbusinesses ist sie aber eine unverzichtbare Grundlage strategischer Arbeit.
Für diese Art der Herangehensweise benötigt es allerdings auch einige Zutaten:

Und natürlich die Inspiration, die wie in der biologischen Veredelung den inneren Reflexionsprozess positiv irritiert und die häufig um sich selbst kreisenden Reflexionsschleifen leicht aus der Bahn wirft, damit Neues entsteht und Emergenz ermöglicht wird. Diese Aufgabe – den Keim der Veränderung –finden wir im Kunden und Anwender. Also benetzen Sie Ihre Organisation immer wieder mit Kundenperspektiven, O-Tönen und echten Begegnungen.
Unsere möglichen Zukünfte sind wie das Wetter der Zukunft. Es wird regnen, die Sonne wird scheinen, Nebel wird unsere Sicht eintrüben. Eis und Glätte werden Wärme und Hitze weichen. Das alles in überschaubarer, mit Wahrscheinlichkeiten zu versehender Gewissheit. Eines aber ist sicher: Wir werden glückliche Momente erleben. Wir werden erfolgreich sein. Wir werden bestehen.

Scrum – eigentlich so einfach wie kochen

Einzelne Teams, inzwischen aber auch ganze Unternehmen stellen sich die Frage: Wie können wir uns angesichts sich ständig verändernder Marktbedingungen so aufstellen, dass wir unsere Anpassungsfähigkeit erhöhen und gleichzeitig schneller in der Umsetzung werden? Sicher: Auf diese Frage gibt es viele mögliche Antworten und ganz sicher gibt es nicht das eine Rezept. Eine Antwort ist, die Haltung und Methoden von Scrum für sich zu entdecken und anzuwenden.
Oft erleben wir viele Hemmungen, wenn Menschen zum ersten Mal von Scrum hören und es für sich und ihren Kontext anwenden sollen. Deshalb wollen wir das Thema einmal aus einer anderen Perspektive betrachten und es mit dem Kochen vergleichen. Stellt euch vor, ein Familienmitglied hat Geburtstag. Ihr wollt diesen Geburtstag bei euch Zuhause feiern und ein Festmahl zubereiten. So ähnlich ist es, wenn man den Scrum Flow für sich entdeckt und seinen Projekt-/Arbeitsalltag mit Leben füllt.

Mit Offenheit kocht es sich leichter

Eine wichtige Voraussetzung ist aus unserer Sicht die Haltung, beispielsweise die Offenheit für Experimente. Bezogen auf unser Menü bedeutet das, nicht zu lange zu überlegen, sondern bereit zu sein, einfach loszulegen. Sich darauf einzulassen, dass das Menü während des Kochens weiter Form annimmt. Natürlich kann man beliebig viel Zeit investieren, ein besonders kreatives Menü zusammenzustellen, doch lasst uns einfach mal damit beginnen!
Auf den Kontext der Organisation übertragen, bedeutet das eine neue Haltung in der Führung: sich beispielsweise gemeinsam mit den Mitköchen zu überlegen, was traue ich mir und meinen Mitköchen zu, die Aufgaben aufzuteilen und dann loszulassen. Es bedeutet, in die Selbstorganisationsfähigkeit des Teams zu vertrauen, in die Kollaboration über horizontale und vertikale Grenzen hinweg, damit das Essen gemeinsam gelingt. Welche Zutaten tragen wesentlich zum Gelingen bei?

Die Vision: Pasta oder Schweinshaxe?

Um den Geburtstag gebührend zu feiern, wollen wir unsere liebe Familie und die Freunde bekochen. Natürlich soll es etwas Besonderes geben. Wir haben es geradezu vor Augen: Das größte Festmahl aller Zeiten soll es werden! Ein rauschendes Fest, wie es die Welt noch nicht gesehen hat. Mit einem Leuchten in den Augen erzählen wir bei der Einladung von unserem Plan und sehen, wie geradezu der Funke überspringt. Alle freuen sich auf das anstehende Fest und bieten ihre Unterstützung an. Im Scrum-Kontext ist es der Product Owner, der diese Vision in ein Produkt verwandelt und emotional kommuniziert und dadurch das Team motiviert, voller Energie an der Umsetzung mitzuwirken.

Die Constraints: der Blick in den Kühlschrank

Wir stehen also in der Küche und haben die Vision eines opulenten Festmahls vor Augen. Ein Blick in den Kühlschrank holt uns zurück auf den Boden der Tatsachen. Er ist ziemlich leer. Es ist Monatsende und das Konto zeigt überdeutlich, dass ein Großeinkauf heute nicht mehr drin ist. Es gibt aber noch ein paar Dosen geschälte Tomaten und in der Vorratskammer findet sich eine Packung Nudeln. Etwas Knoblauch ist auch noch da, frische Chili-Schoten und Olivenöl. Leider ist der Backofen seit Wochen defekt, aber immerhin funktionieren die Herdplatten, im Schrank finden sich ein Topf und eine Pfanne. Mit diesen Rahmenbedingungen lässt sich zwar kein 10-Gänge-Menü zaubern, für eine große Portion Penne Arrabbiata dürfte es aber reichen. Zusammen mit der letzten Flasche von dem guten Rotwein ergibt es das bestmöglichste Gericht.
So ambitioniert eine Vision auch sein mag, kein Produkt und kein noch so leckeres Gericht ist frei von Einschränkungen und Rahmenbedingungen, eben den sogenannten „Constraints“. Im Kontext einer Produktentwicklung geben diese Rahmenbedingungen vor, wie die Vision umgesetzt werden kann. Wie groß ist das Budget? Wie viele Mitarbeiter können an einem Projekt arbeiten? Welche gesetzlichen Vorschriften müssen eingehalten werden? Was ist technisch überhaupt machbar?

Die Rollen: Verantwortung teilen – kochen im Team

Wie auch im Scrum Flow gibt es beim gemeinsamen Kochen zugewiesene Rollen. Diese Rollen sind klar voneinander abgegrenzt: Jeder der mitkocht, übernimmt eine bestimmte Arbeit. Im Scrum Flow gibt es die drei Kernrollen Scrum Master, Product Owner und Entwicklungsteam. In drei weiteren Rollen kommen noch Kunde, User und Management ins Spiel. Auch hier sind die Rollen klar voneinander abgegrenzt: Der Product Owner weiß genau, was er oder sie am Schluss vor sich stehen haben möchte. Er organisiert das Menü und ist dafür verantwortlich, dass jeder Koch im Team die benötigten Fähigkeiten hat, um das beste Menü auf den Tisch zu zaubern. Seine „Vision“ gibt er an die Mitköche weiter, die das Entwicklungsteam bilden. Sie kochen das Menü „tatsächlich“ und bringen es in eine Form. Ohne sie würde der Product Owner das Gericht nicht rechtzeitig zur Feier fertigbekommen.
Die Rolle des Scrum Masters kann in der Küche mit jemandem verglichen werden, der sich darum kümmert, dass jeder die Zutaten hat, um seine Arbeit schnellstmöglich auszuführen. Der Scrum Master sorgt auch dafür, dass das Team ohne Probleme und Einschränkungen kochen kann, indem zum Beispiel Geschirr abgewaschen oder Abfälle entsorgt werden. Um den Scrum Flow zu vollenden, benötigen wir noch Kunde, User und Management. Im unserem Fall ist das Geburtstagskind Kunde und User. Es gibt im Vorfeld an, welche Wünsche es hat (oder das Kochteam weiß das aus vergangenen Beobachtungen), und genießt das Mahl im Anschluss an die Zubereitung. Der Manager finanziert das Geburtstagsessen, er hat nichts mit der Küche und dem Kochen zu tun. In unserem Fall könnte das der Vater des Geburtstagskindes sein.

Kochen und abschmecken: Selbstreflexion und Feedback-Loops

Lasst uns nun kochen. Um das Rezept bestmöglich umzusetzen, bietet sich ein gewisses Vorgehen an. Die taktische Ebene des Scrum Flow umfasst alle Meetings und ist mit den Anleitungen in einem Rezept vergleichbar. In diesen Anleitungen steht genau beschrieben, welche Schritte und welche Zutaten wann eingesetzt werden.
Starten wir mit dem Sprint Planning 1: In diesem Meeting überlegen wir uns, was das Festmahl beinhalten soll. Eventuell möchten wir mehrere Gänge zubereiten und entscheiden uns dafür, dass Kartoffelsuppe das Beste für den ersten Gang sei. Nachdem alle zugestimmt haben, überlegen wir uns, wie wir unseren ersten Gang umsetzen werden – vergleichbar mit dem Sprint Planning 2. Jeder Koch hat seine Aufgabe zugeteilt bekommen: Der eine wäscht die Kartoffeln, der andere schält die Kartoffeln, der Dritte schneidet sie klein und so weiter.
Nun ist das Vorgehen klar und alle Köche kommen ins Tun. Während der Zubereitung kann es Rücksprachen geben – im Scrum Flow spiegelt sich das in den Dailys wider. In diesem täglichen, rund 15 Minuten dauernden Standup-Meeting halten alle Köche kurze Rücksprachen zu den einzelnen Aufgaben. Ist die Suppe fertig, wird der Product Owner in die Küche gerufen, um zu probieren. Gefällt ihm die Kartoffelsuppe, wird sie an den Tisch gebracht und kann vom Geburtstagskind und den Gästen probiert und bewertet werden. Sind die Gäste und vor allem das Geburtstagskind zufrieden, hat die Kartoffelsuppe bestanden. Sollte es jemandem nicht schmecken, wird zum Beispiel mit weiteren Gewürzen nachgebessert – das geschieht im Rahmen des Scrum Flow mit Produkten nach dem Review. Nachdem die Kartoffelsuppe von den Genießern „abgenommen“ wurde, trifft sich das Team in der Küche und reflektiert die Zusammenarbeit, wie in einer Retrospektive.
Die Prinzipien und Vorgehensweisen von Scrum sind also eigentlich nichts Neues – sie werden in anderen Kontexten täglich praktiziert. Was vielleicht ungewohnt ist, ist die Anwendung dieser Prinzipien auf die Wissensarbeit. Fangen Sie doch einfach genau so an, wie wir es hier beschrieben haben: Legen Sie einfach los, machen Sie sich den Spaß und bereiten Sie mit Freunden ein Essen nach dem Ablauf des Scrum Flow zu. Guten Appetit!

Diesen Artikel haben Mara Ambs, Michael Gissler und Miruna Sachse im Mob-Writing gemeinsam verfasst.

Video: Level of Done

 
ScrumMaster und Manager in Organisationen müssen zwei Dinge im Auge behalten: den Level of Done und die Definition of Done. Der Level betrifft die Organisation, die Definition das Team. Wie das genau gemeint ist, erfahrt ihr in diesem Video.
Viel Spaß beim Anschauen
Boris
 

Agile Banking – die Zukunft?

Das Zinsumfeld ist herausfordernd, die Regulierungszyklen werden immer kürzer und junge Fintechs knabbern an den wenigen verbliebenen Profit-Bringern der Bankhäuser. Die Antwort der etablierten Bankenwelt: Start-up-Mentalität und Agilität – eine Art Verjüngungskur für die Veteranen. Doch warum sind es genau diese zwei Zutaten, die in Zukunft den großen Erfolg bringen sollen? Für die Vorbereitung eines Vortrags habe ich mir diese zwei Fragen mit Jakob Etzel gestellt, der mit Partnern sein eigenes Fintech “predictr” gegründet hat. Aber der Reihe nach.
Start-Ups sind Vorbild für alle großen Konzerne, wie unlängst einmal mehr die Tageszeitung “Die Welt” feststellte (“Silicon Valley ist der Ballermann der Tech-Szene”). Was ist das Magische an diesen Organisationen? Viele der ehemaligen Start-ups sind bei weitem nicht mehr so klein, dass behauptet werden kann, es liege an der geringeren Größe und den damit einhergehenden Vorteilen. Klar, die schlankeren Strukturen schaffen einen Vorteil, aber viel wesentlicher ist, dass Start-ups die Agilität in ihrer DNA haben. Sie müssen in der Regel immer schnell Lösungen entwickeln, um erstens zu überleben und zweitens die nächste Finanzierungsrunde zu überstehen. Wichtig ist, als Start-up nicht der Verführung eines Shareholder-Ansatzes in neuen Kleidern zu erliegen und somit den Kunden bzw. die Lösung komplett außer Acht zu lassen. Das zeigt ein prominentes Beispiel der letzten Zeit: Theranos, ein Unternehmen, das seine bisherige Finanzierung auf einem großteils auf zweifelhaften Methoden basierenden Geschäftsmodell aufbaute und versuchte, die Investoren mit dem Wecken großer Erwartungen ohne wirkliche Substanz zufrieden zu stellen. Wir sollten jedoch nicht von einzelnen Beispielen auf die Gesamtheit schließen. In der Regel orientiert sich ein Großteil der Start-ups stringent an den Kunden, um ein möglichst ertragreiches Geschäftsmodell zu entwickeln. Das bedeutet auch, dass im Falle eines nicht maximal erfolgreichen Modells einfach flexibel weiter evaluiert wird, ob eine andere Variante des Modells oder ein gänzlich anderes nicht noch sinnvoller sein kann.

Methoden und Prinzipien sind überall einsetzbar

Dank des Sparrings und der Diskussion mit Jakob bin ich mir heute noch viel sicherer als zuvor: Viele der Ideen, die Start-ups verwenden, um flexibler zu sein, können tatsächlich auch problemlos in großen Unternehmen angewendet werden – wir schreiben immerhin das Jahr 2016. Methoden wie Design Thinking und Rapid Prototyping sind heute weit verbreitet und sollten zum Repertoire jeder Produktentwicklungsabteilung gehören. Das funktioniert in vielen Branchen: Werden im Mobile-Bereich Papier-Prototypen erstellt, so bedient man sich in der Hardware moderner 3D-Drucker oder eines speziellen Prototyping-Equipments. Was, wenn gar kein Produkt erstellt wird? Auch das ist kein Problem, der Kreativität sind keine Grenzen gesetzt. Die Bankfiliale der Zukunft? Mit Hilfe von Lego ist schnell ein Modell gebaut, das mit Hilfe von Passanten vor der Filiale getestet werden kann.
Agilität ist das zweite Mittel zum Erfolg. Auch hier zeigen diverse Transformationsvorhaben in Großbanken, dass diese Ambitionen durchaus ernst genommen werden. Die niederländische ING Bank hat es vorgemacht: Nach einem jahrelangem Veränderungsprozess hat sie nun eine Organisationsstruktur, in der einzelne Teams tatsächlich end-2-end verantwortlich sind – und das auch außerhalb der IT (siehe dazu das Video “Agile way of working at ING Netherlands”).

Die Bremsklötze

Doch was sind die großen Herausforderungen speziell im Bankenbereich? Ein wesentlicher Aspekt neben dem regulierten Umfeld sind sicher die Kernbankensysteme, die in der Regel bereits seit Jahrzehnten im Einsatz sind und alles andere als optimale Voraussetzungen für eine agile Entwicklung bieten. Diese Tatsache bremst die Innovation. Die IT hindert das Business, neue und bessere Produkte auf den Markt zu bringen, und das nur, um die Altsysteme nicht weiter zu belasten. Die gute Nachricht ist: Es gibt Auswege und Strategien, um diese Monolithen mit Hilfe moderner Softwarearchitekturen wie Microservices schrittweise und in vielen kleinen Iterationen abzulösen und so einer flexibleren Zukunft entgegen zu gehen.
Eine weitere Herausforderung ist die Verbindung der analogen und digitalen Kanäle: offline in der Filiale und am Schalter und online in den unzähligen Finanzportalen und Apps. Hier sind nicht nur neue Systeme nötig, sondern auch grundlegende Veränderungen in den Strategien, um diese zwei Welten in Einklang zu bringen. Das e-Commerce-Business hat es erfolgreich vorgemacht; es gibt zahlreiche gute und vor allem funktionierende Multi-Channel-Konzepte.
Ich denke, dass sich der Weg der Reise hin zu einer agileren Bank lohnt. Mit Hilfe der agilen Werte und Methoden wie Scrum und Kanban können bei richtigem Einsatz viele der erhofften Vorteile – insbesondere die Nähe zum Kunden, die kürzere Time-to-Market und eine flexiblere Releaseplanung – erzielt werden. Tatsache ist, dass die Reise anstrengend wird und viele alte Denkmuster durchbrochen werden müssen. Auch müssen wir uns von den Rucksäcken der Vergangenheit befreien und wenn notwendig, alte Relikte entsorgen, um Neues entstehen lassen zu können – auch wenn das vielleicht das Ende des Kernbankensystems in seiner bisherigen Form bedeuten mag.

Von User Experience Design, Agilität und Personas

Im Rahmen des World Usability Days und der vom Beratungsunternehmen USECON organisierten Konferenz „Return on Experience“ durfte ich einen Vortrag über den Zusammenhang zwischen User Experience Design und agilem Arbeiten halten. Zu allererst: Was ist User Experience eigentlich genau? So wie viele andere Begrifflichkeiten wird auch “User Experience” oft ungenau verwendet. Im Wesentlichen bezeichnet es die Gesamtheit der Erfahrungen, die ein Anwender mit einem Produkt oder einer Dienstleistung macht. Ziel des User Experience Design ist es, ein Produkt oder eine Dienstleistung so zu gestalten, dass die positive Erfahrung maximiert wird und negative Aspekte wie Frustration etc. vermieden werden. Somit spannt sich User Experience Design von der Gestaltung von Bildschirmmasken bis hin zum zielgerichteten Auslösen von Emotionen während der Produktnutzung.
Doch was hat das Ganze jetzt mit agilem Arbeiten zu tun?
Wenn wir uns die Ideen rund um Scrum 3.0 näher ansehen, erkennen wir, dass der User heute noch viel stärker in den Mittelpunkt rückt. Innovationsmethoden wie Design Thinking gehen ebenfalls diesen Weg und orientieren ihre gesamte Prozessmethodik ausschließlich am Endanwender. Die logische Konsequenz: Kompetenzen wie User Experience Design werden zu einer zentralen Fähigkeit von Scrum-Teams. Sie benötigen daher nicht nur einen User Experience Designer im Team, sondern müssen diese Kompetenz breiter integrieren – User Experience muss jeden im Team etwas angehen!
Die Grenzen zwischen Agilität und User Experience Design verschmelzen besonders stark bei der ganzheitlichen Integration von Personas in den Entwicklungsprozess. Personas sind fiktive Endanwender. Sie werden im Rahmen der Entwicklung modelliert, um sich besser in die Lebenswelt der künftigen User einfühlen zu können. Personas werden meist mit einem kleinen Lebenslauf versehen, um sie so real wie möglich zu gestalten. Sinn und Zweck ist es, jede User Story mit einer Persona als Rolle zu versehen. Welche Funktionalität braucht diese Persona genau? Und wie muss diese Funktionalität nutzbar sein, um die Persona zu begeistern?

Ein Beispiel aus dem Online Banking:
Ein Digital Native (20 Jahre, Student) stellt ganz andere Ansprüche an eine Überweisung als ein typischer Filialkunde (65 Jahre, Rentner). Ein „Heavy Trader“ hat an das Wertpapier-Depot völlig andere Anforderungen als der Durchschnittsbürger, der mit Wertpapieren für eine Zusatzrente spart.
So schaffen Personas die Brücke zwischen User Experience Design und User Storys. Mit Hilfe der Persona an jeder User Story kann sich das Team in die potentiellen Anwender hineinversetzen und so die optimale Lösung/Experience für jeden Anwender-Typ designen. Für Product Owner bieten Personas zudem die Möglichkeit, eine zusätzliche Achse der Priorisierung einzubeziehen. Funktionen, die hochprofitable Kunden (wie z.B. Heavy-Trader) überdurchschnittlich nutzen würden, wären eventuell priorisierter zu betrachten als andere.
Doch Personas können noch weit holistischer als in User Storys verwendet werden. Auf einem höheren Level können sie auch in Customer Journeys verwendet werden. In Customer Journeys wird analysiert, wie bestimmte Personas mit dem Unternehmen in Berührung kommen, um dessen Produkte zu kaufen oder Dienstleistungen in Anspruch zu nehmen. Hier können wertvolle Inputs für das Design der User Experience und in weiterer Folge für die Entwicklung generiert werden. Wie sieht ihre Customer Journey aus? Ist es ein Erlebnis aus einem Guss oder eine beschwerliche Reise mit vielen Hindernissen?

Um den Kreis der Personas nach User Storys und Customer Journeys zu schließen, sollten in weiterer Folge die tatsächlichen Anwender, die die Produkte oder Dienstleistungen verproben, anhand dieser Personas ausgewählt werden. So können die verschiedenen Hypothesen, die auf Basis der Personas erstellt wurden, an realen Beispielen verifiziert werden. Dieser gesamtintegrative Ansatz stellt sicher, dass die Entwicklung zentral am User und dessen Vertreter in Form der Personas ausrichtet ist.
In Zeiten der Digitalisierung wird User Experience zunehmend an Stellenwert gewinnen – gerade in agilen Teams, die an den Innovationen von morgen arbeiten. Bereiten wir dieser Entwicklung den Boden und forcieren wir ein breites User Experience Wissen in unseren Teams, um diesen neuen Anforderungen zu begegnen.

Magic portfolio prioritization – the Magic Matrix Technique

Whenever I work together with clients in a scaled agile organization, prioritization across the borders of a team or even across large business units is perceived as most challenging by the participating Product Owners, Managers or Shareholders. One of the reasons for this perception is the fact that a common method for prioritization is often missing and thus urgently needed.
In this blog post I want to introduce to you the Magic Matrix Technique that my colleague Karl Bredemeyer and I designed for a large workshop a long time ago. With the Magic Matrix Technique you can prioritize cross-organizational projects and create a unique company backlog that lists all projects of a company in a discrete order. We have used this technique very often since then and it always proofed its value.
The technique is called Magic Matrix just because the client for whom we designed the workshop called it that way after the workshop was over.
It is basically a good combination of the Magic Estimation game invented by Boris Gloger, the Prioritization Matrix invented by Donald Reinertsen, and some facilitation. This technique is very generic and can be used for almost every prioritization approach. That’s why some Product Owners I worked with use it to prioritize their user stories in their product backlog as well.

Initial situation

Let me introduce you to the challenge this client faced that day. Based on a management consulting intervention that we had done before a group of shareholders, c-level executives and top managers from ‘business‘ (e.g. marketing, customer care), ‘technology‘ (e.g. directors of tech, lead architects) and ‘legal‘ for the first time in the history of that company aimed to establish a common company backlog to avoid prioritization conflicts in the development teams. These prioritization conflicts had led to avoidable context switches, multitasking within product development, and thus to poor output of their delivery flow.
All the people named above attended an offsite workshop to bring all the important projects into a discrete order and to consequently allow the different development teams to pull work from that list. As in every business context the total budget for the whole product development was limited – and so was the available time to realize certain projects and initiatives.
The atmosphere in this offsite workshop had been tense since minute one. We did a check-in and asked each participant about his or her intention for attending the meeting. Very often they answered: “I am here to fight for my projects.” After some time of community building and introduction to the topic, the participants wanted to start with prioritization. But how to do this in such a tense atmosphere and with so many strong managers in the room?
Let’s have a detailed look on how to perform the Magic Matrix Technique in order to achieve a (company-wide) portfolio prioritization.

Attendees

Keep the number of attendees reasonably small. I know that everybody has an opinion on project priorities but only few have budgets to run projects. Try to have less than 20 participants.
The selection of attendees to this workshop depends on the specific situation you are facing. If you try to create a company backlog, make sure that each business unit that is requesting resources needed to develop a product has a representative in this workshop. When I say ‚resources needed to develop a product‘ I am not only talking about development resources. Think also of all the ‚shared resources‘ that are necessary to bring a product to life (e.g. purchasing, release management, lawyers and so on).

Overall time frame

Depending on the number of attendees and their experience in collaborating across the company, the time needed for this technique will range from two hours to a bit more than half a day.

Setting

The setting of a workshop always determines the behavior of the attendees. Karl and I chose to create a special setting: we printed out all project requests on A3-sheeevernote-camera-roll-20160111-230914ts and pinned them to the wall. We aimed at creating a feeling of being in a museum or a gallery. Very often those galleries trigger a certain sense of urgency because the attendees are overwhelmed by the sheer amount of projects they want to deliver. Sometimes they immediately understand that they need to say NO to certain projects for now.
On the floor, we had prepared a large square, simply made of white painter’s tape, and two long tape lines next to it. The square contained nine smaller squares. The y-axis was labeled ‘cost of delay‘ and was divided into three sections: low, medium, high. The x-axis was labeled duration of delivery and was divided into short, medium, long. This creates a 3 by 3 matrix that distinguishes 9-fields.
Right, this is the Matrix created by Donald Reinertsen which he derived from prioritization mathematics also known as weighted shortest job first (WSJF / 2).
The two long tape lines repeat the labels of the Magic Matrix (below I’ll explain why). The first taped line was divided into three sections labeled high, medium, low. The second line was also broken down into three sections labeled long, medium, short.
evernote-camera-roll-20160111-230912
 

Operation

1. Gallery walk

Let the attendees walk along the gallery that shows every project (or user story) printout taped to the wall and let each project be introduced briefly by the attendee who raised the project.

2. Allow Questions

Allow short questions to improve understanding. This is not about arguing, just about a common knowledge base of each project.

3. Distribute the printouts

Now take the printouts off the wall. In order to run the next part of the session smoothly, only pick around 30 to 40 printouts. In case you have printed out far more projects or initiatives, ask the attendees to pick the one project that is most important to them. Do the same with the second most important project and so on until you have picked around 30 to 40 printouts. In the workshop described above more than 160 printouts were sticking to the walls.
Deciding what NOT to take off the wall was a first emotional moment for the participants.
Let every participant hold one or more printouts in his or her hands. It is not necessary that every participant holds a printout of a project that he or she raised initially.

4. Introduce the cost of delay scale

Introduce the first line of tape on the floor to the participants. This is the line symbolizing the cost of delay (2a3d75a8d-bd6b-49d6-aa28-60efdaf7b511). The cost of delay is always defined with a specific point of time in mind. Make this point of time explicit to the participants.
In the situation described above, it was a date some months ahead. A highly important media event was going to take place and would have high economical relevance to the whole company. The question at this first line of tape is then: How high will the cost of delay be if we do not finish the selected project completely until that special date in the future? Consider the cost of delay in direct relation to the other projects. Make sure that everybody understands the meaning of the word ‘relation’. It means that you don’t try to calculate precise costs but rather estimate it in close relation to the other projects you are discussing. Don’t try to assume the cost of delay for one project in isolation.
 
Consider different categories for the cost of delay. The cost of delay is the area below the line.

5. Play the first round of Magic Estimation

With this question in mind let all the participants play one round of Magic Estimation. Magic Estimation is an Estimation game that was invented by Boris Gloger many years ago and has proven its value in countless user story prioritization sessions. I will not describe the game in detail. If you are not familiar with the game, feel free to follow the link.
Instead of using the modified Fibonacci scale as you might know it from the original Magic Estimation game (you can buy a Magic Estimation poster to facilitate estimation meetings on our website) or from planning poker, we only use these three sections of the scale: low, medium, high. It is essential that all the participants remain silent during the whole round. Talking will disrupt the flow and impact the outcome of the estimation negatively.
The facilitator, who might be you, looks for projects that jump from one section of the scale to another. Those printouts are marked with a dot in a specific color by the facilitator. This dot indicates that the participants disagree on the relative cost of delay of this project.
If you perceive that almost all projects tend to move towards the ‚high‘ section of the scale, interrupt the game for a moment. Remind the participants that they have limited resources as well as limited time. Point out that not all projects can be equally critical in terms of cost of delay regarding the specific date defined at the beginning of the session.

6. Agree on the cost of delay category for each project

After the first round Magic Estimation is over and all projects have been put to the floor, grab the first project from the ‚high‘ section that has been marked with a dot by the facilitator. Ask who disagrees with the cost of delay for this project being high.
The project should not be discussed separately but in relation to other projects, so chose some from the high and medium section that did not receive a dot mark. Keep the discussion short and always keep it in relation to other projects without a dot mark and in relation to the specific date in the future you agreed on before. Formulate something like this: “You silently agreed on a medium cost of delay for project A and on a high cost of delay for project B. Is the cost of delay of project C closer to project A or to project B?”
Agree on the relative cost of delay for the project at hand and write it on the printout in the same color as the dot mark.

7. Repeat brief discussions

Repeat these brief discussions for all projects with a dot mark. Keep the discussions short and decision-oriented.

8. Have a coffee break

When you’ve agreed on the relative cost of delay for all projects, have a coffee break and let lots of fresh air into the room. While the participants enjoy their coffee, write the relative cost of delay on the remaining project printouts according to the sections they were put into. It is important that every project printout has its own cost of delay note because you will need this later for sorting the projects.

9. Second round of Magic Estimation

Repeat the Magic Estimation game at the second taped line. Again, every participant receives some project printouts before the game starts.
The question for this round is: “In relation to the other projects: How long would it probably take to finish this project if we only did this single project at a time?” In order to avoid confusion, use a different color now for making the dot marks than you used in the cost of delay round.

10. Agree on the duration of delivery

Agree on the relative duration of delivery for those projects that received a color mark. This again needs some facilitation to avoid long discussions. Remind the participants that this is just a wild guess in relation to the other projects left and right along the taped scale. It is not necessary to be precise.
Write down the assumed duration on the project printout.

11. Sort the projects into the matrix

After this is done, ask all the participants to grab the project printouts on the floor and sort them into the taped matrix on the floor. This is straight forward. Every of the nine squares is described by a specific cost of delay and duration of delivery.
reinertsen-matrix

12. Do the elevator

We are almost done. You probably experience that some squares contain more than one project. This is not a problem at all. Do the ‘easy elevator’ next. Start with square 1 (cost of delay high and duration of delivery short) – grab two of the projects in that square and ask for the relative cost of delay again considering the special date in the future. Let the participants explain their opinion and come to a decision.
Now grab one more project out of the same square of the matrix. Ask: “Is the cost of delay of this project higher than of the project currently lowest or is it lower?” Quickly sort the projects until you have a discrete order in this particular square.
prioritization-elevator-borisgloger-consulting

13. Create the sequenced company backlog

Take the ordered projects and lay them out in the room in this discrete order. Since you have started with the most critical square 1, you will now experience that discussing the other squares will go more smoothly.
Repeat the ‘elevator‘ and complete the discrete order of the projects until you’ve laid out all projects that you have chosen after the gallery walk.

If there are still projects on the wall

It might happen that there are still some projects left on the wall. Honestly, this is not surprising at all. This actually happened in the workshop described above as well. Reflect on this situation together with the participants: Are these projects really worth being discussed in this workshop? The participants already have a quite big backlog. Long backlogs harm delivery performance and should be avoided.
Make clear that the participants now have a technique at hand with which they can add backlog items smoothly whenever the backlog is almost delivered.

Why it works like magic

1. Overview

Usually cross-company projects or initiatives are discussed, handled and processed each at a time. One prepares a business case and tries to overcome some gates in an approval process.
Opposite to that the Magic Matrix prioritization technique makes all projects visible at once that are important to the company – so one can overview their overall importance and their general contribution to the company goals.

2. Communication

It is not uncommon at all that different businesses or requesting units don’t have to talk to each other when initiating a project. This inevitably leads to the perception that one’s own project belongs to the most important ones or is even the most important project in the company. This often causes conflicts between business units since multiple resource allocations are revealed far too late – that is, when conflicting projects have already started.
When using the Magic Matrix Technique, a lot of valuable discussions arise among the participants. If you repeat this format – let’s say quarterly – the participants get used to collaboration and aim for a shared goal together.

3. Movement instead of mathematics

I assume that Don Reinertsen, who I once met for some days in Essen, would consider this format to be a bit playful and not mathematical enough. And although I highly value Don and his contributions to the art of product development, I have experienced that only few understand his insights and recommendations to such an extent that they can use it practically.
If you don’t have enough time to introduce the principles and ideas behind Don’s ‚Second Generation Lean Product Development‘, this specific matrix suffices to benefit from its strong mathematical basis.
Instead of calculating the cost of delay, you relatively determine it using group knowledge. In his book mentioned above, Don states that humans are not very successful in estimating the cost of delay (COD) of a single item based on intuition. If different experts are questioned separately, the resulting COD values spread tremendously. Relative estimation in the Magic Estimation game and the communication here comes into play: Obviously, values like ‘high‘, ‘medium‘ or ‘low‘ are not precise. But that is not the intended result of this technique.
The goal of this technique is to be fairly accurate and to support decision making in a very short time. Just recap: You initially prioritize a whole company backlog in less than a day!
And because all the projects on the wall are important to the company, it doesn’t even matter if the cost of delay is precise as long as the priorities of the company backlog items are mostly right.
Prioritization means to sort and sequence. It is important to consider that – with all due respect to mathematics – this is a decision. I often experience ‘decisions by Excel‘ which means the decision to prioritize some project or feature is somehow ‘outsourced‘ to a spreadsheet to avoid clear decision making.
Don’t forget that there is a ‘No’ in every decision: prioritization also means not to do something else that has less or no priority. Saying ‘NO‘ is the ultimate tool to avoid system overload thus resulting in low performance.

5. Agreement

Generally you ‘just‘ need to agree on resource allocation and on the method you use in order to achieve this allocation. Both will be reached with the Magic Matrix Technique – it is fast and, maybe surprisingly, it is also fun. Not to forget that the initiated discussions about business goals among all participants are as valuable as the prioritized company backlog itself.

6. Speed

Since this technique can be executed fast and with little effort, it can be repeated several times a year. This helps to constantly refine the company backlog which allows strategic adjustments more often without harming the currently running product development process.
In the end this makes the company more adaptive. It even allows to decrease the size of projects to a bare minimum because you can reduce the forecasting cycles. As soon as your management team is capable of constantly and effortlessly adjusting the company backlog, you can run prioritization sessions more frequently. This reduces the investment risk and allows quicker market feedback, which ultimately results in better products and more revenue.

What happened then

The client which first participated in the Magic Matrix workshop still uses this technique to prioritize the company backlog. Over time it evolved into a strategic product portfolio. The Magic Matrix is not only used for the company portfolio. It is also used to prioritize team backlogs which have a higher granularity.
Today, for this client prioritization conflicts belong to the past. The product development teams are more focused and are thus able to deliver faster and in higher quality.
In this workshop we created a shared view of the company’s priorities across the business domains. Over time a cross-domain top management Scrum team emerged which adjusts its shared strategic product roadmap once a month in an office workshop.

Additional information: Constraints to this technique

As far as ‘mathematical logic‘ behind the presented technique is concerned, we are talking about the division of cost of delay and the duration of development. This calculation is also called CD3 calculation. It fits with Scrum very well since it focuses on time dependencies and thus fosters delivery focus.
Nevertheless, there are some limitations to this technique. Using the Magic Matrix Technique will be beneficial if the compared backlog elements show distinguishable costs of delay. Sometimes backlog elements are so closely related to each other that you can hardly distinguish the delivery of one item from the other. In this case, it helps to find an overarching backlog item that integrates the smaller items.
Using the overall delivery duration as criteria for prioritization is only truly beneficial if the participants of this workshop don’t know the ‘organizational constraint‘ of their delivery flow. If the participants know the constraint, it is not recommended to consider the whole delivery duration. Use the processing duration of the delivery step that constraints the overall delivery flow instead. This calculation technique is called throughput octane (or product octane).
However, management teams performing the prioritization of a ‘company backlog‘ for the first time are hardly ever familiar with the ideas of the theory of constraints. Therefore, it is very unlikely that they are able to precisely name their constraints, which makes it impossible to calculate or estimate the throughput octane. Which leads back to the Magic Matrix Technique as being ‘good enough‘ for the described purpose of prioritization.

Micro Sprints – your way to effective workshops

Don’t get me wrong, meetings and workshops are important for managers to get their work done. As Paul Graham nails it: meetings are the managers’ work. Nevertheless I’ve experienced so many management workshops dull and vague, lacking any specific outcome. This is why I started to design management workshops as micro sprints. These workshops are now fun, fast, productive and always result in a specific delivery.
During the last years of my work as a Management Consultant I’ve learned that the right setting is key to working with top-managers and executives. In my case this means that most of the consulting impulses on how to build fast, adaptable user centric organizations are given during management workshops that most of the time are held offsite. Offsite meetings should take place regularly (at least bi-monthly) and should be scheduled way in advance.
The micro sprint workshop structure provides the participating managers with a strict repetitive structure that helps them to deliver high quality decisions – which are most of the time deliverables of the management participants – in a very high pace by using and at the same time learning some of the core practices of Scrum.

What’s the idea behind Micro Sprints?

Focus is a Scrum value. It helps to get work done and avoids overload by doing too many things at a time. By using the micro sprint workshop framework I try to create as much focus as possible to achieve productive and fun workshops.
stefan_msprints_bild_1
 
 

Define the Workshop Release Goal

Consider the workshop as a period of time that needs to have a specific outcome. In Scrum we define the release and sprint goals before we define how we are going to achieve these goals. We apply this practice within the micro sprint workshop framework to direct the attendees’ focus onto this release goal. I suggest to define the release goal before the workshop takes place. If this is not feasible, do it directly after the initial workshop check-in. A possible release goal might be: After this offsite meeting we are going to announce the first iteration of organizational changes towards the new delivery structure. All necessary decisions have been made.

stefan_msprints_bild_2

Keep the agenda loose

Usually management workshops have strict agendas that schedule every single minute precisely upfront. This might be useful in a lot of settings. Nevertheless I try to avoid these rigid agendas whenever I want the management team to work closely together. What I use instead, is an agenda that only prescribes the sessions in which we work together. I don’t prescribe which topic will be tackled when. I have made good experiences with sessions of 90 minutes each, intermitted by generous coffee breaks.

Example

09:00 – 10:30 : Check-in, Backlog Grooming and Micro Sprint 1
10:30 – 11:00 : Coffee break
11:00 – 12:30 : Micro Sprint 2
12:30 – 13:30 : Lunch
13:30 – 15:00 : Micro Sprint 3
15:00 – 15:30 : Coffee break
15:30 – 17:00 : Micro Sprint 4
17:00 – 17:30 : Check-out and next steps
This structure creates four highly effective micro sprint sessions. In every single session the management team is encouraged to develop and finish at least one specific deliverable.

Switch off the gadgets!

Altstefan_msprints_bild3hough this might be a no-brainer: Please switch off your electronic devices. You don’t need your smartphone for being productive in the workshop. Your notebook might be stored in your bag. Try to work as distraction-free as possible. It is the workshop facilitator’s mission to create focus during working sessions.
 

Create the Workshop Backlog

Prior to every workshop collect issues that are raised by the participants. Usually not every topic is closely related to the defined release goal but don’t consider this as a problem. Prepare all these issues on story cards which then will be pinned to a wall in the room. I let the attendees add issues if needed. Consider this part of the workshop as an initial Backlog Grooming or Backlog Refinement session. Every participant is then invited to briefly present his or her issue and the aimed outcome if it will be tackled in the workshop. After every ‘story‘ on the wall has been introduced to the participants and no more issues are raised you get a fully ‘groomed‘ workshop backlog. Then let the participants prioritize the stories.

Prioritize the Workshop Backlog

Prioritizing the backlog can be done fast and fairly easy by using an adaptation of the Matrix for Cost of Delay by Don Reinertsen. Two questions are relevant to finding the right priority of each story:

  1. stefan_msprints_matrixHow high is the cost of delay if this story will not be delivered within this release (this workshop)? The answer needs to be given in proportion to the other stories on the wall.
  2. How long does it take to deliver this story if we only work on this one story at a time? This estimate needs to be given in proportion to the other stories as well.

With a little help of the workshop facilitator this prioritization work is done within some minutes. I once got the feedback from a participant that it helps if you don’t show the prioritization numbers of each box in the matrix to the participants. With this easy technique you’ll get a prioritized release backlog that will be the foundation of the workshop. Feel free to reprioritize this backlog if new issues are introduced to the backlog within the workshop or if the group of managers has learned something so important that the old prioritization doesn’t make sense anymore.

Story 1 – Sprint Planning 1

What happens then is basically pure Scrum. From time to time I like to address the managers in my workshops as a management team. This is meant to be a hint that it is not enough to announce that Scrum now needs to be done within the company. Instead, even the management needs to understand and feel what it is like to work within a management framework called Scrum. So, at the beginning of every session the story with the highest priority is pulled from the workshop backlog. Just pull one story at a time!
Then start Sprint Planning 1 by defining exactly what needs to be done within this story by adding information to:

  1. Understand the context of the story. Why is it important to deliver this story and which information might be relevant for all participants?
  2. Define the acceptance criteria. This answers the very important question: When are we done? Based on which criteria do we know that we have done the right thing? This also gives a very good idea on what the expected benefit of this story will be. It is not unusual that participants start to argue who the user of this story is after all.
  3. Define the constraints of that story. What are the givens which cannot be ignored or violated by the derived deliverable?
  4. Define the user acceptance tests. This basically answers the question what needs to be fulfilled in order to deliver the story in the right way.

These items shall be testable by the participants. Although it might be ideal that the participants write these additional informations on their own, it is often a bit too much for them if they are confronted with this approach for the first time. The facilitator should then guide the conversation, collect all the information and write it down in a prepared template. This Sprint Planning 1 format might sound like overhead. But I’ve experienced too many times that participants have a hard time to define the aimed deliverable of an issue. I often experience participants who „just want to talk“ about an issue. But seriously: this is not Scrum. Scrum was designed to deliver. We want to get things done.
stefan_msprints_bild7The pleasing part of this exercise is that managers feel relieved and energetic when they can say precisely what they want to deliver. It creates focus and frees their minds from load that hinders them from working on one item. Due to their daily work routines managers are trained in analyzing topics broadly. They swiftly find edge cases and dependencies which usually make it almost impossible to deliver. Thats why I use the constraint of micro sprints lasting no longer than 90 minutes to get something worthy done. This is challenging and possible.
The edge cases are important you say? Fair enough. Nevertheless, if the edge case prevents the 80% solution to be outspoken, it is not helpful at all to stick to the edge case. It is far more easy to find a solution for the edge case if you’ve found a solid solution for the default cases first.

Sprint Planning 2 – optional

Sometimes participants have a hard time saying how they are going to tackle the started story. They now know exactly what they want to deliver. In Sprint Planning 2 they work out how they are going to achieve this. The easiest way to walk through this exercise is by checking the previously defined User Acceptance Tests and derive designs or work items that address this test. I sometimes even create tiny task boards to visualize what the participants want to do in order to deliver the story.
stefan_msprints_bild4
 

Delivery Check

If the story is so well defined it is usually very easy for participants to deliver it within 90 minutes. Don’t forget that Sprint Planning 1 and 2 are included in these 90 minutes. Also the delivery check takes place within this micro sprint session. The participants check if all the User Acceptance Tests are met and if the Acceptance Criteria is fulfilled.

Micro Celebration

Believe me, the feeling of having accomplished something is staggering for managers who are used to sit in boring meetings caught in endless discussions and close to no substantial decision. Let the participants celebrate their deliverable. Check the time then. Let the participants decide if they want to deliver one additional story before the break. If there are only some minutes left, start the break.
This way of working and delivering together as a management team is fun and can be exhausting at the same time. Having some slack is fine! This will help to deliver the next story. The facilitator then documents all the deliverables and prepares the next micro sprint.

Repeat

Keep the structure stable and repetitive for every micro sprint session of the workshop. This is not boring. It helps to improve the overall team collaboration and helps the participants to become focused and faster.

Retrospective

Don’t forget the Retrospective. This is an essential part of Scrum and therefore should also be integrated in the micro sprint workshop framework. To keep the retrospective short and effective ask two simple questions at the end of the workshop:

  1. What went well this management offsite meeting that we are going to keep in the next offsite?
  2. What are we going to improve in the next management offsite?

That’s it. It’s the facilitators job to collect the results of the Retrospective in the same structured way as he has collected the deliverables of the workshop. This is the fast to implement and easy to use micro sprint workshop framework for your effective offsite meetings. I hope you find it useful and it will help you the same way it helped me and my clients to get the most out of their offsite sessions.

Agile project monitoring – avoiding the agile watermelon

Agile Monitoring is not project marketing. It is about effective control at all levels and the proactive dialogue within the team and with the management.
Some time ago I had a quite intense discussion with a client of mine about the purpose of project reporting. He elaborately tried to convince me that the purpose of project reporting is to create comfort to his line manager. The manager himself should be convinced that the project was well on track and should feel well informed about the overall status of the project. I strongly disagreed and showed him the perspective I aim for in agile management.
First let me clarify that this will be the last time I use the word reporting in an agile context. The word itself is highly misleading. I am going to use the word monitoring instead. In comparison to reporting, monitoring exceeds the pure view on the current state of a project by being decision oriented for the team itself and not only for archiving purposes required by the line manager.

Initial situation

The client I was talking to was a project manager and has been used to work in waterfall projects for most of his career. Together with me he ran his first agile product development project. In his career he experienced that managers can strongly intervene in projects and that this might have changed the course of the project heavily and might even have ended the career of some project managers he knew. From that standpoint I could absolutely understand his perspective on the purpose of classic project reporting which was basically to create some calm – well, before the storm.
The project he accompanied in the role of project manager was fairly large and was planned for a duration of several years. The project was integrated in an even bigger program which was planned in a waterfall sense for an even longer project duration. I was the agile coach for the only project in this program which ran agile. From his perspective his job description was to gather information on the status of the different projects in the program and aggregate this information to a point where the top managers could see… what? A green traffic light. What else. You know the term the project status is „melon green“, right? It states the fact that many projects pretend to have a „green“ status but the deeper you drill in the green melon the more red it becomes.

suze/photocase.de

suze/photocase.de

It is about effective management not about reporting

When I look across all the projects I was able to accompany so far I make an interesting observation. Data, derived out of project circumstances, is almost always aggregated across several hierarchical levels and is then handed to a position within the organization where a certain decision is executed based on that aggregated data. The person making that decision has almost no connection to the source of the data itself anymore – the product development work.
The client I described above faced the same situation. But how effective can such an executed decision be? Does such a top management impulse really have any effective impact referring to the aimed goal of that project? Sure top management executions are powerful. But do they have a managerial impact on the operation of the project? I say no. Because the effect of that management decision is limited to the direct reports of that particular manager. From there it slowly has to trickle down. This doesn’t only consume a lot of time. Also the intent of the top management impulse might change during its course through the different levels of the hierarchy on its way down to the project team due to certain degrees of interpretation and individual motivations by people in the hierarchy.
My client experienced the same in his career. That is why he prepared his project reporting in a way that it was, as he described it, safe to be clearly understood by his own 6-year-old son and by his top-executives.
When I think of agile project monitoring I don’t think in terms of manipulation, I think in terms of effective maneuvering and management that has an impact on product development. Impact in that sense means the management action that is derived out of monitoring information is effective in regard to the vision of product development. Feedback is a foundational practice in Scrum. So think the measurement in terms of feedback, not as the traditional lever to motivate behavior.
The effectiveness of an intervention increases with its immediacy. Which leads to the conclusion that those in direct operation of the project have to make the change, have to make the bold decisions based on their own project data, which then leads to the point where those people in the operation of a project need to understand the modes of operation within their own project domain which they need to actively influence.
So when you’re looking for effective management you have to set up the monitoring „from below“, which means from the perspective of the Scrum team. With this setup you create immediacy. Every decision you make based on real development data has in return a direct impact on the product development project.
Whenever a Scrum team escalates the need for a decision based on observations in the project, that Scrum team willingly gives away the responsibility for the decision itself. This bears at minimum two quite high prices: First, you accumulate cost of delay due to the time it takes until the need for a decision has climbed up the hierarchy and comes back to the team. Secondly, the quality of the decision is very likely not as good as it could have been if the team had made the decision on its own. But at least the team doesn’t feel responsible anymore. But isn’t that a fad? The team ultimately remains responsible but gives away its chance to boldly influence the outcome of the project.

A relevant discourse about the status of the project

„Where are we?“ That was the introductory question my client was used to be faced with in his recurring project status meetings. A question repeated a million times across so many projects, so it seems to be the one vital question of managers when project team representatives report about the project. But what does that question mean in terms of agile product development? Time and budget are fixed. The scope changes as the product development team learns. So the question needs to be reversed: „When is the project doing well?“ Start with the desired outcomes. This also helps to understand what might be worth measuring.
What we are looking for in agile monitoring is a relevant discourse between the Scrum team represented by the Product Owner and its manager. The first relevant discourse is the one about the goal of the project that is broadly described in the product vision. This discourse should be repeated over time. Later, during product development the Scrum teams needs to aggregate their gathered data in a way so that it leads to a specific question that can be answered by a manager. A question that is the starting point of a fruitful dialogue. This dialogue should take place every single sprint. The Scrum team decides which data it is going to present to the manager and the scrum team defines the intent with which they present it. Don’t kill your manager by data. In an agile monitoring dialogue, you aim for transparency and not for dumping random data on your manager.
The manager shapes the environment in which the Scrum team delivers. If project monitoring is the invitation to a dialogue, it implies also the invitation for an intervention by the management. So the dialogue with the manager focuses on the improvement of the working environment of the Scrum team. Therefore, you need data that indicates which offer the manager has to make to create a beneficial impact on the project.

The monitoring dialogue: Forget about any justification

When I think of my client and our discussion that day, I can remember that he didn’t feel very well before he was supposed to go to a project status review. He had experienced a lot of blame games in his career and he knew that from his perspective his status reporting presentation was always intended to make clear that whenever something wasn’t going well at least it was not his or his project teams fault.
This might be common practice but justification doesn’t have a place in this dialogue. It is all about support. There is no need for the Scrum team, which starts the dialogue, to automatically defend itself. The manager and the Scrum team share the same goal which is manifested in the product vision. Whenever you identify a risk in your project, talk about risk mitigation and not about who’s fault this could be. This monitoring dialogue is not intended to convince your manager that your project is on track and soothe his nerves. Agile monitoring is not project marketing.
The idea of agile monitoring exceeds the pure description of the projects current state. It is always asking for contribution at all levels. What does the Scrum team do to actively improve its delivery capability? What can the contribution of the manager be?
The goal of this monitoring dialogue of course is the generation of transparency which should lead to maneuverability of the whole organizational system. You want to establish a framework for action along with your management. If your dialogue doesn’t aim for this goal it is waste.
The foundation of this dialogue obviously is honesty. You are not intended to lie to your manager. And clear enough the manager is not intended to ask for being lied to. Every form of political theatre should be sentenced because it is causing waste. Manager, who punish transparency and honesty along with it, massively harm the whole organization. This behavior is dysfunctional as well and should not be tolerated either. The rate in which you allow openness and transparency in this particular dialogue determines the size of your framework of action. If a manager doesn’t want to hear anything about the Scrum teams’ impediments he loses his option to support in removing those impediments and ultimately contributing to the success of the project. He loses the chance to shape the environment of the Scrum team which basically is his job.

Done. The most reliable monitoring of all

The heavy need for a status update in a sense of project reporting stems, as far as I can see, from times when product development teams weren’t able to constantly deliver product increments which could be considered done. The urge for a status report on whether the team will deliver all the planned features in the given time and budget can easily be understood if a project team needs to work for several months on a concept on how to implement certain product features. I guess that was also the perspective of my client that day. As I said before, his experiences were based on many years of waterfall-ish projects.
In agile product development this urge is not relevant anymore. At least every sprint you see the delivery. In Scrum we only talk about things that can be considered done. The discussion doesn’t circle around consumed hours. The focus shifts to the actual delivery.
If your Scrum team cannot deliver features in the state of done than don’t dare to talk about all the things you’ve worked on. Accept that there was simply no delivery this sprint. Don’t talk about the pretense of delivery. Instead shift the dialogue to what the Scrum team needs in order to be able to constantly deliver “done” features within one sprint. Don’t accept the state that it is “not possible”. It always is. Managers can offer help to make it possible.
I’ve used the word effectiveness above. Now you can see what that means from a Scrum perspective. It means realization of the product not realization of the effort. Effort without delivery is just waste. Your client doesn’t care how much you’ve spent as long as you cannot show him on what value for him it was spent.

Relevant monitoring artifacts

So to make it even more frankly: The only relevant aspect of your monitoring is the realization of your product. All your monitoring artifacts should have a clear relation to this realization.
In this client’s organization and in many organizations before I’ve experienced that these organizations measured how well they are on track in terms of planning. But every IT organization in the world is responsible for the realization of a product and not only for planning. Even if this IT organization buys a product from a vendor. The product is not tangible as long it is not up and running. The whole effort of planning is not relevant and it’s not worth monitoring it. A finished concept is not a delivery in terms of product realization. Whenever you talk about the work you’ve spent you just disguise the fact that your flow of delivery is dysfunctional. Doing is worthless without the state done. Doing is not performance. Whenever you value doing over done you reward dysfunctional behavior.
What in fact is worth monitoring is the recurring answer to the question: What can currently be considered as done? How does the product evolve? What did the Scrum Team learn about the user’s needs?
Practically there are some pretty straight forward monitoring artifacts to be considered at different levels. If you take a look at the team level, use

to understand the delivery flow within the team. Actually you don’t need more. Sure enough there are plenty of other metrics and diagrams and they all might be useful but if you consider the bare minimum, start with these two at team level.
If you talk to your user all that matters is the shippable increment. In other words: What is done. And for that you have a review meeting. And yes this means that you need to invite the user to the review. The line manager or the top-executive is not the user. He is allowed to attend the review but the Scrum team does not present to him but to the user.
In the dialogue with the manager or other stakeholders you can use:

With these artifacts prepared the Scrum team initiates the dialogue with the management. Impediments which the team cannot solve by itself become a vital part in that monitoring dialogue. Ask the manager for contribution and use the monitoring artifacts as feedback device to see if you’ve pushed the right levers and if the current influence on the project environment is sufficient.
In the discussion with my client that day we agreed to change the course of his reporting over time in incremental steps. First we started to measure two lead times. One for the delivery of the backlog items and a second for the decisions which have been needed by the Scrum team to make progress. Especially the second lead time led to a very positive discussion between the project manager, who was still representing the Scrum team, and the line manager, which over time resulted in a change of the project framework that fostered the decision making by the Scrum team. To make those decisions fast and safe to fail at the same time, the Scrum team started to work with explicit working hypotheses to show that they had made decisions and they were eager to check those hypotheses over time. Moreover, the impediments of the Scrum team became a part of this monitoring discussion which helped the management to understand the situation of the Scrum team and to offer some solutions for these impediments.

Aufgaben machen statt managen!

Gerade kommt die nächste Werbemail von Basecamp rein – wie toll die neuen To-Do-Listen nicht wären. Ich klicke die E-Mail weg und denke mir: Ich war einmal ein Tool-Addict. Wie gut, dass ich diese Listen nicht mehr mache. Jedes neue To-Do-Listen-Tool musste ich ausprobieren. Immer in dem Wahn, dass meine Arbeitsbelastung dann sinken würde. Aber alle diese Tools lösten das Problem nicht, denn: Die vielen Aufgaben mussten ja auch erledigt werden.
Im Wesentlichen halfen mir die Tools nur dabei, die Listen länger und länger zu machen. Dafür gibt es wirklich unzählige Werkzeuge am Markt. Sie wollen uns helfen, die viel zu vielen Aufgaben zu verwalten, zu managen und unter Kontrolle zu bekommen. Sie alle sind Auswüchse der vielen Zeitmanagement-Methoden, die es wie Sand am Meer gibt: Getting Things Done, die Seiwert-Methode, ABCD-Methode, das Eisenhower-Prinzip, Stephen Covey, Pomodoro und und und. Tools dazu gibt es sogar noch mehr als Zeitmanagementsysteme: Vor 25 Jahren war TimeSystems das Nonplusultra des Zeitplanbuchs, den Filofax gibt es noch immer und heute kommt sicher jeden Tag ein weiteres Zeitplanungsinstrument dazu. Eine elektronische Variante nach der anderen wird programmiert: Remember the Milk, Wunderlist, Asana, BaseCamp, Trello, …
Mich selbst haben diese Methoden und Tools zunehmend gestresst. Sie halfen mir lediglich dabei, noch mehr Aufgaben aufzuhäufen, die ich nicht bewältigen konnte. Manche Leute waren so unglaublich diszipliniert und konnten mit diesen Tools wunderbar umgehen, sie hatten ihr TimeSystem im Griff und hakten eine Aufgabe, einen Termin nach dem anderen ab. Ich fühlte mich schlecht. Aber wenn ich meinen unternehmerischen Erfolg, meine Veröffentlichungsquote, meine Anzahl an gehaltenen Trainings mit denjenigen verglich, die ich bewunderte … sagen wir es so: meine Lieferungen waren meistens zahlreicher. Wie kommt das? Unser Hirn hat eine wunderbare Funktion: das Vergessen. Und oft reagiert es mit einer wundervollen kleinen Entzündung: der Aufschieberitis.

Wert oder Menge?

Als ich letztens einen Vortrag zu Scrum 3.0 hielt, habe ich versucht, die Wut des gemeinen POs, uns unsäglich lange Backlogs zu bescheren, einzudämmen. Wenn die Backlogs länger und länger werden, ist die instinktive Handlung der Entwicklungsteams, diese Backlogs (die nichts anderes als To-Do-Listen sind) immer wieder anders darzustellen und zu managen – durch JIRA, Agile Zen, Trello und wie sie alle heißen. Aber das macht sie nicht produktiver, sondern nur langsamer und unproduktiver.
Also war ich so frech und sagte: „Ein Backlog sollte weniger als die Höhe der dreifachen Velocity, gemessen in User Stories/Sprint, haben. Diese Zahl wäre ideal.“ Es kam, wie es kommen musste: Ich wurde dafür kritisiert. Man warf mir vor, ich könne das so doch nicht sagen, ich verstünde die Warteschlangentheorie nicht, könne nicht rechnen und letztens habe ich sogar gelesen, ich hätte keine Beispiele gebracht. Kurz: Es sei wertlos, was ich sage.
Nun ja, klar: Wenn man Scrum als Management-Framework versteht, um einfach irgendetwas zu bauen, statt Value zu liefern, dann ist das, was ich sage, eine ketzerische Behauptung. Denn im Grunde sage ich: Lasst uns weniger tun, um mehr zu liefern. Doch da läuft gerade etwas ganz gehörig schief. Ken Schwaber hat vor zehn Jahren gesagt: In dem Moment, in dem im Backlog genügend Items liegen, um den ersten Sprint sinnvoll zu füllen, startet man los.

Das Backlog ist kein Lagerplatz

Warum? Die Antwort ist logisch: Es soll erst gar kein Backlog aufgebaut werden. Jede Verzögerung ist schädlich, jede Verzögerung lässt das Backlog anwachsen. Das Wunschkonzert wird immer lauter und diffuser, ohne durch Abarbeitung und Lieferung der Items Daten zu generieren. Hat Ken eigentlich gewusst, wie weise das war, was er gesagt hat? Die Backlogs müssen kleiner werden, die Tasklisten müssen kürzer werden, wir müssen aufhören, Defects und Aufgaben zu verwalten. Wir müssen weg vom Zeitmanagement und hin zum Value-Management. Wir müssen uns  auf eine Aufgabe nach der anderen fokussieren und jedes Mal die Dinge wieder wegwerfen, die wir sonst noch so machen könnten.
Ich höre schon den nächsten Projektleiter, der die x-te Migration eines existierenden Systems machen soll, mit mir schimpfen. Produkte und Applikationen, die jahrelang gewachsen sind, sollen in viel weniger Zeit erneuert werden, als es ursprünglich gebraucht hat, um sie zu entwickeln. Noch dazu sollen das Menschen tun, die vom eigentlichen Geschäft dahinter keine Ahnung haben: Das ist und bleibt Schwachsinn. Extrem gut bezahlter Schwachsinn für den, der dieses Projekt gewinnt, aber am Ende eine für den Kunden geld- und wertvernichtende Praxis. Das Ziel sollte sein, die geistige Kapazität fähiger Menschen darin zu investieren, etwas Neues und aktuell Sinnvolles zu entwickeln. Würde man das machen, gäbe es auch wieder die Chance zu sagen: eine Funktion nach der anderen.
Ja, ich weiß, ich bin sooo weit weg von der Realität, das ist alles so aus der Luft gegriffen. Aber ich muss einfach widersprechen. Disruptive Technologien wurden noch nie so schnell und in dieser Geschwindigkeit entwickelt wie heute. Die einen bauen noch immer die komplizierten Medizintechnik-Produkte, die der Arzt für viel Geld kaufen muss, und die anderen probieren mal eben, das iPhone zum Ultraschallgerät zu machen. Aus den USA kommt die Bewegung des Minimalismus: So wenig wie möglich besitzen, die Garderobe ausdünnen, so wenig wie möglich kaufen, so wenig wie möglich machen. Diese Bewegung lässt sich auf ein Wort reduzieren: Fokus. So viel Raum in seinem Leben machen, dass es möglich ist, die Dinge zu tun, die uns wirklich wichtig sind.

Was ist wichtig?

Aber was ist uns wichtig? Was wollen wir wirklich? Welche Funktionalitäten sind wichtig, was sollten wir tatsächlich tun? Wie wäre es damit, einfach die Dinge zu tun, die uns faszinieren? Wie wäre es, dafür Raum zu schaffen, indem wir all das auf die Seite schieben, was nicht dazugehört?
Für euer tägliches Geschäft könnte das heißen:

Um Raum in eurem Leben zu schaffen, könntet ihr auch damit aufhören, ständig online zu sein, oder ständig in eure Smartphones zu schauen. Wer ständig online ist, der bekommt einfach zu viele Daten, ohne echte Informationen zu produzieren. Hört auf, jeden Tweet, den ihr nicht einmal gelesen habt, weiter zu verbreiten. Twitter ist der Kettenbrief von heute. Wahnsinnig viel Traffic, ohne dass es etwas bringt.
Wer reduziert, sich fokussiert, der hat auch noch die eine oder andere Taskliste und sogar die wächst – und dann kommen die Gnade des Vergessens und die Aufschieberitis zu Hilfe. Alles das, was dann nicht gemacht ist – na und? Es war offenbar nicht wichtig genug. Dann schaut man nach ein paar Tagen wieder drauf und sieht: Das eine muss getan werden und das andere wird einfach doch nie gemacht.
Oh, übrigens, To-do-Listen können sogar sehr viel Geld kosten. Aus Versehen habe ich einmal die Steuern nicht rechtzeitig eingezahlt. Tja, hätte ich es nicht als ein To-do von vielen auf den Haufen gelegt, sondern einfach sofort abgearbeitet, hätte ich eine Menge Geld gespart. Damit will ich sagen: Das mit dem kurzen Backlog funktioniert nur, wenn man die Dinge auch tut, die anstehen. Sofort. Aufgaben machen, statt sie aufzuschieben und zu verwalten. Dann brauchen wir auch keine Tools mehr, die nur verwalten, was wir eigentlich schon längst erledigt haben sollten.