Mindmapping: So sprudeln die Ideen für Texte und Projekte

Ob beim Schreiben eines Buchs, bei der Planung von Projekten oder um schnell und einfach Ideen zu generieren: Mindmapping ist eine hilfreiche Technik, um von Beginn an Struktur ins Vorhaben zu bringen. Dabei geht es in erster Linie darum, linke und rechte Hirnhälfte zu verbinden und das jeweilige Themengebiet räumlich-visuell zu erschließen.

Mindmapping funktioniert so gut, weil die Technik das Prinzip der freien Assoziation nutzt. Im Video erfahrt ihr, wie das funktioniert und was man in der Praxis beachten sollte. Viel Spaß.

Alles beginnt mit einem Problem: Ideation im Rahmen des Design Thinking

Es gibt eine Vielzahl von Innovationsmethoden, um Produkt- und Serviceideen zu entwickeln. Was haben diese Methoden zur Ideenentwicklung gemeinsam? Was ist im Geschäftskontext eine wichtige Voraussetzung für wertvolle Innovationen?

Um das zu beantworten, müssen wir uns immer vor Augen führen, warum wir Ideation überhaupt betreiben. Es geht in der Regel darum, eine Lösungsidee für ein bestehendes Problem zu entwickeln, was meist als komplexe Herausforderung wahrgenommen wird. Doch was macht diese Komplexität aus? Wenn wir es schaffen möchten, Ideen zu kreieren, welche in Form von innovativen Produkten oder Dienstleistungen einen „nachhaltigen Nutzen“ stiften, ist es essenziell, dass die konkrete Idee auf drei Ebenen wirkt: auf der technologischen, der menschlichen und der Business-Ebene.

Das Problem dabei ist häufig, dass Technologie und Business in der Realität intensiv in den Überlegungen auftauchen, der Mensch mit seinen wahren Bedürfnissen und Wünschen hingegen allzu häufig in den Hintergrund rückt. Dies kann schnell dazu führen, dass ein Problem in Hinblick auf die zugrundeliegenden Ursachen nicht richtig verstanden wird, wodurch Produkte am Markt vorbeientwickelt werden und nicht den gewünschten Gewinn erwirtschaften.

In der agilen Welt gibt es eine japanische Redewendung, welche eine mögliche Lösung zu diesem Problem liefert. Genchi Genbutsu, was soviel bedeutet wie: „Gehe hin und schau selbst“. Wir nutzen diese Redewendung oft dafür, um unseren Kunden vor Augen zu führen, wie wichtig es ist, den eigentlichen Nutzer in den Mittelpunkt des empathischen Herangehens und Entwickelns zu stellen.

Der Ansatz des Design Thinking in Kürze umrissen

Design Thinking (DT) ist ein bekannter Ansatz, der zur Entwicklung von nutzerzentrierten Produkten oder auch Dienstleistungen herangezogen werden kann und somit den übergeordneten Rahmen für die Ideengenerierung steckt. DT basiert auf dem „Double-Diamond-Prozess“, der sich in vier Phasen unterteilt.

In den ersten beiden Phasen liegt der Fokus auf dem Problemraum. Es geht vorerst darum, das Problem mithilfe zielführender Research-Methoden zu verstehen und dieses in einem weiteren Schritt klar zu definieren. Das ist von großer Bedeutung, damit das gesamte Ideation-Team das gleiche Verständnis darüber gewinnt, wofür eine Lösungsidee kreiert werden soll. Die „Wie-können-wir-Methode“ stellt an dieser Stelle bereits eine bewährte Möglichkeit dar, um eine lösungsorientierte Haltung einzunehmen, indem ein definiertes Problem als Chance beziehungsweise Herausforderung formuliert wird.

Die darauffolgenden Phasen beschäftigen sich mit dem Lösungsraum. Mit der Ausgangslage eines klar definierten Problems geht es nun an die Entwicklung diverser Lösungsansätze durch das Ideation-Team. Die besten Lösungsvorschläge liefern letzten Endes den Plan für die Entwicklung des Prototyps und der notwendigen Tests.

Ideation im Design Thinking

Neue und beeindruckende Ideen, welche eine Antwort auf klar definierte Herausforderungen darstellen sollen, tauchen in den seltensten Fällen aus dem Nichts auf. Ein Grund, um den Prozess der Ideenentwicklung im Rahmen des Design-Thinking-Ansatzes näher zu beleuchten.

Ideenentwicklung im Design Thinking

Wie bereits angedeutet, kann ein strukturierter Prozess bei der Ideenfindung hilfreich sein, vor allem dann, wenn es darum geht, komplexe Herausforderungen zu lösen. Oft sind diese Lösungsideen dabei das Ergebnis einer Synthese von bereits bestehenden Ideen. Demnach kann es hilfreich sein, zu Beginn der Ideation-Phase Lösungsideen zu sammeln, welche zum Beispiel aus einer anderen Branche stammen, jedoch versuchen, ein ähnliches Problem zu lösen. Ein solcher Ansatz ist als Inspirationsmöglichkeit anzusehen und soll den Teilnehmern dabei helfen, über den Tellerrand hinauszuschauen, um nicht lediglich bestehende Ideen der eigenen Konkurrenz zu kopieren. Es geht darum, das eigene kreative Gedankenspektrum zu erweitern.

Die von den Teilnehmern recherchierten Produkt- oder Serviceideen, auch als „Lightning Demos“ bezeichnet, werden dann im Plenum vorgestellt und auf einem Whiteboard skizziert, sodass alle Beteiligten die Möglichkeit haben, die für sie wichtigsten Eckpunkte der jeweiligen Idee nachzuvollziehen. Im Folgenden geht das Ideation-Team zur individuellen Lösungsskizzierung über.

Die Lösungsskizzierung in vier Schritten stellt eine Methode zur Ideenfindung dar, bei der jedes Teammitglied eine detaillierte und durchdachte Lösungsskizze anfertigt.

Schritt 1: Notizen machen

Timebox: 20 Minuten

Zu Beginn haben alle Teilnehmer des Ideation-Teams die Möglichkeit, sich Notizen zu machen. Es geht darum, sämtliche Schlüsselinformationen, welche bisher vorgestellt wurden, stichwortartig zusammenzutragen. Dabei soll sich jeder vor allem auf jene Aspekte konzentrieren, die seiner Meinung nach für die Lösung des Problems von Relevanz sein könnten.

Schritt 2: Ideengenerierung

Timebox: 20 Minuten

Das Ziel im zweiten Schritt liegt darin, in den Ideenmodus zu schalten und aus den gesammelten Notizen mögliche Lösungsansätze grob zu skizzieren. Hierbei geht es nicht um Vollständigkeit. Die Übung soll dazu beitragen, die eigenen Gedanken auf das Papier zu bringen, wobei es jede Idee wert ist, aufgeschrieben zu werden – egal, wie verrückt sie auch klingen mag.

Schritt 3: die verrückten Acht

Timebox: 8 Minuten

Sinn dieser Übung ist es, sich auf die besten Ideen zu konzentrieren, welche die Teammitglieder im vorherigen Schritt gesammelt und grob skizziert haben. Diese sollen nun verbessert und ergänzt werden. Wählen Sie hierfür jene Ideen aus, von denen Sie glauben, dass sie am besten funktionieren und Ihnen dabei helfen, Ihre Ziele zu erreichen. Aber die Zeit drängt: Für jeden der insgesamt acht Kurzentwürfe haben Sie eine Minute zur Verfügung.

Ein kleiner Tipp: Es hat sich als sinnvoll herausgestellt, mehrere Varianten derselben Idee zu skizzieren.

Schritt 4: Lösungsskizze

Timebox: 30 Minuten

Nachdem sich die Teilnehmer in den vorherigen Schritten ausgiebig mit möglichen Lösungsansätzen beschäftigt haben, ist es nun an der Zeit, eine finale Lösungsskizze pro Person anzufertigen. Die Lösungsskizze spiegelt die beste Idee jedes Teilnehmers wider, wobei diese detailliert durchdacht und selbsterklärend sein soll. Hinsichtlich der Verständlichkeit ist es daher empfehlenswert, auf sorgfältige Formulierungen zu achten. Zum Schluss geben Sie Ihrer Idee eine aufmerksamkeitsstarke Überschrift. Halten Sie die Skizze anonym.

Doch wie identifiziert man nun die besten Bestandteile der jeweiligen Lösungsvorschläge, welche letzten Endes den tragfähigen Plan für die Entwicklung des Prototyps und der notwendigen Tests liefern? Hierzu gibt es eine schnelle und einfache Möglichkeit, ohne dabei in ausufernde und nicht zielführende Diskussionen zu verfallen.

Die Entscheidung

Um eine Entscheidung treffen zu können, ist es wichtig, die individuell angefertigten Lösungsskizzen gut sichtbar nebeneinander an der Wand zu platzieren. Für einen ersten Eindruck davon, welche Ideen die Gruppe am überzeugendsten findet, können die Teilnehmer die Lösungsskizzen nun im Stillen betrachten, um die ihrer Meinung nach herausragenden Elemente der Ideen vorab mit einem oder mehreren kleinen Klebepunkten zu markieren. Falls einem Teilnehmer dabei Fragen oder Zweifel an einer Idee aufkommen sollten, schreibt er diese Gedanken auf einen Klebezettel und hängt diesen unter die Lösungsskizze. Anschließend werden die einzelnen Lösungsskizzen im Rahmen einer Kurzkritik besprochen, wobei dabei auf ein zeitliches Limit pro Begutachtung zu achten ist.

Ein kleiner Tipp: Um ehrliche Diskussionen zu ermöglichen, ist es ratsam, dass der Urheber der Idee, welche in jenem Moment besprochen wird, erst am Ende zu Wort kommt. Dies erleichtert es dem Team, kritische oder ablehnende Äußerungen zu treffen.

Letztlich gibt es mehrere Möglichkeiten, wie das abschließende Votum vonstattengeht – je nachdem ob die Entscheidungsgewalt bei den Teammitgliedern selbst liegt. Ist das der Fall, bekommt jeder Einzelne von ihnen einen großen Klebepunkt. Dieser Klebepunkt wird dann mit einer kurzen Begründung, an die subjektiv zielführendste Lösungsidee geklebt. Die Idee mit den meisten Klebepunkten stellt die Siegerlösung dar und wird in ein Storyboard überführt.

Hinweis: Eine andere Variante kann auch darin bestehen, dass sich die Siegerlösung aus Bestandteilen verschiedener Lösungsideen zusammensetzt. Entscheidet sich das Team für ein solches Vorgehen, sollte darauf geachtet werden, dass sich die einzelnen Lösungskomponenten innerhalb des Storyboards zu einer sinnvollen Gesamtlösung integrieren lassen. Sind die ausgewählten Lösungsideen nicht kompatibel miteinander, könnten Sie es auch in Betracht ziehen, mehrere Prototypen herzustellen, um die Lösungsideen gegeneinander zu testen.

Freewriting – der agile Zugang zum Schreiben

Ob Blog-Beiträge, Artikel in Magazinen oder ganze Bücher – was man auch zu Papier bringen möchte: Am Anfang stellt sich oft die Frage, wie man überhaupt beginnen soll. Man möchte etwas schreiben, aber es fällt einem nichts ein – die meisten von euch kennen das. Wie kann man dieses Dilemma auflösen?

Freewriting ist eine Technik, die viele Gemeinsamkeiten mit Scrum hat, weil man sich schrittweise dem fertigen Text annähert. Diese Herangehensweise eignet sich erfahrungsgemäß sehr gut, um die grauen Zellen in Fahrt zu bringen. Wie das funktioniert und was man dabei beachten sollte? In diesem Video erwarten euch spannende Überlegungen zum Schreibprozess und eine hilfreiche Schritt-für-Schritt-Anleitung. Probiert es aus, es lohnt sich.

In jedem steckt ein Genie. Man muss es nur wecken können.

Jeder ist ein Genie! Aber wenn du einen Fisch danach beurteilst, ob er auf einen Baum klettern kann, wird er sein ganzes Leben glauben, dass er dumm ist.“ – Albert Einstein

Mit diesem Bild des Fisches, der immer wieder vergeblich versucht, den Baum zu erklimmen, beschreibt Albert Einstein sehr bildlich ein Dilemma, dessen Auswirkungen wir tagtäglich zu spüren bekommen. Obwohl oder gerade weil wir uns in einer stark leistungsorientierten Gesellschaft befinden, fokussieren wir uns sowohl im beruflichen als auch im privaten Kontext viel zu häufig auf unsere Schwächen. Dasselbe gilt für den Umgang mit unseren Mitmenschen: Wir thematisieren tendenziell eher ihre Fehler anstatt ihrer Glanzleistungen.

Fragen Sie sich doch einmal selbst: Was sind Ihre Stärken und was Ihre Schwächen? Mir persönlich fallen sofort fünf Dinge ein, die mir nicht liegen oder die ich in Zukunft besser machen möchte. Bei der Formulierung einer Liste von fünf Stärken liegt mir der Stift schon deutlich schwerer in der Hand. Woran das liegt, ist schnell beantwortet: Von klein auf widmen wir einen Großteil unserer Zeit den fehlenden Kompetenzen. Egal ob Schulfächer, Tätigkeiten in der Ausbildung oder Aufgaben im Beruf – uns wird recht schnell klargemacht, worin wir noch besser werden müssen.

Was bringt uns wirklich weiter?

Müssen wir uns mit aller Kraft zu Dingen zwingen, die uns gar nicht liegen? Dass wir unsere Zeit viel besser in unsere Talente investieren können, verdeutlicht eine Studie, die bereits 1950 in Nebraska durchgeführt wurde. Diese verglich die Lesefähigkeit von normal begabten StudentInnen mit der von anderen StudentInnen, die sich durch eine besondere Lesebegabung auszeichneten. Es zeigte sich, dass normal begabte StudentInnen durch Übung von ursprünglich 100 gelesenen Wörtern auf bis zu 250 Wörter pro Minute kommen können. Aber: Die begabten KollegInnen konnten ihre Lesefähigkeit von anfangs 250 auf bis zu 2.900 Wörter pro Minute steigern. Sie erreichten somit ein fast 12 Mal besseres Ergebnis und hatten dabei auch noch Spaß.

Mir ist dieses Thema gerade im Bereich der Team-Facilitation so wichtig, weil ich davon überzeugt bin, dass Teams nur optimal funktionieren, wenn jeder seine individuellen Stärken einbringen kann. Ich selbst habe den Anspruch, in meinen agilen Teams ein Arbeitsumfeld zu schaffen, in dem man Spaß an seinen Aufgaben hat und die Teammitglieder jeden Tag mit guter Laune und voller Tatendrang zur Arbeit kommen. Eine wichtige Rahmenbedingung ist deshalb für mich, dass jede Kollegin und jeder Kollege die individuellen Talente nutzen kann. Denn nur so hat man das Gefühl, etwas erreichen zu können und Tag für Tag seinen Teil dazu beizutragen, dass das Team immer ein Stückchen besser wird. Und nur so kann man die erstrebten Ziele umsetzen und vielleicht sogar übererfüllen.

Durch einen Kompetenzworkshop das Bewusstsein für die individuellen Fähigkeiten stärken

Um die Stärken eines jeden Einzelnen gezielt einsetzen zu können, muss man sich diese jedoch erst einmal bewusstmachen. Ich unterstütze meine Teams gerne durch einen gemeinsamen „Kompetenzworkshop“ dabei, sich auf ihre individuellen Fähigkeiten zu fokussieren. In diesem Workshop darf jeder innerhalb von 15 Minuten seine eigenen Kompetenzen in Form eines „Kompetenzbaums“ visualisieren.

In den fest verankerten Wurzeln werden die Kernkompetenzen und das erlernte Wissen dargestellt. Der stetig wachsende und kräftiger werdende Stamm, der von Baum zu Baum ganz spezifische Strukturen haben kann, zeigt die Erfolgsfaktoren jedes Einzelnen. Dort ist Platz für die USPs (unique selling points = Alleinstellungsmerkmale), die jedes Teammitglied einzigartig und unabdingbar machen. Die Krone des Baums bildet eine prächtige, immer wieder nachwachsende Laubpracht, in der sich der persönliche Mehrwert wiederfindet, den das Teammitglied für das Team oder den Kunden generiert.
Nach Ablauf der 15 Minuten stellen alle ihren eigenen Kompetenzbaum kurz vor und hängen ihn gut sichtbar im Raum auf.

Dann beginnt mein Lieblingsteil der Übung: Jeder darf nun in einem Gallery-Walk die Kompetenzbäume der anderen vervollständigen. Hierbei ist es immer wieder erstaunlich, welche USPs und bereichernden Fähigkeiten man an sich selbst gerne übersieht. Indem die Kolleginnen und Kollegen diese offenlegen, geht man auf einmal viel bewusster mit ihnen um. Man nimmt sie nicht nur wahr, sondern erkennt auch Situationen, in denen man diese einsetzen kann, oder man entdeckt, wie die eigenen Fähigkeiten die der anderen Teammitglieder ergänzen können.

Kompetenzbaum

Nutzen Sie die Talente der einzelnen Teammitglieder und profitieren Sie als Team davon

Mit dieser recht simplen Übung stelle ich das Bewusstsein über die Unterschiede im Team her und sensibilisiere den Blick für die jeweils starken Seiten und Begabungen eines jeden Einzelnen. Gleichzeitig haben der Gallery-Walk und die Vervollständigung der Kompetenzbäume durch die Kolleginnen und Kollegen einen tollen wertschätzenden Nebeneffekt.

Natürlich ist mir klar, dass sich unsere Schwächen nicht in Luft auflösen, indem wir uns allein auf unsere Stärken fokussieren. Und selbstverständlich werden in bestimmten Berufsfeldern gewisse Grundanforderungen vorausgesetzt. Spiegeln sich diese nicht in den Fähigkeiten eines Bewerbers oder einer Bewerberin wider, wird es in diesem Arbeitsumfeld immer schwer sein. Wir sollten den Fokus unserer Aufmerksamkeit jedoch weg von den Fehlleistungen hin zu den Begabungen eines jeden Einzelnen lenken. Denn nur so können wir die individuellen Eigenschaften und das Genie, das in jedem von uns schlummert, optimal nutzen und in unser Team und die Arbeit einfließen lassen.

How to formulate suitable check-in questions – what I have observed

“Check-in questions are childish,” so one member of the development team stated, which stimulated a vibrant discussion that filled our 15 minutes during our daily. “If we want to reach our goals, we need to be efficient and serious about our work.”

As a reflective person, I certainly scrutinized this statement and made a thorough investigation of the relevancy of check-in questions. And guess what I found? Check-in questions are not childish.

Why do we even “check in”? Why do we need to arrive? What benefit do we expect from asking a supposedly “random” question at the beginning of a meeting?

Before the serious business starts, it is an excellent method to deflate the “tension-balloon” and to talk about something everyone can contribute to; a topic that needs less rational thinking and rather stimulates an intuitive answer.

The art of the question matters

Think about it like this: Everyone comes to work in a certain mood, has hobbies, specific topics of interests or recent happenings that circulate his or her minds. I believe that you can get every person to speak about something they are passionate or currently thinking about.

It is about who

However, I have observed that the challenge lies within the “who.” Who am I sharing these thoughts with? Some individuals consider topics outside the scope of their business (e.g., philosophical, fictive, abstract questions) as personal and intimate; subjects they feel uncomfortable sharing in a large group of colleagues. Check-in questions hence become vexing and not pleasant.

How do I deal with it?

  1. Know your audience
    Are you dealing with a loquacious, young-spirited, very open-minded, knowledge-seeking and sharing team or is your team filled with timid, closed-minded, not very cooperative individuals? Or even a mix of both?
  2. Formulate check-in questions that suit your audience
    The more non-cooperative and closed-minded your team, the less likely it is to be successful with personal or fictive questions (e.g., What do you appreciate about yourself?). I have noticed that answering rating and guessing questions positively correlates with closed-minded teams, provided that the question is pragmatic, non-personal and relevant. For mixed teams choose questions that are fun, non-personal, value-creating; and for open-minded teams make sure your question is fun or challenging, informative and creative.
  3. Make participation voluntarily but very attractive
    Clarify, that answering check-in questions is voluntarily, but make them damn attractive to answer. Make people want to be part of the discussion.

Here are a few example questions for each group:

Open-minded

Closed-minded

Mixed

Consequently, a team that communicates well works well together. Vivid check-in time is an indicator for an open-minded and motivated team. Know your audience and slip in questions that trigger a conversation.

Lastly, a tip I learned from my colleague: The word “check-in question” may put people off – ask the question without mentioning that you are about to ask a check-in question.

Die Suche nach dem Warum – und wie Sie Ihre Vision finden

Ich arbeite jeden Tag mit Teams zusammen, die auf ambitionierte Ziele hinarbeiten. Sie bereiten beispielsweise den Market-Launch eines völlig neuartigen Hardware-Produkts vor oder überarbeiten das bestehende IT-System grundlegend. Diese Produkte erweitern das bisherige Angebot des Unternehmens. Sie sind Teil der Weiterentwicklung des aktuellen Geschäftsmodells und zahlen auf die Neuausrichtung ein, die vom Top-Management angestrebt wird. Die Teams selbst sehen jedoch häufig nur eines: Diese neuartigen Produkte passen nicht zum bisherigen Angebot des Unternehmens. Und so steht immer wieder die unausgesprochene Frage im Raum: Warum machen wir das?

Die Antwort auf dieses Warum bleibt man den Teams oft schuldig. Man gibt ihnen keine Vision, zeichnet ihnen kein Bild der Zukunft und lässt sie im Ungewissen, worauf ihre Arbeit einzahlt. Wenn wir uns die folgende Geschichte ansehen, wird jedoch deutlich, welchen entscheidenden Unterschied ein solches Zukunftsbild bewirken kann:

Ein Fremder geht durch die Gassen einer Stadt. Er trifft auf drei Maurer und sieht ihnen bei der Arbeit zu. Nach einiger Zeit fragt er die drei, was sie da tun. „Das sehen Sie doch”, erwidert der erste mürrisch, „Ich bearbeite einen Stein.” Und der zweite Maurer, der das Gleiche tut, sagt gelangweilt: „Na, ich errichte eine Mauer.” Der dritte Maurer allerdings antwortet mit glänzenden Augen: „Ich baue eine Kathedrale.”

Wir wollen alle eine Kathedrale bauen

Warum ist eine Vision wie der Bau einer Kathedrale so wichtig für uns? Weil wir alle auf der Suche nach unserem persönlichen Warum sind, das uns jeden Tag aufs Neue motiviert. Wir sind auf der Suche nach einer Vision, die unsere persönlichen Werte widerspiegelt. Und nach einer Organisation, die nach diesen Werten ausgerichtet ist und in der wir durch unsere tägliche Arbeit zur Umsetzung dieser Vision beitragen können. Wir wollen nicht einfach nur Stein auf Stein setzen. Wir wollen in 10 Jahren zu unseren Kindern sagen können: Das, was ich getan habe, hat etwas bewirkt. Siehst du diese Kathedrale dort? Die habe ich miterrichtet! Besonders in Zeiten der Veränderung und bei der Neuausrichtung eines Unternehmens braucht jeder Mitarbeiter und jedes Team ein solches Ziel vor Augen. Ein Ziel, das die Hoffnung auf Verbesserung aufkeimen lässt und den Weg in die neue Zukunft zeigt.

Und doch fehlt vielen Teams und Unternehmen eine solche Vision. Woran kann das liegen? Zum einen mangelt es oft an Zeit und andererseits fehlt das Wissen darüber, wie man überhaupt eine Vision entwickelt. Dabei ist das gar nicht so schwer.

Der Bauplan für Ihre Vision

Der erste Schritt ist meiner Erfahrung nach, sich als Führungspersönlichkeit – sei es als Product Owner oder Cluster Lead – die Zeit zu nehmen, um sich selbst darüber klar zu werden: Warum brauchen wir dieses Produkt? Eine Vision wirkt durch die Kraft der Worte, daher sollten Sie diesen ersten Entwurf Ihres Zukunftsbildes niederschreiben. Und dann stellen Sie sich die folgenden Fragen:

Wenn Sie jede dieser Antworten mit Ja beantworten können, dann nehmen Sie Ihre Vision und reden Sie darüber. Teilen Sie diese mit Sparring-Partnern und passen Sie sie immer wieder an. Sobald Sie Ihre Vision durch Iterationen entsprechend nachgeschärft haben, können Sie diese Ihrem Team vorstellen. Freuen Sie sich auf das Feedback, das ihnen dabei helfen wird, Ihr Zukunftsbild noch präziser zu formulieren.

Anschließend bleibt noch ein letzter wichtiger Schritt: Schicken Sie das Team mit dieser Vision auf die Suche nach dem Wie. Wie können wir als Team diese Vision erreichen? Welche Schritte sind notwendig? Seien Sie für Ihr Team da und beantworten Sie dessen Fragen. Und vor allem: Beobachten Sie, wie sich die Zusammenarbeit positiv verändert!

Agilität muss man aushalten können – Szenen aus der Praxis

1. Sackgasse Selbstorganisation – wenn keiner pullt

Auch bei borisgloger consulting richten wir den Blick regelmäßig nach innen. Retrospektiven sind für uns ein fester Bestandteil, um gemeinsam herauszufinden, mit welchen konkreten Maßnahmen wir Verbesserungen herbeiführen können. Mit zwei weiteren Kollegen übernahm ich die Planung einer dieser Retrospektiven. Die Wahl fiel auf ein Format, bei dem das Team in zwei Gruppen aufgeteilt wird, die sich am Ende die erarbeiteten Ergebnisse gegenseitig vorstellen. Warum? Weil man bei diesem Format gleich zweimal Feedback bekommt: einmal in der Teilgruppe und danach beim Vorstellen und Challengen der Ergebnisse am Ende.

Alle waren mit dem Ergebnis zufrieden. Zuletzt sollten noch die zuständigen Kollegen gefunden werden, die die erarbeiteten Maßnahmen dann angehen und umsetzen würden. Die Frage „Wer kümmert sich drum?“ stand im Raum. Schweigen. Auch nach einer Weile gab es kein „hier“ zu hören. Selbst in selbstorganisierten Unternehmen ist das nicht unbedingt überraschend. Dennoch, für einige im Team war das höchst unbefriedigend. Die Gründe für die Zurückhaltung sind vielseitig: Die eigene Priorisierung der Aufgaben, wichtige andere Commitments am gleichen Tag etc. Wie schafft man es trotzdem, die Verantwortung zu verteilen? Das Pull-Prinzip, nach dem wir arbeiten, fordert, dass die Arbeit im agilen Kontext freiwillig gezogen und eben nicht angeordnet wird.

Option A: Vielleicht werden die definierten Maßnahmen später gezogen oder auch gar nicht, wenn anderes einfach höher priorisiert ist.
Option B: Der ScrumMaster weist daraufhin, dass die Aufgabe auch gemeinsam übernommen werden kann und motiviert dadurch neuere Teammitglieder, den Sprung ins kalte Wasser zu wagen.
Option C: Der Product Owner priorisiert diese Aufgabe höher und vermittelt damit, dass die Aufgabe wichtig ist und gezogen werden sollte.

Wenn Teams mit Scrum zu arbeiten beginnen, ist das freiwillige Pull-Prinzip oft schwierig zu akzeptieren oder schwer nachvollziehbar. Ist es nicht viel einfacher, Aufgaben direkt zu verteilen anstatt zu warten? Das wäre am Anfang tatsächlich einfacher. Nur, ist es eine nachhaltige Alternative, die Aktivitäten per Ansage zu verteilen? Wie groß ist dann die Wahrscheinlichkeit, dass sie mit der notwendigen Motivation und Konsequenz umgesetzt werden? Was bleibt dafür im Gegenzug liegen? Hier braucht es Mut, unterschiedliche Optionen auszuprobieren und darauf zu vertrauen, dass die Teammitglieder eine Lösung finden werden.

2. Commitment muss gelernt werden

Gleiches Thema, anderes Setting. Ich hatte zu einer teamübergreifenden Retrospektive eingeladen. Es sollten Vertreter von zwei Teams geschickt werden. Ich erhielt die Zusage aller Kollegen und bereitete die Retro vor.

13:59 Uhr am Tag der Retro – Wir warteten auf vier Teilnehmer. Dafür hatte ein Team noch weitere Kollegen mitgebracht. Enttäuscht über das Nichterscheinen der Kollegen schlug jemand vor, die Retro abzusagen oder zumindest dafür zu sorgen, dass aus jedem Team gleich viele Personen am Meeting teilnehmen würden, damit es gerecht blieb. Das kam für mich nicht in Frage.

Ich konnte die anderen überzeugen, die Retro genau mit jenen Personen durchzuführen, die gekommen waren – ein Grundsatz, der auch im Open Space Format Anwendung findet. Mit der Aussage „Diejenigen, die kommen, sind die richtigen“ haben wir unsere Retrospektive durchgeführt und sogar die Timebox eingehalten. Es kamen tolle Ergebnisse dabei heraus und das Meeting war ein voller Erfolg!

Auch hier waren die Beteiligten erst unzufrieden mit der Situation. Und auch in diesem Fall spielt das Prinzip der Freiwilligkeit eine Rolle. Im „Open Space“ kennt man zudem das Gesetz der zwei Füße, das besagt, dass jeder nur dann erscheint, wenn er oder sie etwas lernen oder einen Beitrag leisten kann. Das war in diesem Meeting der Fall.

Agilität braucht viel Geduld und Durchhaltevermögen. Die Beteiligten dürfen die Prinzipien selbst in schwierigen Situationen nicht fallen lassen, auch wenn es Zeit braucht, bis alle an Bord sind und die agilen Werte und Prinzipien leben können.

Bis dahin gilt: In solchen Situationen muss man Agilität einfach mal aushalten können.

Foto: CC0 Creative Commons – pixabay, Pexels

Fostering cultural change by failing to deliver

What do cultural change and improving delivery results have to do with one another? This could very well be a question posed in any business environment that is facing calls for change and embracing new ways of thinking. Often by inertia, many companies, especially if they are doing well, will be quite resistant to change because they are doing well enough.

The fundamental assumption is that cultural change is about improving performance and therefore improving delivery. In that respect cultural change means living values such as openness, commitment, respect and courage. It also means building accountability where people in the company do things not because they have to do them, but because they want to do them. In essence, it is about developing and continuously refining an environment that enables seeing everyone’s role in an organisation not as a passive component, but an active contributor.

But, how is it connected to delivery? That is both simple and very difficult. The simple part is that by living the above-mentioned values individuals at all levels of an organisation are able to play accountable, self-reflecting roles who share a common vision and goal, therefore putting their efforts towards achieving it as a collective and improving performance. The difficult part is convincing people that this is worthwhile, and facilitating a process that will help them share the same vision and the same goal.

Change – everyone’s responsibility

So, who is responsible for bringing about cultural change? The simple answer is, everyone. It is a matter of having the management level committing and living the values and then unequivocally communicate them through the organisation. The more people in the organisation become acquainted with the values, the easier it will be to create a spontaneous communication matrix where the vision and values related to it are communicated and lived by, from meetings to lunch breaks. Clearly and consistently communicating values and visions and living those values will be the best form of feedback to everyone, that this is the way to go. This is what makes a team that does work, into a team that wants to do work and enjoys being a part of what it is doing.

The challenge, however, is that change, all other things remaining constant, is usually difficult. Not only that, but the saying ‘if it isn’t broken, don’t try to fix it’ goes a long way in thwarting innovation.

How to initiate change when everything seems okay

The benefits of change described above may be completely clear to the management, and the people in the company, but until they are in some kind of trouble and need to change something, will they do something about it? It is a bit like a company selling goods online. They have been doing well for years, but the introduction of new companies who are offering the same goods through a more user-friendly webpage, they are beginning to see a drop in their market share. The competitors have, on the other hand, been seeing a steady increase. Looking back, they could have changed, for example improving their 10-year-old webpage, which was clearly out of date and putting some customers off. Instead they relied on their previous performance and reputation thus ignoring the need for change even though the signs were there. Now, that the results are consistently indicating something is not right they are hearing the alarm bells ringing. And what do they do? They develop a new web page, by which time some damage has been done and their competitors have perhaps gained the upper hand. This tells us two things:

The example above can be put into a different context and at a different level. Imagine a team inside a company working on a new software. They have a large user story that they have committed to resolving over a period of time, i.e. a several sprints. They began working on them, but soon realised that they might not be making the release date because testing software is preventing them from carrying out tests as they develop rather relying on the end test. Although they have a development plan, they are not reflecting on the risks and communicating them. In other words, they have not embraced a culture which gives them the freedom to organise their work by continuously reflecting and producing smaller functional releases. With the deadline and the all-important release looming large, what does the team do?

The art of letting them fail

If you are the Product Owner, and your goal is cultural change, which you believe will bring better performance in the future, you will not intervene. Even if that means that the team will probably fail to deliver a functional product? Yes, even if that is what it takes. Of course, you weigh out the risks and benefits, but if you are serious about investing in cultural change, and having a real team, then you may realise that it is better off letting them fail.

The logic behind this is that just like the goods provider with an outdated website, there needs to be a trigger for the team or a company to learn to change and live the agile principles. If you as the Product Owner step in the team has not learnt much. In fact, if they are new to the agile working environment intervention will only end up supporting their view that old ways are best. They will be happy to play with agile methods, but not take the associated responsibility. And as always, the product owner (or the big boss) solves it all. If, on the other hand, you let them fail you have probably done them a favour because they will be able to question what they are doing as a team and realise that the commitment and responsibility were not there from their side. In other words, you as a company will fail on delivering in the short run but will have probably succeeded in massively investing in cultural change that will yield results in the long run.

Support the learning process

This does not mean that you need to let everything burn down in an instant. Culture change is also about patience, trust, and strategic thinking. All are immensely important before embarking on letting teams experience failure in order to stimulate change culture. First of all, there needs to be consensus that cultural change is a strategy that requires commitment, even if it does not (and it probably won’t) work immediately. As a ScrumMaster and a Product Owner you need to have trust that the team will be able to reflect on the results and the reasons for the results. You also need to show patience and provide an enabling environment for the team to reflect and find a solution to the reasons for the failure. Communicating values and visions, while also living by them is crucial in this respect because it will help the team feel that they themselves have a place to reflect and therefore move forward. Ultimately, what you as both a ScrumMaster or a Product Owner want to have is a team that are change agents.

Wie man einen Wal in die Freiheit springen lässt – der Free Willy Ride in Agile Organizations

Mittlerweile sind in Unternehmen die 5 Phasen der Veränderung (bzw. der Trauer) nach Kübler-Ross allseits bekannt. Scheinbar bildet das Modell etwas ab, das Menschen mal mehr, mal weniger wiedererkennen und das ihnen in Veränderungsprozessen Orientierung bietet. Nach nunmehr einiger Zeit in der Rolle als ScrumMaster stelle ich folgende These auf:

Das Hineintragen des agilen Prinzips der Freiwilligkeit in ein klassisch arbeitendes Team verläuft (in den meisten Fällen) ebenfalls nach einem bestimmten Muster.

Ich nenne dieses Muster „Free Willy Ride in Agile Organizations“ nach Vera Ferreira Mafra. Zum einen amüsiert mich das Wortspiel im Englischen und zum anderen erscheint mir die Geschichte des berühmten Film-Wals „Free Willy“ eine gute Analogie zu sein. Ein Wal in Gefangenschaft (Kultur des Command & Control) schafft durch die Freundschaft mit einem Jungen (Agilität & ScrumMaster) den Sprung in die Freiheit (Leben der Freiwilligkeit & neue Haltung zur Arbeit). Die dramatische Komponente des Films, dass der Tierparkbesitzer Free Willy töten möchte, um die Versicherungsprämie zu kassieren, klammere ich für meine Zwecke aus.

Was ist der Free Willy Ride?

Der Free Willy Ride besteht aus acht Stationen: Kennenlernen – Sacken lassen – konfrontiert werden – Widerstand leisten – Verstehen – Transfer starten – Einspruch erheben – selbstverständlich anwenden

Veränderung

1. Kennenlernen
Zu Beginn hat der ScrumMaster einen großen Beitrag als Trainer zu leisten, um die agilen Prinzipien und Werte in einem Team bekannt zu machen. Durch Schulungen, Formate wie Brown Bag Sessions oder Scrum Shots, Literatur und und und erfahren die Teammitglieder, dass Freiwilligkeit ein agiles Prinzip ist. Die Augen werden groß, die Ohren spitz: Freiwilligkeit – das klingt gut!

2. Sacken lassen
Was eingangs zu großen Augen geführt hat, entpuppt sich bald als diffuse Worthülse. Als ScrumMaster lege ich meinen Fokus gerade auf Fokus und Commitment. Das Ziel ist, die Teams in einen Liefermodus zu bringen und Vertrauen zu mir aufzubauen. Wo macht sich denn nun die Freiwilligkeit bemerkbar?

3. Konfrontiert werden
Nachdem mich das Team als ScrumMaster nun schon ein wenig kennt und mit den Basics bereits erste Erfolge gefeiert hat, zaubere ich das Prinzip der Freiwilligkeit aus dem Hut. Ich nutze jede sich mir bietende Meetingsituation, um verschiedene agile Prinzipien gebetsmühlenartig zu platzieren:

Wenn ich merke, dass ein Meeting unzureichend vorbereitet ist und in vielschichtige Diskussionen ausartet, stehe ich auf, berufe mich ebenfalls auf das Prinzip der zwei Füße und verlasse ohne weitere Erklärung den Meetingraum. Ein völlig perplexes Team bleibt zurück. Ich ziehe es durch und das Team erlebt Freiwilligkeit. In den Teammitgliedern bewegt es etwas, gut so.

4. Widerstand leisten
Freiwilligkeit als Gesprächsthema steht jetzt im Raum. Egal wie sich die Teammitglieder drehen und wenden, ich piekse mit der Freiwilligkeit. Und jetzt passiert etwas Spannendes: Die Teammitglieder instrumentalisieren das Prinzip der Freiwilligkeit. Es fallen Sätze wie:

Die Teams führen das Thema ad absurdum, aus den Mündern tönen Ironie und Skepsis – aber: Sie sprechen darüber und nutzen die Begrifflichkeiten. Klammheimlich vollführe ich Freudentänze: Endlich habe ich eine Basis, auf der ich in die konstruktive Auseinandersetzung mit dem Team gehen kann.

5. Verstehen
„Lasst uns doch mal eine kleine Session starten, die wir einzig und allein dem Thema Freiwilligkeit widmen!“ Ich erkläre dem Team, in welchen Rahmen sich diese proklamierte Freiwilligkeit einbettet. Ich erzähle ihnen von ihrer Aufgabe als Dev-Team, die Qualität des Produkts sicherzustellen, und von Team-Commitment. Ich erkläre ihnen, dass die Freiwilligkeit ihre Wahlmöglichkeiten erweitert: Sie dürfen auf einmal „Nein“ sagen und sie dürfen auf einmal sagen, bei welchen Aufgaben sie sich selbst sehen.

6. Transfer starten
Freiwilligkeit ist nach der Session kein Schwarz-Weiß-Thema mehr. An manchen Teammitgliedern ist das Thema ohnehin vorbeigegangen, weil es ihnen nicht wichtig erscheint, andere verweilen weiterhin im Widerstand. Das ist völlig okay, ich konzentriere mich auf diejenigen, die neugierig fragen und sich in ihrem Alltag damit auseinandersetzen. „Also ich sehe gerade ehrlich gesagt keinen Mehrwert für mich in diesem Meeting und einen Beitrag leisten kann ich auch nicht … Gesetz der zwei Füße, oder?“ „Jetzt ist der richtige Zeitpunkt zu pullen, oder?“ Sie sprechen ihre Gedanken aus und hängen gefühlt an jeden Satz ein fragendes „oder?“, oder sie machen Aussagen und gehen am Satzende etwas mit ihrer Stimme hoch – meine detektivischen Sensoren springen an: Eine Frage als Aussage getarnt. Aha! Sie erfragen mein Feedback und tarieren aus, ob sie richtig liegen oder ob noch etwas fehlt.

7. Einspruch erheben
Meist haben die Teammitglieder nun für sich selbst in den verschiedensten Situationen hinterfragt, wann das Prinzip der Freiwilligkeit für sie greift und wie es mit anderen Prinzipien zusammenhängt. Im nächsten Schritt werden sie mutiger. Sie beobachten gezielt Situationen und nehmen für andere die Rolle des Richters ein: „Klaus, als PO ist es nicht deine Aufgabe, Tasks zuzuweisen! Das widerspricht dem Pull-Prinzip!“ Jackpot! Ich bin nicht mehr ein einsames querulantisches Fähnchen im Wind mit der Aufschrift Scrum. Stattdessen habe ich aus dem Team selbst heraus Fürsprecher gewinnen können! Dem Schneeballprinzip folgend, setzen sich zunehmend mehr Teammitglieder damit auseinander und es wird zum Usus im Team.

8. Selbstverständlich anwenden
Und dann springt Free Willy in die Freiheit und lässt los! Die Freiwilligkeit ist dem Team durch die bewusste Auseinandersetzung und durch die Reflexion in spezifischen Situationen in Fleisch und Blut übergegangen. Sie ist zum integralen Bestandteil der Arbeitsweise geworden.

Es hat mit einer Blogidee zum Thema Freiwilligkeit im agilen Arbeitsumfeld und einem Wortspiel begonnen. Ich wollte einen Namen für mein skizziertes Muster finden und das hat für mich persönlich den Wal schließlich zu einem Sinnbild für Freiwilligkeit in Teams werden lassen. Auf dem Weg zur gelebten Freiwilligkeit beobachte ich meine Teams und frage mich: „In welcher Phase schwimmt Free Willy gerade rum?“

Foto: CC0 Creative Commons – pixabay, Free-Photos

Feedback oder die Kunst der Anerkennung

Wir Menschen streben nach Anerkennung. Unsere Motivation steigt, wenn unsere Arbeit „erkannt“ und wertgeschätzt wird. Diese Wertschätzung können wir durch unser Umfeld, also Kollegen, Freunde oder Familie erhalten, aber auch durch uns selbst. Und doch passiert beides immer noch viel zu selten.

Konstruktives und wertschätzendes Feedback kann das Bedürfnis nach Anerkennung der eigenen Arbeit bedienen. Es kann dabei helfen, die eigenen Ressourcen besser einzusetzen, produktiver zu werden und Erfolgspotentiale weiterzuentwickeln. Nicht zuletzt bietet es die Chance, aus Fehlern zu lernen und blinde Flecken aufzudecken. Halten wir uns bei der Arbeit mit Feedback zurück, bringen wir uns selbst und vielleicht auch unser Team oder ein ganzes Unternehmen um den Erfolg.

Die Devise heißt also: Schwächen abbauen und Stärken aufbauen. Doch leider ist Feedback oft eine Mogelpackung, wenn es falsch formuliert ist und dadurch verletzend wird. Wissenschaftliche Erkenntnisse beweisen, dass es entscheidend ist, wie man etwas sagt.

Wie formuliert und gibt man Feedback?

Die Kunst ist also, Feedback wertschätzend zu formulieren. Es sollte beschreibend sein und nicht bewertend. Es sollte sich auf eine erlebte Situation und ein konkretes Beispiel beziehen und am besten sofort im Anschluss gegeben werden. So, dass man über veränderbares Verhalten spricht – konkret und nicht allgemein gehalten, mit klar formulierten Aussagen. Besonders positive Wahrnehmungen und Gefühle können und sollen mitgeteilt werden. Wichtig ist dabei, stets aus eigener Perspektive für sich zu sprechen. Gut wäre es, eine Gesprächsatmosphäre so zu kreieren, die nicht unter Zeitdruck und in der Öffentlichkeit geschieht, sodass der Feedbacknehmer auch die Zeit hat, das Feedback in Ruhe zu verarbeiten.

Um das Feedback zu entschärfen und nicht als verletzende Waffe einzusetzen, sollten Sie sich im Voraus über die folgenden Punkte klar werden:

Feedback geben in drei Schritten

Wenn Sie diese grundlegenden Fragen geklärt haben, hilft es, das Feedback in drei Schritte zu gliedern:

  1. Klären Sie zunächst den Sachverhalt und stellen Sie sich die Frage: „Was ist geschehen?“
  2. Danach folgt eine Offenbarung bzw. Beschreibung der Gefühle: „Wie geht es mir damit?“
  3. Die konstruktive Komponente ist schließlich entscheidend für die Umsetzung: „Wie kann für die Zukunft eine Verbesserung herbeigeführt werden?“ Wichtig dabei ist, dass Sie realistische Maßnahmen vorschlagen, die auch umgesetzt werden können.

Fakt ist, dass Selbst- und Fremdeinschätzung meistens voneinander abweichen. Des Weiteren ist jedes abgegebene Feedback zu einer Person anders, weil jedes Individuum andere Dinge an der beobachteten Person wahrnimmt. Die Gefahr ist daher groß, missverstanden oder überhaupt nicht verstanden zu werden. Deshalb seien Sie offen, hören Sie beim Feedback nehmen aktiv zu und fragen Sie bei Unklarheiten beim Gesprächspartner nach. Nur so können beide Seiten sichergehen, dass Ihre Botschaften auch ankommen.

Auf den Punkt gebracht

Feedback erlaubt uns, das eigene Verhalten aus der Perspektive des Gegenübers zu betrachten und es damit auf den Prüfstand zu stellen. Somit haben wir die Chance uns weiterzuentwickeln und in dem was wir tun noch besser zu werden. Für den Feedbackgeber ist die Kunst, die konstruktive Kritik wertschätzend zu formulieren, damit der Empfänger das Feedback auch annehmen kann und nicht in eine abwehrende Haltung gezwungen wird. Fragen Sie den Empfänger ruhig vorher, ob Sie Feedback geben dürfen. Als Empfänger lohnt es sich bei Unklarheiten oder nicht nachvollziehbaren Beispielen nachzufragen, was gemeint ist und in den Dialog zu treten. Denn nur so profitieren Sie und damit Ihr Unternehmen davon.

Wohnung putzen mit dem Minimum Viable Product

„MVP“ – Minimum Viable Product – ist ein verbrannter Begriff. Er wurde missbraucht, um eine Brücke zwischen dem klassischen und dem agilen Projektmanagement zu schlagen. Arbeitspakete des Projektablaufplans werden kurzerhand zu MVPs umgetauft – so wirkt alles schon viel agiler. Dabei wird jedoch eines vergessen: Ein MVP ist ein Produkt, das mit seinen Eigenschaften bereits die minimalen Anforderungen des Kunden abdeckt. Ein Produkt, das in sich geschlossen ist und einen Mehrwert bietet. Etwas, das schon verkauft werden könnte und wofür der Kunde bezahlen würde. Wenn der Kunde beispielsweise sagt, er möchte von Punkt A zu Punkt B gelangen, dann ist ihm mit einem Reifen nicht geholfen. Dazu benötigt er schon ein Fortbewegungsmittel, das seiner wichtigsten Anforderung – der Fortbewegung – genügt. Aufbauend auf diesem MVP können anschließend weitere Anforderungen hinzugefügt werden – der Kundennutzen wächst und ein neues MVP entsteht. Trotzdem fällt es vielen schwer, die Übertragung aus der klassischen Welt mit ihrer Meilensteinplanung hin zur Customer Journey mit MVPs und einem Releaseplan nachzuvollziehen. Für den Ausbruch aus diesen eingefahrenen Denkmustern braucht man manchmal aber nur einen kreativen Ansatz, um den Zusammenhang klarer zu machen. Was eignet sich dafür besser als eine alltägliche Situation?

Putzen Sie Ihre Wohnung – MVP 1

Angenommen, der Wohnungsputz wird hauptsächlich von Ihrer Partnerin oder Ihrem Partner durchgeführt. Stellen Sie sich vor, sie wollen ihr oder ihm diese Aufgabe nun einmal komplett abnehmen. Wo fangen Sie an zu putzen? Welche Räume nehmen Sie sich vor? Und die wichtigste Frage: Wie viel müssen Sie putzen, damit sie oder er zufrieden ist, Sie aber nicht mehr als nötig gemacht haben? Dafür ist für Sie wichtig zu wissen, was der „Putz-Standard“ bei Ihnen zuhause ist. Die Mindestanforderungen Ihrer Partnerin oder Ihres Partners an den Wohnungsputz sind ein wichtiger Teil der Vorbereitung. Sinnvoll ist es außerdem, die Aufgaben zu sammeln, die in der gesamten Wohnung regelmäßig anfallen. Diese Aufgaben können gut den jeweiligen Räumen zugeordnet werden. So entsteht eine in Rubriken strukturierte Sammlung wie „Wohnzimmer“, „Küche“, „Bad“ und „Schlafzimmer“. Diese Rubriken können Sie mit Themenklammern gleichsetzen, also sogenannten Epics.
Wenn Sie nun also wissen, dass Ihre Partnerin oder Ihr Partner glücklich ist, wenn in jedem Raum gewisse Aufgaben erledigt sind, so ergibt sich für Sie eine Anzahl an Aufgaben, die in Summe das MVP ergeben. Nach der Erledigung sämtlicher Aufgaben, die zur Erfüllung des MVPs beitragen, kann das Ergebnis vorgeführt werden. Sie werden recht schnell merken, ob Ihre Überraschung geglückt ist und Sie alle Anforderungen erfüllt haben!

Stellen Sie sich vor, die Schwiegermutter kommt zu Besuch – MVP 2

Nun ist also Ihre Partnerin oder Ihr Partner durch dieses MVP zufrieden gestellt. Was passiert allerdings, wenn sich spontan die Schwiegermutter mit einem Besuch ankündigt? Dann muss das ursprüngliche MVP ein bisschen erweitert werden. Und zwar um genau die Aufgaben, die dabei helfen, auch die Schwiegermutter zufrieden zu stellen. Die Anforderungen aus dem ersten MVP bestehen weiterhin, es gibt jedoch Aufgaben, die es ergänzen. Das Gesamtpaket ergibt dann ein neues MVP.
Die gleiche Vorgehensweise kann auch in der Produktentwicklung angewendet werden. Auch dort sollte angestrebt werden, mit einem ersten Produkt, das dem Kunden einen Mehrwert bietet, den Markt bedienen zu können. Somit kann erstes Kundenfeedback frühestmöglich in die nächste Iteration einfließen. Außerdem lassen sich mit diesem Ansatz Fehlinvestitionen vermeiden und somit das Risiko minimieren, indem früh erkannt wird, ob eine Weiterentwicklung des MVP rentabel ist und welche Funktionalitäten vom Kunden überhaupt gewünscht und bezahlt werden.
Allgemein ist, wie auch beim Wohnungsputz, dabei zu berücksichtigen, wer die Zielgruppe des Produkts ist. So können Unternehmen entlang der Customer Journey ein Produkt entwickeln, das die rentabelsten Funktionalitäten enthält und die Kundenbedürfnisse befriedigt. Im Gegensatz zur klassischen Produktentwicklung setzt der Cashflow hierbei wesentlich früher ein, die Reaktions- sowie Entwicklungszeiten sind kürzer und der Kunde steht im Zentrum der Überlegungen. Der Trick ist also eine geänderte Perspektive auf die Produktentstehung.

Magic System Mapping oder "How to make toast"

Ein und dasselbe Thema – viele Sichtweisen und Wissensstände. So sieht es oft in einem Team aus, bevor es an die Entwicklung eines Produkts geht oder ein bestimmtes Problem gelöst werden soll. Mit „Magic System Mapping“ lassen sich individuelle Sichtweisen und Standpunkte, die es innerhalb einer Gruppe zu einem Thema oder Problem gibt, zu einem Gesamtbild zusammenführen.
Magic System Mapping beruht auf ähnlichen Prinzipien wie Magic Estimation: non-verbale Kommunikation wird visualisiert. Ich habe diese Methode schon für unterschiedliche Zwecke verwendet:

Wie funktioniert Magic System Mapping?

Um die Methode zu erklären, beginnt man mit einer einfachen Design-Übung, die je nach Gruppengröße 10 bis 15 Minuten dauert. Ausgedacht hat sich das ganze Tom Wujec, Businesss-Visualisierungs-Pionier und Mitgründer der Singularity University, der die Hintergründe fabelhaft in einem TED-Talk vorstellt.

Was man dafür braucht
Anmoderation der Aufgabe

Die Teilnehmer werden begrüßt, anschließend kündigt ihr an, dass ihr mit ihnen jetzt eine viertelstündige Design-Aufgabe mit anschließender Reflexion durchführt. Dazu bittet ihr die Anwesenden, in den nächsten fünf Minuten auf Post-its aufzuzeichnen, wie sie Toast machen. Dazu gibt es drei Regeln:

  1. Jeder macht die Aufgabe im ersten Schritt für sich.
  2. Nur ein „Toastmachschritt“ auf je einem Post-it.
  3. Das Ganze ist kein Kunstwettbewerb.

Optional könnt ihr noch erwähnen, dass zehn Post-its pro Person ein guter Anhaltspunkt für die Granularität der einzelnen Schritte sind. Falls noch nicht geschehen, könnt ihr jetzt die Post-its austeilen.

Review der Toast-Modelle

Nach Ablauf der drei Minuten bittet ihr einen Kollegen damit anzufangen, seine Toastmachschritte auf der freien Wandfläche von links nach rechts aufzuhängen. Dann geht es weiter mit der nächsten Person, er oder sie hängt sein Toastmodell darüber oder darunter. Falls er oder sie ähnliche Schritte hat, können sie unter bzw. übereinander angeordnet werden. Das Ganze wiederholt ihr, bis jeder sein Toastmodell geteilt hat.
Nachdem alle ihre Modelle aufgehängt haben, könnt ihr die Teilnehmenden fragen, was ihnen an den unterschiedlichen Modellen auffällt. Zum Beispiel: Wie komplex oder simpel sind die jeweiligen Modelle, werden dabei Personen oder keine Personen gezeigt? Diese Phase könnt ihr kurz halten. Zwei bis drei Wortmeldungen aus der Gruppe genügen.

Magic System Mapping

6 verschiedene Toast-Modelle im Vergleich

Zusammenführen der Toast-Modelle

Im letzten Schritt geht es darum, eine Synthese zwischen allen Toastmodellen herzustellen. Hier ist als Anforderung: Im finalen Bild darf es keine Duplikate mehr geben und es muss eine Reihenfolge erkennbar sein – und das Ganze soll ohne verbale Kommunikation gelöst werden. Im normalen Arbeitskontext kommt Letzteres auch häufig vor: Beispielsweise bei der Priorisierung von Anforderungen oder dem Treffen von Entscheidungen, ohne dass das Team mit den Stakeholdern sprechen kann.
In diesem Prozess werden sehr schnell unterschiedliche Sichtweisen und auch Konflikte in der Gruppe deutlich. Ziel ist es, eine Einigung zu finden und das im Gesamtmodell abzubilden. Schweigen ist hierbei Gold Wert. Interessanterweise funktioniert das ohne verbale Kommunikation deutlich schneller als mit.
Als Zeitvorgabe bieten sich für diesen Schritt fünf Minuten an.

Magic System Mapping

Das zusammengeführte Toastmodell ohne Duplikate in einer Reihenfolge

 

Reflexion

Nachdem die Gruppe ein Gesamtbild erarbeitet hat, gibt es erst einmal eine Runde Applaus. Den Reflexionsprozess kann man mit den folgenden zwei Fragen an die Gruppe starten:

Häufig berichten die Teilnehmenden, dass ihnen die Übung gezeigt hat, wie eingeschränkt ihre eigene Sichtweise auf ein Problem ist und wie unterschiedlich die Denkweisen von verschiedenen Personen sein können. Dieser Punkt wird häufig mit unterschiedlichen Expertisen und Spezialisierung in Verbindung gebracht. Einige Personen sind Spezialisten für einzelne Teilbereiche des Prozesses, die sie besonders stark ausdetaillieren – beispielsweise wie ein Toaster funktioniert – und andere beginnen den Toastprozess beim Weizenkorn, das gesät und bewässert wird. Nur durch die Synthese entsteht ein gesamtes System.
Als weiterer Punkt kommt in der Reflexion oft auf, dass unterschiedliche Perspektiven im System sichtbar gemacht und berücksichtigt werden können. Etwa die Tatsache, dass manche Menschen ihren Toast mit Butter essen und andere das niemals tun würden. Im Toastmodell werden die unterschiedlichen Belegungspräferenzen häufig durch übereinander hängende Post-its dargestellt.
Eine weitere Erkenntnis der Übung ist: Abgebildete Systeme bestehen immer aus Knoten und Verbindungen, die eine Logik herstellen. Die Übersetzung in BPMN-Sprache wäre: flow-basierte Objekte wie Ereignisse oder Aktivitäten und verbindend strukturierende Elemente wie Kanten/Assoziationen oder Gateways.

Anwendung im realen Kontext

Nach der Trockenübung mit dem Toastbeispiel könnt ihr euch eurem tatsächlichen Thema oder Problem zuwenden. Der Ablauf ist am Anfang analog zum Toastbeispiel:

  1. Startet mit eurer Fragestellung – falls sie noch zu grob ist, nehmt euch etwas Zeit, um sie in der Gruppe genauer zu spezifizieren
  2. Sammelt in der Gesamtgruppe die Knotenpunkte
  3. Entwickelt ein Gesamtbild/System in der Gruppe und stellt die Verbindungen her
  4. Verfeinert das System in der Gruppe
  5. Verfeinert das System weiter …
  6. … und weiter

Je mehr Runden ihr in die Verfeinerung des Systems steckt, umso klarer wird das System für die Beteiligten. Im Zuge dessen werdet ihr auf immer feingranularere Probleme oder Abhängigkeiten stoßen, für die es Lösungen zu finden gilt.
Mein Tipp für diese Phase: Teilt euch in Kleingruppen auf und arbeitet einzelne Teile eurer Systems genauer aus. Nehmt euch dafür je nach Größe und Komplexität des Themas 30 bis 60 Minuten Zeit. Danach stellt jede Kleingruppe ihre Ergebnisse vor, sie werden diskutiert und anschließend in das System eingebaut.
Wie viel Zeit ihr für diesen Prozess benötigt, hängt von der Komplexität eurer Fragestellung ab. Ich beginne meistens mit einer dreistündigen Session, in der am Anfang Zeit für die „How to make Toast“ Übung ist. Am Ende wird besprochen, wie an den Ergebnissen weitergearbeitet wird. Ich habe aber auch schon mehrtätige Off-Sites in diesem Stil organisiert.

Eine abschließende Bemerkung

Das Feedback der Teilnehmenden war bisher immer positiv. Die Methode hat nur einen Haken: Das erarbeite System ist eine Momentaufnahme – abhängig von den Beteiligten, und es hat nur Gültigkeit, solange man in der Gruppe zusammenbleibt. Durch den iterativen Ausarbeitungsprozess hat eine Verständigung auf Begrifflichkeiten und Regeln für das System stattgefunden. Ein Außenstehender kann das Abgebildete nur mit Hilfe von guter Dokumentation verstehen.
Das ist aber auch für die Teilnehmenden wichtig: Ab dem Moment, an dem sie den Raum verlassen, machen sie neue Erfahrungen, führen Diskussionen mit Kollegen oder haben Ideen, die Auswirkungen auf das System haben. Was kann man dagegen machen? Man muss den Prozess regelmäßig wiederholen, um ein längerfristiges Alignment herzustellen und das System an die aktuellen Gegebenheiten anzupassen. Am Ende ist es die Auseinandersetzung mit dem richtigen Personenkreis zu einem Thema, was uns am Ende erfolgreich macht. Die Visualisierung ist dabei nur ein Hilfsmittel. In diesem Sinne wünsche ich euch viel Erfolg und Spaß beim kollaborativen Visualisieren.

Ressourcen

Templates zu verschiedenen Themen:
DrawToast
Mural – ein gutes Tool für kollaboratives Visualisieren
Originalartikel erschienen im ProjektMagazin – verwendet mit freundlicher Genehmigung.
Foto: CC0 Creative Commons – pixabay, pexels

ScrumMaster in Aktion: Das Feiern von Erfolgen

Es ist 9.00 Uhr. Wir haben uns vor dem Taskboard versammelt. Es ist alles noch ganz frisch, wir lernen noch, ein Hauch Unsicherheit liegt in der Luft. Der erste Kollege beginnt und hängt seine Tasks um. Die Kollegin folgt. Der erste Task wird auf „Done“ gesetzt. Die erste Aufgabe ist geschafft. Ich lade zum Feiern ein, strahle die Kollegin an. Ich empfinde die erste erledigte Aufgabe als große Genugtuung. Grund genug, um kurz innezuhalten und den Moment wirken zu lassen. Einziger Haken daran: um mich herum nur verdutzte Gesichter, die Kollegin ist verunsichert. Lob für eine solche „Kleinigkeit“ ist sie nicht gewohnt. Sie mache doch nur ihren Job. Auch der Product Owner ist verwirrt: Sollte das hier nicht selbstverständlich sein? Warum also ist der ScrumMaster so begeistert?
Ich merke schnell: Das Problem liegt tiefer. Lob und positive Rückmeldungen gehen hier allen schwer von den Lippen. Aus der Psychologie ist bekannt, dass Belohnung der positiven Verstärkung dient. Damit soll die Wahrscheinlichkeit erhöht werden, dass sich ein gewünschtes Verhalten wiederholt. Situationsgebundene Belohnung kann also durch Loben erfolgen. Dies sollte allerdings nicht zu freigiebig eingesetzt werden, da es sonst unverdient erscheint. Bewiesenermaßen wird das Belohnungssystem jedoch gezielt durch die Wertschätzung unserer Mitmenschen angesprochen – das steigert die Ausschüttung des Glückshormons Dopamin.

Den kleinen Dingen Aufmerksamkeit schenken

Meistens sind es ja die kleinen Dinge, die als selbstverständlich hingenommen werden, und es erscheint uns deshalb nicht nötig, diese wertzuschätzen. Es liegt uns fern, die kleinen Dinge zu sehen, die in Summe zum Gesamterfolg beitragen. Gerade im Prozess der Veränderung ist es jedoch sehr wichtig, diese kleinen positiven Fortschritte zu erkennen und hervorzuheben. Dopamin ist dafür verantwortlich, dass wir Erfahrungen als wohltuend empfinden, in Zukunft werden wir uns an dieses Gefühl erinnern können. So werden diese aktiv unterstützt und in Zukunft höchstwahrscheinlich wiederholt werden. Noch wichtiger als das Lob durch den ScrumMaster und den Product Owner ist das Lob untereinander. Kollegen, die sich gegenseitig zu ihren einzelnen Leistungen wertschätzend äußern, steigern die produktive Zusammenarbeit und den Zusammenhalt im Team.

Das Team mit Freiheiten belohnen

Das Team kann neben diesen kleinen Wertschätzungen auch durch Freiheiten belohnt werden. Vertrauen, das dem Team beispielsweise vom Product Owner entgegengebracht wird, ist eine wertschätzende Handlung, die dazu führen kann, dass das Team bemüht ist, beim nächsten Mal die Erwartungen des Product Owners zu übertreffen. Es wird dadurch selbstbewusster und beginnt, sich selbst mehr zuzutrauen. Damit ist die Grundlage für innovativere und kreativere Lösungen gelegt und das Team wächst noch mehr zusammen. Zugestandene Freiheit wirkt durch ihren wertschätzenden Charakter also ebenfalls als positive Verstärkung und steigert die Produktivität im Scrum-Team.

Gold Cards

Die gleiche Wirkung haben sogenannte Gold Cards, die der Product Owner an die Teammitglieder vergibt. Mit diesen Cards können Mitarbeiter innerhalb eines gewissen Zeitraums einen Teil ihrer Arbeitszeit in etwas investieren, das sie interessiert. Dies kann eine Fortbildung, persönliche Weiterbildung oder Zeit sein, um an eigenen Ideen zu arbeiten. Der Vorteil an dieser Variante ist, dass dem einzelnen Mitarbeiter gegenüber Interesse ausgedrückt wird, nicht nur an der Leistung des Teams.

Eine Release-Party schmeißen

Im skalierten Umfeld gibt es eine weitere mächtige Möglichkeit, das gesamte Team oder sogar mehrere Teams für ihre erbrachten Leistungen zu belohnen. Wie wäre es beispielsweise mit einer Release-Party? Die Teams haben durchgehalten, gekämpft und geliefert. Warum also nicht den Release gebührend mit allen Beteiligten feiern? So kann sogar das Angenehme mit dem Nützlichen verbunden werden: Die Teams können ihre Leistungen bei einer Präsentation von den Stakeholdern und dem gesamten Umfeld anerkennen lassen und anschließend kann sich das Team gebührend selbst feiern.
Zurück zum Geschehen: Ich wiederhole meine Aufforderung, den ersten Task auf „Done“ zu feiern. Peinlich berührt versucht sich die Kollegin aus dem Mittelpunkt zu stehlen. Wir haben noch einen langen Weg vor uns, aber ich werde nicht aufgeben, denn: Gerade am Anfang sind es die kleinen Erfolge, die aus einer Gruppe von Menschen ein Team machen.

Foto: CC0 Creative Commons – pixabay, pexels

Agiles Demand Management im skalierten Umfeld

Klassische Unternehmensbereiche und Scrum treffen oft aufeinander. Fast immer stellt sich dabei auch folgende Frage: Wie kann beides auf einen Nenner gebracht werden? Diese Frage stellt sich auch beim Anforderungsmanagement. Denn im grundlegenden Konzept von Scrum gibt es lediglich die Rollen Product Owner, ScrumMaster und Entwicklungsteam – Boris Gloger hat das Konzept um die Rollen Kunde, Management und Nutzer erweitert. Das klassische Demand Management wie in Großkonzernen, bei dem interne Anforderungen bewertet und gesteuert werden, findet sich in keiner der Rollen direkt wieder.
Der täglichen Arbeit des Anforderungsmanagements kommt die Rolle des Kunden noch am nächsten. Er liefert dem Product Owner jene Impulse, die er in eine Vision bündelt, um dem Entwicklungsteam die richtige Orientierung zu geben. Nun werden in einem Großkonzern auf eine entwickelnde Abteilung jedes Jahr hunderte Anforderungen aus allen Teilen des Unternehmens eingesteuert. Hier reicht die Rolle des methodisch sauber aufgesetzten Kunden nicht mehr aus, um die Anforderung zu handhaben.

Eine Lösung: das Demand Management Team

Doch für diese Problematik im skalierten Umfeld ist die Lösung leichter als gedacht. Bei einer größeren Anzahl von Scrum-Teams wird zwischen Kunde und Chief Product Owner (CPO) ein vorgelagertes Scrum-Team aufgesetzt: das Demand Management Team. Es arbeitet in regulären Sprints und übergibt im Refinement dem CPO die evaluierten und spezifizierten Anforderungen. Bei diesem Refinement können bzw. sollten neben dem CPO und dem Demand Management durchaus auch andere Experten anwesend sein. Schließlich kann ab einem bestimmten Komplexitätsgrad eine einzelne Person nicht die fachliche Tiefe mitbringen, um für Großprojekte alle Anforderungen adäquat zu priorisieren und den Return on Investment bewerten zu können.
Nach dem Overall Refinement werden die Anforderungen in den Sprintzyklen der skaliert zusammenarbeitenden Scrum-Teams bearbeitet. Am Ende des Sprints tritt das Demand Management wieder auf den Plan, um den Kunden und seine zu Beginn des Sprints eingesteuerten Anforderungen im “Overall Review” zu vertreten. Hier hat das Demand Management auch die Möglichkeit, Änderungen des Kunden zu kommunizieren. Sollte es der Kunde einfordern, ist das Demand Management in der Rolle des Transmitters nach diesem Termin auch aussagekräftig zu Zwischenständen und Teillieferungen. In der darauf folgenden “Overall Retro“ wird neben den projektübergreifenden Learnings auch der Rahmen aufgespannt, um die Zusammenarbeit zwischen Demand Management und CPO zu evaluieren und langfristig zu verbessern.
In der Praxis funktioniert diese Lösung sehr gut, dennoch sollten einige Voraussetzungen erfüllt sein, um den Übergang in die Agilität zu vereinfachen. Im ersten Schritt sollten die betroffenen Personen zu einem frühzeitigen Zeitpunkt inhaltlich und methodisch auf den gleichen Wissensstand gesetzt werden, sodass alle Beteiligten die gleiche Vorstellung von Begrifflichkeiten oder Artefakten haben. Sind Methode und Inhalte, sowie deren Anwendung klar, kann im finalen Schritt die Integration eines eigenen Scrum-Teams “Demand Management” angestrebt werden.

Foto: CC0 Creative Commons, pixabay – ulrichw

3 Argumente gegen User Stories und wie ihr ihnen begegnen könnt

In unseren Trainings oder in der Arbeit mit Teams begegnen wir einer Vielfalt von Gründen, warum eine bestimmte agile Praktik in diesem Team nicht angewendet werden kann. Dabei sind die Begründungen nur auf den ersten Blick spezifisch für das jeweilige Team und vor allem sind es in den seltensten Fällen tatsächlich sachliche Gründe, warum etwas nicht geht. Menschen stehen Veränderungen prinzipiell erst einmal kritisch gegenüber. Deshalb werden neue agile Praktiken nicht einfach ausprobiert, sondern meist erst einmal gründlich geprüft.
Daran ist prinzipiell nichts Falsches – unser Gehirn spart viel Energie, wenn es gelernte Praktiken abspielt und nicht immer Neues ausprobiert. Gleichzeitig kann es ganz schön frustrierend sein, wenn man einem Team etwas zeigen möchte und nur Widerstand erntet. Manchmal verbirgt sich hinter der vorgeschobenen rationalen Begründung auch ein Gefühl der Unsicherheit. Ehrlich wäre es, einfach zu sagen: „Ich will es nicht machen! Den alten Prozess kenne ich, der neue macht mir Angst, weil ich noch nicht weiß, was genau passiert.“ Im beruflichen Kontext sind aber wenige so reflektiert und ehrlich und deshalb lohnt es sich, sich als Scrum Master oder Agile Coach schon einmal auf die typischen Widerstände einzustellen, die einem bei der Einführung eines neuen Meetings, Artefakts oder einfach nur einer kleinen Prozessänderung begegnen werden.
In den nächsten Wochen wollen wir euch einige jener Argumente nennen, die uns immer wieder begegnen, damit ihr dagegen gewappnet seid und euren Teams helfen könnt, sich auf das Abenteuer des Ausprobierens einzulassen. Im ersten Teil widmen wir uns dem Thema User Stories.

„So ein simpler Satz ist mir viel zu wenig!“

Ganz klar, die User Story in ihrer klassischen Syntax ist einfach – und das soll sie auch sein! Eine gute User Story ist nämlich nichts anderes als eine „Einladung zur nachgelagerten Konversation“. Das bedeutet: In ihrer offenen Formulierung ist sie dazu gedacht, dass der Product Owner mit dem Team über die User Story spricht, sie auf den Prüfstand stellt und dadurch die Details immer klarer werden – bis die Story „ready for sprint“ ist.

„Aber eine User Story kann doch nicht mindestens zwei Mal im Refinement gewesen sein!“

Gerade weil User Stories anhand der INVEST-Kriterien formuliert werden, sollen sie unter anderem verhandelbar und klein sein. Das bedeutet, dass es viele Gespräche und einige Durchläufe braucht, um mehr Klarheit über die Anforderung zu bekommen, die sich in der User Story versteckt. Je vager die Formulierung und je näher die User Story noch an ihrer Ideenphase ist, desto klarer wird, dass es mehr Details braucht, bis alle Teammitglieder das gleiche Verständnis über den Inhalt der User Story haben. Das Backlog Refinement ist dafür der geeignete Termin. Sprecht als Team über den Inhalt, verschafft euch Klarheit und ergänzt, was das Zeug hält: Akzeptanzkriterien, Testfälle, Abhängigkeiten, Risiken und alle Details, die euch einfallen. User Stories werden dann auch oft kleiner geschnitten, wenn sie sich für einen Sprint als zu groß herausstellen.

„User Stories, okay, aber Personas? Brauch ich wirklich nicht!“

Simon Sinek sagt immer wieder, dass das „Why“, also das Warum, das einen antreibt, klar sein muss. Daher sollte die dahinterliegende Antwort etwas elaborierter sein als ein lapidares „Isso“. Auch wenn dem Team der Mehrwert klar ist, ist es unglaublich hilfreich, sich die Anforderungen mit der Brille bestimmter Zielgruppen anzusehen: Warum tickt meine Zielgruppe so wie sie tickt? Und was bedeutet das für mein Produkt? Gibt es widersprüchliche Anforderungen meiner User-Gruppen? Worauf will ich als Product Owner mein Augenmerk legen und für wen priorisiere ich? Personas helfen dabei, sich als Team in die jeweilige Zielgruppe hineinzuversetzen. Je mehr Daten und Fakten in die Persona fließen, desto besser – und dennoch: Entwerft eure Personas so, als wären sie reale Wesen mit Charakter, Lebenslauf, Vorlieben und gebt eurem Produkt damit so viel Kontext, dass ihr euch der Frage nach dem „Why“ leichter nähern könnt.
Sind euch in eurer Arbeit noch andere Argumente gegen User Stories begegnet? Lasst uns wissen, wie ihr darauf reagiert.

Dieser Beitrag ist im Pair Writing mit Sandra Wittmann entstanden.
Foto: CC0 Creative Commons, pixabay – aitoff

Was die Position des Scrum-Teams vor dem Taskboard über das Team aussagt

„Leistet mein Team gute Arbeit?“ Eine Frage, die viele Führungskräfte in Unternehmen umtreibt, wie zahlreiche Anfragen nach Projektbesuchen und Assessments beweisen. Doch braucht es Fragebögen, Interviews oder stundenlange Post-Mortems, um eine Antwort zu finden? Die Frage lässt sich häufig mit einer scheinbar einfachen Methode beantworten: durchs Beobachten.
Wenn ich zum ersten Mal ein Team besuche, das bereits agile Arbeitsweisen wie Scrum oder Kanban nutzt, achte ich bewusst und unbewusst auf viele kleine Hinweise, um eine Hypothese über den Teamerfolg und das Verhalten des Teams und des Unternehmens zu bilden. Ich versuche bewusst, nicht in Aktionismus zu verfallen und sofort alles auf links zu drehen. Denn es gibt Gründe, warum die Menschen so arbeiten, wie sie es gerade tun. Es geht also nicht darum, nach wenigen Tagen einen detaillierten 12-Punkte-Aktionsplan zu haben, sondern ein tiefes Verständnis für die Arbeitsweise der Menschen im Unternehmen zu entwickeln.
Erfahrungsgemäß ist die Stehung, das Catch Up, Stand Up oder Heads Up, oder wie auch immer Sie das tägliche kurze gegenseitige Update im Team, also das Daily Scrum, bezeichnen, eine tolle erste Möglichkeit, um diese Beobachtung durchzuführen. Neben dem üblichen Teilnehmerkreis, der Dauer und der Häufigkeit des Dailys sagt die Position der Teammitglieder vor dem Taskboard sehr viel über die Kultur und den Teamspirit aus.
In den zahlreichen Unternehmen und Projekten, die ich gesehen habe, zeichneten sich einige Muster immer wieder ab. 12 davon zeige ich Ihnen hier. Zur Erklärung: Der orange Kreis ist der ScrumMaster, Gelb symbolisiert die Teammitglieder, in Grün sehen sie den Product Owner und blau ist der Manager.

Muster 1 – das einsame Taskboard


Niemand kommt zum Daily. Man hat sich zwar die Mühe gemacht, die Arbeit sichtbar zu machen, doch das Hilfsmittel wird nicht genutzt. Wahrscheinlich wird das Taskboard nicht als hilfreich erachtet. Offensichtlich sind Zusammenarbeit und Koordination in diesem Team nicht notwendig.

Muster 2 – die Leere


Kein Taskboard, keine Gespräche, kein Treffen. Ob das besser oder schlechter ist, als das „einsame Taskboard“ sei mal dahingestellt.

 

Muster 3 – kein Taskboard


Das Team unterhält sich mehr oder weniger strukturiert. Das ist ein guter Anfang. Der Hauptzweck des Meetings – die kurze, zielgerichtete Unterhaltung zwischen den Teammitgliedern funktioniert. Ein Taskboard kann helfen, diesen Austausch zu fokussieren und zu strukturieren.

Muster 4 – das Zentrum

Die Teammitglieder berichten an den ScrumMaster. Der ScrumMaster steht viel zu sehr im Fokus und verhindert, dass sich die Teammitglieder offen und ehrlich austauschen. Das Team hat den Nutzen des Dailys für sich selbst wahrscheinlich noch nicht erkannt. In besonders schlimmen Fällen fragt der ScrumMaster die Teammitglieder einzeln ab und verlangt eine Rechtfertigung, wenn etwas nicht klappt. Selbstorganisation muss hier noch beigebracht werden.

Muster 5 – das alternative Zentrum


Die Teammitglieder berichten an den Product Owner. Ein Wort – Micromanagement. Anscheinend vertraut der Product Owner dem Team nicht ausreichend. Der ScrumMaster scheint auch schwach zu sein.

Muster 6 – die spanische Inquisition


Product Owner und ScrumMaster sitzen hinter einem Schreibtisch vor dem Taskboard und erwarten den Bericht der Teammitglieder. So ziemlich das Schlimmste, was einem Team passieren kann. Noch schlimmer wäre es nur mehr, wenn die Teammitglieder mit verbundenen Augen vor einer Wand stünden.

Muster 7 – das Meeting


Offensichtlich ist die alte Meetingkultur noch tief verankert. Die Teammitglieder sitzen an den Tischen. Im „Idealfall“ klappt jeder noch seinen Laptop vor sich auch und tippt wild vor sich hin. Es geht um Anwesenheit, nicht um Ergebnisse. Langeweile ist vorprogrammiert, Leidenschaft werden wir in so einem Meeting vergeblich suchen. Kann noch gesteigert werden durch das nächste Muster.

Muster 8 – das Klassenzimmer


Ähnlich wie „Das Meeting“, zusätzlich können sich die Teammitglieder jetzt nicht mehr in die Augen schauen. Auch hier arbeiten eher Fachexperten in einer Arbeitsgruppe. Zusammenarbeit gibt es hier wahrscheinlich nicht.

Muster 9 – der Experte


Das Daily findet ausschließlich mit dem ScrumMaster und dem „einzigen Teammitglied, das sich wirklich auskennt“ statt. Ab und zu gibt es auch mehrere Experten, die jedoch getrennt voneinander befragt werden. Die restlichen Teammitglieder werden ignoriert. Teamzusammenarbeit und Austausch wird man in diesem Team vergeblich suchen.

Muster 10 – noch ein alternatives Zentrum


Die Teammitglieder berichten an den Manager – Micromanagement in Vollendung. Der Product Owner ist entweder entmachtet oder nicht da.

 Muster 11 – der Lonesome Rider


Der ScrumMaster macht das Daily mit sich alleine, weil er das Team nicht braucht, um Transparenz zu stiften. Er weiß Bescheid (oder meint Bescheid zu wissen), was im Team gerade läuft. Hat den Sinn des Dailys komplett verfehlt. Offensichtlich hat der ScrumMaster auch wenig Respekt vor den Fähigkeiten der Teammitglieder. Eine alternative Interpretation ist, dass keines der Teammitglieder zum Daily kommt, weil sie den Mehrwert und Sinn nicht sehen. Vergleichbar mit Muster 1 und 2.

Muster 12 – der Reporter


Der ScrumMaster berichtet direkt an den Manager. Teammitglieder werden komplett außen vor gelassen – entweder, weil der ScrumMaster die Teammitglieder als nicht fähig genug einstuft oder diese keine Lust auf das Meeting haben. Vertrauen und Identifikation mit dem Produkt, das entwickelt wird, wird man hier vergeblich suchen.

Die Kraft des Taskboards nutzen: Wie macht man es besser?

Idealerweise stehen alle Scrum-Teammitglieder – also Entwicklungsteam, Product Owner und ScrumMaster – gleichberechtigt vor dem Board. Die Teammitglieder erzählen sich gegenseitig von ihrem Fortschritt, der ScrumMaster moderiert, achtet in den Ausführungen des Teams auf Hindernisse und erzählt auch selbst von den Themen, an denen er arbeitet. Der Product Owner interessiert sich auch für den Fortschritt des Teams und berichtet von den Themen, die bei ihm passiert sind. So gefällt mir das.

Starten Sie an dieser Stelle ein kleines Experiment. Beobachten Sie bei nächster Gelegenheit das Verhalten Ihres Teams. Überprüfen Sie, ob sich der aus der Beobachtung ableitbare Zweck mit der Funktion deckt, die das Team erfüllen soll. Passt das Gesagte mit dem sichtbaren Verhalten zusammen? Damit wird die Beobachtung auch zur Strategiearbeit: Was haben wir uns vorgenommen zu tun und was tun wir tatsächlich? Beobachtung als bewusste Führungsaufgabe benötigt etwas Zeit und Kontakt ins Team, kann aber zur Rekalibrierung des Veränderungsbedarfs führen und zur Steuerung genutzt werden. Konkret könnte das bedeuten, die Beobachtung zu teilen und zusammen mit dem Team in Bezug auf den angestrebten Zweck zu reflektieren.
Kennt ihr noch weitere Muster? Ich freue mich über eure Kommentare.

Meetings: Haben Sie noch Zeit zu arbeiten?

Ein Blick in die Tagesplanung und es wird klar: Heute wird ein anstrengender Tag. Ein Meeting reiht sich an das nächste – dass die Mittagspause nicht auch noch belegt ist, ist ein Wunder! Der Frust ist natürlich groß, denn die Themen, die schon seit Tagen liegen geblieben sind, werden also auch heute nicht fertig. Ein voller Terminkalender ist zum Statussymbol geworden. Ein Zeichen der persönlichen Wichtigkeit, er gibt das Gefühl, unersetzbar zu sein. Selbst, wenn die Zeit im Meeting nur abgesessen wird: Die pure Anwesenheit zählt.
Hier ein kleines Gedankenexperiment: Was wäre, wenn im Kalender wirklich nur noch jene Termine mit der höchsten Priorität stünden? Diejenigen, zu denen etwas beigetragen werden kann und die einen Mehrwert für die eigene Arbeit darstellen? Auf einmal ist da Zeit, ein kahler Fleck im Kalender. Platz, um an eigenen Ideen zu arbeiten, zu reflektieren, vorzubereiten, nachzubereiten, sich fortzubilden, Kollegen zu unterstützen, sich auszutauschen. Und das Beste daran ist, dass alle diese Tätigkeiten viel unkomplizierter umzuplanen sind als fixe Meetings mit vielen Teilnehmern.

Das Prinzip der Freiwilligkeit

Probieren Sie es doch mal mit dem Prinzip der Freiwilligkeit. Jeder kann für sich entscheiden, ob er oder sie an einem Meeting teilnehmen möchte oder nicht. Das heißt auch: Die bloße Einladung zu einem Meeting ist noch keine Verpflichtung – der oder die Eingeladene entscheidet selbst, ob er oder sie die Einladung annehmen möchte. Dazu muss sich jeder selbst die Frage stellen: „Welchen Beitrag kann ich in diesem Meeting leisten und kann ich überhaupt einen Beitrag leisten?“ Das Prinzip der Freiwilligkeit setzt also die Fähigkeit zur Selbstorganisation und zum Treffen von selbstständigen Entscheidungen voraus – die auch mit aller Konsequenz getragen werden. So ist von Anfang an sichergestellt, dass das Meeting effizient sein wird: Es sitzen nämlich genau jene Menschen gemeinsam an einem Tisch, die motiviert sind und etwas zum Thema beitragen können. Die Produktivität während des Meetings selbst lässt sich noch einmal steigern, wenn gewisse Regeln eingehalten werden:

  1. Elektronische Geräte werden zugeklappt und stumm geschaltet. Die volle Aufmerksamkeit richtet sich auf das momentane Geschehen.
  2. Timeboxing verhindert, dass die anberaumte Meetingdauer zu sehr überzogen wird. Die goldene Regel lautet: Die Zeit ist fest, der Umfang ist variabel. Um dieses Prinzip einhalten zu können, ist eines essentiell: Pünktlichkeit.
  3. Nachhaltige Dokumentation: Entscheidungen, Aufgaben und Commitments müssen schriftlich fixiert werden. Sinnvoll ist es, immer einen der Anwesenden das Protokoll schreiben zu lassen – die anderen können sich darauf verlassen, alles Wichtige im Nachgang noch einmal nachlesen zu können.
  4. Raum für konstruktive Diskussion muss zeitlich unbedingt berücksichtigt werden. Ein Meeting dient maßgeblich dem Austausch untereinander!
  5. Vorbereitung auf beiden Seiten ist verpflichtend. Der Einladende sollte eine Agenda erstellen, damit den Teilnehmenden klar ist, was im Meeting besprochen wird und sie besser abschätzen können, ob sie einen Beitrag leisten können. Die Teilnehmer müssen sich ebenfalls vorbereiten. Nur dann können sie gezielt und produktiv an den geplanten Punkten arbeiten und fundierte Entscheidungen treffen.
  6. Wertschätzender Umgang, Respekt und Offenheit. Eigentlich Grundlage jeglicher Zusammenarbeit, auch außerhalb der Meetings.

Die eigenen Ressourcen kennen

Wichtig ist, sich selbst realistisch einschätzen zu können. Welcher Arbeitstyp bin ich? Wie viel Zeit zum Reflektieren brauche ich? Arbeite ich produktiver am Morgen oder am Nachmittag? Wenn die Aufgaben und Meetings laufend die eigenen Kapazitäten überschreiten, wächst der Berg an unfertigen Themen stetig an. Dazu ist es nötig, Nein sagen zu können – freundlich, aber bestimmt.

Commitments geben – Commitments einhalten

Grundsätzlich gilt: Ein Commitment wird eingehalten. Die Entscheidung, Commitment zu geben, sollte also gut durchdacht sein und nicht vorschnell getroffen werden. Immer sollte auch im Hinterkopf behalten werden: Es kann etwas Unvorhersehbares dazwischenkommen, auf das reagiert werden muss – das beeinflusst die Taktung der Aufgaben. Kollegen wissen dadurch, dass sie sich verlassen können und ein offenes und transparentes Verhältnis untereinander wird unterstützt.
Ein leerer Kalender bedeutet nicht, dass man nicht arbeitet – diese Tatsache muss in vielen Organisationen erst noch akzeptiert werden. Der Nutzen ist sonnenklar: Unverplante Zeit lässt Raum für Flexibilität und für die Möglichkeit, spontan auf Geschehnisse zu reagieren, ohne damit gleich den gesamten Plan des Tages oder gar der Woche zu sprengen. Auf einmal ist es möglich, Gelegenheiten wahrzunehmen – denn man hat wieder Zeit zu arbeiten.

Foto: CC0 Creative Commons, pixabay – geralt

4 Gründe warum auch Agilität standardisierte Prozesse braucht

Als wir unser Team in Frankfurt etablierten, kam ich wiederholt an den Punkt, der beim Bilden neuer agiler Teams regelmäßig aufpoppt: das Aufsetzen und Standardisieren von Prozessen. Es ist an der Zeit, mit dem weit verbreiteten Irrtum aufzuräumen, Prozesse gehörten in einer agilen Umgebung der Vergangenheit an.
Natürlich ist es zwiespältig: Einerseits sind Prozesse essenziell für die Organisation eines Unternehmens. Zugleich sind langwierige und behäbige Prozesse einer der Gründe dafür, dass Konzerne und Großunternehmen den Anschluss an Innovation – und damit vor allem ihre Kunden – verlieren. Der Kunde will nicht warten, nur weil ein Geschäftsprozess eingehalten werden muss.
Unternehmen verstehen Prozesse als Richtlinien, an die man sich halten muss. Sie genießen so etwas wie Gesetzesqualität und werden von den Mitarbeitern zwar bemängelt, jedoch selten in Frage gestellt oder gebrochen. Die Grundregel lautet: „Wir machen es so, weil es der Prozess so vorsieht.“
Erstaunlicherweise gilt diese Aussage aus verschiedenen Gründen auch in einem agilen Umfeld.

Grund 1: Struktur und Sicherheit

Definierte Prozesse ermöglichen ein strukturiertes, kollaboratives Arbeiten. Je präziser Prozesse definiert sind, umso klarer sind die Rahmenbedingungen, die agiles Arbeiten erst möglich machen. Dadurch entsteht für die Mitarbeiter Sicherheit in einem unsicheren Umfeld: Halte ich mich an den Prozess, brauche ich keinen Gedanken daran zu verschwenden, ob ich es richtig mache. Ich kann mich auf meine Kollegen und meine Organisation verlassen.

Grund 2: Continuous Improvement

Erst wenn ein Vorgang immerfort in derselben Reihenfolge wiederholt wird, kann man an diesem Prozess eine Verbesserung vornehmen. Es ist wie mit einem Backrezept: Hält man sich immer exakt an das Rezept, schmeckt der Kuchen immer gleich gut (oder schlecht). Backe ich den Kuchen mit den gleichen Zutaten, aber in anderer Reihenfolge, entsteht ein anderer Kuchen. Der kann zufälligerweise mal besser gelingen, genauso aber auch scheitern. Erst wenn ich den Prozess dokumentiert ändere, kann ich den Erfolg reproduzieren oder den Misserfolg vermeiden.
Hinzu kommt, dass man durch häufiges Wiederholen Übung bekommt und erst dadurch merkt, wo es hakt, wo es Probleme gibt, was automatisiert oder ganz weggelassen werden kann. Um in der Metapher zu bleiben: Am Anfang halte ich mich exakt und aufs Gramm genau an das Rezept, im nächsten Schritt mische ich die Zutaten nach Gefühl und vielleicht auch in einer anderen Reihenfolge, weil ich weiß, wo exaktes Arbeiten entscheidend ist und wo Augenmaß ausreicht. Ein Profi braucht schließlich kein Rezept mehr, sondern weiß aus tiefer Erfahrung, wie ein Kuchen gut wird und welche Zutaten zusammenpassen. Er kommt auch auf Kombinationen, die ein Anfänger nie zusammenrühren würde.

Grund 3: Zeitersparnis

Befolge ich für einen bestimmten Vorgang einen vordefinierten Prozess, erspare ich es mir, jedes Mal aufs Neue darüber nachdenken zu müssen, welche Prozessschritte es gibt und in welcher Reihenfolge ich sie abarbeiten muss. Das spart nicht nur Zeit, sondern auch Gedanken und ich kann meinen Fokus auf denkintensive Vorgänge richten.

Grund 4: Verhinderung von Hoheitswissen und schnelle Einarbeitung

Vordefinierte Prozesse ermöglichen es jedem, diese zu befolgen. Je definierter die Prozesse sind, umso geringer ist der Einarbeitungsaufwand. So kann jeder Kollege, auch wenn er bislang nicht in den jeweiligen Prozess involviert war, die Arbeit dem Prozess entsprechend übernehmen.

Das Kunststück: Balancieren zwischen Notwendigkeit und Einengung

Die Herausforderung besteht darin, genau jene Prozesse zu definieren, die erforderlich und notwendig sind. Prozesse können dabei schnell zu einem Korsett werden, das selbstbestimmtes Arbeiten behindert. Ich befolge daher vier Grundregeln für meine Projekte:

  1. Ein Prozess sollte erst dann definiert werden, wenn er mindestens fünf Prozessschritte umfasst.
  2. Ein Prozess sollte erst dann definiert werden, wenn der Vorgang öfter als drei Mal zu erwarten ist.
  3. Jeder Prozess ist disponibel und kann von jedem, der einen schlankeren oder sinnvolleren Prozessschritt identifiziert hat, angepasst werden.
  4. Ein Prozess kann jederzeit ersetzt oder gestrichen werden, wenn er überflüssig ist oder durch einen besseren Prozess ersetzt worden ist.

Richtig angewendet können Prozesse ein Segen sein und haben gerade auch in einem agilen großen Anteil am Erfolg!

Circle Way – eine zeitgemäße Form von Führung

Ich habe bereits viele Meetings, Workshops und Trainings gehalten. Alle in meist ganz klassischen Formaten: U-Form, Gruppentische oder Block. An den Kreis habe ich mich selten getraut. Zu nah, zu neu, zu viele Vorurteile.
Als Teil einer Facilitation-Ausbildung habe ich mich intensiv mit dem Format der Kreisarbeit auseinandergesetzt. Meine Vorurteile? Verschwunden. Der Kreis spiegelt eine Urform menschlicher Kommunikation wider. Saßen unsere Vorfahren bereits um ein Lagerfeuer, erzählten sich Geschichten, wärmten sich und hatten eine Gemeinschaft für Vertrauen und Sicherheit geschaffen, machen wir heute eben genau das in der Kreisarbeit.
The Circle Way, eine Methode ohne viele Regeln und Rollen. Ganz unaufgeregt.
Der Kreis beschreibt drei klare Grundregeln:

  1. Aufmerksames Zuhören
  2. Intentionales Sprechen
  3. Beitragen zum Wohle der Gruppe

Der Check-in

Ein Willkommen an die Gruppe.
Die gemeinsame Absicht jedes Teilnehmers transparent machen.
Die Einstiegsrunde ist für die Qualität der anstehenden Gespräche von Bedeutung.

Die Mitte

Die Mitte des Kreises ist zentrales Element der Kreisarbeit.
Die Mitte ist Symbol für den Grund des Kreises. Warum sind wir zusammengekommen? Welches Thema oder welche Frage treibt uns an?
In der Kreismitte finden unsere Augen und unsere Gedanken einen Anker. Die Mitte lässt und innehalten und inspiriert zu neuen Gedanken.

Der Check-out

Die Kreisteilnehmer reflektieren in der Gruppe über Gehörtes, Gelerntes, Gesprochenes. Was nehme ich persönlich aus dieser Gruppe mit? Der Check-out ist Symbol für die Verabschiedung und die Auflösung des Kreises.
Der Kreis lässt viele Hierarchien verschwinden. „A Leader in every chair“, haben es die Neuentdecker der Kreisarbeit, Ann Linnea und Christina Baldwin, beschrieben. Jeder hat eine Stimme und jede Stimme ist es wert, gehört zu werden. Jeder hat das Recht seine Meinung zu teilen und jeder Teil inspiriert das große Ganze.

Foto: CC0 Creative Commons – pixabay, PublicDomainPictures

Wie klassisches Projektmanagement und Agilität mit der Unvorhersehbarkeit zukünftiger Umstände umgehen

Als Berater, der methodisch und in seiner Haltung der agilen Hemisphäre zuzuordnen ist, habe ich schon oft die Dichotomie zwischen klassischem Projektmanagement und Agile argumentiert und noch öfter genau dieser zugehört.
Eine oft gehörte Variante bezieht sich auf die Unvorhersehbarkeit zukünftiger Umstände und Entwicklungen. Das zentrale Schaubild ist hier die Stacey-Matrix: Gerne wird in dem Feld zwischen „trivial“ und „chaotisch“ im Bereich des Komplexen die Agilität verortet. Damit wird Agilität sofort zur Antwort auf Komplexität, Unvorhersehbarkeit und Unplanbarkeit gestempelt. Als Gegenbild dient dann meist das klassische Duo aus Wasserfallmethodik und Projektmanagement, das an der Komplexität scheitern muss, weil es auf Planbarkeit setzt.
Beim Lesen des Buchs eines befreundeten Autors und Universitätsprofessors über „Therapeutisches Chaos“ hat mich ein Gedanke besucht: „Auf diese Weise wird der Theorie und Welt des klassischen Projektmanagements unterstellt, sie würde Komplexität und Unplanbarkeit per se weder verstehen noch für die eigene Modellierung zur Kenntnis nehmen oder berücksichtigen.“ Dass es in der Praxis durchaus zu oft so vorkommt, ist damit nicht ausgeschlossen.
An dieser Stelle möchte ich für einen Agilisten allerdings etwas ziemlich Unpopuläres machen: Ich unterstelle bewusst, dass sich klassische Ansätze des Projektmanagements sehr wohl im Kontext von Komplexität bewegen und sich mit Inhalten und Umwelten auseinandersetzen, die man schwer bis gar nicht deterministisch behandeln kann. Sie sind sich dieses Umstandes gewahr und gehen bewusst damit um.

Klassisch vs. agil – der Unterschied im Wie

Der große Unterschied zwischen klassischem Projektmanagement und Agilität liegt im „Wie“, und das ganz deutlich.

Ist also im klassischen Projektmanagement die Abweichung per se eine Krise, wird sie im agilen Kontext per se als Chance behandelt.
Formulieren wir die beiden Begriffe einmal im Sinne ihrer Funktion um, um sie einander gegenüberzustellen:

Warum kann es wichtig sein, den Unterschied zwischen diesen beiden Ansätzen sorgsam zu betrachten?
Zu allererst ist das wichtig, wenn wir uns mit Veränderungen beschäftigen – als Change Manager, Agile Coaches oder Berater, die beim Umbau von Unternehmen mitwirken bzw. diese verantworten. Wir verantworten das Bild der Veränderung „VON – ZU“. Und dabei sind wir gut beraten, bei den richtigen, damit auch relevanten, weil wirksamen Inhalten und Umständen anzusetzen. Einen Schritt weitergedacht, ließe sich also ein Change, noch besser eine Transformation „vom Projektmanagement hin zu Agile“ reframen in „von der korrektiven Organisation hin zur lernenden Organisation“.

Foto: CC0 Creative Commons, pixabay – Septimiu88

"Ja, genau. Was für eine Chance!" oder wie Sprache Wirklichkeit schafft

In unserer täglichen Arbeit in Unternehmen verschiedener Größe und Art begegnen uns immer wieder Sätze wie folgende:

Kennen Sie diese Sätze aus Ihrem eigenen Arbeitsalltag, nutzen Sie diese vielleicht manchmal selbst ganz automatisch oder sogar gern? Da sind Sie nicht allein. Wir hören sie sehr oft und immer wieder, sie nisten sich in unserem Sprachschatz ein. Lesen Sie diese Sätze noch einmal und hören Sie in sich rein. Neben dem wiedererkennenden Augenrollen merken Sie vielleicht, was diese Sätze noch auslösen: Grenzen. Enge. Unverbindlichkeit. Resignation. Hilflosigkeit. Unbeweglichkeit und Fremdbestimmtsein. Wie stehen wohl die Chancen, in einem solchen Umfeld neue Dinge zu probieren? Sich weiter zu entwickeln? Lust zu bekommen, die Verantwortung für sein eigenes Handeln wieder zu übernehmen?
Sprache schafft Welten. Ich bin als Kind mit Bastian und Fuchur durch Phantasiewelten geflogen, habe mich mit Momo vor den grauen Herren versteckt oder mit Michel aus Lönneberga im Schuppen geschnitzt. Vielleicht haben Sie ähnliche Erinnerungen und lächeln gerade, weil Sie daran denken? Dann geht es Ihnen wie mir. Und das alles durch Sprache. Sie als Führungskraft sollen eine Wirklichkeit schaffen. Sie haben eine Vorbildfunktion, spannen und geben einen Rahmen, haben eine Vision und motivieren Ihre Mitarbeiter. Sprache und Kommunikation können Ihnen dabei einen nicht unerheblichen Dienst erweisen. Es liegt in Ihrer Hand, Ihre Umgebung mitzugestalten und das nicht nur, aber definitiv auch über die Kommunikation. Was bedeutet das für Ihre tägliche Arbeit? Achten Sie ausreichend auf Ihre Kommunikation? Wie können Sie Sprache einsetzen, um eine produktivere Arbeitsumgebung zu schaffen?

Welche Wirklichkeit wollen Sie für sich und Ihre Mitarbeiter schaffen?

Wenn Sie frei wählen wollen, welche Kommunikation aus Ihnen heraus passiert, wenn Sie adressatengerecht und gezielt kommunizieren und Ihr Team auch über Kommunikation führen möchten, habe ich hier ein paar Tipps für Sie. Doch tragischerweise gilt wie bei so vielen Dingen: Beginnen Sie bei sich selbst. Gleichermaßen sind diese Hinweise auch auf Ihr Team anwendbar.

1. Sprache ins Bewusstsein holen durch Zuhören

Gönnen Sie sich den Spaß und beobachten Sie Ihre Kommunikation einen Tag lang. Wie oft sagen Sie wundervolle kleine Worte wie „man“, „eigentlich“, „ja, aber…“ oder verwenden den unverbindlichen Konjunktiv? Hören Sie also zu. Sich selbst und anderen. Denn das Tückische ist: Wir HÖREN diese Worte nicht mehr bewusst, und doch landen sie in unserem Bewusstsein und tun dort ihre Arbeit im Verborgenen. Zerren Sie sie wieder ans Licht, indem Sie darauf achten. Bitten Sie Ihre Mitmenschen, Sie auf die Nutzung dieser Worte anzusprechen, am besten direkt in der Situation, in denen es ihnen auffällt. Erst, wenn Sie sich Ihre Sprache ins Bewusstsein holen, können Sie an ihr etwas verändern. Wenn es Ihnen auffällt, halten Sie inne und korrigieren Sie sich selbst laut. So lernt Ihre Umwelt direkt etwas mit. Vielleicht machen Sie im Team direkt eine Tagesaufgabe daraus, um alle einzubeziehen? Zusammen mit anderen lernt es sich ja doch leichter und lustiger.

2. Bedürfnisse kennen – Was will Ihnen Ihre Kommunikation sagen?

Jeder Mensch handelt in jeder Situation für sich selbst sinnvoll. Und jede menschliche Handlung ist darauf ausgerichtet, ein Bedürfnis zu befriedigen, das in ihrem System eine Rolle spielt. An diesen Aussagen kommen Sie nicht vorbei, wenn Sie sich selbst reflektieren – was wiederum unvermeidlich ist, wenn Sie Ihre Kommunikation ins Bewusstsein holen und verändern möchten. Fragen Sie sich so oft wie möglich: „Welches Bedürfnis bediene ich gerade mit dieser Wortwahl? Welche Aussage steckt wirklich dahinter?“ Lassen Sie sich davon überraschen, was Sie dabei über sich selbst lernen werden. Können Sie eine bestimmte Sache nicht, oder wollen Sie das vielleicht gar nicht? Und wenn dem so ist, was heißt das für Sie, welche Konsequenzen hat das? „Das müsste man eigentlich mal machen …“ Nutzen Sie den Konjunktiv, weil Sie nicht alle Informationen haben, um sich zu committen? Nutzen Sie das „man“, um zu signalisieren, dass Sie es – aus welchen Gründen auch immer – auf keinen Fall machen wollen?

3. Fragen stellen

Eine Hauptaufgabe meines Berufs schätze ich sehr: Fragen stellen – ob nun mir selbst oder meinem Gegenüber in Coaching- oder Beratungssituationen. Manchmal reicht nur die eine richtige Frage zum richtigen Moment, ein „ja, aber“ löst sich in Luft auf und eine neue, nie dagewesene Betrachtungsweise liegt auf einmal auf dem Tisch. Eine der wirksamsten Fragen in meinem beruflichen Alltag ist für mich: „Was bräuchte es denn, um …“ Viele Menschen sind so schnell in einem negativen Kreisel von „Das geht nicht, weil“, dass selbst mir schwindlig wird. Ein „Was bräuchte es denn, um …“ bremst den Kreisel ab und man kann die Umgebung wieder wahrnehmen und neue Wege sehen. Diese Frage ist nicht nur für das Gegenüber toll, sondern auch für Sie selbst. Was bräuchte ich denn, um … zu wollen, zu können, den Mut zu haben,…? Was fehlt noch, um …? Wen bräuchte es, damit wir…? Was ist uns nach der Veränderung möglich? Ich könnte stundenlang weitermachen, wie Sie merken …

4. Üben, üben, üben

Versuchen Sie es mal, sagen Sie: „Ich kann das nicht.“ Halten Sie inne und sagen Sie dann: „Ich kann das noch nicht. Was bräuchte ich, um es zu lernen?“ Merken Sie den Unterschied? Alle Sätze, die Ihnen begegnen, können Sie umformulieren. Wichtig ist dabei meiner Ansicht nach, dass die neue Formulierung einen Raum für Möglichkeiten öffnet, Handlungsfähigkeit zurückgibt und beweglich macht. Frei nach dem Motto: Handle so, dass sich die Anzahl deiner Möglichkeiten vermehrt.
Worauf ich meine Aufmerksamkeit richte, davon bekomme ich mehr – so heißt es. Richten Sie also Ihre Aufmerksamkeit auf eine öffnende, positive, wertschätzende, Möglichkeiten aufzeigende Kommunikation und Sie werden mehr davon bekommen. Werden die Menschen um Sie herum zunächst vielleicht irritiert sein? Klar, das kann sehr gut sein. Und gleichzeitig geschieht dies dadurch, dass Sie das Kommunikationssystem Ihrer Mitmenschen irritieren und es darauf reagiert. Irritieren, Muster hinterfragen und verändern, Denk- und Lernprozesse in anderen Menschen anstoßen und mitgestalten … das ist alles möglich mit der entsprechenden Kommunikation. Und vor allem ist es notwendig für Veränderungen jeglicher Art.
Wollen Sie also in Ihrem Umfeld etwas verändern, schauen Sie sich Ihre eigene Kommunikation und die Ihrer Umgebung an. Und dann… fangen Sie an, entdecken Sie Ihre Sprache neu, nehmen Sie bewusst wahr und lernen Sie, sie einzusetzen.
Ich wünsche Ihnen viel Erfolg und auch Freude dabei. Wenn Sie Unterstützung benötigen, sagen Sie Bescheid, wir stellen dann gerne ein paar relevante Fragen.

"Ja, aber …" oder woran ich erkenne, dass ich agil bin

Wie bei jeder Reise, die wir unternehmen, wollen wir auch in Veränderungsprozessen wissen, ob wir Fortschritte machen. Wenn wir wissen, wie weit wir schon gekommen sind, können wir eine Prognose darüber anstellen, wie viel mehr Energie wir einsetzen müssen, bis wir unser Ziel erreicht, unsere Vision erfüllt haben. Gehen wir daran, agile Arbeitsmethoden, wie zum Beispiel Scrum, zu implementieren, ist die Einhaltung des Rahmenwerks ein konkreter Indikator dafür, wie vollständig, wie gut ich schon agil „mache“:

In der Praxis hat sich allerdings gezeigt, dass man nur vollständig agil „machen“ kann, wenn man auch agil ist, d.h. wenn das dahinterliegende Mindset, die Kultur im Unternehmen etabliert ist. Es gibt eine Wechselwirkung zwischen machen und sein. Nun lässt sich das agile Machen – wie oben beschrieben – recht einfach messen: Ich zähle einfach die Häkchen, die ich hinter die verschiedenen Elemente des Rahmenwerks machen kann. Falls ich nicht auf die volle Zahl Häkchen komme, lässt sich interessanterweise mutmaßen, dass es beim Mindset hapert. Anders ausgedrückt: Tatsächlich sind die Hard Facts ein Indikator dafür, ob es bei der Etablierung eines agilen Mindsets in eurem Unternehmen noch Verbesserungspotenzial gibt. Und wie beschrieben, lassen sich die Hard Facts recht leicht messen. Wer sich mit Objectives und Key Results auseinandergesetzt hat, weiß wahrscheinlich, dass Ergebnisziele und Fortschrittsziele zwei verschiedene Dinge sind. Auf unser Anliegen übertragen heißt das: Ich messe den Erfolg der Einführung agiler Methoden anhand der „Treue“ zum Scrum-Framework.

Ja, aber wie messe ich nun die Soft Facts?

Nur wie lässt sich messen, wie weit meine Bemühungen zur Etablierung des Mindsets gediehen sind? Wie messe ich meine Fortschritte auf dem Weg zum Ziel? Wie messe ich Kultur? Für den Start reicht es einmal genau zuzuhören. Zählt einmal, wie oft ihr „Ja, aber …“ in eurem Team und Unternehmen hört – und wie oft ihr selbst „Ja, aber …“ sagt. „Ja, aber“ heißt in Klardeutsch „Nein“. Alles, was hinter dem Aber kommt, negiert die erste Satzhälfte. lehnt damit die Position des anderen ab. Erst wenn ein Team in der Lage ist, verschiedene Standpunkte nebeneinander in der Schwebe zu halten, können dem Spannungsfeld der verschiedenen Sichtweisen neue und kreative Lösungen entspringen. Dann hat das Team dialogische Kompetenz entwickelt – eine wichtige Kulturtechnik für ein agiles Unternehmen. Im praktizierten Pluralismus liegt die Chance zur Schaffung eines neues Ganzen, das größer ist als die Summe seiner Teile.

Was könnt ihr für die Entwicklung dieser Kompetenzen tun? Was sind eure Fortschrittsziele?

In multifunktionalen Teams treffen häufiger Menschen mit unterschiedlichen Persönlichkeitstypen aufeinander als in Silo-Teams, deren Teammitglieder meist denselben Beruf gewählt haben. Analysen von Persönlichkeitstypen, wie beispielsweise disc oder der Myers-Briggs-Typenindikator helfen den Teammitgliedern zu verstehen, wie ihre Kollegen ticken. Das erhöht auch die Bereitschaft, Andersartigkeit zu tolerieren und den genannten Pluralismus zunehmend wertzuschätzen. Der ScrumMaster spielt in der Förderung dieser Entwicklung eine wichtige Rolle. Er erklärt den Teammitgliedern die Bedeutung von „ja, aber …“ und spiegelt ihnen, wie sich Kommunikation gestaltet, wenn es verwendet wird oder wenn es ausbleibt.

Was agiles Testen nicht ist und was es ist

In meinen Projekten höre ich oft Sätze wie „Unser Testing-Team macht auch Scrum, also machen wir agiles Testen“ oder „Wir testen in den Sprints, also machen wir agiles Testen. Und vor dem Release gibt es noch einen Testing-Sprint für die Integrationstests“ oder „Wir testen sprintversetzt – was in einem Sprint entwickelt wurde, testen wir im nächsten“ usw.
Solche und noch viel mehr ähnliche Sätze zeigen mir, wie sehr „agiles Testen“ missverstanden wird. Alle erwähnten Aussagen zeigen mir nur: Es wird weiterhin nach dem Wasserfall entwickelt – nur in kürzeren Iterationen, mehr nicht. Kein agiles Entwickeln und schon gar nicht agiles Testen. Denn was ist „agil“ per Definition?

„Lieferung funktionierender Software in kurzen Iterationen und in Inkrementen.“

Wie aber soll man sicherstellen, dass die Software funktioniert, wenn sie nicht innerhalb einer Iteration getestet wird? Und zwar komplett. Nicht nur ein bisschen, ohne Integrationstests am Ende des Releases, ohne sprintversetzte Tests, sondern alles findet im Sprint statt, sodass am Ende des Sprints ein Stück Software potenziell an den Kunden geliefert werden kann.

Was unterscheidet agiles Testen noch vom klassischen Testen?

Wir wissen, dass das ganze Entwicklungsteam für die Qualität des Produkts verantwortlich ist. Wenn nur die Tester testen, kann von gemeinsamer Verantwortung nicht die Rede sein. Natürlich braucht es weiterhin die Tester im Team. Sie bringen wertvolles Know-how mit, auf das nicht verzichtet werden kann. Dennoch können und sollten alle Teammitglieder ihren Beitrag zur Qualität des Produkts leisten, zum Beispiel so:

Mit anderen Worten: Agiles Testen ist die Gesamtsumme aller Tätigkeiten, die dafür sorgen, dass am Ende jedes Sprints die gelieferten Funktionalitäten funktionieren und vom Kunden potenziell sofort genutzt werden können.

Foto: CC0 Creative Commons, testbytes – pixabay

Pair und Mob Programming – der kleine, aber feine Unterschied

Wissenstransfer, die Ideen und Kompetenzen von vielen nutzen, Einarbeiten neuer Kollegen – Mob und Pair Programming sind wirklich sinnvolle Arten der Zusammenarbeit. Aber wann eignet sich welche der beiden Arbeitsmethoden am besten?

Vier Augen sehen mehr

Beim Pair Programming sitzen zwei Entwickler gleichzeitig vor einem Bildschirm und bilden somit ein „Pair”. Einer der beiden programmiert, der Zweite liest die Codezeilen mit. Nach dem Motto “vier Augen sind besser als zwei” wird so der Code von beiden Entwicklern gleichzeitig geschrieben. Besonderen Charme hat dieses Vorgehen deshalb, weil die beiden Entwickler einerseits besseren und sauberen Code schreiben und sich andererseits gegenseitig zu innovativem Denken motivieren. Der Austausch zwischen den Entwicklern zum geschriebenen Code führt dazu, dass sie voneinander lernen und ihr Wissen erweitern.
Tipp: Nach einer zuvor vereinbarten Zeit sollten Coder und Mitleser sich abwechseln, um Ermüdungserscheinungen (nachlassende Konzentrationsfähigkeit) vorzubeugen.

Komplexe Themen im Team bearbeiten

Beim Mob Programming sitzt das gesamte Team vor einem großen Bildschirm und nur einer aus dem Team programmiert. Die Besonderheit ist hierbei, dass das programmierende Teammitglied nicht seine eigenen Gedanken in Code verwandelt, sondern das restliche Team über den nächsten Codeabschnitt diskutiert. Der Entwickler an der Tastatur muss aus der Diskussion heraushören, wie die nächsten Codezeilen aussehen werden bzw. lässt er sich diese teilweise sogar diktieren (je nach Erfahrungsgrad). Durch die Diskussion wächst nicht nur bei jedem Teammitglied die Erfahrung im Umgang mit komplexen Problemstellungen, sondern gleichzeitig auch das Wissen über den Code. Jeder im Team ist in der Lage, den Code zu verstehen, weiß worum es geht und kann schnell Code Refactoring betreiben.
Tipp: Diese Art des Programmierens ist für denjenigen, der gerade tippt, sehr anstrengend. Daher sollte der codende Entwickler nach ca. 10-15 Minuten von einem anderen Teammitglied abgelöst werden. Bei einer Teammitgliederanzahl von mehr als vier ist es besser, mit einem Beamer zu arbeiten, statt auf einen Bildschirm zu starren. So kann jeder einfach folgen und niemand versperrt einem anderen Teamkollegen die Sicht.

Best Practice

Meine persönliche Erfahrung mit beiden Methoden hat gezeigt, dass es bei neuen Thematiken sinnvoller ist, erstmal gemeinsam zu starten, um eine gemeinsame Laufrichtung zu finden. Im nächsten Schritt sollte man das Team in kleine Pairs aufbrechen, um sich die geschnittenen Themen zu erarbeiten. Nach einiger Zeit trifft man sich wieder als Team im Mob, fügt die Codefragmente zu einem gemeinsamen Code zusammen, testet gemeinsam und bleibt für die weitere Entwicklung im Mob. Oder: Das Team einigt sich auf die nächsten Einzelthemen, die wieder im Pair erarbeitet werden. So entsteht ein angenehmer Arbeitsflow, bei dem das Wissen aller Teammitglieder stark wächst und das Produkt dadurch schnell, effizient, effektiv und erfolgreich geliefert werden kann.

Foto: (c) rawpixel

Meetings: Vorbereitung ist alles!

Folgende Situation spiegelt sich  in unserem Projektalltag häufig wider: Für ein zentrales Thema in der strategischen Ausrichtung wird ein vierstündiges Meeting einberufen. Die Einladung erfolgt dabei wie üblich per E-Mail und hat circa 40 weitere Empfänger im CC. In der E-Mail selbst wird auf vier Seiten und mit weiteren Dokumenten im Anhang versucht, die Situation vage zu schildern sowie spezifische Aufgaben an Personen zu adressieren. In Summe eine nicht zufriedenstellende Ausgangssituation, die nur zu einem ineffizienten Meeting führen kann.
Szenenwechsel – wir steigen in das Meeting ein. Eine Person erhebt sich und steigt mit den Worten „Wie schon in der E-Mail gesagt …“ in das Meeting ein. Schon jetzt wird der Fahrplan für die nächsten vier Stunden ersichtlich: Es gibt keine Vision, keine Agenda, keine Zielsetzung. Also klappen 60 Prozent der Teilnehmer die Laptops auf, lesen E-Mails und koordinieren weitere Meetings. Weitere 30 Prozent überprüfen in kurzen Zyklen die Uhr auf ihren Mobiltelefonen. Die restlichen zehn Prozent werfen wahllos Fragen und hilfesuchende Blicke in die Runde. Was ist hier passiert? Ist die Thematik für die Teilnehmer nicht relevant oder nicht nachvollziehbar? Betrifft es die Teilnehmer nicht? Klar ist, es scheitert an der Vorbereitung des Meetings.

Vom Durcheinander zum Miteinander

Was braucht es also, damit ein Meeting nicht nur vergeudete Zeit ist und zum unorganisierten Durcheinander wird? Es bedarf einer klaren Struktur, die den Teilnehmern von Beginn an kommuniziert werden muss. Konkret heißt das: Thema, Ziel und Annährung an das Ziel werden von Anfang an transparent gemacht. Warum das eine wichtige Voraussetzung ist, liegt auf der Hand. Die Teilnehmer sollten verstehen, warum es für sie auf persönlicher Ebene sinnvoll ist, am Meeting teilzunehmen. Die Struktur vermittelt Orientierung über den Ablauf und sorgt für Sicherheit: Was passiert wann? Hier ist eine exemplarische Agenda, die zeigt, wie man die Aufmerksamkeitspanne der Teilnehmer vergrößern kann und somit deutlich mehr Laptops geschlossen bleiben:

  1. Wir starten mit der Begrüßung und einem kurzen Check-in. Grundlegend dient dieser Einstieg lediglich dazu, die Teilnehmer aus dem Kontext, der sie aktuell beschäftigt, herauszuholen und die Fokussierung auf die kommende Zeit zu erleichtern.
  2. Fahrplan. Im Anschluss daran sollte, wenn notwendig, das Meetingformat bzw. die Spielregeln erläutert werden. So wissen die Teilnehmer, was von ihnen erwartet wird und wann sie sich wie am Meeting beteiligen können.
  3. Für das Thema des eigentlichen Meetings gilt: den Inhalt und das Ziel des Termins klar benennen. Am besten distanziert man sich vom „Vortanzen“ oder vom „PowerPoint-Kino“. Im Fokus sollten die Key Facts des jeweiligen Themas stehen stehen. Vertiefende Informationen liefert gegebenenfalls ein Handout, das am Ende nachgereicht werden kann. So wird sichergestellt, dass sich die Teilnehmer auf den Präsentierenden konzentrieren.
  4. Abschluss mit Fazit. Am Ende der Veranstaltung ist es notwendig, dass der Moderator angefangene Themen auch wieder schließt. Er oder sie zieht ein Fazit des Termins.
  5. Nächste Schritte. Allen sollte schlussendlich klar sein, welche Ergebnisse der Termin gebracht hat, wie sich das Thema in den Gesamtkontext einordnet und was gegebenenfalls die nächsten Schritte sind.

P.S.: So banal es klingt, auch Pausen spielen eine wichtige Rolle. Nach spätestens 90 Minuten Meeting sollten 15 Minuten Pause berücksichtigt werden, da sonst die Konzentration stark abnimmt.
In jedem Fall gilt: Preparation is King!

Dieser Beitrag ist im Pair Writing mit Sebastian Truthän entstanden.

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

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 (2). 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.

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.

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.

German train ride – a real life burndown experience

As a consultant my workplace is where my client is. This leads to quite a bit of traveling. Usually I like to travel longer distances by train. This is not only due to the ecological aspect of not burning kerosine (the federal train company Deutsche Bahn uses 100% green electricity for owners of a Bahncard) but also for the quality time of focused work or contemplation. Unfortunately using the train on long distances often is a gamble. You cannot be certain to be on time, sometimes not even close.
Today I am on a train ride from Karlsruhe to Berlin. In Berlin I am going to meet my girlfriend and honestly I can’t wait to see her. She will wait for me in Berlin at the central station at 10:00 o’clock in the evening. Do I have a chance to be there on time? I am thinking to myself: Can an agile artifact help me to answer this question? I’m in the mood for a little fun with Excel and curious what the buffer integrated burndown chart – which I often like to use in clients’ projects – of this train ride would look like? In this post I am going to find out.

The ingredients for a buffer integrated burndown chart

What do I need for an illuminating and neat burndown chart?

Integrate visual buffer management to the burndown

To integrate a visualization on the buffer consumption I need a few more ingredients.

The optimistic velocity spread this time will be 5%. This means the average velocity of the train might increase by 5% during the ride. In the case of a train ride this is quite optimistic but as an agile coach I’ve learned to be optimistic about almost anything.
The pessimistic velocity spread will be set to –20%. This is realistic. Any incident on the track can easily drop your average velocity by that amount.
By using a three-point estimate (optimistic, realistic, pessimistic) you can calculate the absolute probability of your velocity or backlog size. But I won’t do this academic calculation today.

Thursday 15:30 – Leaving the client

I use public transport to get from the client to Karlsruhe main station. For 6,06 kilometers it takes me 20 minutes. This equals to a velocity of 9,09 kilometers per iteration. I need to speed up! If I progress by this velocity, it will take me almost 79 30-minute-iterations to meet the committed scope of 711 kilometers. I am sure my sweetheart is not going to wait for 1,6 days at the train station in Berlin.

Thursday 16:00 – The scheduled train is not on time

The train I expected at 4:00 o’clock already has a 30-minute delay. In my experience this is not too uncommon for a project. It takes a project team a while to gain speed when initially set up. Usually everybody in the project lives in the hope that the speed of progress in the project will cope with this delay. But I’ve never experienced this to be the case.
train ride burndown - borisgloger consulting - 01

Thursday 16:30 – Starting the ride on the long distance train

With a velocity of 0 kilometers in the last iteration I enter the train.
train ride burndown - borisgloger consulting - 02

Thursday 17:00 – We gain speed

The velocity increased dramatically in the last iteration. The train passed Mannheim and delivered 81,16 kilometers in the last iteration. The train still has to deliver additional 623 kilometers but if it were to proceed like this we could get back on track. To visually keep the last iterations in mind I usually calculate the burndown forecast by using the average velocity of the last two iterations.
train ride burndown - borisgloger consulting - 03

Thursday 17:30 – Still fast on our way, Frankfurt almost in sight

In 5 minutes we will be in Frankfurt. The average velocity increased to 74 kilometers per iteration. I could now call my girlfriend that I will be on time, but the visual scenario of the worst case velocity spread indicates that there is still a huge risk of missing the deadline in this train ride project.
train ride burndown - borisgloger consulting - 04

Thursday 18:00 – Again too slow when arriving in Hanau

Again the velocity dropped dramatically. Now the train delivered 49 kilometers on average per iteration. This is way too slow. Time to inform my gilfriend. If the train progresses like this and the velocity drops by the pessimistic spread factor which I defined above, I am not going to arrive in Berlin this day. Usually this is the time when Development Teams decrease the scope of the project. Unfortunately, this is not the best option today since this would have me spend the night in Wolfsburg.
train ride burndown - borisgloger consulting - 05

Thursday 18:30 – Still below needed velocity

I can easily calculate the needed average velocity to deliver 711 kilometers in 6 hours: 118,4 kilometers per hour. This means the train needs 59,2 kilometers per 30-minute-iteration. But currently it only gets 45 kilometers. If the train progresses by this speed it will be 4 iterations late, not talking about the visually indicated worst case scenario.
train ride burndown - borisgloger consulting - 06

Thursday 19:00 – A spark of hope

In the last iteration the train delivered almost 79 kilometers. The average velocity increased to 69 kilometers. The train will stop in Kassel Wilhelmshöhe soon. There are currently no disruptions on the track.
train ride burndown - borisgloger consulting - 07

Thursday 19:30 – We are fast again, passing Göttingen

Without any inconveniences the train races along. The average velocity increased again. Now the train can deliver 77 kilometers per iteration. But the visual worst case scenario in the burndown chart indicates that I will not meet the deadline.
train ride burndown - borisgloger consulting - 08

Thursday 20:00 – A bad last iteration, arriving in Hildesheim

The last iteration was not as good as the ones before. Only 57 kilometers could be delivered. I think to myself: This is so common. No team in the world can keep the pace for long after they almost doubled their velocity from one iteration to the next. 66 kilometers per 30 minutes is the trains current average velocity. Now it is certain: I am going to be too late. I inform my girlfriend that I will be late. Luckily she is going to wait for me.
train ride burndown - borisgloger consulting - 09

Thursday 20:30 – The track ahead is blocked

The train arrives in Braunschweig but is not going to proceed. The track ahead is blocked. The train has to wait for an undefined amount of time. That’s what I call a blocker. Even in the best case of my burndown scenario I am going to exceed my deadline by more than one iteration. My buffer is consumed. I am happy I had one. The average velocity dropped below 50 kilometers per iteration.
train ride burndown - borisgloger consulting - 10
 

Thursday 21:00 – Waiting in Wolfsburg

After we have been allowed to proceed our train ride we arrived in Wolfsburg. The average velocity is still below 50 kilometers and the train manager announces that we again have to stop the ride. We have to wait in Wolfsburg until a train, riding behind us, has passed. Sigh.
train ride burndown - borisgloger consulting - 11

Thursday 21:30

There will be no further stop until we reach Berlin Spandau. Only 100 kilometers to go until the train will have delivered the whole backlog and I can hug my honey. The average velocity increased to 58 kilometers per iteration. If there are no further disruptions, I am going to arrive in Berlin central station one iteration after the committed deadline and two iterations after the planned buffer.
train ride burndown - borisgloger consulting - 12

Thursday 22:00

We arrive in Berlin Spandau. The last two iterations have been a race. Like in most of the delivery teams in the world the speed of my delivery unit (the train) increased noticeably shortly before the deadline. The average velocity is now an amazing 80 kilometers per iteration. But we already know what has to happen after such a tremendous velocity boost.
train ride burndown - borisgloger consulting - 13

Thursday 22:30

The train missed the deadline and the velocity dropped again. Nevertheless, even with a velocity of only 10 kilometers in the last iteration I arrived in Berlin central station. As projected before I am one iteration behind the deadline but my girlfriend is still waiting. I am a lucky man.
train ride burndown - borisgloger consulting - 14

Summary

It was fun to play this little game today. It helped me to not get mad about the delay. The burndown chart with integrated buffer visualization helped me to predict the realistic arrival time and proved that you can manage a project with this simple agile artifact. I a real world project situation I would have de-scoped the project after the first sign of putting the deadline at risk because it is way easier to increase the scope later in the project than to decrease it. Just for fun I created a little animated gif to show at a glance how the burndown chart evolved over the 14 iterations until the full scope of the ride was delivered.
train ride burndown - borisgloger consulting
In this train ride example the consumption of the buffer was displayed visually between the two bars (begin of buffer and deadline). If you want to view this more at a glance you can aggregate the buffer consumption in a fever curve. This could also be then aggregated to a simple traffic light visualization which is well known by executive management.
Buffer Consumption
The latest value of buffer consumption can be displayed in a portfolio diagram. This helps a lot for executives to focus on projects at risk only. I wonder what this portfolio diagram would look like for all the long distance trains which have been on the track today.
Project Portfolio View
 

Steuern mit dem Taskboard

Wie im ersten Teil „Taskboard Basics“ beschrieben, sind Taskboards ein einfaches, aber wirkungsvolles Mittel, um einen Überblick über den Arbeitsfortschritt von Teams zu geben. Manchmal auch mit brutaler Ehrlichkeit. So erlebt in einem Daily vor einem vielzeiligen, ein wenig zerfleddert wirkenden Taskboard. Bei vielen Storys hingen einzelne Tasks “in progress”, Punkte für hängengebliebene Tasks wurden schon nicht mehr verzeichnet und ganz unten prangte die Zeile für “Sonstiges“. Resultat: Wir rackerten uns ab, bekamen aber kein einziges Ding fertig. An priorisiertes Abarbeiten war gar nicht zu denken.
Das Resultat des Sprints waren viele offene, halbfertige User Storys. Jedes Teammitglied hatte bei fast jedem Thema ein wenig mitgestaltet. Bei vielen Storys war der letzte Schritt zur Erfüllung der Akzeptanzkriterien aber noch nicht erledigt oder sogar unklar. Spätestens nach dem nächsten Sprintwechsel verursachten die unfertigen Storys und das noch immer mit denselben Themen vollgepackte Taskboard Schmerzen – und die führen bekanntlich zur Veränderung. In unserem Fall durch eine Intervention von zwei Teammitgliedern. Das Taskboard ist immerhin nicht nur ein Reportingtool, es bietet auch die Möglichkeit, die Arbeit aktiv zu gestalten.
Nach dem Motto “Stop starting, start finishing” wurde das Taskboard umgebaut und die Regeln der Zusammenarbeit wurden geändert: Neben der User Story wurde nun das zugehörige Akzeptanzkriterium, auf das wir uns geeinigt hatten, explizit gemacht; unter der ersten User Story prangte ein dicker Strich. Die Aussage war klar: Wir greifen die zweite User Story erst an, wenn die erste User Story abgeschlossen ist. Bis dahin unterstützt jedes Teammitglied die Kollegen oder hat eben Slack. Ein gewagter Ansatz. Das Team committete sich trotzdem. Versuchszeitraum: ein Tag.

Acht Stunden später

Am Ende des ersten Tages war die Zahl der Tasks gestiegen, da Kollegen ihre Aufgaben kleiner geschnitten hatten, um Teile auf andere Teammitglieder auszulagern. 19 Tasks done, fünf andere auf “to do” oder “in progress”. Die Disziplin hatte gehalten, keine anderen Baustellen wurden aufgerissen. Die Lieferung der Story war nicht innerhalb eines Tages möglich, aber wir standen kurz vor der Fertigstellung unserer Delivery. Das Experiment hatte sich bewährt.

Unser Fazit

Durch die Fokussierung haben wir drei Ziele erreicht:

Taskboard Basics

Jeden Morgen treffe ich mich mit meinem Team aus ScrumMastern vor unserem Taskboard, jeden Morgen synchronisieren wir uns im Daily und jeden Morgen verschieben wir dabei Post-Its auf mehreren Spalten von links nach rechts. Synchronisation über den Arbeitsfortschritt, das Glücksgefühl, etwas erfolgreich abgeschlossen zu haben und auf “Done” hängen zu können oder einfach nur einen Überblick über die Aktivitäten des Tages zu bekommen – es gibt viele Gründe, die für ein Taskboard sprechen.

Wie ist ein Taskboard aufgebaut?

Wegen seiner vielen Vorteile hat sich das Taskboard schnell verbreitet. Teams passen ihre Taskboards zwar ihren Bedürfnissen an, der Grundaufbau bleibt aber immer gleich. Es besteht aus drei Spalten: Tasks „To Do“, „Work in Progress“ und „Done“.
Taskboard
Scrum-Teams stellen vor die „To Do“-Spalte außerdem noch die priorisierten User Stories, auf die die jeweiligen Tasks einzahlen. Ein Taskboard liest sich also in der Regel von links nach rechts (Fortschritt) beziehungsweise von oben nach unten (Priorisierung). Neben den Spalten nutzen Teams gerne auch horizontale Unterteilungen, sogenannte „Swim Lanes“. Diese helfen, die Zuordnung von Tasks zu einer User Story besser im Blick zu behalten.
Darüber hinaus gibt es noch verschiedenste Elemente, die die Bedürfnisse des jeweiligen Teams unterstützen:

Obwohl es mit wenigen Handgriffen gebaut werden kann, hilft uns das Taskboard, einen Überblick über unsere aktuelle Arbeit zu geben und veranschaulicht den Arbeitsfortschritt des Teams. Das Taskboard ist dabei nicht nur Reportingtool, sondern gibt Teammitgliedern vielmehr auch die Möglichkeit, Sachen auf „Done“ zu setzen und somit als fertig abzuhaken. Dank dieser Erfolgsmomente wird es von Teammitgliedern als Arbeitswerkzeug geschätzt.

Scrum Spaces oder Agilität braucht Raum

Ich habe ein neues Team, ein neues Projekt, eine neue Herausforderung. Einige der Tätigkeiten scheinen jedoch auf den ersten Blick nur wenig mit den Aufgaben eines ScrumMasters, wie man ihn aus den Lehrbüchern kennt, zu tun zu haben. Ich möchte, dass mein Team sich wohlfühlt, schließlich wird es hier, im Teamraum, die meiste Arbeitszeit verbringen. Mein Ziel: Ein Raum, in dem alle Lust haben zu arbeiten.
Scrum muss gelebt werden und um etwas zu leben, muss man es spüren – jeden Tag aufs Neue. Es ist ein aufregendes Gefühl, Teil von etwas Neuem zu sein. Scrum heißt, gemeinsam an einem Ziel zu arbeiten. Dieses Wir-Gefühl soll sich auch im Arbeitsraum widerspiegeln. Eine gute Stube. Hier sitzen ALLE Entwickler zusammen. Idealerweise finden auch ScrumMaster und Product Owner in der guten Stube ein Plätzchen zum Arbeiten. An diesem Punkt kommt oftmals die Frage: „Warum denn alle zusammen? Ich habe doch mein Büro …“ Eine einfache Antwort: Face-to-face- Kommunikation. Eine Frage oder ein Problem ist im direkten Gespräch viel schneller geklärt. Ohne Telefon, ohne E-Mail, ohne Chat. Ein Problem? Wir kreieren gemeinsam die Lösung! Tasks können in einem Teamraum einfach leichter und schneller gemeinsam bearbeitet werden. Durch das gemeinsame Arbeiten werden Wissen und Erfahrung direkt ausgetauscht und die Qualität des Arbeitsergebnis steigt dadurch erheblich.
Im Agile Manifesto liest man:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
Doch wie schaffe ich es als Scrum Master, diese Prinzipien in das tägliche Arbeitsumfeld meines Teams zu implementieren? Bei der Frage nach dem perfekten Teamraum für agile Teams gibt es kein Schwarz oder Weiß. Alles, was sich gut anfühlt, ist erlaubt. Teams sitzen gerne zusammen, ob in Arbeitsinseln oder in einer U-Form. Fühlt sich das Team wohl, ist es die richtige Form. Und wenn nicht? Dann nutzen wir doch einfach zehn Minuten nach dem Daily, um ein wenig zu experimentieren … agil sein … anpacken und testen.

Wie sieht unser Teamraum nun aus?

Als ich die Teammitglieder gefragt habe, was für sie wichtig ist, stand an erster Stelle das Taskboard. Das Team wünscht sich, immer einen guten Blick auf seine Aufgaben zu haben. Wichtig ist den Teammitgliedern auch, die Sitzplätze je nach Zusammenarbeit wechseln zu können.
Wir wissen, wie wichtig die gemeinsame Arbeit an einer Tätigkeit und der disziplinenübergreifende Austausch sind. Also haben wir die Trennwände zwischen den Arbeitsplätzen abgebaut und Raumteiler entfernt. Nichts, abgesehen von den Bildschirmen, steht nun den Entwicklern und ihrem täglichen Austausch im Weg. Jeder kann so mit jedem kommunizieren und arbeiten, aufstehen, Sitzplatz wechseln, alles ist erlaubt. Feste Sitzplätze schränken das agile Arbeiten für gewöhnlich ein. Daher kann die tägliche Teamaufteilung (Pairs oder MiniMobs) je nach Bedarf wechseln. Das bedeutet auch, dass sich die Sitzordnung mit jeder Anforderung ändert. Platzwechsel als ein kleiner Ausdruck von Agilität – den Blickwinkel auch auf den Teamraum einmal ändern.
Viele Teams zeichnen und teilen gerne ihre Ideen, sie wollen die Strukturen oder Abhängigkeiten ihrer Storys und Tasks sehen. Am besten funktioniert das auf Whiteboards oder Flipcharts. Hier können neue Ideen ergänzt, Optimierungen direkt eingearbeitet und am Ende alles auf einem Foto festgehalten werden. Die zu Beginn noch weißen und leeren Wände füllen sich dann im Laufe der Zeit mit zahlreichen Visualisierungen, Zeichnungen und Artefakten. So bekommt der Raum einen teamindividuellen Ausdruck (oder Anstrich). Wichtig ist dabei, auch darauf zu achten, dass kein Information-Overflow entsteht, sondern dass nur Informationen vorhanden sind, die das Team wirklich braucht.
Wenn der Teamraum groß genug ist, würde ich als ScrumMaster noch eine Time-out-Zone einführen. Bequeme Sessel, ein Sofa – Open Areas. Dieser Bereich ist ideal für ad-hoc-Meetings, so muss nicht extra ein Meetingraum gebucht werden. Auch kann dieser Open-Space-Bereich einfach für 10 Minuten kreative Pause genutzt werden. Diese kurzen Auszeiten können für die Produktivität wahre Wunder wirken.
Agile Räume sind in meinen Augen genauso wie ihre Teams: individuell und anpassungsfähig.

Das andere Ende der Leitung: Scrum in verteilten Teams

Verteilte Teams passieren nicht. Sie entstehen, weil das Management festgestellt hat, dass erforderliches KnowHow nicht an einem Ort versammelt ist oder an einem anderen Standort günstiger zu bekommen ist. Wir müssen unser Team also dezentral organisieren. Nachdem wir uns im ersten Schritt mit der Kommunikation in verteilten Teams befasst haben, können wir uns nun daran machen, das Projektmanagement zu organisieren.

Warum bietet sich Scrum für die Organisation verteilter Teams an?

Am Ende jedes erfolgreichen Teambuilding-Prozesses steht ein gemeinsam geteiltes und verinnerlichtes Ziel. Im Scrum-Umfeld verbinden wir dieses gemeinsame Ziel in erster Linie mit dem Artefakt der Vision und mit dem agilen Wert des Commitments. Die Vision sollte bereits auf strategischer Ebende schnell, klar und deutlich verbreitet und laufend erneuert werden. Auf Sprint-Ebene ist das Commitment zu einem gemeinsamen Ziel das erste integrative Element. Es hilft dem Team, sich auf die Aufgaben des kommenden Sprints zu konzentrieren.
Scrum setzt auch im Verlauf des Sprints auf mehrere integrative Effekte. Wie bereits erwähnt ist das Peer Working ein effektiver Weg der Zusammenarbeit. Hier geht es aber nicht nur um den angesprochenen Vertrauensaustausch. Wenn es den Teamspirit stärkt, Checklisten abzuhaken hilft es uns erst recht, dieses Erfolgserlebnis zu teilen. Apropos: (Miss-)Erfolg ist der abschließende integrative Teil unserer Arbeit. Das Erreichen eines gemeinsamen Ziels kann uns als Team bestärken, Lohn für unsere Mühen sein. Ebenso kann gemeinsamer Leidensdruck Auslöser für Veränderung und Verbesserung sein.

Be part of it!

Spätestens wenn Sie versuchen, Magic Estimation mit einem verteilten Team zu spielen, werden Sie herausfinden, dass die Integration von Menschen, die sich nicht in einem Raum befinden, recht kompliziert sein kann. Hier gibt es verschiedenste Lösungsansätze, die je nach Teamsetting umgesetzt werden können. Zum Beispiel

Spätestens, wenn Sie ein großteils verteiltes Team betreuen, müssen Sie sich als ScrumMaster über eine vollkommen digital spielbare Variante der Magic Estimation Gedanken machen. Egal, um welches Meeting oder welchen Arbeitsschritt es sich handelt, die zwei wichtigsten Anforderungen sind dabei, dass

Remote. Ein Problem, das wir letzten Endes alle kennen.

Ihr Scrum-Team ist an einem Standort zusammengefasst? Herzlichen Glückwunsch! Sie werden sich im Rahmen der Zusammenarbeit gewisse Abstimmungsarbeit sparen. Das bedeutet aber nicht, dass Sie die oben genannten Grundsätze nicht beachten sollten. Irgendwie ist nämlich jedes Team verteilt. Wenn wir von Scrum sprechen, meinen wir die kontrollierte Zusammenarbeit von verschiedenen (Interessen-)Gruppen, den Rollen. Ich habe schon verschiedenste Unternehmen und Teams gesehen: Eine Konstellation, in der der operative Kern, externe Zulieferer, Management, Kunden und User nicht verteilt waren, habe ich dabei noch nie beobachtet. Die zugrundeliegenden Probleme können dabei durchaus die gleichen sein wie bei einem verteilten Scrum-Team. Somit betrifft uns das Problem des verteilten Teams doch irgendwie alle. Machen wir uns das bewusst und agieren wir dementsprechend. So können wir uns wieder ein klein wenig verbessern.

5 Punkte für ein effektives Daily

Scrum ist ein hocheffizientes Rahmenwerk für die Produktentwicklung, sofern es richtig gelebt wird. Leider erleben wir zu oft das Gegenteil. Die Scrum Meetings werden prozessual etabliert, aber es fehlt am qualitativen Mehrwert, der durch die Meetings entstehen sollte.
Immer wieder sehen wir Dailys, in denen der ScrumMaster vor dem Board steht, als gelte es sein Heiligtum zu bewachen. Das Team hat im weiten Bogen um ihn herum Aufstellung bezogen und jede Person sagt einen Satz, ohne dass sich die Kärtchen am Taskboard bewegen. Fast alle Storys hängen in der WIP-Spalte und die Tasks bekommen trotz Bewegungsfaulheit keinen Punkt dafür. Der Product Owner vergibt bei Gelegenheit noch Aufgaben an einzelne Teammitglieder und fährt anderen Teammitgliedern über den Mund.
Ein so oder so ähnlich durchgeführtes Daily ist leider ein sehr ineffizientes Daily. Gut, immerhin ist das Daily als Meeting etabliert. Es wäre weitaus schlimmer, wenn das Meeting überhaupt nicht stattfinden würde. Da es stattfindet und das auf eine transparente Art und Weise, können wir anfangen, es in eine effektive Richtung zu lenken.

1. Daily als Ort der Kommunikation

Das Daily ist KEIN Statusreport für den Product Owner und auch nicht für den ScrumMaster. Das Daily ist da, damit sich das Dev-Team austauschen und koordinieren kann. Die Mitglieder des Dev-Teams sprechen miteinander und erklären sich gegenseitig, was sie machen, wo sie bei der jeweiligen Story noch Hilfe brauchen bzw. wo es sinnvoll ist, im Pairing zu arbeiten. Der ScrumMaster achtet darauf, dass das Ganze im zeitlichen wie auch menschlichen Rahmen bleibt und ist hellhörig bezüglich Impediments. Der Product Owner steht für Rückfragen zu den Akzeptanzkriterien zur Verfügung oder kann sich einbringen, wenn er das Gefühl hat, dass das Dev-Team über das Ziel der Akzeptanzkriterien hinausschießt.
Umsetzung: Der SM fordert die Teammitglieder auf, vor dem Taskboard zu stehen und stellt sich selbst mit den Product Owner in den Hintergrund. Wenn der ScrumMaster oder der Product Owner in den Mittelpunkt der Kommunikation rutschen, erklärt der ScrumMaster wiederholt, dass das Daily nicht dazu da ist, um ihn oder den Product Owner auf den neuesten Stand zu bringen. Das Daily dient dem Informationsaustausch zwischen den Teammitgliedern. Der ScrumMaster hält bei Bedarf wiederholte Mini-Workshops ab, um den Sinn eines Dailys zu erläutern und coacht bei Bedarf den Product Owner in seiner Rolle.

2. Das Herz des Dailys – Aufbau des Tasksboards

Ein Taskboard besteht aus drei Spalten: To do, Work in Progress (WIP) und Done – nicht mehr und nicht weniger. Die horizontalen Zeilen ergeben sich aus den Storys, wo die Tasks zugeordnet sind.
Umsetzung: Der ScrumMaster baut ein Taskboard auf. Unsere beliebtesten Hilfsmittel sind: Pinnwände oder Metaplanwände, die mit Kreppband oder Garn und Stecknadeln in die Bereiche aufgeteilt werden. Moderationskarten sind optimal für die Spaltenüberschriften und die Storys, während verschiedenfarbige Post-its und Stifte das tägliche Aktionsmaterial sind.

3. Die Fragen für das Daily

Man orientiert sich an den 4 Fragen:

Diesbezüglich gibt es mehrere Optionen. Entweder man geht diese Fragen pro Teammitglied oder pro Story durch. Ich persönlich präferiere letzteres: Letztendlich geht es darum, zu sehen, ob die Storys fertiggestellt werden können und nicht darum, dass alle Teammitglieder ausgelastet sind. Wer etwas Neues ausprobieren will, geht einen Schritt weiter und lässt die Teammitglieder herzeigen, was Sie bereits produziert haben, sodass jedes Daily zum Mini-Review wird.
Umsetzung: Der ScrumMaster achtet darauf, dass zu jeder Story/Person die Fragen beantwortet werden. Wenn etwas vergessen wird, erinnert er daran. Die Fragen auf Moderationskarten neben dem Taskboard aufzuschreiben, ist eine einfache und gute Erinnerungsstütze. Beim Mini-Review sorgt der ScrumMaster dafür, dass die Teammitglieder zwischen den Präsentationen zum Taskboard zurückzugehen, um es auf den neuesten Stand zu bringen. Der ScrumMaster sorgt dafür, dass die Timebox von 15 Minuten eingehalten wird, indem er die Leute daran erinnert, sich kurz zu halten bzw. eine Uhr mitlaufen lässt, die alle daran erinnert, wie viel Zeit noch übrig ist. Tipp: Es gibt Timebox-Uhren mit kleiner werdendem Zeitbereich zu kaufen.

4. Das Team bewegt sich, nicht der ScrumMaster

Das Team bewegt die Tasks über das Taskboard. Wenn ein Task done ist, sollte er auch wirklich done sein und nicht mehr zurückkommen. Dabei hat jeder Task ein Namenskürzel. Auch wenn wir Consultants als ScrumMaster arbeiten, können wir uns nicht immer merken, wer von uns welchen Task erstellt hat – mit Namenskürzel auf dem Task hat man aber immer eine Anlaufstelle, wenn man sich über Sinn und Zweck eines Tasks im Unklaren ist. Sollte sich ein Task nicht in die nächste Spalte bewegen, bekommt er jeden Tag einen Punkt und zwar von den Teammitgliedern. Der ScrumMaster achtet auf diese Tasks und fragt während oder nach dem Daily, ob es ein bestimmtes Impediment gibt, das die Fertigstellung des Tasks behindert, oder ob der Task einfach nur zu groß ist.
Umsetzung: Der ScrumMaster bittet die Leute, selbst die Tasks zu schreiben und zu bewegen und reicht dabei auch gerne die Stifte. Auch wenn es sich am Anfang unangenehm anfühlt: Der ScrumMaster bittet die Leute wiederholt höflich (oder auch direkter), die Tasks selbst zu schreiben, zu bewegen und Punkte zu machen. Irgendwann wird er es nicht mehr tun müssen, weil es die Leute selbst tun werden.

5. Flow

Es wird immer daran gearbeitet, so wenige Storys wie möglich offen zu halten und so wenige Tasks wie möglich in progress zu haben. Im Allgemeinen gilt es, sich immer in die Richtung des Optimums einer offenen Story zu bewegen und eine Taskanzahl in progress zu haben, die geringer oder gleich der Anzahl der Teammitglieder ist. Wir wissen alle, dass Multitasking ineffizient ist und wir wollen einen schnellen Feedback-Loop mit dem Product Owner erzeugen. Sobald eine Story abgeschlossen ist, nimmt der Product Owner sie ab bzw. gibt Feedback, warum sie nicht abgenommen werden kann.
Umsetzung: Der Scrum Master vereinbart mit dem Team ein WIP-Limit auf Story-Ebene oder gibt eines vor. Er sorgt dafür, dass das WIP-Limit eingehalten wird, indem er es nicht zulässt, dass weitere Storys eröffnet werden. Sobald eine Story fertig ist, sorgt er oder sorgen die Teammitglieder dafür, dass der Product Owner davon erfährt. Der ScrumMaster sorgt dafür, dass es bald Feedback gibt, ob die Story abgenommen wird oder was die Abnahme verhindert.
 
Es gäbe noch viel mehr dazu zu sagen, aber diese fünf Punkte sind für mich die Basis für jede weitere Aktion – sie erschaffen im Kern eine gesunde Daily-Kultur. Dabei ist es wirklich schwierig, diese Punkte alle im Kopf zu behalten und kontinuierlich zu kontrollieren. Es ist ein Idealbild, dem man sich im im Laufe der Zeit annähern kann. Im Laufe der Entwicklung des Scrum-Prozesses wird der ScrumMaster immer mehr seiner Verantwortung an die Teammitglieder abgeben, sobald er sieht, dass sie das Konzept verinnerlicht haben. Am Anfang jedoch muss er durch Vorzeigen, Vorleben und häufiges Erklären die Grundlage und das Verständnis für die Vorgänge schaffen, die für langfristige Produktivität sorgen.

Ist "done" wirklich "better than perfect"?

Wenn ein Team mal wieder Ewigkeiten an etwas rumschraubt, ohne zu einem Ende zu kommen, wird in der agilen Community gerne ein Spruch verwendet: „Done is better than perfect!“ Er hat in der Zwischenzeit eine gewisse Berühmtheit erlangt, sodass ich keinen Agilisten kenne, der nicht schon drüber gestolpert ist (oder ihn im eigenen Repertoire hat) und ja, ich verwende Ihn auch gerne – sowohl für meine eigenen Projekte als auch um anderen Menschen den Kern der Agilität beizubringen. Dabei gilt es aber, eine gewisse Vorsicht walten zu lassen, da dieses Sprichwort sehr unterschiedlich verstanden werden kann. Reden wir bei „Done is better than perfect“ davon, die Tätigkeit schnell mal zu erledigen, sie in eine Ecke zu werfen und die nächste Sache anzugehen? Nein, das wäre genausowenig zielführend, wie Ewigkeiten an einem Thema zu arbeiten und darauf zu hoffen, alles perfekt zu machen, ohne andere Leute zu involvieren.

Einfach wie das Autofahren

Tatsächlich hat dieses Sprichwort viel damit zu tun, uns selbst Lernschritte zu ermöglichen –  in kleinen gut verdaulichen Häppchen, ohne dass wir von Anfang an viel zu viel Arbeit investieren. Das Sprichwort soll ermutigen, den allerersten Draft (im Sinne eines in sich geschlossenen, aber rudimentären Prototyps) so schnell wie möglich zu erstellen und in einen Feedbackzyklus mit den Kunden oder Kollegen zu gehen, um an der nächsten Iteration zu arbeiten. Man kann sich das etwa so vorstellen wie die minimalen Ausgleichsbewegungen beim Autofahren. Wir würden doch auch nicht die Augen schließen, losfahren und nach einer halben Stunde kontrollieren, ob wir auch wirklich wie geplant perfekt am Ziel gelandet wären, oder? Der Fahrer hat immer die Straße im Blick und kontrolliert damit die Korrekturbewegungen seiner Hände am Lenkrad (wir fahren in der Realität nie wirklich ganz gerade, sondern gleichen ständig aus). Beim Autofahren sorgt also ein sehr schnelle Feedback-Loop dafür, dass wir minimale Abweichungen vom Soll jederzeit korrigieren.
Ähnlich wie beim Autofahren sollten wir diese Methode in unseren Alltag integrieren. Es ist wichtig, nicht allzu lange alleine an etwas zu tüfteln, sondern so schnell wie möglich nach draußen zu gehen und andere Menschen um ihr Feedback zu fragen. Nur so kann man wissen, ob man vielleicht in eine nicht so sinnvolle Richtung abgedriftet ist und wo man vielleicht eine andere, neue Richtung einschlagen sollte. Das Feedback muss man nicht immer umsetzen, aber eine Meinung, die über das eigene System hinausgeht, ist in jeder Hinsicht wertvoll.

Nur das Ego legt sich quer

Das einzige, was uns davon abhalten kann, ist unser liebes Ego. Gibt es irgendein sinnvolles Argument, seine Ideen nicht schon recht früh jemand anderem zu zeigen? Ich persönlich sehe nur einen Grund: Die Angst davor, dass jemand die geniale Idee für doch nicht so genial halten könnte. Dabei vergessen wir aber gerne, dass selten eine Türe zugeht, ohne dass sich eine andere öffnet. Es entsteht doch immer etwas Neues, wenn wir unsere Ideen dem Umfeld zeigen, und je früher wir das tun, desto schneller können wir unser Produkt adaptieren und wirklich das erschaffen, was der Zeit und Ort gerade dringend benötigen.
Ich persönlich arbeite daran, diesem Konzept immer öfter und immer früher in meinem Leben zu folgen. Die herben Enttäuschungen werden weniger und ich werde mir immer mehr bewusst, dass es nicht darum geht, etwas alleine bis zur Perfektion zu treiben (natürlich vergesse ich manchmal darauf, aber es ist eine Tendenz erkennbar). Das ist ungemein erleichternd. Ich muss nicht mehr der Superheld sein, der die Dinge von Anfang bis Ende perfekt gestaltet, sondern ich habe die Möglichkeit, mich ständig zu adaptieren und etwas zu gestalten, das iterativ durch Feedback besser wird. Und das jederzeit im Bewusstsein, dass ich mich Stück für Stück in die richtige Richtung bewege und am Ende nicht darum zittern muss, in eine komplett falsche Richtung gelaufen zu sein.
Warum sich also das Leben kompliziert machen, wenn es auch so einfach geht, oder?

Der Testmanager in Scrum

Auf den Software Foren Leipzig im April hatten wir das Vergnügen, Kay Grebenstein, Testmanager bei unserem Partner Saxonia Systems, über den Testmanager in Scrum sprechen zu hören. Sein Vortrag war für mich deshalb so interessant, weil er uns ein Mapping der Aufgaben des Testmanagers auf die Aufgaben des Development-Teams zeigte und begründen konnte, dass Scrum-Teams tatsächlich alle Aufgaben des Testmanagers erfüllen (können). Nach den Standards des International Software Testing Boards (ISTQB) hat ein Testmanager folgende Aufgaben:

(c) Kay Grebenstein

Dabei wird zwischen strategischer Ebene – der des Qualitätsmanagers – und der operativen Ebene (Testmanager) unterschieden. Laut Grebenstein müssen wir also schauen, dass sich Scrum-Teams mit beide Ebenen befassen. Auf den ersten Blick sagt Scrum nichts darüber aus, wie getestet wird und wer dafür die Verantwortung übernehmen sollte. Sicher, es wird immer gesagt, dass in Scrum das Team testet. Aber wer trägt die Verantwortung?
Sieht man sich die Standards des ISTQB an, hat ein Testmanager Aufgaben wie
• den Aufbau eines Testteams,
• das Erstellen eines Testkonzepts,
• Erstellen der Testfälle durch die Tester,
• Erstellen und Durchführen der Testfälle durch das Testteam,
• u.v.m. (siehe unten)

(c) Kay Grebenstein

Wie passt dazu nun ein agiler Testprozess, der all das ja nicht vorschreibt? Grebenstein  zeigte uns dazu zunächst, wie in einem Scrum-Team getestet wird. Und richtig, alle von der ISTQB beschriebenen Aufgaben werden vom Team tatsächlich erfüllt.

(c) Kay Grebenstein

Die Tester im Team – oder besser das Entwicklungsteam selbst – wird nun mit diesen Dingen konfrontiert und die Kompetenz der Tester wächst, weil sie die gesamte Testpyramide abdecken müssen. Das bedeutet, dass die Tester nun sowohl für Unit-, Service- und Systemtest zuständig sind und das Testen, die Domain und das Codieren beherrschen müssen, da sie alle Tests auch automatisieren sollten, wenn nicht sogar müssen.

(c) Kay Grebenstein

Schaut man sich die Aufgaben (siehe erste Abbildung) noch einmal an, ist nun die wichtige Frage, wann diese Aufgaben durchgeführt werden. Dabei werde auf der obersten Ebene – bei agilen Transitionen – die Aufgaben der strategischen als auch der operativen Ebene von den Scrum-Teams durchgeführt. Und hier das dazugehörige Mapping:

(c) Kay Grebenstein

 

(c) Kay Grebenstein

(c) Kay Grebenstein

Genau betrachtet ist nicht viel nötig, um alle Aufgaben gemäß ISTQB durchzuführen. Dazu müssen wir nur geeignete Meetings oder Artefakte bereitstellen oder bestimmte Verfahren wie exploratives Testen tatsächlich durchführen. Dabei hilft es, die drei Stadien Testkonzeption, Umsetzung und Koordination auseinanderzuhalten und getrennt voneinander anzuschauen.
Alles in allem war der Vortrag von Kay Grebenstein ein Gewinn für die agile Community, weil er es dem ScrumMaster ermöglicht, den Qualitätssicherungsabteilungen fundiert entgegenzutreten und in skalierten Umfeldern (Scaled Agile) zu zeigen, dass Scrum alle notwendigen Anforderungen der ISTQB erfüllt.
Der Vortrag war natürlich ausführlicher, als ich es hier nacherzählen kann. Ich bin sicher, Saxonia Systems hilft bei Fragen mit Rat und Tat. Oder schickt mir eine Mail, ich kümmere mich dann drum.
Noch ein wenig Werbung in eigener Sache: Das nächste Treffen der User Group “Agilität in der IT” der Softwareforen Leipzig findet im November 2015 statt und beschäftigt sich mit der Frage: Braucht Agilität Führung? Nähere Informationen findet ihr Softwareforen Leipzig

User Storys im ERP-Umfeld

Ich gebe zu: Es freut mich sehr, dass sich immer mehr Unternehmen dazu entscheiden, für die Entwicklung und Einführung ihrer Enterprise Software auf alternative Vorgehensmodelle zu setzen. Das klassische Fachkonzept, das in einer monatelangen Analyse- und Konzeptionsphase geschrieben wird, hat ausgedient. Für die Herausforderungen der Zukunft sind agile Geschäftsprozesse, die mit den Anforderungen mitwachsen, besser geeignet. Ein paar Feinheiten sollte man im ERP-Umfeld dennoch beachten – zum Beispiel beim Schreiben von User Storys. Der Unterschied zu anderen Kontexten ist nicht gravierend, aber doch eine Besonderheit, der man ein wenig Aufmerksamkeit widmen sollte.
User Storys im ERP-Umfeld leiten sich in der Regel immer von den Geschäftsprozessen eines Unternehmens ab. Oft werden parallel zur Entwicklung und/oder Einführung einer neuen Enterprise Software auch diese Geschäftsprozesse fachlich und organisatorisch modelliert, was eine zusätzliche Herausforderung ist. Ich finde in diesem Zusammenhang das Konzept des Minimum Viable Products von Frank Robinson sehr hilfreich. Dabei soll ein Produkt geschaffen werden, das für den Markt akzeptabel genug ist, dass es verkauft werden könnte.
Werden Geschäftsprozesse für eine Enterprise Software nach dem MVP-Konzept modelliert, bedeutet das: Die Prozesse sind gerade so ausgestaltet, dass sie von den Anwendern verwendet werden können. Diese minimale Prozessausprägung sollte zudem …

Ist dieser Prozess gefunden, kann er eins zu eins als User Story übernommen werden. Ist diese Story zu groß für einen Sprint, muss noch einmal geschnitten werden. Das kann auf unterschiedlichste Art und Weise erfolgen, mir persönlich gefallen besonders diese zwei Varianten:

  1. Versuche, noch dünnere Prozessausprägungen zu schneiden, auch wenn diese kein sinnvolles MVP mehr ergeben.
  2. Versuche, den Prozess in Teilprozesse zu gliedern, um jeden Teilprozess in weiterer Folge als User Story aufzunehmen.

Variante 1

Für die erste Variante kann es sich anbieten, das Verb der User Story genauer zu untersuchen. Möglicherweise kann es weiter konkretisiert werden. Sehen wir es uns an einem Beispiel zur Auftragssteuerung für regionale Einheiten oder externe Dienstleister an. Die ursprüngliche User Story könnte in etwa so lauten:

„Als Vertriebsmitarbeiter möchte ich meine Aufträge steuern, um jederzeit Kontrolle über diese zu haben.”

Das Wort „steuern“ ist in diesem Beispiel bewusst gewählt, um zu zeigen, dass es weiter konkretisiert werden kann:

In diesem Fall haben wir die User Story nun weiter detailliert. In vielen Fällen handelt es sich jedoch nicht um solch triviale Beispiele, sodass kleinere User Storys durchaus kein sinnvolles MVP ergeben können. Nichtsdestotrotz kann ich diesen Ansatz empfehlen.

Variante 2

Bei Variante 2 wird eine Story Map (Idee von Jeff Patton) erstellt. Dazu können Hauptgeschäftsprozesse in Prozesse und diese in weiterer Folge in Teilprozesse gegliedert werden. Der Geschäftsprozess „Einkauf“ kann beispielsweise in folgende Teilprozesse untergliedert werden:

Für jeden dieser Teilprozesse kann nun eine User Story formuliert werden. Auch der Tipp aus Variante 1 bietet sich hier wieder an. So kann es in einem ersten Schritt durchaus gewollt sein, dass …

Es sind nur kleine Kniffe. Aber sie helfen manchmal sehr dabei, auch bei der Modellierung und Abbildung von Geschäftsprozessen auf die agilen Grundsätze wie eine End-to-End-Betrachtung von User Storys und den Fokus auf das „Minimum Viable Product“ zu vertrauen.

Alles Gute hat Grenzen

In der letzten Zeit habe ich immer stärker den Einfluss von Limitationen auf die menschliche Produktivität bemerkt. Vielleicht hat es damit zu tun, dass ich mich gerade in einem Selbstexperiment zum Thema Single Tasking befinde. Jedenfalls ist es unglaublich, was passiert, wenn wir Limitationen aufheben. Das beste Beispiel dafür sind räumliche Begrenzungen.
Als Consultants werden wir immer wieder dazu angehalten, uns auf Papier und Bleistift sowie Marker und Flipchart zu konzentrieren, statt auf digitale Alternativen auszuweichen. Das hat den Vorteil, dass die Begrenzung wesentlich deutlicher zutage tritt als in der digitalen Welt. Wenn wir ein Flipchart zur Verfügung haben, um ein Meeting zu protokollieren, dann ist es genau das: ein Flipchart. Das Meeting selbst wird von der Timebox umrahmt, die Zahl der Teilnehmer ist unterschiedlich. Nichtsdestotrotz bleibt der Platz limitiert. Weicht man in einem Meeting auf elektronische Möglichkeiten der Protokollierung aus, ist diese Limitation nicht mehr gegeben. Das Ergebnis ist beeindruckend: mehrere Seiten voller Notizen in Schriftgröße 12. Mir stellt sich die Frage: Wer wird das lesen und haben sich die Leute damit etwas Gutes getan?

Grenzen schaffen Ordnung

Natürlich verstehe ich den dahinter liegenden Wunsch, detaillierte Aufzeichnungen zu haben, um bei Bedarf darauf zurückgreifen zu können. Das Problem ist aber, dass dabei ein anderer Effekt verloren geht, der den Vorteil der genauen Protokollierung weitgehend in den Schatten stellt. Es ist der Effekt der natürlichen Priorisierung. Haben wir nur wenig Platz für das Protokoll zur Verfügung, diskutieren wir Dinge automatisch nach deren Wichtigkeit. Wir können nicht alles aufnehmen, wollen aber am Ende mit einem möglichst aussagekräftigen Ergebnis hinausgehen: Also mit einen Flipchart mit den wichtigsten Erkenntnissen aus dem Meeting.
In Dateien mit ihren unendlichen Weiten können wir hingegen Seite um Seite, Zeile um Zeile und Spalte um Spalte hinzuzufügen. Jede Aussage bekommt eine neue Zeile und am Ende erhalten wir eine Abschrift aller möglichen Gedanken und ein Sammelsurium an Informationen. Was wir nicht haben, ist eine aussagekräftige Arbeitsgrundlage, mit der wir die nächsten Schritte planen können.
Also, limitieren Sie sich: Bleiben Sie bei einem haptischen Taskboard, bleiben Sie bei einem Flipchart, nehmen Sie sich ein Blatt Papier, um Ihre Gedanken zum Tag festzuhalten und machen Sie eine Sache nach der anderen. Am Ende werden Sie immer einen Schritt nach dem nächsten machen können und nicht das Gefühl haben, von unzähligen parallelen Schritten überrannt zu werden.

Agiles Anforderungsmanagement mit dem Poke-Prinzip

Marco Ley, Leiter eEntwicklung bei CosmosDirekt, sprach auf den Softwareforen Leipzig letzte Woche über “Agiles Anforderungsmanagement: Das Poke-Prinzip – von harten Anforderungen zu kleinen Experimenten.“ Ich muss von diesem Vortrag erzählen, weil ich so stolz auf dieses CosmosDirekt Team bin. Ich habe nichts dafür getan, dort kennt man mich nicht, und ich will gar keine Lorbeeren einheimsen, die Marco Ley gehören, aber ich bin einfach vollkommen fasziniert.
Kennt ihr das, wenn ihr hart für etwas arbeitet und dann feststellt, dass all das, worüber ihr nachgedacht und ständig gesprochen habt, plötzlich Realität wird? Nun ja – so fühlte ich mich an diesem Morgen beim Vortrag von Marco Ley. Er sprach davon, dass seine Entwicklungsteams vollständig crossfunktional aufgestellt sind – UX, RE, Tester, Developer. Diese Teams arbeiten nicht etwa Anforderungen ab, sondern erarbeiten die User Storys selbstständig, basierend auf groben Vorgaben. Und es sind nicht etwa klassische User Storys, sondern Hypothesen, die in mehr oder weniger aufwendigen A/B Tests auf der Produktivumgebung geprüft werden, so dass die Funktionalitäten für das gesamte CosmosDirekt-Portal live gestellt werden. Die durch die Implementierung gewonnenen Daten beweisen, ob sie wirklich einen Return On Investment bringen.
Damit zeigt uns Herr Ley, dass es ihm gelungen ist, die Rolle des Product Owners so zu leben, wie es meiner bescheidenen Meinung nach sein sollte. Er kümmert sich darum, Ideen zu finden, diese daraufhin zu bewerten, ob man damit Geld verdienen kann und macht dann diese Ideen zu Hypothesen, die er von seinen Kollegen durch Implementierung überprüfen lässt. Was funktioniert, wird behalten, der Rest wieder entsorgt. Einfach toll!
Wir haben ihn natürlich gefragt, wie er erkennt, ob er Erfolg mit der Funktionalität hatte, und er sagte: „Weil wir eine Datenbasis haben.” Er trifft Entscheidungen auf Basis von Daten, die er durch Ausprobieren gewinnt und nicht durch politische Überlegungen. Chapeau!Wenn man ihm so zuhört, tut mir die übrige Online Direktversicherungsbranche leid. Sie kann sich warm anziehen, sollte sich sein Vorgehen bei ComosDirekt weiter durchsetzen. Sein Team wird allen anderen einfach davonlaufen.
Vielen Dank für diesen tollen Vortrag!
An dieser Stelle noch etwas Werbung: Die Softwareforen in Leipzig haben mit der Agilen User Group, die sich dort zwei Mal im Jahr trifft, eine wirklich tolle Veranstaltung ins Leben gerufen. Ich bin sehr dankbar, dass ich dabei sein darf. Mehr Infos hier

Status des Agilen Festpreises

Trotz Alerts, Twitter & Co habe ich ab und zu das Bedürfnis, die Google-Search-Engine zum Thema “Verträge für agile Projekte” oder “Agiler Festpreis”, auch “Agile Contracts” genannt, zu durchstöbern. Dabei stolpere ich immer wieder über die üblichen Verdächtigen, beziehungsweise über die gleichen Seiten, die seit Jahren als Mahnmale in den Weiten des Netzes stehen und ihren Ruf in die Ferne klingen lassen: “Ist eh klar!” Gemeint sind Webseiten & Blogs, die Möglichkeiten zeigen, wie man einen Vertrag gestalten kann, um mehr Vorteile des agilen Vorgehens zu nutzen oder das Risiko zwischen Kunden und Lieferanten zu teilen. So rügen Blog-Posts wie einer von Alistair Cockburn aus dem Jahr 2006 den immer noch nicht Bekehrten mit einer Liste von 15 Möglichkeiten, wie er seinen agilen Vertrag konstruieren kann. Wobei die meisten Varianten in knappen 4 bis 8 Zeilen beschrieben sind. Ist das Thema nun so einfach oder in Wirklichkeit sehr komplex? In meinen Gesprächen zu diesem Thema drängt sich mir aber immer mehr der Verdacht auf, dass es nicht um die Komplexität des Themas geht, sondern eher um Erfahrungswerte sowie das Unverständnis, wie dieses neue Konzept in der bestehenden Kultur des eigenen Unternehmens angewendet werden könnte.
Zumindest nach dem Durchlesen des Buchs “Der Agile Festpreis” haben viele die Grundzüge des Themas verstanden. Die meisten attestieren auch, dass dies ein wichtiger nächster Schritt für eine agile Organisation ist. Was meist fehlt, ist der Glaube, dass dies auch wirklich so möglich ist. In der Praxis zeigt sich das sehr oft dadurch, dass der Fokus der meisten Diskussionen auf der Glaubwürdigkeit und Anwendbarkeit liegt. Welche Unternehmen haben das schon gemacht? Wie würden sie das genau in unserer Situation anwenden? Wir arbeiten mit internen Dienstleistern, da ist das sowieso etwas anders, oder? Komplex ist der Agile Festpreis eigentlich nicht. Schwierig ist oft die konkrete Anwendung des neuen Konzepts in einer bestehenden Unternehmenskultur und das Sammeln der Details und der Erfahrung, die für die Einführung dieses neuen Prozesses notwendig ist.
Das mit der Kultur ist eben so eine Sache. Man kann nicht einfach mit einem neuen Begriff um sich werfen, einen schönen Plan für eine Reorganisation entwerfen und dann den Kultur-Schalter umlegen. Nein, es muss vorgelebt werden und wenn der damit errichtete Leuchtturm das Licht gut verteilt, folgen immer mehr Schiffe dem Beispiel. Das ist ja auch wesentlicher Bestandteil des agilen Vorgehens: Wenn man vor einer komplexen oder unübersichtlich großen Aufgabe steht und nicht sicher ist, wie man es angehen soll, startet man am besten mal und kontrolliert den Fortschritt.
So auch der Appell an all jene, die immer noch mit Freelancer-Time&Material-Heerscharen kämpfen, oder im Hoffnungsmodell des Festpreisvertrags ihre Nerven und ihr Geld verschwenden, einfach mal zu beginnen und sich nicht von einem “eh klar” abschrecken zu lassen. Das Konzept ist klar, aber die Umsetzung und das Ausrollen ist in jedem Unternehmen eine eigene Herausforderung. Die agile Organisation beginnt und endet an ihren Schnittstellen nach außen. Das heißt: Jedes Unternehmen, das sich agiler aufstellen will, muss sich über kurz oder lang auch mit den Lieferantenbeziehungen beschäftigen. Wenn man das richtig hinkriegt, kann man einige der Vorteile agiler Methoden erst richtig nutzen. Einkaufs- und Vertragsprozesse anzupassen und die damit verbundene Kultur einer Partnerschaftlichkeit zu leben, ist ein wesentlicher Aspekt des Erfolgs. Viele Unternehmen haben in den letzten Jahren – auch mit unserer Hilfe – den Schritt gewagt. Es gibt also mittlerweile genügend Erfahrung, auf der andere Unternehmen nun mit Bedacht aufbauen können.

Zeit für eine neue Meeting-Kultur

Meetings haben ihren guten Ruf verloren. Vorbei die Zeiten, in denen ein gut gefüllter Terminkalender Indikator für Produktivität war. Heute sind Meetings gleichbedeutend mit langweiligen Diskussionsrunden, in denen alles getroffen wird – außer Entscheidungen. Dabei sind Meetings im Grunde völlig in Ordnung – seit Urzeiten kommen Menschen in Familie, Gesellschaft und Wirtschaft zusammen, wenn es darum geht, die wichtigen Dinge im Leben zu besprechen. Es wird immer irgendeine Form von Meetings geben – die Frage ist nur, wie diese sinnvoll gelebt werden können. Hier ein paar Tipps & Tricks für eine neue Meeting-Kultur.

Alle Hände voll zu tun

Oft sind Meetings wie gute Vorsätze für das neue Jahr: Es ist leicht, sie zu fassen, aber verdammt schwer, sie konsequent umzusetzen. Deshalb ist unbedingt darauf zu achten, dass alle Meetings mit einem klaren Nutzen ausgehen, indem am Ende Maßnahmen, Vereinbarungen, Commitments konkretisiert werden. Mehr noch: Anstatt die Maßnahmen bloß zu benennen, warum diese nicht gleich umsetzen?
Tipp: Sobald in einem Meeting klar wird, dass etwas Konkretes zu tun ist – jemand muss hinzugezogen, eine Information eingeholt werden – handeln Sie sofort. Rufen Sie die Person noch während des Meetings an (bitte mit Freisprechfunktion, damit alle teilnehmen können), lassen Sie die Information vor aller Augen recherchieren, legen Sie Prototypen und Wireframes zur sofortigen Begutachtung aus. Wählen Sie einen Raum, der nicht mit Tischen und Stühlen zugestellt ist, so dass die Teilnehmer frei interagieren können. Sie werden sehen, wie das die Teilnehmer vom Raum der Möglichkeiten in den Raum der Handlungen bringt. So wird die Unterscheidung zwischen Meeting und der eigentlichen Arbeit immer irrelevanter.

Unrentable Meetings abschaffen

Wer ein Meeting einberuft, raubt den Teilnehmern Arbeits- und Lebenszeit. Das sollte nie leichtfertig geschehen und in jedem Fall gut begründet sein. Am Ende jedes Meetings ist zu überprüfen, ob die Zeit sinnvoll investiert wurde. Und ein Meeting sollte grundsätzlich nie länger als 90 Minuten dauern – es gibt genügend Studien, die zeigen, dass danach die Aufmerksamkeit der Teilnehmer den Bach hinuntergeht.
Tipp: Bitten Sie die Teilnehmer darum, vor Verlassen des Meetings ihren Return on Time Invested zu visualisieren. Zeichnen Sie dafür eine Skala von 0 (= kein Return on Time Invested) bis 5 (= sehr hoher Return on Time Invested) auf einem Flipchart und hängen Sie diese neben den Ausgang. Drücken Sie jedem Teilnehmer ein Post-It oder ein Voting Dot in die Hand, und bitte Sie die Teilnehmer, damit einen Punkt auf der Skala zu markieren. Nutzen Sie das Feedback, um sich beim nächsten Mal zu überlegen, ob das Meeting in dieser Form wirklich nötig ist.

Zeitfetischismus zahlt sich aus

Wenn ich ein Meeting für eine Stunde anberaume, dann prüfe ich nach spätestens 30 Minuten, ob wir es beenden können. Häufig ist das der Fall, denn bei einer klar definierten Agenda und Vorbereitung der Teilnehmer entsteht ein guter Kommunikationsfluss, der sich nur an wenigen, kritischen Stellen aufhält. Verharrt das Meeting hingegen in langwierigen Argumentationsrunden ohne Entscheidungen, dann wird auch die ursprünglich anberaumte Zeit nicht ausreichen – eine Unterbrechung ist dann erst recht sinnvoll, um zu einem späteren Zeitpunkt in anderer Konstellation wieder zusammenzukommen.
Tipp: Fragen Sie zur Halbzeit eines Meetings (also nach 30 Minuten bei einem einstündigen Meeting), ob eine Verlängerung erforderlich ist. Wenn ja, verlängern Sie das Meeting um die Hälfte der bereits abgelaufenen Zeit (in diesem Fall um 15 Minuten). Fragen Sie nach Ablauf dieser Zeit erneut, ob eine Verlängerung erforderlich ist. Falls ja, verlängern Sie noch einmal, teilen Sie dabei aber die verlängerte Zeit wiederum um die Hälfte (hier um 7.5 Minuten). Und so weiter. Sie werden sehen, wie die Teilnehmer von Meeting zu Meeting immer zeitbewusster werden und genau abwägen, ob eine Verlängerung erforderlich ist.

Freiwilligkeit – mit allen Konsequenzen

Menschen, die fragen, ob sie an dem Meeting teilnehmen müssen, haben meist Besseres zu tun. Es ist für mich eine Frage des Respekts, andere zu Meetings tatsächlich einzuladen (und nicht mit Pflichtfeldern einzuberufen). In jedem Meeting sollte daher das Gesetz der zwei Füße gelten:
“Wenn Sie in einer Gruppe nichts mehr lernen oder beitragen können, dann dürfen Sie gehen. Ehren Sie die Gruppe durch ihre Ehrlichkeit und suchen Sie sich neue Aufgaben, denn Sie bestimmen alleine wo, wie und wie lange Sie sich beteiligen. Lassen Sie sich von Ihren Füßen leiten. Gehen Sie dahin, wo Sie Ihre Energie und Aufmerksamkeit einbringen wollen, nur dort werden Sie produktiv sein. Dies ist ein Gesetz: Es ist mehr als nur erlaubt, es ist vorgeschrieben.” (Harrison Owen – User’s Guide to Open Space Technology)
Tipp: Machen Sie Ihrem Mitarbeitern klar, dass ab sofort kein Meeting mehr verpflichtend besucht werden muss. Denn es ist die Verantwortung jedes einzelnen zu entscheiden, wie die eigene Zeit am produktivsten einzusetzen ist. Machen Sie aber auch klar, dass die Entscheidungen der Anwesenden von den Nichtanwesenden mitzutragen sind.
Es ist Zeit, Meetings wieder produktiv und spannend zu machen. Die hier genannten Tipps sind leichter umzusetzen, als Sie vielleicht denken. Allerdings lohnt es sich, dafür eine dedizierte Rolle – die des Moderators – einzusetzen. Dieser sollte durchaus Ahnung von der Materie haben und in der Lage sein, die Diskussion etwa um gute Fragen zu bereichern. Vor allem aber sollte er oder sie in der Lage sein, Meetings so zu führen, dass Entscheidungen getroffen und am besten gleich umgesetzt werden können.
fuesse

Mit Tests die Kostenkurve kriegen

Bei einem Gespräch unter Kollegen kam wieder einmal das Thema „Qualität der Software“ zur Sprache. Jeder von uns hatte seine eigene Geschichte aus seinem Projekt mitgenommen und mit den anderen geteilt. Wir waren verblüfft, wie schwer es Software-Teams noch immer fällt, Software regelmäßig und funktionstüchtig zu liefern. Um mit gutem Beispiel voranzugehen, entschieden wir daher, diesen Beitrag im sogenannten “Pair Blogging” entstehen zu lassen. Was bedeutet das? Zwei Kollegen arbeiten nebeneinander auf ihren Notebooks in einem Google-Dokument und schreiben was das Zeug hält. Und damit zum eigentlichen Thema.
Wir haben das Gefühl, dass auch heute noch viele Unternehmen bzw. das Management die anfänglichen Investitionskosten für einen guten Softwareauslieferungs-Prozess scheuen. Bei Legacy-Systemen ist die Angst vor einem langen und teuren Migrationsprojekt oft noch viel größer. Die Verlockung, schnell Software ohne wirkliche Achtung der Qualitätsgrundsätze zu entwickeln, rächt sich spätestens bei den ersten Anforderungsänderungen der Kunden. Denn zu diesem Zeitpunkt kippt das Verhältnis der anfänglichen Investitionskosten gegenüber den immer stärker steigenden Kosten für jede einzelne Änderung. Das folgende Diagramm, das die “Cost of Change”-Kurven von Berry Boehm, Alistar Cockburn, Scott Ambler und Kent Beck abbildet, macht dieses Phänomen deutlich sichtbar.
Screenshot 2014-11-28 10.03.18
Dabei ist es weder notwendig noch sinnvoll, für die Einführung von Testautomatisierung oder Continuous Delivery ein großes Projekt zu starten. Ein erfolgsversprechendes iteratives Vorgehen zeichnet sich durch einen schnellen Return on Investment und geringe Risiken aus. In kleinen Schritten immer genau jenen Teil verbessern, in dem die Schmerzen am größten sind. Welche Komponente sorgt für die meisten Fehler im Test? Diese sollte mit automatisierten Tests überprüft werden, und erstmal nur diese. Wo läuft das Deployment immer wieder schief? Für genau dieses System sollte das Deployment automatisiert werden. Solche Investitionen zahlen sich sofort aus, und wir lernen gleichzeitig für den Umgang mit dem nächsten Problem. Indem man immer das akut größte Problem löst, entsteht Stück für Stück ein Rahmen für agile Softwareentwicklung.
Teams benötigen dafür folgende drei Rahmenbedingungen:

  1. Verantwortungsbewusstsein für Qualität und Lieferung
  2. Die Freiheit und die Freiräume, sich selbstorganisiert darum kümmern zu dürfen
  3. Das nötige Können und Wissen

Das Management ist gefragt, diese Rahmenbedingungen zu schaffen. Die Experten für die Etablierung agiler Entwicklungsmethoden seid jedoch ihr in den Teams – fangt einfach mit dem ersten kleinen Schritt an und erfreut euch am Ergebnis eures Schaffens.
Der Beitrag entstand im Pair Blogging mit Frank Janisch.

Quick Retrospective

The Retrospective meeting is one of the six meetings in Scrum. The main purpose of this meeting is to get an overview of the last sprint. The Development Team has the opportunity to reflect on the process and to identify the advantages and disadvantages of the current sprint and its work procedures.
I would like to introduce you to four different types of a quick retrospective, especially focused on teams who are participating in this type of meeting for the first time. It is common that team members are not really willing to open up and express their feelings, problems, experiences at the first couple of times. Therefore, only the Scrum-Team (DevTeam, SM, PO) is allowed in that meeting, others can only join with the DevTeam’s permission. It is a learning process and the team has to adapt to this new environment of openness. However, every team is more than welcome to use these methods regularly and for other intentions, eg. a short retrospective after every meeting to analyse how helpful and productive it was. A retrospective after a sprint review would give an insight on how stakeholders experienced the meeting.

Rocket Retrospective

Procedure
It is important that you limit the time to your time box and do not extend any parts of the meeting.
The first step is called “Appreciation” and it should not take longer than five minutes because your DevTeam members just have to write down all the positive changes that had an impact on them and their project.
The second step is referred to “Collection of Information”. Every team member gets a card and a pen and he/she has to write down something that should be implemented or something that should be eliminated. Additionally, it is necessary that the person explains what exactly the problem is, why it is a problem and what are the benefits if it is implemented/eliminated. The members have to finish this task within five minutes. Afterwards, all cards are put upside down on a table, so nobody can see what is written on them. Once all cards are on the table the ScrumMaster collects and shuffles the cards.
The last step is termed “Making a Decision”. Each team member has to pick up one card of the table and take “ownership” of it. Then he/she has to write at least one proposal of action on the back of the note. It could be something as simple as writing an email or meet with another team member for 10 minutes two times a week, etc. Once everybody has finished this task, they present their card one by one with the issues and proposed follow-up actions. If some cards are similar those team members get together and put their solutions together on the back.
The ScrumMaster should keep the cards and put them on a whiteboard for everybody to see. The ScrumMaster has to bring the cards at the next retrospective for the participants to give appreciation on them.

Gifts & Hooks

Procedure
The participants have to write down their strengths on paper within 10 minutes. Their strengths are called gifts because they have to list how they could contribute to the project to make it successful. Afterwards every participant has to list every ‘hook’, which are all the things that stand in their way to work more efficiently. At the end everybody shortly presents their list and then the discussion can start on how to remove those hooks preferably.

Genie in a Bottle

Procedure
The team tracked down an ancient bottle. A genie appeared when they opened it. The genie told the team that he/she will grant them three wishes regarding changes at their workplace. And the genie will fulfil them. Now the team splits up into groups of three and list their three wishes on a flip chart and hangs it on the wall for everyone to see. Every team explains why they think those three wishes are the most important ones . The ScrumMaster asks the participants what needs to change for the wishes to become true. Now the SM has a list of the most urgent impediments he/she has to take care of. The charts will be presented at the next retrospective again to see if anything has changed in the meantime.

Hot-air Balloon

Procedure
The ScrumMaster should draw a hot-air balloon on the whiteboard and then ask the participants to write notes and stick them on the following areas: fire, hot air, and forces pulling down. The team has to identify what helps them to go higher and what pushes the project forward by placing those post-its on fire and hot air. Meanwhile, the things that hinders them to work productively are the forces pulling them down. This should not take more than five minutes. Then the team has 10 minutes left to discuss the issues.

Next round please!

Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Der Deming Cycle begleitet mich als Mensch schon ein Leben lang. Die dahinterliegenden Begriffe sind umgangssprachlich schnell erklärt (Für eine intensivere Auseinandersetzung siehe http://en.wikipedia.org/wiki/PDCA oder die Vielzahl der Bücher zum Thema.)
Plan – Lege fest, wie Du das Ziel erreichen willst.
Do – Zerlege das Ziel in kleine Schritte und führe diese aus.
Check – Analysiere das Ergebnis dieser Schritte.
Act – Führe korrektive Maßnahmen durch und mache diese zum Bestandteil des nächsten Durchlaufs.
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Das Konzept ist ein Grundbestandteil der Scrum Methodik und somit ein fester Bestandteil unserer täglichen Arbeit. In den Estimation und Sprint Plannings #1 & #2 planen wir, WAS getan und WIE es getan werden soll (Plan). In den Sprints setzt das Team diese Planung durch die Ausführung von Tasks um (DO). Im Review und in der Retro sehen wir uns an, wie es für die Kunden und für das Team gelaufen ist und was wir in der nächsten Runde besser machen können (Check). Diese konkreten Verbesserungsvorschläge nehmen wir mit in die nächste Runde, um wieder Dinge ein Stück weit zu verbessern (Act).
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
Es ist ein ständiger Kreislauf. Als Metapher dazu fällt mir der ständige Kreislauf der Natur ein. Der Frühling ist der Anfang: Es fangen die ersten Triebe zu sprießen an und die Luft ist voll von Hoffnung auf Wachstum und darauf, in diesem Jahr ungeahnte Größen zu erreichen. Im Sommer beginnt der Wettbewerb der Schönsten: alles blüht und zeigt, welche Pracht die Natur entwickeln kann. Im Herbst ist Showtime: Was wurde denn wirklich produziert und wer trägt die meisten Früchte? Der Winter ist die Regenerationsphase: Es gibt eine Ruhepause, in der die Natur ihre Kräfte sammelt, um im Frühling den Zyklus wieder neu beginnen zu können.
Plan, Do, Check, Act – Plan, Do, Check, Act – Plan, Do, Check, Act – Plan …
So und nun folgendes Szenario: Mutter Natur sagt eines Tages als Personifikation des gesamten Kreislaufes: “Puh, immer dieser Kreislauf und dieses ständige Verbessern und Verändern der Gene und das Mutieren. Ach lassen wir das doch einfach sein. Wir haben das doch schon so einige Jahrmillionen Jährchen gemacht, langsam sollte ich den Dreh ja raus haben, ich hör jetzt einfach auf mich zu verändern. Ich hab mein Ziel erreicht.”
Klingeln da nur bei mir dir Alarmglocken oder geht das anderen Lesern auch so? Ich habe den starken Verdacht, dass diese Maßnahme kein gutes Ende für die Natur (geschweige denn für uns Menschen) haben würde. Was würde mit unserem Ökosystem passieren, wenn Bäume sich entschließen würden, sich nicht mehr an ihre Umstände anzupassen und sich zu verbiegen, um das Sonnenlicht zu erreichen? Was würde passieren, wenn Blumen nicht immer neue Geruchsstoffe entwickeln würden, um Insekten jedes Jahr aufs Neue anzulocken?
Das ständige, nie aufhörende sich Verändern ist ein stetiger Bestandteil der Natur, dem wir unser Überleben verdanken. Mehr noch, wir Menschen selbst befinden uns in einem ständigen Veränderungsprozess, der unser eigenes Überleben ermöglicht. Eine Lebensphase wechselt die nächste ab. Was gestern noch unglaublich wichtig war, kann morgen schon bedeutungslos sein.
In diesem Sinne, feiern Sie in Scrum den Herbst (Review) und nutzen Sie die Winter (Retrospektive), um sich Gedanken zur Optimierung der nächsten Iteration zu machen – aber bitte vermeiden Sie es, das Ende von Scrum zu suchen. Das Ende von Scrum als iterativer Prozess wäre das Ende der Weiterentwicklung. Die Weiterentwicklung ist jedoch der größte Vorteil auf einem sich verändernden Markt und hilft, jede Schwierigkeit zu meistern.

Sichtbarkeit ist der erste Schritt – das Taskboard auf Management-Ebene

„Aber ich habe ja so viele Dinge, die ich jeden Tag erledigen muss – da kann ich doch gar nicht ständig einen Zettel schreiben?“ So oder so ähnlich lauteten in einem Projekt die Kommentare, als wir begannen, ein Taskboard auf Management-Level einzuführen. Ich kann das gut nachvollziehen, meine Taskliste von heute sieht so aus:

Soll ich da wirklich jedes Mal einen Zettel schreiben oder meine kleine 1h-Aufgabe in einem Tool wie JIRA oder Trello ablegen? Ihr könnt euch denken, dass ich vor mich hin schmunzle. Denn während ich das hier schreibe, habe ich ja gerade die Einträge für ein Taskboard erstellt. Das nun auf Klebezettel zu schreiben, oder vielleicht sogar in ein Tool wie JIRA einzutragen, ist sicher genauso möglich. Es ist ein wenig komplizierter, aber nicht sehr. Wer mehr dazu wissen will, wie man das effizient macht, dem sei Personal Kanban empfohlen. Und doch: Management-Teams wehren sich zunächst, diese wenigen Einträge zu machen. Also mache ich sie in meiner Rolle als ScrumMaster in der ersten Woche für das Management-Team. Auf diese Weise sehen sie auch, wie viele Dinge sie erledigt bekommen und wie viele Dinge sie abseits des Üblichen  noch so machen.
Ist Euch das auch schon mal aufgefallen? Die meisten Manager machen unendlich viele ad-hoc-Aufgaben, sie stecken zu tief im Tagesgeschäft. Ständige Störungen, permanente Meetings und sie werden von E-Mails überflutet. Konzeptionelles Arbeiten oder gar Führen ist fast nicht möglich. Ich habe schon öfter geschrieben, dass Henry Mintzberg das schon vor Jahren festgestellt hatte:
“Folklore: The manager is a reflective, systematic planner. The evidence of this issue is overwhelming, but not a shred of it supports this statement.

Fact: Study after study has shown that managers work at an unrelenting pace, that their activities are characterized by brevity, variety, and discontinuity, and that they are strongly oriented to action and dislike reflective activities. Consider this evidence: Half the activities engaged in by the five chief executives of my study lasted less than nine minutes, and only 10% exceeded one hour. A study of 56 U.S. foremen found that they averaged 583 activities per eight-hour shift, an average of 1 every 48 seconds. The work pace for both chief executives and foremen was unrelenting. The chief executives met a steady stream of callers and mail from the moment they arrived in the morning until they left in the evening. Coffee breaks and lunches were inevitably work related, and ever-present subordinates seemed to usurp any free moment.“
Trotzdem es ist etwas anderes, das täglich in der Praxis zu sehen. Management-Teams haben also nicht wirklich Zeit, das große Ganze zu sehen. Sie kommen gar nicht dazu, sich um die vielen wichtigen Aspekte zu kümmern, denn sie sind total beschäftigt. Gesehen haben wir ein ähnliches Phänomen in der Vergangenheit bereits bei skalierten Scrum-Implementierungen. Dort mit den Product Ownern konzeptionell zu arbeiten, in Ruhe ein Backlog aufzubauen, vielleicht zwei Tage intensiv daran arbeiten, eine wirklich ausgearbeitete Story Map zu erstellen – das war aufgrund der vielen Störungen gar nicht möglich. In diesen Kontexten hatten wir aber die Schwierigkeiten auf die Komplexität der Produkte geschoben.
Was mir jetzt als ScrumMaster eines Management-Teams auffällt: Es fehlt die Priorisierung. Alles scheint gleich wichtig, als wäre es in einem größeren Unternehmen nicht auch möglich, sich zu fokussieren. Gleichzeitig ist das nicht so viel anders als das, was die Arbeit von vielen Entwicklungsteams in der Vergangenheit gezeigt hat.
Wie kann ich meinem Management-Team dabei helfen: Mit einem Taskboard. Es macht transparent, wie viele Dinge erledigt werden müssen. Damit kann man daran arbeiten, die wirklich wichtigen Dinge zu tun und sich gegenseitig zu helfen. Jetzt brauche ich nur noch Geduld – wie bei allen Teams dauert es ein wenig, bis die Idee des Taskboards angenommen wird.
Literatur
Henry Mintzberg: The Manager’s Job: Folklore and Fact, HARVARD BUSINESS REVIEW: March/April 1990, p. 163 – 176

Agile Projektsteuerung mit Artefakten und KPIs

Kürzlich durfte ich mit einem Team zusammenarbeiten, das Treiber entwickelt und ein großes Problem hatte: Es konnte seine Sprint-Commitments nie einhalten. Nach zwei Monaten war das Team so weit, dass es nicht mehr Scrum machen wollte. Das Framework passe einfach nicht zu ihnen, sagten sie.
Ich setzte mich mit dem Team zusammen und wir begannen, den Prozess, so wie er aktuell ist, aufzuzeichnen. Üblicherweise können Commitments dann nicht eingehalten werden, wenn das Team im Laufe des Sprints viele ungeplante Aufgaben (Support, Change Requests) zu bewältigen hat. Das war aber hier nicht der Fall – der Anteil ungeplanter Aufgaben war mit jenem anderer Teams vergleichbar. Das eigentliche Problem war die Anzahl an Backlog Items, die gleichzeitig in Bearbeitung waren. Je mehr Treiber das Team parallel entwickelte, desto länger wurde die Fertigstellungszeit. Warum aber nahm das Team so viele Treiber gleichzeitig in Bearbeitung? Um der Sache auf den Grund zu gehen, setzten wir Artefakte auf, die den Arbeitsfluss verdeutlichen sollten:

  1. Das Taskboard: Anstelle der klassischen Dreiteilung (Open/In Progress/Done) fingen wir an, den Workflow der Treiber-Entwicklung darzustellen. Es gab also pro Arbeitschritt eine eigene Spalte. Außerdem begrenzten wir die Zeilen am Taskboard, so dass maximal fünf Treiber gleichzeitig in Bearbeitung genommen werden konnten.
  2. Das Cumulative Flow Diagram: Hier wird jede Woche gezählt, wie viele Aufgaben sich in welcher Spalte auf dem Taskboard befinden. So entsteht für jede Spalte eine eigene Kurve, die wöchentlich fortgeschrieben wird. Dadurch lässt sich ablesen, ob sich der Arbeitsprozess im Fluss befindet. In unserem Fall hatten wir mit einer flachen “Done-Kurve” zu tun (denn die Anzahl an fertig gestellten  erhöhte sich nicht) während z.B. die “Waiting for Test”-Spalte steil anstieg, weil neue Treiber auf den Integrationstest warteten. Dadurch konnten wir sehen, wo die Engpässe im System sind – und was wir verändern müssen, um wieder einen Fluss zu erzeugen. Zudem lassen sich am Cumulative Flow Diagram Lead Time und Work in Progress ablesen (siehe nächster Punkt).
    Cumulative Flow Diagram
  3. WIP und Lead Time: Wir einigten uns auf zwei KPIs (Key Performance Indicators). WIP (Work in Progress): Das ist die Anzahl an Treibern, die sich gleichzeitig in Bearbeitung befinden. Die Obergrenze hierfür haben wir auf fünf festgelegt und das Taskboard als quasi physikalische Grenze entsprechend aufgebaut. Lead Time: Das ist die Zeit, die zwischen Aufnahme eines neuen Treibers in die Entwicklung und dem Release vergeht. Hier fingen wir an, jedem Backlog Item auf dem Taskboard zwei Zeitstempel zu geben – “IN” und “OUT”. Je länger die Lead Time, desto unproduktiver ist das Team.
  4. Release-Burndown-Chart: Der Product Owner hatte für das Jahr mit 13 neuen Treibern (darunter Neuentwicklung und Updates) geplant. Mit dem Burndown-Chart konnten wir die tatsächlich fertig gestellten Treiber visualisieren – und anhand des Kurvenverlaufs erkennen, ob mit der aktuellen Lead Time das Ziel noch realistisch ist.

Was hat sich verändert?

Vor Veränderung kommt immer die Transparenz. Gerade als erfahrener agile Practitioner sollte man von schnellen Ratschlägen Abstand nehmen. Erst wenn tatsächlich verstanden wurde, wie das Team aktuell arbeitet, können Hebel für Veränderungen identifiziert werden. In diesem Fall wurde klar, dass das Team mit langen Wartezeiten konfrontiert war, da es für die Erstellung von Skripten sowie für die Verifikation und Validation auf Unterstützung von anderen Teams angewiesen war. Das Team füllte diese Wartezeiten, indem es in der Zwischenzeit mit etwas Neuem anfing. Wir kennen das Phänomen, wenn wir zu viele Downloads gleichzeitig starten – am Ende dauert alles viel länger. Deshalb konnte das Team keine Commitments einhalten. In der Außenwahrnehmung wurde das Teams als unzuverlässig gesehen – in Wirklichkeit machte es zu viel gleichzeitig.
Um das Vertrauen in die Planbarkeit zurückzugewinnen, fing das Team mit wöchentlichen Forecasts an. Am Montag stellten sich alle vor das Taskboard und beschlossen gemeinsam, was sie bis Freitag erreicht haben wollten. Das Taskboard, wie es dann am Freitag aussehen sollte, wurde aufgezeichnet und zum Vergleich neben das aktuelle Taskboard gehängt. Das funktionierte gut.
Product Owner und Management erhielten über den Release-Burndown und die Lead Time zwei ehrliche Indikatoren darüber, was tatsächlich geschafft werden kann. Somit hatten sie zum ersten Mal eine verlässliche Planungsgrundlage. Und der ScrumMaster konnte die Impediments beim Namen nennen, die der Produktivität im Wege standen. Mittelfristig wurden diese über eine engere Zusammenarbeit mit den anderen Teams (tägliches SoS) gelöst, so dass Abhängigkeiten sofort adressiert werden konnten und durch bessere Synchronisation Wartezeiten erst gar nicht entstehen. Langfristig geht es darum, dass das Team immer mehr selber in die Hand nehmen kann (etwa beim Testen) und so schneller wird.

Die Operation am offenen Herzen

Eine Situation unlängst in einem meiner Kundenprojekte: Die aufwändig in mehr als 5 Monaten entwickelte Software-Lösung befindet sich im großen abschließenden Test durch alle Fachbereiche. Es ist ein zeitintensives Verfahren, da viele Stakeholder involviert und jede Menge Testfälle abgearbeitet werden müssen. Ein in der Mitte des Integrationstest gefundenes und zunächst klein aussehendes Problem entwickelt sich während der Analyse zusehends zum „Show-Stopper“. Wichtige Plausibilisierungsprüfungen für den Geschäftsprozess finden wegen einer falschen Logik keine Anwendung. Das To-Do ist schnell klar: Die Methode muss umgeschrieben und verbessert werden, die Anpassungen sind überschaubar.
Was zunächst einfach klingt, gestaltet sich auf den zweiten Blick äußerst problematisch. Die Anpassung muss in einem zentralen Baustein der Geschäftsprozesslogik angepasst werden – das hat große Auswirkungen auf die Geschäftsprozesse. Die Software und Prozesse sind nur sehr mangel- und lückenhaft mit Unit Tests und automatisierten Testskripts abgesichert. Änderungen könnten großflächige Nachtests aller Geschäftsprozesse bedeuten, welche die Produktivsetzung der IT-Lösung um Wochen verzögern wurde. Gute Ideen sind nun gefragt …
Nach einem hektischen und diskussionsreichen Brainstorming hat das Team einen vermeintlich vernünftigen Weg aus der Misere gefunden:

  1. Die betroffene Methode soll in einem ersten Schritt umfangreich durch zahlreiche Unit Tests an den Schnittstellen abgesichert werden.
  2. In einem zweiten Schritt wird die Methode überarbeitet und mit Hilfe der Unit Tests auf deren gleiche Funktionsweise getestet.
  3. In einem dritten Schritt sollen einzelne Testfälle des Integrationstests stichprobenartig wiederholt werden.

Müsste ich eine Analogie für diese Vorgehensweise finden, würde ich die Operation am offenen Herzen wählen. Auch in der Medizin wird versucht, das Herz so gut wie möglich vom Rest der Organe bei gleichzeitiger Beibehaltung seiner Funktion zu isolieren. Beide Vorgehensweisen bergen Risiken, aber sie sind deutlich geringer als bei einem rigorosen Vorgehen ohne vorherige Absicherung bzw. Isolierung.
Wenig überraschend ist, dass die nachträgliche Absicherung der Methode deutlich aufwändiger ist, als wenn sie gleich von Beginn an testautomatisiert aufgebaut worden wäre. Gerade dieses Beispiel hat mir wieder gezeigt, wie wichtig es ist, bestehende Funktionalität gewissenhaft abzusichern, um Änderungen im Code vornehmen zu können. Denn diese Änderungen werden kommen, ganz gleich ob durch Fehler oder neue Anforderungen bedingt.
Respond to change … Start code test-driven!

Cross-funktionales Arbeiten – wie geht das?

Über Apple ist in den letzten Jahren so viel geschrieben worden, dass in der Flut an Informationen nur noch wenige wirklich neue Erkenntnisse aufwarten. Und doch: Auf der Webseite Co.Design ist kürzlich ein aufschlussreiches Kurzportrait über Apples Designkultur erschienen. Der Bericht stützt sich auf Mark Kawano, der sieben Jahre lang als Designer für Apple arbeitete.
Die Kernaussage ist: Apples Designkultur ist nicht auf die Herrschaft besonders begabter Designer zurückzuführen. Sie beruht vielmehr auf einer Ausrichtung des gesamten Unternehmens auf gutes Produktdesign. Bei der Entwicklung neuer Produkte sind Designer und Entwickler so in der Lage, am gleichen Strang zu ziehen:
“For the most part, Apple didn’t employ specialist designers. Every designer could hold their own in both creating icons and new interfaces, for instance. And thanks to the fact that Apple hires design-centric engineers, the relatively skeleton design team could rely on engineers to begin the build process on a new app interface, rather than having to initiate their own mock-up first.”
In Scrum sprechen wir in diesem Zusammenhang von cross-funktionalem Arbeiten: Wie in einem Operationssaal arbeiten Spezialisten Hand in Hand. Jeder hat andere Aufgaben und auch Ziele – und trotzdem weiß jeder zu jedem Zeitpunkt, was der andere gerade macht und wo er welche Unterstützung braucht.
In der Produktentwicklung gibt es diese Spezialisierung ebenfalls: Disziplinen wie Design, Konstruktion, Qualitätsmanagement, Einkauf, Marketing und Vertrieb sind normalerweise in verschiedenen Abteilungen untergebracht. Innerhalb von Produktentwicklungsprojekten kommen die Abteilungen zwar punktuell zusammen (etwa beim Erreichen von Meilensteinen), doch findet keine intensive Zusammenarbeit wie im OP-Saal statt. Das führt häufig dazu, dass jede Disziplin ihren eigenen Zielen folgt und sich nicht genügend austauscht:

Dass jede Disziplin ihren eigenen Zielen folgt, ist völlig normal. Doch führt ein Mangel an Zusammenarbeit dazu, dass aus Unkenntnis über die Ziele der anderen kein gemeinsamer Grund entstehen kann. So haben wir die berüchtigten Silos, in denen nur noch lokal optimiert wird.

Das Team als Keimzelle der cross-funktionalen Zusammenarbeit

Mit der Schaffung von Scrum-Entwicklungsteams ist formal eine Instanz geschaffen, in der die verschiedenen Spezialisten zusammen kommen. Und es gibt auch einen gemeinsamen Grund: Die Verantwortung des Entwicklungsteams ist die erfolgreiche (Aus-)lieferung des Produkts. Doch der erfolgreichen Zusammenarbeit stehen häufig Hindernisse im Weg. Die typischen Hindernisse sind:

Organisationsveränderung will gelernt sein

Keines der drei Hindernisse ist prinzipieller Natur – alle sind sie überwindbar. Sie erfordern allerdings mutige Entscheidungen, die altbewährte Denkweisen und Paradigmen wie z.B. das der maximalen Auslastung und Effizienz in Frage stellen.
Machen wir uns nichts vor: Der Weg zum cross-funktionalen Arbeiten ist für die meisten Unternehmen ein starker Veränderungsprozess, der zu Widerstand und tiefer Verunsicherung führen kann. Umso wichtiger ist das Design des Prozesses: Veränderungen, die von wenigen konzipiert und dann ausgerollt werden, haben meistens mit erheblichen Akzeptanzproblemen zu kämpfen. Man spart sich viele Grabenkämpfe und Umwege, wenn die Betroffenen von Anfang an zusammen kommen, damit sie selbst einen Lösungsvorschlag erarbeiten.
Hierzu bietet sich das Format der Pilotgruppe an, die aus einem repräsentativen Querschnitt des Unternehmens besteht und damit beauftragt wird, Antworten auf die relevanten Fragestellungen zu finden. Wichtig ist, dass eben diese Fragestellungen und die dazu gehörigen Rahmenbedingungen im Vorfeld vom Management festgelegt werden. Wir haben am Beispiel Apple gesehen, wie ein Unternehmen seine Kernbotschaft (bei Apple ist es das Design) über einige wenige Spezialisten hinaus in der gesamte Unternehmenskultur verankern konnte.
Was auch immer Ihre Kernbotschaft ist: Erlauben Sie nicht, dass sie von den Zwängen der Unternehmensprozesse und -strukturen verwässert wird.

5 minutes on scaling: Hangout & Co

Natürlich nutzen wir mittlerweile neben den physischen Taskboards auch JIRA und Co. Doch jedes Mal, wenn ich diese Tools nutze, gehen mir ihre Unzulänglichkeiten auf den Geist. Sie lösen im skalierten Umfeld das eigentliche Problem nicht: Sie helfen nicht, die Kommunikation zwischen den Scrum-Teammitgliedern einer weltweit aufgestellten Organisation zu vereinfachen. Vielmehr sind sie zu Datenbanken, Reporting Tools, perfektionierten Bug Tracking Tools und Forecast Push Systemen degeneriert. Selbst bieten diese Wesen keinen Mehrwert – sie müssen sich der Lebenszeit von Entwicklern und Managern bedienen, um am Leben zu bleiben.
Dabei wäre es so einfach, ein wirklich funktionierendes, agiles Scrum-Tool zu entwickeln. Eines nämlich, das Arbeit beschleunigt und Kommunikation erleichtert, statt zu einer Belastung zu werden. Dazu bräuchte es nur ein paar Entwickler, die nach folgendem Rezept das perfekte Scrum-Tool bauen:

  1. Man nehme ein wirklich funktionierendes, d.h. stabiles Video Conferencing System wie zum Beispiel Google Hangout und verpasse ihm eine bessere Usability – sorry liebe Googles, das geht besser!
  2. Man füge eine Prise Telefoneinwahl international und kostenfrei hinzu – für die Teammitglieder, die während des Daily Scrums unterwegs sind (sorry, noch ist WLAN oder LTE auf deutschen Autobahnen und im ICE zu instabil – vor allem bei Hochgeschwindigkeitsfahrten).
  3. Dann mische man ein Whiteboard, eine Desksharing-Funktionalität, einen Persistent Chat und ein Taskboard hinzu.
  4. Nun braucht man noch die Möglichkeit, Texte auffindbar zu erstellen, die u.a. aber nicht nur an den Stories hängen. Deshalb integrieren wir ein Wiki, das sich aber bitte so wie ein Google Docs verhält.
  5. Für große Mengen an Bildern und Dokumenten brauchen wir noch Dropbox oder Evernote.
  6. Als Dessert nehmen wir noch einen integrierten Kalender, ein Shared Adressbook und eine E-Mail-Funktionalität.

Fertig. Alle zu Tisch, so kann man international arbeiten.
Ach so: Die Reporting-Funktionalitäten fürs Management lassen wir weg.
Fortschritte zeigen wir, indem wir fertige Produkte liefern – wir zeigen es nicht durch abgearbeitete Stories oder Tasks. Das ginge ja, wenn wir das Video-Chat-Programm so ausweiten könnten, dass wir ohne Probleme Demos auch für nicht Firmenmitglieder abhalten könnten.
Naja, ich träume. Aber ganz ehrlich, wir brauchen solche Tools. Die Entwicklung in der postindustriellen Netzwerkgesellschaft geht hin zu mehr Remote-Arbeit (work were you are), denn Teams kaufen sich die Kollegen dort ein, wo sie eben wohnen. Einer meiner Bekannten wohnt in St. Pölten (Niederösterreich) und arbeitet täglich für ein kalifornisches Unternehmen als Entwickler – warum auch nicht. Softwareentwicklungs-Teams können das heute. Andere Firmen werden folgen.
Wir müssen das möglich machen. Die Teams eines unserer Kunden arbeiten an zwei Orten in den USA, in China, in Indien und in München. Wir brauchen die Infrastruktur, um sie miteinander arbeiten zu lassen – und zwar produktiv. Und nein: Menschen zu einem Umzug oder hunderttausenden Flugmeilen mehr zu zwingen, ist keine wirkliche Alternative – weder steuertechnisch noch aus Sicht der Produktivität. Wissensarbeit braucht den Austausch, das miteinander Denken. Das geht in der Business Class des A380 nicht, da hilft auch die überfüllte Senatoren Lounge nichts mehr. Das ist nichts anderes als verlorene Lebenszeit.
Verteiltes, skaliertes und mulitkulturelles, grenzüberschreitendes Arbeiten wird zum Alltag werden. Kleine, schlanke Firmen werden das mit einer Symbiose aus den günstigen Lösungen wie Google HO, Confluence, Evernote und Dropbox stemmen. Große, unbewegliche Konzerne werden folgen – und dafür teure Enterprise Tools einkaufen. Vor allem müssen wir es schaffen, auch den multikulturellen Aspekt zu berücksichtigen. Schweizer, Österreicher und Deutsche – wir sprechen eine Sprache und meinen etwas völlig anderes. Ein elektronisches Board, dessen Sichtbarkeit auf die Größe eines Monitors beschränkt ist, muss also etwas anderes können, als beim Verschieben der Tasks die Farbe zu wechseln.

Sag mir, wie du schätzt und ich sage dir, wer du bist

Traditionell fragen Projektmanager ihre Kollegen: “Wie lange dauert es, das zu entwickeln?“ Sie wollen Kosten berechnen, die Länge des Projekts kalkulieren und möglichst früh wissen, wie viele Ressourcen das Projekt braucht.
Diese Fragen deuten immer in die gleiche Richtung: Die Projektmanager wollen die Unsicherheit aus dem Projekt nehmen. Unsicherheiten gibt es in Projekten genug: Haben die Projektmitarbeiter genügend Ahnung? Bekommt man die Technologie in den Griff? Hat man am Ende für das gesamte Projekt genügend Budget? Findet man die richtigen Features für das Produkt? Wird der Kunde es haben wollen? Werden die Kollegen die geeigneten Lösungen schnell genug finden … und, und, und. Kurz, es wird versucht die Zukunft vorherzusagen und gleichzeitig weiß man ganz genau, dass das gar nicht geht. Denn jeden beschleicht das Gefühl, dass man bei einem Projekt ja etwas Neues macht – also etwas, das es vorher noch nicht gegeben hat, etwas, das noch nie gemacht wurde. Alle diese Fragen können also gar nicht beantwortet werden. Mit diesen Fragen bin ich immer in die Diskussion eingestiegen und habe mich dabei gewundert, wie man als Projektmanager überhaupt annehmen kann, diese Fragen zu Anfang eines Projekts klären zu können. 
Dann fragte mich letztens ein Zuhörer bei einem meiner Vorträge: „Ist es denn so? Ist es nicht vielmehr so, dass die meisten Projekte sehr wohl von Leuten gemacht werden, die genau das Gleiche schon einmal gemacht haben? Daher kann man doch sehr genau die Aufwände schätzen.” In diesen Fällen wisse man doch genau, wie lange etwas dauere.

Diesem Argument lässt sich nicht viel entgegensetzen, oder? Denn es ist korrekt: Wenn man mehr oder weniger immer das Gleiche tut, kann man auch Vorhersagen treffen. Auf diesem Prinzip basieren auch alle Ansätze der Schätzverfahren in Scrum-Teams. Wenn man zu irgendeinem Zeitpunkt genug Daten darüber hat, wie lange etwas dauert, dann lassen sich sehr wohl die Aufwände schätzen. Aber Moment: In diesem Fall befindet sich ein solches Team doch gar nicht mehr in einem Projektmodus. In diesem Moment, in dem es wiederkehrende Aufgaben vollbringt, ist es wieder in einem Support-, Maintenance- oder Bug-Fixing-Modus. Aber genau dann sollte man doch sofort vom Projektmanagement hin zu einem klassischen Verfahren der Prozesssteuerung und des Workflowmanagements zurückgehen und wo landet man da? Genau – beim Lean Management des Toyota Production Systems. Dann ist man besser damit beraten sich anzusehen, wie man in Call Centern, in Produktionsbetrieben, in der Logistik oder in Einkaufszentren arbeitet. Dort sollten Logistiker den Ton angeben: Denn Workflowmanagement wird seit 40 Jahren nach dem Pull-Verfahren und dem One-Piece-Flow-Verfahren optimal gesteuert. Es hat lange gedauert, bis sich dieses Wissen durchgesetzt hat, aber es war am Ende erfolgreich. Viele Manager, die Sales-Zahlen vorgeben, Absatzzahlen erfinden und Produktionsziele vorgeben wollen, wollten lange nicht wahrhaben: Der Empfänger des Produkts, meist der Kunde, bestimmt durch sein Kaufverhalten, wie viel ein Unternehmen liefern sollte, und nicht die Annahmen darüber, wie viel der Kunde möglicherweise kaufen wird. Das hat der Handel in den letzten 10 Jahren gelernt und man sieht es jeden Tag an der Kasse der Discounter, wie dieses Prinzip funktioniert.

Dieses Denken hat auch in die Software-Entwicklung Einzug gehalten. Die massive Hinwendung vieler Software-Entwicklungsabteilungen hin zu Kanban – die heute sogar in Tools wie JIRAs Ansatz zur Workflowsteuerung gipfeln – lässt sich so erklären, und sie ist folgerichtig. Wo nichts Neues entwickelt, wo keine Projekte gemacht und einfach das immer Gleiche immer wieder neu angepinselt und noch einmal verkauft wird, da gilt es tatsächlich nichts anders als effizientes Workflowmanagement zu machen. Support-Aufgaben hier, ein Bugfix da.
Es gibt Untersuchungen und IT-Leiter, die behaupten, 70% dessen, was entwickelt werde, wäre nunmal Maintenance. Aus meiner Beobachtung stimmt das. Es ist so – aber wieso? Ist das eine Ursache oder ein Symptom? Ich glaube, dass ist das Symptom. Wenn Software-Entwicklung so durchgeführt wird, wie in vielen Unternehmen heute noch immer und am Ende zu gigantischen Bergen technischer Schulden führt, ja dann schreibt man relativ schnell keine neuen Features, sondern ist ständig damit beschäftigt, das Alte anzumalen oder kleine, völlig unbedeutende Veränderungen vorzunehmen. Die wunderbare Präsentation von Salesforce.com zeigt sehr eindrucksvoll, wie das auch einem Internet-Startup wie Salesforces.com sehr schnell passiert ist.

Aber zurück zum Schätzen. In diesen Umfeldern ist es zwar prinzipiell möglich, Aufwände sogar relativ gut und valide zu schätzen, denn man hat ja eh immer das Gleiche zu tun. Aber es ist völlig unnötig, wie uns die Logistikindustrie gezeigt hat. In diesen Umfeldern hat sich etwas anderes durchgesetzt: Die sogenannte Flusssteuerung, die mit Hilfe statistischer Verfahren die Durchflussgeschwindigkeit und die Höhe der Inputschlange bestimmt, und basierend auf diesen Aussagen die Lieferzeiten sehr korrekt ermitteln kann.
Man braucht also gar nicht mehr zu schätzen, sondern man weiß, wann etwas geliefert wird. Diese Ideen hat Kanban für die Software-Entwicklung populär gemacht – es wurden Serviceklassen eingeführt und nun ist man sehr gut darin, mit diesen Verfahren und WIP-Limits die Auslastung von Teams zu steuern. Jedes Schätzen ist hier Zeitvergeudung und vollkommen unnötig. Erklärt man diesen Umstand, schauen mich Projektmanager oft ungläubig an. Die Prinzipien sind zwar einfach, doch leider liegen diese Erkenntnisse quer zu dem, was der gesunde Menschenverstand sagt und vollkommen quer zu dem, was in vielen Unternehmen zum Thema Auslastung, Workflowmanagement etc. gelehrt wird. Es hat 20 Jahre gedauert, bis in der Automobilindustrie die Ideen von Toyota wirklich angekommen sind.
forward-412761_640

Wenn also Schätzen in diesen Umfeldern nicht mehr notwendig ist, wie ist das dann bei echten Projekten? Also in einem Kontext, in dem etwas versucht wird, das noch nie zuvor versucht worden ist? Ich habe das große Glück, in den letzten beiden Jahren mit Kunden arbeiten zu dürfen, die solche Projekte durchführen. Dort werden tatsächlich Dinge getan, erforscht, erprobt, ausgetüftelt – also Produkte gebaut, die noch nie zuvor ein Mensch gesehen hat. Das ist ein bisschen so wie der erste Mondflug. Man weiß einfach nicht ob es geht. Die einzige Chance, in diesen Projekten zu Ergebnissen zu kommen, ist die Welt zu gestalten. Man erfindet einfach das, was man braucht. Seien es die Entwicklungsmethoden, die Tools oder auch die notwendigen Produktideen. Allerdings ergibt sich aus diesem Vorgehen eine prinzipielles und unlösbares Faktum. Nun kann man einfach nicht mehr voraussagen, wann man fertig ist. Sicher, man kann sich etwas vornehmen, auf ein Ziel hinarbeiten. Doch etwas zu versprechen wäre illusorisch.
Findige Designer haben für Dinge, die nicht zu komplex sind, eine relativ simple Methode gefunden, wie man dennoch Fortschritte dokumentieren kann und wie man sich zumindest auf etwas festlegen kann: Man gibt einen Zeitrahmen vor. Diese zeitliche Grenze erzeugt den notwendigen Druck, zumindest immer auf ein Ziel hinarbeiten zu müssen, sich also nicht selbst zu belügen und einfach ergebnislos vor sich hinzuarbeiten. Zeitliche Grenzen erzeugen den Fokus, man probiert nicht alles aus, sondern liefert mal den erstmöglichen Fortschritt, das erstmögliche Ergebnis. Kann man diesen Zeitrahmen sinnvoll strukturieren? Sicher! Es gibt Techniken wie Design Thinking oder Scrum, die Teams dabei helfen, genau diesen Zeitrahmen zumindest insofern zu strukturieren, dass das Finden von Ergebnissen wahrscheinlicher – nicht aber sicher – wird.

Doch jetzt das Paradoxon: Diese Methoden sind bekannt. Sie sind sogar so erfolgreich, dass die erfolgreichsten Firmen des letzten Jahrzehnts freiwillig erzählen, dass sie darauf setzen. Sie sind sogar in den Firmen bekannt, die bis dato ganz anders gearbeitet haben – dennoch wird stillschweigend noch immer vorausgesetzt, dass man wissen muss, wann zu welchen Kosten und mit welchem Ergebnis auf jeden Fall das geliefert werden soll, was man heute noch gar nicht kennt. Es wird also versucht, diese neuen Methoden in einem Kontext zu leben, der zugegeben hat, dass die Aufgabe unlösbar ist. Deshalb nimmt man die neuen Methoden und gleichzeitig verdrängt man die Tatsache, dass die Aufgabe unlösbar ist.
Aufwände zu schätzen ist in diesen Umfeldern schlicht unmöglich. Das ist jedem klar, und doch wird es immer wieder gefordert. Warum? Der Trugschluss herrscht, dass man mit Hilfe des Schätzens eines bekämpfen könnte: Die Angst, in irgendeiner Weise zu versagen. Es geht also anders ausgedrückt darum, das Risiko zu verringern. Als könne man durch das Schätzen gewährleisten, dass es zu keinem Verlust kommen könnte.

Doch Schätzen ist aus mindestens diesen vier Gründen ungeeignet, das Risiko zu minimieren:

  1. 
Aufwandsschätzungen werden zumeist optimistisch abgegeben. Damit wird das Risiko erhöht.
  2. Aufwände werden als Kostenfaktor gesehen. Damit ist eine hohe Schätzung zwar vielleicht ein Maß für Risiko, aber wirtschaftliche Interessen konterkarieren dieses Thema sofort.
  3. Wir wissen aus den Arbeiten von Eliyahu Goldratt, Autor von „The Goal“, dem einflussreichsten Buch zur Theory of Constraints, dass im Falle dessen, dass Aufwandsschätzungen zu groß waren, dennoch diese Aufwände aufgebraucht werden. Damit erhöht sich das Risiko, die Puffer des Projekts zu sprengen und wenn dann wirklich eine Schätzung zu gering war, bricht man die zeitlichen Grenzen. Das Projekt wird also riskanter.
  4. 
Aufwandsschätzungen sind abhängig von dem, der sie durchführt. Damit erhält man kein objektives Maß für das Risiko.

All das ist hinreichend bekannt. Dennoch erzeugen Aufwandsschätzungen und die sich daran ausrichtende Planung immer wieder die Illusion, das Risiko wäre gebannt.
Was durch das Schätzen von Aufwänden also in Wahrheit geschieht: Das Risiko wird nicht eingeschätzt und bewertet, sondern es wird verdrängt und ignoriert. Wir haben geschätzt und gebannt.
Wie wäre es, wenn wir das Risiko benennen würden, ihm ins Gesicht schauen und es angreifbar machen? Wie wäre es, wenn wir von Anfang an sagen würden: Wir haben hier die besten Kollegen zusammengerufen, die wir haben. Wir lassen Sie das Vorhaben mit ungewissem Ausgang wagen. Wir wissen, dass wir nicht wissen können, wann wir fertig sein werden, doch wir nehmen uns Etappen vor, und wir überprüfen immer wieder, was es braucht, um das Ziel zu erreichen. Was wäre, wenn wir offen darüber sprechen würden, dass wir nicht wissen, ob die Technologie die richtige ist, und deshalb davon ausgehen, dass wir bei neuen Erkenntnissen die Richtung noch einmal wechseln können. Was wäre, wenn wir das Risiko dadurch minimieren, dass wir immer einen kleinen Schritt machen und überprüfen, ob wir auf Kurs sind?
Auch dann wäre es nicht nötig zu schätzen. Man schaut einfach, wie viel man ausgegeben kann und wohin man kommen muss, damit man die nächste Investition rechtfertigen kann. Venture Capitalists gehen so vor – und nicht nur diese. Jeder nutzt genau diese Strategie in seinem eigenen privaten Bereich. Man schaut, was man an Ressourcen hat und dann fängt man an. 
Ist das ideal? Nein, aber der einzige Ausweg für alle, die innovative Produkte auf den Markt bringen wollen.
Für alle, die sich der Unvorhersagbarkeit stellen wollen, habe ich ein Buch geschrieben: Wie schätzt man in agilen Projekten – oder warum Scrum-Projekte erfolgreicher sind.

Wir machen Scrum und wann werden wir agil?

Immer wieder gibt es neue Ideen und Ansätze, wie man Agilität erreichen kann. Die haben alle etwas für sich, ergänzen sich ideal und würden im Großen und Ganzen ein supergeiles agiles Unternehmen ergeben. Aber zu Beginn hinterlässt diese Themenbreite auch oft Verwirrung. Müssen wir alles davon machen, sollen wir keines davon machen, sind wir denn richtig agil, wenn wir was weglassen?
Eine Art Kampf der Methoden oder anders gesagt, “der Practices”, fängt damit an. “Tja, Scrum allein ist nicht genug, Kanban ist doch besser!”, ” Was ist mit Design Thinking?”, ” Lean IT Management?”, “Lean Product Development?”, ” Wasserfall hat doch seine guten Seiten?”, “Sollen wir wirklich Test Driven Development oder Pair Programmimg einführen?”, “Wir brauchen doch traditionelles Projektmanagement?”, “Und die Rolle des Managers?”, ” Es gibt doch keine einzelne Lösung, die Lösungsmethode ist doch hybrid, oder?”
Was mache ich mit diesem Blumenstrauß?
Aber was bedeutet Agilität eigentlich, was bedeutet “Scrum machen”?  Eigentlich ganz einfach: Ein einfacher Rahmen, kombiniert mit einer Sammlung von ausgewählten Best Practices, die zusammen die Art zu denken und zu arbeiten vollkommen verändert. Agil sein passiert erst dann, wenn ihr die Grundprinzipien und Werte von Scrum verinnerlicht habt.
Der Einfluss und die Auswirkung dieses Umdenkens ist schwer auf einen Teil der Organisation zu begrenzen, da unter anderen mit Scrum die Kommunikation insgesamt und vor allem die interdisziplinäre Kommunikation und Zusammenarbeit schnell alle Bereich der Organisation betreffen. Alle Individuen sind damit konfrontiert, ihre alten Denkmuster und Arbeitsweisen auf den Prüfstand zu stellen und sie werden die neuen Ansätze kritisch oder zumindest hinterfragend betrachten.

Wie werde ich wirklich agil im Kopf?

Der erste Schritt dazu, agil zu werden, ist agil zu handeln und herauszufinden, was heute zu einer Organisation passt. Genauso müsst ihr aber herausfinden, was erst morgen oder übermorgen passen wird.

So, wie wollen wir das rausfinden? Wie schon gesagt: tun! Es ist an dieser Stelle wichtig, folgende Punkte zu betrachten:
Scrum ist kein Selbstzweck
Wisst ihr überhaupt, warum und wofür das Ganze? Was bedeutet für euch Erfolg? Ist eure Organisation mehr mit den Kunden oder mit sich selbst beschäftigt (prozessgetrieben)? Sucht euch einen Teil eurer Organisation aus, in dem ihr mit agilen Vorgehensweisen anfangen wollen. Sucht euch einen Bereich, der übersichtlich ist, wo ihr grundlegende Rahmenbedingungen anbieten könnt – vor allem Ressourcen und die Unterstützung des Managements.
Leute befähigen
Um sich zu ändern, soll ein Mensch etwas Neues lernen. Ja, das Scrum-Rahmenwerk ist einfach, bedeutet aber trotzdem für viele Menschen eine große Veränderung. Zeigt eurer Mannschaft, dass ihr es ernst nehmt, schätzt diese Veränderung nicht gering und bietet jedem einzelnen Betroffenen (und damit AUCH dem involvierten Management!!) Trainings und Schulungen an.
Schutz und Rahmen schaffen
Lasst ein Team und einen ScrumMaster nie dabei allein, sich mit Scrum in der Organisation zurechtzufinden. Stellt Manager an ihre Seite, um die ersten Impediments aufzuräumen, den Rahmen klarzustellen und sie vor allem durch Kommunikation mit dem Rest des Unternehmens zu unterstützen. Informiert und involviert von Anfang an Personen in anderen Teams oder Abteilungen, die mit eurem Pilot-Team zu tun haben werden.
Zeit lassen
Sobald ihr klar gemacht habt, warum ihr euch für ein agiles Vorgehen entschieden habt (kürzere Releasezyklen, Kundenausrichtung, Time to Market, etc.): Lasst die Leute arbeiten! Lasst eure alten Berichtsformate links liegen und wagt euch an die neuen Artefakte wie Release Plan, Burndownchart oder Review Meeting.
Neue Wege, Änderung der Organisation und der Prozesse fordern
Jetzt kommen wir zurück zu unserem Blumenstrauß. Einmal gestartet, werden sowohl das Team als auch das Management identifizieren, welche Praktiken sie gerne versuchen würden bzw. werden sich basierend auf den priorisierten Problemen oder Herausforderungen ein paar agile Ansätze sofort als Lösungsansatz anbieten. So wie ein Team nicht über Nacht alle Best Practices anwenden kann und muss, wird auch die Organisation nicht alle Veränderungen durchführen können und müssen, um über Nacht agil zu sein. Der notwendige Lernprozess und Assessmentprozess kann nur inkrementell durchgeführt werden. Ein Schritt nach dem anderen. Das Motto: Versuchen und … lernen. Gemeinsam lernen, kontinuerlich lernen! Neu versuchen, anders versuchen, etc. Seid mutig und seid offen, neue Dinge zu probieren. Geht respektvoll miteinander um und setzt euch den gemeinsamen Anspruch, in kürzerer Zeit Qualität und Ergebnisse zu liefern und vor allem: euch aufeinander verlassen zu können.
Tja, dann fangen wir mal an, agil zu sein!

Communities of Practice

Scrum tritt an, um Menschen mit unterschiedlichem Wissen, unterschiedlichen Interessen und Erfahrungen zusammen zu bringen, damit sie gemeinsam an der gleichen Werkbank arbeiten. Dafür haben wir cross-funktionale Scrum-Teams. Klassische Rollenunterschiede, etwa die zwischen Tester und Entwickler, werden im Scrum-Team aufgeweicht. Jeder, auch der absolute Spezialist, hat den einen Auftrag, an der erfolgreichen Lieferung in seinem Team mitzuwirken (selbst wenn sein Spezialwissen gerade nicht gefragt ist). Das ist ein deutlicher Unterschied zum klassischen Projektmanamagent, wo unter der Maxime größtmöglicher Auslastung Spezialisten auf verschiedenen Projekten gleichzeitig unterwegs sind.
Um Menschen mit ähnlichem Wissen, Interessen und Erfahrungen zusammen zu bringen, gibt es in Scrum sogenannte Communities of Practice (CoP). Eine CoP ist zunächst eine Gruppe, die freiwillig zusammenkommt, und sich ein Thema zu eigen gemacht. So kann es beispielweise CoPs für Architektur, Testen, UX oder Scrum geben. Anders als Task Forces verfolgen CoPs nicht den Zweck, ein eng gestecktes Ziel zu erreichen. Ebensowenig haben sie die Erzeugung von Statusberichten zum Zweck. Sie sind vielmehr dazu da, Ideen zu generieren und dafür zu sorgen, dass – teamübergreifend – ein gemeinsames Bild entstehen kann. So kann sich zum Beispiel eine CoP zum Thema Testen damit beschäftigen, die Automatisierung von Testfällen in den Scrum-Teams zu platzieren und die Hindernisse auf dem Weg dorthin zu identifizieren. Mike Cohn schreibt, es sei Aufgabe von CoPs, einen gewissen Grad an Konsistenz über die Teams hinweg zu sichern.
Communities of Practice sind als zusätzliche Ebene in Scrum gedacht, jedes Mitglied einer Community of Practice ist in der Regel auch Mitglied eines Scrum-Teams. Wichtig ist, dass CoPs in keinem Konkurrenz- oder Hierarchieverhältnis zu den Scrum-Teams stehen. Das, was in einer CoP anvisiert wird, sollte von den Mitgliedern in ihre jeweiligen Scrum-Teams getragen und dort umgesetzt werden.
Damit heben wir die Dualität auf, die klassischerweise durch vor- oder nachgeschaltete Instanzen auftritt: Ein Team, dessen Mitglieder beispielsweise für die Qualitätssicherung verantwortlich sind, wird immer daran leiden, dass es seine Wirkungsstätte außerhalb der Scrum-Teams hat. Die Scrum-Teams werden dazu geneigt sein, das Thema Qualität an das QS-Team abgehen – und das QS-Team wird am Versuch verzweifeln, die Scrum-Teams zu mehr Qualitätsbewusstsein zu “erziehen”. Selbstorganisation sieht anders aus.
Etienne Wenger unterscheidet zwischen fünf Ausprägungen einer Community of Practice:

Welche CoPs gibt es in deinem Unternehmen? Wie stark sind sie ausgesprägt? Werden sie vom Rest des Unternehmens wahrgenommen? Falls nein: Was kannst du tun, um sie handlungsfähiger zu machen?
CoPs brauchen zwar keinen dedizierten ScrumMaster, aber eine regelmäßige, engagierte Unterstützung (etwa zur Formulierung der gemeinsamen Mission oder zur Moderation der Arbeitstreffen) kann entscheidend sein.
Literatur
http://www.mountaingoatsoftware.com/blog/cultivate-communities-of-practice
https://dl.dropboxusercontent.com/u/1018963/Articles/SpotifyScaling.PDF

Vom Suchen und Finden eines Projektplans

Anfangs sind Scrum-Implementationen recht übersichtlich. Dem Aufsetzen von Teams folgt eine intensive Lern- und Ausbildungsphase. Wenn alle Akteure ihre Rolle kennen und selbständig ausüben können, ist diese Phase zu Ende. Manche glauben dann, die agile Transformation sei nun ebenfalls abgeschlossen.
Das aber ist ein Irrtum. Denn Teams, die nach Scrum arbeiten, sind die eine Herausforderung. Die andere Herausforderung besteht im Umbau des gesamten Unternehmens hin zu einer Organisation, die erfolgreiche Produktentwicklung in den Mittelpunkt all ihrer Tätigkeiten stellt.
Und spätestens hier brauchen wir ihn: Den Projektplan für die Scrum-Implementierung. Ihn zu schreiben, ist keine leichte Sache. Auf unserem aktuellen Projekt glaubten wir schon, ihn zu haben. Für die kommenden sechs Monate hatten wir Woche für Woche die jeweils zu erreichenden Ziele eingetragen. Neulich habe ich ihn mir im Rückblick angeschaut und musste feststellen: Die zeitliche Schiene hat nichts gebracht außer der Illusion von Kontrolle. Das, was wir für Anfang Januar eingeplant hatten, ist tatsächlich im März aktuell geworden. Manches hat sich zwischenzeitlich als irrelevant erwiesen. Und vieles, das wir überhaupt nicht auf dem Schirm hatten, beherrscht jetzt unsere Arbeit.
Was war passiert? Wir hatten versucht, in die Kristallkugel zu blicken und dabei das festzumachen, was sich nicht festmachen lässt. Die Zukunft heißt nicht umsonst Zukunft – und jeder, der sie vorauszusagen können glaubt, übernimmt sich ein wenig.
Drei Monate später. Wir stehen vor folgender Situation: Die Scrum-Implementation nimmt vollen Lauf. Das Unternehmen hat beschlossen, die gesamte Entwicklung auf Scrum umzustellen. Das Fehlen eines Projektplans ist jetzt umso deutlicher. Unsere Kalender platzen vor Terminen, wir arbeiten sie nur noch ab. Und noch schlimmer: Keiner weiß so richtig, wo wir in der Implementation stehen. Die ersten fangen an zu glauben, wir seien jetzt mit Scrum fertig – und reagieren mit Unverständnis auf die Forderung des Managements nach weiteren Veränderungen.
In dieser Situation setzen wir uns nochmal hin – und schreiben alle Themen runter, die uns einfallen. Wir sortieren es – was ist Aufgabe des Transition Teams, was gehört zu den ScrumMastern und was zu den Product Ownern? Und wir versuchen es erneut auf eine zeitliche Achse zu bekommen. Wir wissen aus vergangener Erfahrung: Kalenderwochen sind eine zu kleine, zu detaillierte Einheit, um eine erste Orientierung zu bieten.
Also gehen wir gröber ran und ordnen die Themen vier Entwicklungsstufen zu:

Der Vorteil: Sind diese Stufen erstmal hinreichend klar charakterisiert, können wir einschätzen, wo die Scrum-Implementierung gerade steht und was noch alles vor uns liegt. Wir können auch sagen, welche Themen zwar wichtig, aber in der jetzigen Entwicklungsstufe noch nicht relevant sind. Noch deutlicher wird das Bild, wenn in einem weiteren Schritt für jedes Team (Transition Team, SM- und PO-Team) möglichst eindeutig beschrieben wird, woran wir erkennen können, auf welcher Stufe sich die Teams gerade befinden. Ein SM-Team, das von seinen vielen Impediments geradezu erschlagen wird, weil es nicht weiß, wohin es damit gehen soll, steht vermutlich auf der zweiten Stufe: Denn die Probleme sind sichtbar geworden, aber der Blick der ScrumMaster ist noch auf die Probleme, nicht auf die Lösungen gerichtet.

Woran merken wir, ob unser Projektplan funktioniert?


Wenn wir jeden Freitag in den Plan blicken können und daraus unsere Aufgaben für die kommende Woche entwicklen können. Wenn wir Kurs halten können, steuernd eingreifen können – und dann auch erkennen, welche Themen gerade gar nicht wichtig sind, und wo wir unbedingt noch nachhaken müssen. Wenn wir einem Product Owner den Plan zeigen können – und er ohne viel Nachdenken sagen kann, auf welcher Implementierungsstufe wir uns gerade befinden – und was wir als nächstes erreichen möchten.
Wie ist Eure Erfahrung bei größer angelegten Scrum-Implementationen? Woran habt ihr gemerkt, ob die Implementation noch auf Kurs ist? Und wie stellt ihr fest, was als nächstes kommt, was überhaupt noch zu tun ist, bevor die Implementation abgeschlossen ist? Ich bin gespannt auf Eure Erzählungen.

Scrum Logbuch-Eintrag: Wenn sich Scrum und Change die Hand reichen

Mein lieber Freund, die letzen zwei Wochen hatten es in sich! Zunächst eine sehr lange Reise vom sonnigen Graz ins regnerische Oldenburg, dann eine etwas kürzere Reise nach Baden-Baden, gefolgt von einer viel kürzeren Reise zurück nach Wien. Aber dann! Dann wieder eine gefühlte Weltreise ans Ziel: back to Graz.
Da sitze ich nun hier und mache eine kurze Retro über meine Erlebnisse als Coach, ScrumMaster und Kollegin. Ich sage dir, liebes Logbuch, ich habe viel gesehen und noch mehr erlebt.

Aber: heute werde ich „nur“ einen Eintrag über ein Thema schreiben, das mich in den letzen zwei Wochen wiederholt begleitet hat: Change!
Geschafft! Die Entscheidung ist getroffen: Scrum wird weiter und breiter eingeführt, erste Teams sind gebildet, Product Owner und Development Team wissen was zu tun ist, erste Sprints sind bereits im Laufen begriffen. Alles prima also! Zumindest fast.
Denn nun erfährt das Team, dass alles anders wird: alles wird transparenter (auch ihre eigene Tätigkeit), viele Veränderungen stehen an und noch das Wichtigste: die Entscheidungen liegen direkt bei ihnen. “Juhuuuu!”, würde sich manch einer denken. Aber falsch – ich wurde eines Besseren belehrt. Angst, Widerstände, Aggressionen und Konflikte begegneten mir auf dem Weg.
Veränderungsprozesse versetzen Menschen in Ausnahmezustand. Warum? Weil unsere menschliche Natur nun mal so ist: entwicklungsgeschichtlich und evolutionsbedingt reagieren Menschen auf Veränderungen erst einmal defensiv und abwehrend. Jede noch so geringe Veränderung verursacht „archaische“ Notfallprogramme in uns: Kampf, Erstarrung oder Flucht. Dies bedeutet, dass die Situation zunächst auf ihre Bedrohlichkeit überprüft wird. Für unsere Vorfahren (die in Höhlen lebten) hatte diese Überprüfung die höchste Priorität, da dadurch ihr eigenes Überleben gesichert werden konnte. War es damals der Säbelzahntiger, von dem sich unsere Vorfahren schützen mussten, sind es heute weniger die wilden Tiere als die Veränderungen im sozialen und beruflichen Umfeld, von denen wir uns zu schützen versuchen.
Globalisierung, permanente Veränderungen in Unternehmen und auf Märkten, erhöhter Stresslevel, Rollenambiguitäten, Druck o.ä. sind die wilden Tiere des 21. Jahrhunderts. Die Folge: emotionale Spannungszustände! Experten sind sich mittlerweile einig, dass es neben den organisationalen Veränderungsprozessen noch einen weiteren Prozess geben muss, der die Emotionen der am Change Prozess beteiligten Personen berücksichtigt und den Umgang mit ihnen trainiert.
Wie das?!
Nun ja, nach Streich (1997) durchlaufen wir, bewusst oder unbewusst, verschiedene Reaktionsphasen im Change Prozess.
Phase 1: Schock
Hier trifft die Erwartung auf die Realität, d. h. Scrum macht alles anders! Neeeein, nicht möglich! Angst breitet sich aus und man ist sich der eigenen persönlichen Kompetenz nicht mehr sicher. Dieser Schock muss zunächst emotional und kognitiv verarbeitet werden. In dieser Phase erfahren wir große Unsicherheit und Dauerblockade.
Phase 2: Verneinung/Abwehr/Widerstand
Die Folgen der Veränderung sind für Teams und Unternehmen nicht abschätzbar, nicht greifbar. Die Kontrolle entzieht sich jedem Beteiligten, was noch mehr Angst, Widerstand und Reaktionen zum Selbstschutz auslöst. Dieser Prozess wird auch „Trauer- und Ablöseprozess“ genannt.
Phase 3: Einsicht/Neugier
Wir Menschen sind „Gewohnheitstiere“, d. h. nach einer bestimmten Zeit gewöhnen wir uns an Veränderungen und erkennen den SINN dahinter. Alte Gewohnheiten weichen plötzlich den Neuen.
Phase 4: Akzeptanz
Wenn der SINN verstanden und die Notwendigkeit der Veränderung erkannt wurde, lassen wir alte Verhaltens- und Verfahrensmuster los und akzeptieren den neuen Zustand.
Phase 5: Ausprobieren
Erste konkrete Maßnahmen werden ausprobiert, Fehler und Erfolge reihen sich aneinander. Hier sind wir nun mitten im Scrum angelangt. Denn Scrum ist der „Weg des Versuchens, des Scheiterns, des Wiederaufstehens und des Erfolgreichseins“, schreibt Boris Gloger in seinem Buch über Scrum. Und Recht hat er – so recht!
Phase 6: Erkenntnis
Aus Erfolgen und Misserfolgen wird gelernt. Je mehr positive Erfahrungen gemacht werden, desto größer ist das Verständnis gegenüber Veränderungen. Hier erreicht das Sprichwort „Nichts ist in Stein gemeißelt“ eine neue Dimension: Lass dich vom Scrum-Regelwerk inspirieren, kreiere aber mittels gesundem Menschenverstand deinen eigenen Arbeitsprozess.
Phase 7: Integration/Akzeptanz
Scrum ist akzeptiert, eingeführt, wird gelebt und ist somit im Handlungsrepertoire integriert.
Zu bedenken ist aber, dass es nicht nur Change-Verweigerer gibt, sondern auch Menschen, die der Veränderung sehr positiv gegenüberstehen. Emotionale Spannungszustände haben u. a. auch etwas mit Stressreaktionen im Körper zu tun. Da es aber nicht nur den negativen Stress, Disstress, sondern auch den positiven Stress, Eu-Stress, gibt, der uns zu Höchstleistungen antreibt, erleben diese Menschen andere körperliche Reaktionen auf der kognitiven, emotionalen und vegetativ-hormonellen Ebene als diejenigen, die eher in die Disstress-Zone geraten. Somit kann ein Change Prozess auch sehr anregend und motivierend sein!
So, jetzt wissen wir es!
Und ich habe es auch erfahren. In Teams und Unternehmen, mit denen ich in den letzten zwei Wochen zu tun hatte; bei Product Ownern, Managern und Kollegen, denen ich auf meinem Weg begegnete. Und stell dir vor: Jeder von ihnen hat sich dabei in einer anderen Phase befunden.
Die Erkenntnis ist heftig, nicht wahr!!?
Eine gute Nachricht gibt es dabei: Wenn wir nun um die Phasen und unsere Überlebensreaktionen wissen und verstehen, was der Mix daraus in uns anstellt, dann sind wir auf dem besten Weg, die Menschen im Change Prozess (so wie Scrum einer ist) konstruktiv, effektiv und effizient zu begleiten.
P.s.
Liebes Logbuch und alle, die es lesen werden: Glaubt mir, die Erkenntnis war wirklich heftig, aber auch sehr hilfreich im Umgang mit meinem eigenen Change Prozess – als ScrumMaster, als „nicht-disziplinarische Führung“ sowie bei der Erkenntnis, warum wir einen zweiten Prozess brauchen: den der emotionalen Steuerung.

Cäsars Entscheidung oder wie aus Wünschen erfolgreiche Handlungen werden

Nur wer sich selbst gut managen kann, kann auch andere gut managen. Folgt man diesem Satz, ist es nachvollziehbar, dass das Thema Selbstmanagement Hochkonjunktur hat, vor allem im Kontext von Führung. Ein spannendes Element im Selbstmanagement ist die Frage, wie man von seinen Bedürfnissen und Wünschen ins Handeln kommt.
Jeder kennt die Situation, dass er etwas verändern möchte, dass er ziemlich genau weiß, wie es nicht sein sollte, eine vage Vorstellung davon hat, wo er hin möchte, wie er handeln müsste. Aber an der Umsetzung hapert es immer wieder. Man fühlt sich blockiert, ja sogar hilflos, bei manchen Themen über eine lange Zeit. Diese Situation kannte auch der große Cäsar, als er mit seinen Truppen am Rubikon, einem Fluss nördlich von Florenz stand und überlegte, ob er den römischen Senat in Rom angreifen und ihm damit den Krieg erklären sollte oder nicht. Sicher machte es sich Caesar nicht leicht mit seiner Entscheidung. Letztlich aber kam er ins Handeln, machte sich nach Rom auf und überschritt mit den berühmten Worten “alea iacta est”, “Der Würfel ist gefallen”, mit seinen Legionen den Rubikon in Richtung Süden. Dieser Ausspruch steht heute noch für Entscheidungen, die ein ganz bewusstes und konsequentes Handeln nach sich ziehen.
Das Rubikonmodell nach Grawe (Grawe, 1998, S. 71) gilt heute als wichtiges und funktionales Selbstmanagementmodell, das die Entstehung einer inneren Struktur von den Bedürfnissen bis hin zum konkreten Handeln aufzeigt und helfen kann, schwierige Entscheidungssituationen handlungsreif zu machen.

 










Bedürfnis: Unbewusste, vorbewusste Impulse
Motiv: Erfassen, bewusst werden, erkennen, wünschen, wägen
Intention: Bewusstes Wollen, Handlungsziel entwickeln, gezielte Entscheidung treffen
Präaktionale Vorbereitung: Planen, Ressourcen und Möglichkeiten eruieren
Handeln: Umsetzen, üben, sichern durch Wiederholen bis die Handlung stabilisiert ist
In der ersten Phase spürt man als Führungskraft oft ein meist noch unklares Bedürfnis im Hinblick auf eine Veränderung, zum Beispiel mit einem „schwierigen“ Mitarbeiter zu reden oder für die Meetings mehr Disziplin im Team zu fordern. Oft ist das Bedürfnis in dieser Phase noch nicht ganz klar oder auch noch nicht richtig bewusst.
Erst mit der Zeit bildet sich in der zweiten Phase daraus ein konkretes Motiv, z.B. ich will mehr Führung zeigen, eine nicht akzeptable Situation in Ordnung bringen. Oft weiß man aber in dieser Phase noch nicht, was genau man tun möchte. Außerdem gibt es immer mehrere Motive, die sich manchmal gegenseitig auszuschließen scheinen. Da stehen z.B. Motive wie Harmonie, die Mitarbeiter nicht zu demotivieren, Konflikten aus dem Weg zu gehen, im inneren Spannungsfeld. In dieser zweiten Phase sind die Menschen sehr mit dem Abwägen aller Motive beschäftigt. Mit Kopf und Bauch versucht man eine Entscheidung herbeizuführen. Manchmal dauert das Abwägen lange, aber irgendwann sind die Prioritäten dann klarer und es entsteht idealerweise ein Gefühl und eine Bewusstheit der Entschlossenheit: Ich tue jetzt etwas für mich und meine Führungsrolle und auch für die Verbesserung von Disziplin im Team und damit für eine bessere Teamleistung.
Dies ist der eigentliche Schritt über den Rubikon. Nach diesem Schritt liegt in der Phase drei das, was der Mensch gern tun möchte, in einem neuen Reifestadium vor, als Intention. Es wird nun ein konkretes Handlungsziel definiert. Jetzt wird nicht mehr abgewogen, sondern es wird nach einer Lösung und nach Maßnahmen gesucht: Wie, wann und wo kann ich mit dem Mitarbeiter Klartext reden? Wie bringe ich das Disziplinthema in mein Team ein?

In der vierten Phase geht es dann um „präaktionale Vorbereitung“ und die Entwicklung von konkreten Ausführungsmöglichkeiten: Ich werde einen Gesprächstermin mit dem Mitarbeiter in meinem Büro vorgeben und von Anfang an die Gesprächsregeln festlegen. Ich werde deutlich sagen, dass ich hier nicht als Kollege, sondern als Führungskraft rede. Ich achte bewusst darauf, dass ich die Steuerung des Gesprächs in meinen Händen behalte. Ich atme vor dem Gespräch tief durch und mache mir bewusst, dass es in Ordnung ist, das Gespräch so zu führen. Ich werde das Thema Disziplin ganz oben auf die Prioritätenliste des nächsten Meetings setzen. Ich werde die Zeit nehmen, die es braucht, damit alle sich äußern können und verstehen, worum es mir geht. Ich behalte die Moderation in meiner Hand und achte auf Regeln und Zeitmanagement. Ich werde konkrete Commitments am Flip Chart visualisieren.
Nun geht es an die gut vorbereitete, bewusste und gezielte Umsetzung, sprich konkrete Handlung, des Selbstmanagementvorhabens im Umgang mit dem Mitarbeiter oder dem Team. Je grundlegender ein Thema für das persönliche Selbstmanagement ist, z.B. eben mit schwierigen Personen oder Führungsautoritäten ist (siehe Beispiele), um so öfter ergeben sich Möglichkeiten, die gezeigten Handlungen auf andere Situationen zu übertragen und den Rubikon immer leichter zu überschreiten. Übung macht auch hier den Meister.
Der Rubikonprozess als Selbstmanagementtool unterstützt den bewussten Umgang mit sich selbst und den Situationen und Herausforderungen die oft scheinbar schwer zu bewältigen sind. Es ist immer auch gerade dann hilfreich, wenn es um Themen wie Unsicherheit, Souveränität, Auftreten, Durchsetzungsvermögen, Setzen von Prioritäten, Grenzen setzen, Verändern persönlicher hinderlicher Muster wie „Ich muss immer perfekt sein“ etc. geht. Im Sinne von Selbstcoaching ist die Reflektion des Rubikonmodells eine Chance, die persönliche Weiterentwicklung anzugehen. Caesar hats ja auch genutzt.
Grawe K. (1998) Psychologische Psychotherapie, Hogrefe: Göttingen

The Pros and Cons of Electronic and/or Physical Taskboards

Interview with the bor!sgloger expert panel on the subject of internationally distributed Teams (Part 4)

Part 1: Does distance cancel out efficiency of internationally dispersed Teams?

Part 2: Should internationally distributed Teams be avoided?
Part 3: Scrum Spaces of internationally distributed Teams – the Do’s and Don’ts
Stephanie G.: You‘ve coincidentally already mentioned it in the previous round – the popular subject of whether electronic or physical Taskboards are better. Did you all use electronic tools or is there another probable option for internationally distributed Teams?!
Deborah W.: We used an electronic tool for the Product Backlog, but had a paper Taskboard hung up on the wall at the main location, which was filmed non-stop by a webcam. Thus, it was continuously displayed on a live-stream and gave the other Team members the possibility to keep the window open in the background of their computer screens at all times. Sadly, we never managed to put up a large screen on the wall. But by doing it this way, it meant that if one person moved a Task, it could be seen by everyone. In order for this to work, however, you need an excellent camera in a good position (best if screwed into the ceiling). In my case, it also only worked because the management really insisted on it – the Dev.Team had wished for  a digital Taskboard from the first Sprint onwards. However, the management had seen this as a measure for pushing its employees towards more communication.
Hélène V.: What works even better in terms of pushing employees to communicate, is to have a physical Taskboard at every location. Every task has an identification number, so that during the Daily (and outside of it, of course, too) the conversation goes a little bit like this, “Today, I am taking Task 162 on user documentation and I will need Peter’s assistance for it, as I’m not entirely sure about the necessary layout”. The number is just the reference, so that everyone at every location can synchronously move the identical Task. This way, whenever a Task is finished during the day and a new one is started, the necessary synchronisation forces the Team members to communicate immediately – in whichever way they like (chat, telephone etc.).
Ina K.: See, that‘s what I tried to introduce in my Team as well. However, it was certainly not easy trying to explain the necessity behind synchronising two manual Taskboards. In the end, we simply used the tool iceScrum and had the Taskboard depicted at all times on a large screen in both Scrum Spaces. Although the effect of pulling the Task to “done“ goes missing, it was pretty cool watching how – if someone at the other location moved a Task – it would show up simultaneously on our screen.
Stephanie G.: Your answers sound like distributed Teams still underestimate the effect of physically experiencing versus watching something move on a screen. I have heard of Teams using both types at the same time – has one of you ever worked with “double” Taskboards?
Bernd K.: Yes, I‘ve seen Teams that use physical Taskboards, and JIRA for documentation. Thus, they use both…In my opinion, one can certainly do that, but you should watch out that it doesn’t start creating an overhead. Like Ina, I also have some experience with iceScrum, which is an alright open-source tool. My Team members weren‘t keen on it, but decided to use it anyway, as they needed it for generating documentation.  In my opinion, electronic tools may be useful for Backlog grooming, generating Burn-Down Charts, providing immediate Sprint Documentation etc., but they will never fully replace the agility and motivation that a physical Taskboard can offer.
Kristina K.: I actually found the electronic Taskboard to be a nuisance. We used Urban Turtle, since the Dev.Team saw a Taskboard made out of paper as too much overhead for a distributed Team. It really was of no help during the Daily: it took long to create new Tasks, the wrong Stories were accidentally discussed, it took ages to scroll down etc. Also, the tool did not place a maximum limit on the amount of characters that could be typed within a Task. I sometimes felt as if the simplicity of Tasks was ruined and turned into electronic essays or lists of reminders. The size of a sticky note limits exactly that. Honestly, if I could build my own electronic Taskboard, I would have a very long list of requirements, such as being able to see the whole board at once, allowing the writing of dots on Tasks that were not finished on the previous day (exclamation marks just don’t do it for anyone), better print views, simplicity of moving Stories into a Sprint, being able to read the titles of User Stories immediately etc.
Christof B.: I agree with my colleagues, but in the end, I believe that it doesn’t really matter what tool you‘re using, as long as everyone in the Dev.Team can work with it at the same time. This means that i.e. physical Taskboards should really have cameras set on them at all times and electronic tools should allow all Team members to see the moving of a Task at all locations at the same time. In future, this should work much more easily, as high-quality video conference systems will become more readily available on the market. However, I also believe that the Team constellation should have an impact on the choice of tooling: if the Product Owner and maybe some consulting architects are placed at one location, and the ScrumMaster plus his Dev.Team at another, I would most certainly say that a Taskboard made out of paper suffices. A picture of the Daily can then be sent to the PO every now and again.
Stephanie G.: I believe I can sum up and prioritize your suggestions in the following way:
#1 choice: Separate Taskboards made out of paper and sticky notes hung up on the wall at each location.
#2 choice: Paper Taskboard at main location with constant live-stream to screens hung up in other locations.
#3 choice: Electronic Taskboard with instant synchronisation (no tool preference).

Was würden Yoda, Dschingis Khan und Goethe zu Agile sagen?

Wie agile ist unsere Vergangenheit, wie agile die Sci-Fi-Zukunft? Wie agile waren und sind Jedi-Ritter, waren mongolische Kriegsherren, große Denker, Poeten und Genies? Ich habe mich auf die Suche gemacht und folgende Zitate von großen Persönlichkeiten der Geschichte zusammengefasst. In dem einen oder anderen Zitat fand ich durchaus einen agilen Ansatz. Ob empirischer Prozess à la “doing as a way of thinking”, Umgang mit Fehlern, der Weg der kleinen Schritte, inspect & adapt oder Innovation – in jedem Zitat steckt ein kleines oder großes Stück Agile.
Viel Spaß mit meinem Agile-ABC:

  1. Glaube nicht, dass ein Ort zu weit entfernt ist – gehe nur los und du wirst ankommen; denke nicht, es sei zu schwer – tu es einfach! (Dschingis Kahn)
  2. Es ist ein großer Vorteil im Leben, die Fehler, aus denen man lernen kann, möglichst früh zu begehen. (Winston Churchill)
  3. Man löst keine Probleme, indem man sie auf Eis legt. (Winston Churchill)
  4. Denken ist interessanter als Wissen, aber nicht als Anschaun. (Johann Wolfgang von Goethe)
  5. Kleine Taten, die man ausführt, sind besser als große, die man plant. (George Catlett Marshall jun.)
  6. Einen Fehler machen und sich nicht bessern: Das erst heißt fehlen. (Konfuzius)
  7. Man muss Unmögliches verlangen, um das Mögliche zu erreichen. (Otto von Bismarck)
  8. Der Weg zum Ziel beginnt an dem Tag, an dem Sie die hundertprozentige Verantwortung für Ihr Tun übernehmen. (Dante Alighieri)
  9. Zwischen einem der führt und einem der folgt, unterscheidet Innovation. (Steve Jobs)
  10. Denken und Tun, Tun und Denken, das ist die Summe aller Weisheit, von jeher anerkannt, von jeher geübt, nicht eingesehen von einem jeden. (Johann Wolfgang von Goethe)
  11. Eine Veränderung bewirkt stets eine weitere Veränderung. (Niccolo Machiavelli)
  12. Wer darauf besteht, alle Faktoren zu überblicken, bevor er sich entscheidet, wird sich nie entscheiden. (Henri-Frédéric Amiel)
  13. Alles auf einmal tun wollen zerstört alles auf einmal. (Georg Christoph Lichtenberg)
  14. Wirklich innovativ ist man nur dann, wenn einmal etwas danebengegangen ist. (Woody Allen)
  15. Denken ist wundervoll, aber noch wundervoller ist das Erlebnis. (Oscar Wilde)
  16. Pläne sind nichts. Planung ist alles. (Dwight D. Eisenhower)
  17. Der größte Feind der Qualität ist die Eile. (Henry Ford)
  18. Lieber Fehler riskieren, als Initiative verhindern. (Reinhard Mohn)
  19. Die Ablehnung eines Risikos ist für ein Unternehmen das größte Risiko. (Reinhard Mohn)
  20. Du gewinnst nie allein. An dem Tag, an dem du was anderes glaubst, fängst du an zu verlieren. (Mika Pauli Häkkinen)
  21. Wer nichts verändern will, wird auch das verlieren, was er bewahren möchte. (Gustav Heinemann)
  22. Wir hatten eine sehr einfache Ausrüstung und sehr primitive Klettertechniken. Das Einzige, was wir wirklich gut konnten, war, eine Stufe nach der anderen in Schnee und Eis zu schneiden. In aller Bescheidenheit kann ich sagen, dass wir darin Weltmeister waren, einfach immer die nächste kleine Stufe zu schneiden, die uns erlaubte, den nächsten kleinen Schritt Richtung Ziel zu machen.” (Sir Edmond Hillary)
  23. Wege entstehen dadurch, dass man sie geht. (Franz Kafka)
  24. Gib mir 6 Stunden einen Baum zu fällen, und ich werde die ersten 4 mit dem Schärfen der Axt verbringen. (Abraham Lincoln)
  25. Unmöglich vorher zu sehen, die Zukunft ist. (Yoda)
  26. Zwei Dinge sind zu unserer Arbeit nötig: Unermüdliche Ausdauer und die Bereitschaft, etwas, in das man viel Zeit und Arbeit gesteckt hat, wieder wegzuwerfen. (Albert Einstein)

by Gareth Simpson

Mein Lieblingszitat hier ist die Nummer 22 von Sir Edmund Hillary. Immer in kleinen Schritten unterwegs und durch das Beschreiten des Wegs ans Ziel kommen. Volle Konzentration im Hier und Jetzt, volle Hingabe, Commitment, ein Einsatz mit Beharrlichkeit, Disziplin und Selbstverantwortung oder auch wie Beppo der Straßenkehrer in Michael Endes “Momo” sagt:
“Siehst du, Momo”, sagte er dann zum Beispiel, “es ist so: Manchmal hat man eine sehr lange Straße vor sich. Man denkt, die ist so schrecklich lang; das kann man niemals schaffen, denkt man.” Er blickte eine Weile schweigend vor sich hin, dann fuhr er fort: “Und dann fängt man an, sich zu beeilen. Und man eilt sich immer mehr. Jedes Mal, wenn man aufblickt, sieht man, dass es gar nicht weniger wird, was noch vor einem liegt. Und man strengt sich noch mehr an, man kriegt es mit der Angst, und zum Schluss ist man ganz außer Puste und kann nicht mehr. Und die Straße liegt immer noch vor einem. So darf man es nicht machen.” Er dachte einige Zeit nach. Dann sprach er weiter: “Man darf nie an die ganze Straße auf einmal denken, verstehst du? Man muss nur an den nächsten Schritt denken, an den nächsten Atemzug, an den nächsten Besenstrich. Und immer wieder nur an den nächsten.” Wieder hielt er inne und überlegte, ehe er hinzufügte: “Dann macht es Freude; das ist wichtig, dann macht man seine Sache gut. Und so soll es sein.” Und abermals nach einer langen Pause fuhr er fort: “Auf einmal merkt man, dass man Schritt für Schritt die ganze Straße gemacht hat. Man hat gar nicht gemerkt wie, und man ist nicht außer Puste.” Er nickte vor sich hin und sagte abschließend: Das ist wichtig.
Welches ist euer Lieblingszitat in Bezug auf Agile und Co? Lasst es mich wissen, ich freu mich drauf!

Definition of Socks

Sonntagnachmittag bei uns zu Hause. Ein Haufen gewaschener Wäsche türmt sich auf dem Sofa. Jetzt nehmen wir uns die Socken vor. Mein Sohn weiß aus seinen eigenen Beobachtungen, wie das geht.
Er nimmt sich scheinbar willkürlich zwei Socken heraus, legt sie vergleichend übereinander, zerrt und zupft an ihnen, sagt dabei “rollen, rollen, rollen”, und wirft sie dann in die Wäschebox zurück.
Damit ist für ihn der Prozess abgeschlossen, und er sieht hochzufrieden aus.
 
Ich bin da mit meiner Definition of Done schon etwas weiter. Anders als bei meinem Sohn, ist bei mir in etwa 90% der Fälle der Vergleichstest erfolgreich: Ich erwische das richtige Paar Socken. Zugegeben: Meistens bleiben danach Einzelgänger übrig, aber da steckt der Wurm an anderer Stelle im Prozess. Nicht mein Problem. Außerdem schaffe ich es, die Sockenpaare so zusammenzurollen, dass sie miteinander verbunden bleiben. Letzer Arbeitschritt, bevor ich fertig bin: Der Transport der Sockenpaare in die Schublade des Kleiderschranks.
 
An einer Definition of Done können wir ablesen, wie viele nachgelagerte Schritte zwischen dem Produkt (Reinigungszyklus Socken) und seiner qualitativ einwandfreien Nutzung (dem Tragen) stehen.
Auf dem untersten (weil anfänglichen) Level steht die Sammlung, gefolgt vom Waschgang. Dann kommen das Aufhängen, das Trocknen, das Sortieren, und schließlich das Einräumen. Auf jedem dieser Level lassen sich unterschiedlich hohe Qualitätsansprüche festlegen. Wichtig ist für mich, dass die Socken sauber sind und einen angenehmen, unaufdringlichen Duft verbreiten, dass sie richtig trocken werden, und dass ich sie morgens mit minimalstem Aufwand und ohne böse Überraschungen wieder verwenden kann. Außerdem sollen sie möglichst geschmeidig sein.
 
Ginge es nach dem Qualitätsanspruch meines Sohnes, müsste ich jeden Morgen die passenden Sockenpaare selber ausfindig machen. Dieser Arbeitsschritt bleibt mir nach meiner Definition of Done erspart, denn ich habe das Level der Bündelung schon erreicht.
 
Ist damit das Ende der qualitativen Fahnenstange erreicht? Sicher nicht. Ich bin farbenblind und stehe morgens meist im Dunkeln auf. Da kann es durchaus passieren, dass die Sockenfarbe nicht zu der des Anzuges passt. Oder dass ich im Laufe des Tages ein Loch in der Socke entdecke. Beides ist unangenehm und vermeidbar. Ich könnte meine Definition of Done anheben und festlegen, dass die Sockenpaare, nach Farben gebündelt, in unterschiedlichen Schubladen landen. Ich könnte einen Qualitätstest verlangen, so dass vor der Bündelung meine Socken auf noch so kleine Perforationen untersucht werden.
Beides ist sicher machbar, aber nicht unbedingt sinnvoll. Ich bräuchte dann vielleicht einen größeren Kleiderschrank mit mehr Schubladen. Und für den Qualitätstest gingen dann vom Sonntag Nachmittag nicht dreißig, sondern sechzig Minuten drauf. Das will ich nicht, denn so wichtig ist mir der Reinigungszyklus meiner Socken dann auch wieder nicht.
 
Vielleicht lohnt es sich für mich, über Automatisierung nachzudenken. In vielen Ländern waschen die Menschen ihre Kleidung immer noch am Fluss, das ist mir erspart geblieben. Unsere Waschmaschine erledigt das fast von selber. Aber warum muss ich immer in den Keller runter, die Wäsche an die Leine hängen, um dann zwei Tage später wieder den umgekehrten Weg zu gehen? Da gehen insgesamt bestimmt 40 Minuten drauf und meinen Sohn kann ich nicht alleine oben lassen. Ich erkenne: Da habe ich technische Schulden akkumuliert. Einen eigenen Wäschetrockner kann ich mir nicht leisten (kein Platz), aber so ein kombinierter Wäsche-/Trockenautomat wäre schon toll. Das aber wäre keine kleine Investition, das Geld würde an anderer Stelle fehlen.
 
Also muss ich schnell entscheiden: Wäschereinigungszyklus verbessern? Pro: Mehr Zeit am Sonntag mit der Familie. Contra: So teuer, dass wir uns in den Urlaub in den Alpen nicht leisten könnten. Wie kann ich mich da entscheiden, ob ich unsere begrenzten Ressourcen dafür investieren soll?
Na klar! Ich muss priorisieren! Aber nach welchen Kriterien? Durch den Kauf des kombinierten Trockenautomaten verzichte ich auf den Urlaub und spare statt dessen manuellen Aufwand beim Waschen. In Scrum gesprochen: Meine Velocity sinkt (ich bekomme weniger Funktionalitäten in die Hand), dafür steigt die Qualität eines bestehenden Prozesses.

Welche Investition ist die bessere?

Ich nehme zur Berechnung mein kostbarstes Kriterium: Zeit. Wenn ich durch den kombinierten Trockenautomaten 15 Minuten pro Wochenende spare, dann macht das knappe 14 Stunden Zeiteinsparung pro Jahr aus. Verglichen mit fünf Tagen in den Alpen ist das lächerlich.
Es fällt mir diesmal leicht, eine Entscheidung zu treffen. Wenn ich aber morgen das teure Markenwaschmittel kaufe, wird mich wieder das schlechte Gewissen befallen. Sollte ich statt dessen nicht besser für eine neue Waschmaschine sparen, ehe die alte eines Tages für immer den Geist aufgibt und mich mit meiner schmutzigen Wäsche alleine lässt?
 
Meine Vision ist mir heute jedenfalls klar geworden: Einen Haushalt zu haben, den ich auf Knopfdruck bedienen kann, um mich danach entspannt zurückzulehnen und die schönen Dingen dieses Lebens zu tun. Vielleicht wurde auf der CEBIT ja was Spannendes präsentiert. Die müssen sich ja mitterweile schon Gedanken zum modernen Haushalt gemacht haben. Vielleicht hat das Web 3.0 Textilien sogar schon abgeschafft und mein Problem damit erledigt. Aber das ist ein anderes Thema.

Wie schreibe ich eine User Story oder anders gefragt: Was nützt mir der Nebel?

Der Weg zur User Story fällt vielen erstmal schwer und zwar an der Stelle, an der man es eigentlich nicht erwarten sollte: Beim Formulieren des Nutzens. Wir sind so darauf getrimmt Funktionen zu beschreiben, dass uns der Nutzen implizit bewusst ist, jedoch anfangs nicht zu greifen erscheint. Einen Nutzen zu beschreiben und ihn in Worte zu fassen fällt schwer, es ist wie das Greifen nach einem Nebelfaden, der kurz vor der Berührung zerstäubt.
Im Nebel, so fühlen sich viele Teams, wenn sie Anforderungen ohne Nutzen übergeben bekommen. Sie müssen anfangen die Schemen, die geschrieben stehen, zu interpretieren. Den Nutzen in den Sätzen, Zusammenhängen zu finden, die Schwaden zu durchtrennen und zu entwirren. Gelingt es, dann haben wir bestenfalls eine Funktion mit einer Interpretation des Nutzens und wir können hoffen, dass die Beteiligten miteinander reden, um zu validieren, ob die Funktion auch den gewünschten Nutzen erfüllt.

“Gib mir einen Nutzen und ich gebe dir die Funktion dazu, die Du dir wünscht.”

Das ist mein persönlicher Leitspruch und auch meine Empfehlung, wenn es darum geht, User Stories zu schreiben. Fangt mit den Fragen “Wer” und “Wozu” an und schreibt diese auf. Startet beispielsweise so:
Als Stammkunde Ralf Müller möchte ich …, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.
Wenn ihr eine gute Idee habt, dann schreibt noch die Frage nach dem “Was” dazu, also die Funktion:
Als Stammkunde Ralf Müller möchte ich eine Benachrichtigung, damit ich erkenne, ob meine Bestellung erfolgreich im System eingegangen ist.
Am besten ist es, wenn ihr das “Was” gemeinsam mit eurem Entwicklungsteam klärt. Verstehen sie den Nutzen, dann werden Sie eine Funktion finden, die den Nutzen erfüllt. Spätestens im Sprint Planning 1 sollten die Anforderungen dann geklärt werden. Vielleicht schlägt das Entwicklungsteam neben der E-Mail Benachrichtigung und der direkten Anzeige auf der Folgeseite noch das Versenden einer Benachrichtigung per Blumenstrauß vor – wer weiß.
Um der angesprochenen Funktion etwas mehr Gestalt zu geben, formuliert ihr noch Akzeptanzkritierien. Dadurch könnt ihr den Rahmen aufspannen und vorgeben, was minimal erfüllt werden muss – nicht mehr, aber auch nicht weniger. Auch diese Kriterien klärt ihr gemeinsam mit dem Entwicklungsteam und zwar im Dialog und zwar von Angesicht zu Angesicht. Vom Entwicklungsteam lasst ihr dann Akzeptanztests bzgl. der  Akzeptanzkritierien aufstellen. Ein Kriterium könnte in unserem Beispiel sein:
Die Bestätigung erfolgt auf zwei Kommunikationskanälen. Ein Kommunikationskanal ist im System, der andere der Postweg.

Warum sollte das Entwicklungsteam die Funktion ausformulieren?

Das ist für mich implizit eine Frage nach der Reife des Teams. Jedes Entwicklungsteam lernt am eigenen Produkt die Fachdomäne, in der es sich bewegt und wird über die Zeit zum Domänenspezialisten. Das ist jedoch nur ein Grund, ein wichtigerer ist der folgende: Jedes Team weiß am besten, wie sich der gewünschte Nutzen im System am besten abbilden lässt. Ein cross-funktionales Team zeigt hier seine Stärken, jedoch kennt jedes andere Entwicklungsteam es auch besser als der Kunde bzw. die meisten User. Man fragt sie nur zu selten.
Ein Grund hierfür ist sicherlich, dass die User sich nicht die Fragen stellen müssen, die ein Teammitglied sich stellt, zum Beispiel: “Wie passt die Funktion in das Konzept der Anwendung?”, “Muss ich hier auch die Funktionen A, B und C berücksichtigen?” Ein Entwicklungsteam hat einen ganz anderen Kontext zum Produkt, das es entwickelt. Dieser muss aufgebaut werden.

Was benötigt eine gute User Story jetzt noch?

Wir haben das normale Format mit Wer, Was, Wozu – also: Als <Persona> möchte ich <Funktion>, damit ich <Nutzen>. Wir haben Akzeptanzkritierien , die aufzeigen, was minimal geliefert werden muss. Akzeptanztests, die das Entwicklungsteam ausformuliert und die aufzeigen, dass die Akzeptanzkritierien erfüllt werden. Was fehlt?
Es ist der Nebel.
In unserem Beispiel ist der Nebel zuerst der leere Funktionsteil. Hier muss Kommunikation erfolgen, damit geklärt wird was selbst der Platzhalter Benachrichtigung später konkret heißen soll. Konkret gesagt ist der Nebel keine Worthülse, die beliebig interpretiert werden darf, trotzdem ist der Nebel die Unklarheit auf dem Weg zur Implementierung.
Eine User Story ist ein Anlass zur Konversation. Das bedeutet, wir benötigen eine gewisse Unstabilität in der User Story, damit eine Konversation, ein Dialog entstehen kann. Wir brauchen Unschärfe. Hier brauchen wir allerdings die Art von Nebel, die nicht verschleiert. Nicht der Nebel, der durch schöne Worte und vermeintliche Vollständigkeit und die stumpfe Präzision eines Löffels uns denken lässt: “Alles steht hier geschrieben, genau das brauchen wir so wie es formuliert wurde.” Nein, wir brauchen den Nebel, der uns fragen lässt: “Hey, sollen wir lieber links oder rechts gehen, ich bin mir gerade nicht ganz sicher.” Software-Entwicklung ist zu großen Teilen ein Kommunikationsproblem und zu genaue Anweisungen verstärken dieses Problem. Bei zu genauen Anweisungen fragen wir nicht mehr nach, die Kommunikation versiegt.
Für viele von Euch ist die Fahrt, der Spaziergang im Nebel erstmals ungewohnt, lasst ihn trotzdem zu und lasst Euch drauf ein. Es ist faszinierend, was nach kurzer Zeit vor einem auftaucht und welche Überraschungen und Details einem ins Auge fallen, die man aus der Ferne, selbst mit Weitblick, nicht hätte erkennen können.

Kopfstandkino Risiko

Agile, Scrum und Risiken. Drei Dinge für mich, die zusammengehören. Hohes Risiko, hoher Gewinn, aber eben auch hohes Risiko. Wir vermeiden gerne Risiken, weil uns der Zugang fehlt. Wir arbeiten lieber darum herum, statt zu scheitern. Wenn ich Risiken angehen möchte, dann brauche ich zumindest einen Zugang, der mir einen kontrollierten Rahmen bietet. Einen Zugang, der mir hilft Entscheidungen zu treffen und mich unterstützt, kleine Fehler zu machen, statt einen großen.
Was macht agil nun anders? Agil stellt Risiken auf den Kopf – im wahrsten Sinne des Wortes. Jedes Risiko lässt sich als Chance formulieren, viele Risiken können als Eintrag im Product Backlog landen. Als Features, deren Nutzen es zu testen gilt, als minimal lieferfähiges Produkt (minimum viable product) über das sich der Mark testen lässt. Statt Risiken zu verwalten, tritt man dem Risiko entgegen, bereitet sich auf eine epische Schlacht mit ihm vor und begrüßt die Erkenntnisse, die auf dem Weg warten. Auf dem Weg heißt: nach dem Start.

Software-Anforderungen erfassen und weitergeben ist ein Kommunikationsproblem

Scrum ist ein Kommunikationsrahmen. Ein Rahmen, in dem mehr und mehr Beteiligte angehalten werden, miteinander zu sprechen und wertschätzend zu kommunizieren. Ein Rahmen, in dem ritualisiert alle relevanten Beteiligten eingebunden werden, damit ein gemeinsames Bild entstehen kann. Wir klären gemeinsam die Anforderungen. Angefangen im Sprint Planning 1: Hier holen wir uns die Personen hinzu, die uns genau sagen können, was gewünscht ist. Im Daily Scrum halten wir Kontakt mit ihnen und optimalerweise nutzen wir die Zeit nach dem Daily Scrum, um Rückfragen zu klären. Spätestens im Review zeigen wir, was umgesetzt wurde. An diesem Punkt kommt die Erkenntnis ins Spiel und wir können den Nutzen validieren. Wichtig ist jedenfalls: “Die Personen, die eine Software wollen, müssen mit den Personen kommunizieren, die die Software bauen.” (Gojko Adzic)
Je weniger Kommunikation stattfindet, desto höher das Risiko, dass wir das Falsche liefern. Dass wir zwar technisch einwandfrei liefern, jedoch nicht das liefern, was der Kunde möchte. Oder in anderen Worten, wie Gojko Adzic es sagt: “I am getting more and more convinced every day that communication is, in fact, what makes or breaks software projects. Programming tools, practices and methods are important, but if the communication fails then the rest ist just painting the corpse.”
Also gehen Sie das größte Risiko “Kommunikation” an und starten Sie mit einem Prozess, der die Kommunikation in den Vordergrund rückt: Scrum!
Wie Scrum im Detail mit Risiken umgeht finden Sie unter anderem in diesem Artikel: Agiles Risikomanagement mit Scrum – empört Euch!

Die Sprint Retrospektive – es kann noch viel verbessert werden (Teil 1)

Die Retrospektive gehört zu den Nachzügler-Meetings im Scrum-Flow. Erst 2004, auf dem Scrum Gathering in Wien (vgl. Gloger, 2011, S. 180f.), erlebte die Agile Community die eigentliche Geburtsstunde des Meetings und es etablierte sich fortan zum unverzichtbaren Bestandteil des Scrum-Prozesses, weil Retrospektiven, fragt man Esther Derby, vor allem eins mit Teams tun: „Keep improving“ (Derby & Larsen, 2006, S. 2).
 
Retrospektiven haben das Ziel, auf der Grundlage des Erlebten (des vergangenen Sprints), Maßnahmen für die Zukunft (den nächsten Sprint) zu generieren, die sowohl die Arbeitsabläufe verbessern sowie  störende Blockaden (Impediments) identifizieren, analysieren und beheben sollen. Um das zu erreichen, stehen zwei Fragen im Fokus der Betrachtung: „Was lief gut?“ und „Was könnte verbessert werden?“ – Erfolgsfaktoren und Potentiale.
 
In meinen täglichen Beobachtungen erkenne ich sowohl in der Moderation als auch in der methodisch, didaktischen Führung des Meetings jede Menge „Luft nach oben“. In diesem Beitrag möchte ich daher das Augenmerk auf die oben bereits erwähnten Schritte 3 (finde funktionierende Prozesse) und 4 (finde nicht-funktionierende Prozesse) (vgl. Gloger, 2011, S. 184ff.) richten. Hier offenbart sich leider ein Trend, den ich nicht nur nicht gutheißen kann, sondern der meines Erachtens auch für eine gewinnbringende Retrospektive kontraproduktiv ist.
 
Die sechs Schritte einer erfolgreichen Retrospektive setzen einen stringenten und lückenlosen Ablauf voraus:
 
Schritt 1: Schaffe Sicherheit
Schritt 2: Sammle Fakten
Schritt 3: Finde funktionierende Prozesse
 
Separator


Schritt 4: Finde nicht-funktionierende Prozesse
Schritt 5: Leite Veränderungen ein
Schritt 6: Entscheide über die Wichtigkeit
 
Zu diesem gehört, dass zwischen Schritt 3 und Schritt 4 ein Zwischenschritt, der sogenannte Separator, eingesetzt werden soll. Dieser hat den Zweck, den „gemeinsamen Denkraum“ (a.a.O, S. 188f.) kurz zu verlassen, um eine spürbare Trennung der beiden Teile „gut“ und „verbesserungswürdig“ zu erreichen. Boris Gloger empfiehlt dafür kreative Arbeitstechniken und betont, dass er mit dem Zwischenschritt „keine Kaffeepause“ meint. Leider ist es aber allzu häufig so, als würde man zu einem kleinen Kind mit erhobenem Zeigefinger sagen: „Fass die Herdplatte nicht an!“
 
Der Separator wird entweder für eine Kaffeepause genutzt oder es wird einfach darauf verzichtet. In beiden Fällen, im zweiten noch mehr als im ersten, verstärkt sich das Risiko, dass die positiven Effekte und Energien (rewards) aus Schritt 3 nicht konserviert werden und durch die nachfolgende Rückschau der nicht-funktionierenden Prozesse, also negative Erlebnisse (threats), sich sogar neutralisieren können. Daher lautet mein deutlicher Appell an alle ScrumMaster und Retrospektiven-Facilitator:



Baut in eure Retrospektiven einen Separator ein, der mehr als ein Durchlüften der Räumlichkeiten ist oder Zeit für einen Toilettengang lässt!
 
Ich möchte euch eine etablierte und gleichzeitige aufheiternde und alle Beteiligten aktivierende Kreativtechnik für euren nächsten Separator vorstellen: den Options Run.
 
Was brauchst du dafür?

  • Einen 5 Meter langen Streifen aus Kreppband (auf dem Boden als Linie geklebt)



Was hast du als ScrumMaster zu tun?

  • Alle Teammitglieder inkl. ScrumMaster stehen an einem Ende der Kreppbandlinie (Start). Die Linie versteht sich als Brücke über einen Fluss. Ziel ist es, ans andere Ende des Ufers zu gelangen. Allerdings gibt es für die Überquerung Constraints.

 
Constraints

  • Der ScrumMaster muss als Letzter ans andere Ufer.
  • Jedes Überqueren ist mit einem Lob (Applaus) zu versehen und verdient die Wertschätzung des gesamten Teams.
  • Bei jeder weiteren Überquerung muss eine neue/andere/eigene Art der Überquerung gewählt werden.

 
Sinn und Zweck des Option Runs

  • Wertschätzung der Leistung jedes Teammitglieds
  • Jede (neue) Lösung ist gut, richtig, besonders. Es gibt kein Falsch!

 
Variante

  • Das Team wählt die kreativste Form der Überquerung aus und der Sieger erhält einen kleinen Preis.

 
In Die Sprint Restrospektive – es kann noch viel verbessert werden (Teil 2) stelle ich euch noch andere kreative Ideen für energiereiche Separatoren vor und weise auf weitere typische Fallstricke in der Retrospektive hin. 
 
 
Literatur
 
Derby, E. und Larsen, D. (2006). Agile Retrospectives: Making good teams great. The Pragmatic Programmers.
Gloger, B. (2011). Scrum – Produkte verlässig und schnell entwicklen. Hanser.

Null-Fehler-Software

Oft wirft das Vorgehen nach Scrum ein paar Fragen und viele Diskussionen zum Thema “Umgang mit Bugs” auf. Manch einer mag sagen, dass die unten formulierten Regeln unrealistisch sind und man sie deshalb von vornherein ignorieren kann. Ich bin jedoch der Meinung, dass man sich dann daran erinnern sollte, warum man mit Scrum entwickeln will. Es gibt doch etwas, was man verändern will, sei es Time to Market reduzieren, Kundenzufriedenheit erhöhen, Qualität der Software verbessern oder oder oder … Und diese – zugegeben nicht einfach zu erreichenden – Veränderungen treten nunmal in der Regel nicht ein, wenn man so weitermacht wie bisher.
Scrum ist dabei ein Gesamtkonstrukt, das uns hilft, diese herausfordernden Ziele zu erreichen. Cherrypicking ist dabei zwar wie in allen anderen Bereichen nett, wird aber nicht die vollumfängliche Verbesserung bringen, die man sich wünscht – leider oft mit dem Fazit, dass Scrum versagt hat. Der Umgang mit Bugs ist da nur ein Beispiel von vielen.
Daher hier – ganz in der gewohnten Scrum-Manier – ein paar ganz einfache Regeln!

Bugs

Bugs werden sofort gefixt!

  1. Bugs sollten innerhalb von 24 Stunden gefixt sein! Ja, dafür muss im Zweifel ein bereits angefangener Task unterbrochen werden. Solange der Fehler nicht behoben ist, kann die Story nicht abgeschlossen werden. Das Gleiche gilt für Broken Builds, fehlgeschlagene Tests etc.
  2. Häufiger Einwand: Was ist mit Bugs, bei denen das Fixing länger dauert? Zumindest innerhalb der ersten 24 Stunden anfangen und sich dann fragen, was im Vorfeld schiefgelaufen ist.

Ein Bug ist ein Bug ist ein Bug – und damit ein FEHLER!

  1. Wir liefern fehlerfreie Software am Ende des Sprints!
  2. Keine Klassifizierungen in major oder minor oder high, medium low (notwendig). Ist es ein Bug, dann siehe Regel 1. Ist es eine neue Funktionalität –> ins Backlog priorisieren! Es werden keine Bugs zurück ins Backlog geschoben und für spätere Sprints “aufgehoben”!
  3. Häufiger Einwand: Nur Laien behaupten, dass es fehlerfreie Software gibt.
    • Mag sein, dass das Laien behaupten. Allerdings schließt das nicht aus, dass es das oberste, immer, ständig, absolut angestrebte Ziel ist, das es zu erreichen gilt. Und das sollte doch auch der Anspruch eines Teammitgliedes in einem Entwicklungsteams sein, oder? Lasst uns gute Arbeit machen und nicht Zeit mit Ausreden verschwenden!

Create a bug lane!

  1. Fügt über der Taksboard-Lane für die erste Story eine Bug Lane ein. Nehmt für Bugs eine andere Post-it-Farbe (Rot bietet sich an).
  2. Häufiger Einwand: Macht es nicht mehr Sinn, die Bugs den Stories zuzuordnen?
    • Die Arbeit in Scrum ist prioritätenbezogen: Was oben steht, wird zuerst bearbeitet. Außerdem sollte sowieso nur die oberste Story in progress sein, so dass die Zuordnung sowieso stimmt.

Das Team bekommt einmal so viel Zeit wie es braucht, um es richtig zu machen!

Calls / Hotfixes / Change Requests

Manche Teams, die auf Scrum umstellen, haben bereits produktive Systeme zu betreuen – sei es in Form von Maintenance, Calls, Hotfixes, vom Kunden entdeckte Bugs oder auch Change Requests. Dabei stellt sich immer wieder die Frage, wie man mit solchen Änderungen am besten umgeht.

Calls haben sich über Jahre angesammelt, der Überblick ist verloren gegangen? Der Call Stack kann nicht mehr abgearbeitet werden, sondern nimmt mit jedem Sprint zu?

  1. Alle Calls löschen!
  2. Mit der Einführung von Scrum sollten alle Calls gelöscht werden. Ab diesem Zeitpunkt werden alle neuen Calls konsequent sofort behoben (siehe Beschreibung oben). Dauert das Beheben, Ändern oder Hinzufügen von Funktionalität zu lange, muss das System neu geschrieben werden.

Kunden bezahlen einen fixen Betrag zur Wartung der Software und erwarten daher sofortige Änderungen!

  1. Der PO entscheidet über Priorisierung und Funktionalität!
  2. In diesem Fall muss oft zuerst genau definiert werden, was unter Maintenance fällt und in welchem Zeitraum diese abgearbeitet werden müssen (sofern es vertraglich festgelegt ist). Oft versucht der Kunde, neue Funktionalität und Change Requests als Maintenance einzubringen. Hier muss der PO die notwendigen Abgrenzungen und Entscheidungen treffen. Auf jeden Fall sollte Transparenz darüber geschaffen werden, wie viele Ressourcen und wie viel Zeit durch die Maintenance-Zahlungen des Kunden zur Verfügung stehen würden. Danach kann sich die Zeit richten, die das Team pro Sprint für Maintenance-Aufgaben nutzen kann (z.B. immer an den ersten oder letzten zwei Tagen eines Sprints). Hier sollte aber wieder darauf geachtet werden, dass es eine Teamleistung ist und diese timeboxed abläuft.

Der Kunde meldet Fehler im Live-System, die seine Arbeitsfähigkeit beeinträchtigen und verlangt sofortiges Hotfixing!

  1. Für den Fehler entschuldigen und sofort beheben!
  2. Halten sich diese Hotfixes im Rahmen, können sie vom Team im laufenden Sprint bearbeitet werden. Umgang wie mit neu entdeckten Fehlern (siehe oben). Nimmt das Hotfixing die gesamte Zeit in Anspruch, sollte eine grundlegende Überarbeitung angestoßen werden.

Es gibt eine überschaubare Menge an Bugs, diese können jedoch nicht in einem Sprint abgearbeitet werden. Das Team, das die Bugs fixen muss, ist nicht für die Produktion der Fehler verantwortlich.

  1. Mit dem Product Owner ein Bug-Burn-Down vereinbaren!
  2. Wie viele offene Defects gibt es und bis wann will man sie gelöst haben? Beispiel: 100 Bugs in 10 Sprints -> 10 Bugs pro Sprint werden gefixt. In der restlichen Zeit wird Funktionalität entwickelt. So schafft man einen Übergang zu einer fehlerfreien Software und bestraft das Scrum-Team nicht damit, ausschließlich die Fehler der anderen beheben zu müssen.

 
Um diesen Umgang mit Fehlern zu ermöglichen und Fehler möglichst früh zu erkennen, gehört daher das nötige Handwerkzeug zur Basisausrüstung eines Entwicklungsteams:

Erst hier ist die Entwicklungsphase abgeschlossen. Erst dann bekommt der (interne oder externe) Kunde die Software.

Und immer dran denken: weniger diskutieren, mehr fixen (Zwinkern)


Couchgespräche – User Acceptance Test vs. User Acceptance Criteria

User Acceptance Criteria

Moderator

User Acceptance Test

Willkommen zu unserem heutigen Couchgespräch. Heute sind zu mir bei Gast zu meiner Linken Frau User Acceptance Criteria und zu meiner Rechten Herr User Acceptance Test. Schön, dass Sie beide den Weg hierher gefunden haben.
Hallöchen, freut mich sehr hier zu sein! Servus alle miteinand!
Man sagt ihnen nach, dass Sie beide so gleich sind, dass Sie oft verwechselt werden? Unterscheiden Sie sich wirklich in so wenigen Punkten?
Ach ja, das ist tatsächlich so – wobei wir uns schon sehr unterscheiden können. Ich bin ja eher so der Detailmensch. Ich zeige konkret, wie etwas funktioniert und ob etwas funktioniert. D. h. mit mir zusammen überprüft man, ob eine Story richtig gebaut wurde.
Richtig gebaut ist natürlich sehr wichtig und wissen Sie, was mindestens genauso wichtig ist? Und zwar herauszufinden, ob etwas auch so funktioniert wie erwartet. D. h. wurde denn die richtige Story gebaut? Die Details von Herrn Acceptance Test benötigen wir, damit wir erkennen, ob wir auch das Richtige geliefert haben.
Okay, bitte nochmal kurz zum mitschreiben. Ich glaube nämlich, Sie haben mich jetzt abgehängt: Die richtige Story richtig gebaut – oder wie war das jetzt?
Naja, fast. In der Konsequenz muss beides übereinstimmen. Nur so haben wir korrekt geliefert. Wobei man hier noch etwas genauer werden kann. Herr Acceptance Test ist dafür zuständig, dass etwas technisch korrekt funktioniert, d. h. lauffähig ist. Das nennt man dann Verifikation.
Richtig! Ich hingegen bin die abstraktere von uns beiden. Für mich ist wichtig, ob etwas fachlich richtig ist. Soll heißen: Mit mir validiert man, ob wir den gewünschten Nutzen erfüllen. Ich hätte da noch ein anderes Beispiel, das uns bei unserer Unterscheidung helfen kann.
Nur zu gerne! Okay. Also bei mir ist das so: Mit mir kann das Team dem Product Owner zeigen, dass das, was es sich vorgenommen hat, korrekt umgesetzt wurde. Ich liefere die Testfälle, die das Team zum Beispiel im Review zeigt. Frau User Acceptance Criteria hingegen tritt den Beweis an, dass der Product Owner auch das liefert, was der Benutzer benötigt. Nur weil wir eine Funktion liefern, die funktioniert, heißt das nicht – und das wissen wir nur zu gut – dass wir auch das wirklich geliefert haben, was der Kunde braucht.
Danke, jetzt haben Sie viel von Unterschieden geredet. Was haben Sie denn gemeinsam?
Ach ja, da gibt es einiges. Manchmal kommt es mir vor, als wären wir ein altes Ehepaar. Oder ein altes Paar Socken, bei dem eine Socke ein paar Löcher hat.
Alles in allem haben wir die Essenz der Funktion gemeinsam. Man kann z. B. aus mir Anforderungen ableiten, die dann mit Herrn User Acceptance Test verifiziert werden können. In diesem Fall gebe ich die grobe Richtung vor, während Herr User Acceptance Test dem Team hilft, die Entscheidung des Teams sichtbar zu machen. Richtig, allerdings geht es auch anders herum. Wenn man erst einmal weiß, was man alles testen möchte, dann fällt einem auch sehr schnell auf, wozu man das möchte. In diesem Fall führe ich das Team hin zur Frau User Acceptance Criteria. Ach ja, wir treffen uns immer und immer wieder.
Ich denke, fürs Erste habe ich soweit verstanden. Ich hoffe, unseren Zulesern geht das auch so. Vielen Dank an Sie beide dafür, dass Sie sich die Zeit genommen haben, uns ausführlich Rede und Antwort zu stehen. Vielleicht können wir bald noch einmal an diese Unterhaltung anknüpfen.

Das Burndown-Chart – 10 Gründe dafür

Das Burndown-Chart dient in Scrum dem Reporting, aber das ist lange nicht alles. Einzelne Elemente in Scrum verstärken sich gegenseitig und das Burndown-Chart ist eines davon. Hier 10 Punkte, warum das Burndown-Chart den Scrum-Flow bereichert:

  1. Es zeigt die Leistung eines Teams innerhalb eines Sprints. D. h. es zeigt an, wie viel Funktionalität bereits fertiggestellt und lieferfähig ist.
  2. Es hilft dem Team, den inneren Schweinehund zu überwinden, indem das Team täglich angespornt wird, die Funktion fertigzustellen. Es setzt täglich einen Reflektionspunkt für das Team und fördert den Fokus auf das zu Liefernde.
  3. Es verstärkt das Anreizsystem der Lieferung, da nur fertiggestellte Funktionen gemessen und dadurch belohnt werden.
  4. Es dient der Transparenz gegenüber dem Management. Das Management kann jederzeit ablesen, ob und wie viel ein Team liefern wird.
  5. Es bringt Teams dazu, offen mit der eigenen Arbeit umzugehen. Hier dient es als wichtiges Startsignal, um Offenheit im Unternehmen zu fördern. Wer transparent mit seinem Arbeitsfortschritt umgeht, der fördert auch die Kooperationsbereitschaft zwischen Teams und Abteilungen.
  6. Es zeigt an, dass ein Team unter Last steht und nicht gestört werden darf. Dabei hilft es vor allem, den Sprint stabil zu halten und keine Ad-Hoc-Anforderungen mit aufzunehmen.
  7. Es zeigt auf, wenn an zu vielen Dingen parallel gearbeitet wird.
  8. Es lässt das Team den eigenen Erfolg feiern. Täglich einmal auf dem Burndown-Chart nach unten oder ab unter die Solllinie – einfach ein tolles Gefühl.
  9. Es dient als Diagnosemittel, bspw. zeigt es Verzug auf. Wenn es hakt, dann sieht man es hier. Das Burndown-Chart bringt Verzug symptomatisch ans Licht, egal ob es an Impediments liegt, das Team parallel an mehreren Geschichten gleichzeitig arbeitet oder gar etwas komplett anderes macht.
  10. Es zeigt auf, wenn Stories zu groß geschnitten sind. Eine weitere Ursache, die das Burndown-Chart zu Tage fördert, sind überdimensionierte User Stories. Ist eine Story zu groß, so erkennt man das auch an der Flatline auf dem Burndown-Chart.

Das Burndown-Chart lässt sich auch sehr gut in Retrospektiven und Reviews einsetzen. Hier dient es als Anstoß für Diskussionen. Nutzt das Burndown-Chart dafür, euren Blick kurz aus dem Tagesgeschäfts zu heben, durchzuatmen und euren Blick auf das Produkt und die versprochene Lieferung schweifen zu lassen. In diesem Sinne: Burn it down baby!

Verrückt verrückt

Vor kurzem kam ein ScrumMaster auf mich zu und fragte mich, was er gegen seine Ungeduld tun könne. Immer wieder ertappe er sich dabei, dass ihn langsames Arbeiten einzelner Teammitglieder manchmal zur Weißglut treibe und er sich innerlich wirklich zusammenreißen müsse, um nicht zu explodieren oder die Arbeit einfach selber zu machen. Ich fragte ihn: „Was tust du, wenn du ungeduldig bist. Angenommen ich wollte von dir lernen, ungeduldig zu sein, was müsste ich tun?“ Verdutzt und mit einem Schmunzeln sah mich der befragte ScrumMaster an. Meine Frage irritierte ihn. Aber warum?
 
Mit meiner Frage hatte er einfach nicht gerechnet. Ich hatte ihm nämlich eine paradoxe Frage gestellt. Paradox heißt widersprüchlich. Mit paradoxen Fragen verfolge ich das klare Ziel, das vom Befragten als Problem identifizierte Verhalten zu verstärken, um auf diese Weise einen ganz bestimmten Zweck zu erfüllen: Jemand, der ein Problem in seinem Verhalten (z.B. Ungeduld) verstärken kann, der hat ebenso die Fähigkeit, dieses Verhalten zu verringern, es in einer abgewandelten (konstruktiveren) Form zu zeigen oder es ganz aufzugeben. Gelingt eine solche Verstärkung, ist eine Veränderung des Fokus in die entgegengesetzte Richtung (weniger ungeduldig) möglich. Somit erreiche ich, dass das „Opfer“ (Ich bin ungeduldig. Was kann ich dagegen tun?) zum aktiven Einflussnehmer wird und sich in seinem eigenen Defizit nicht ausgeliefert fühlt.

Verschlimmerungsfrage

Die Verschlimmerungsfrage ist eine Variante der paradoxen Frage. Die Problemorientierung dieser systemischen Frageart soll dem Befragten bewusst machen, dass Probleme bewusst erzeugt werden und somit auch bewusst unterlassen werden können. Zum Beispiel: “Was könntest du tun, um dich noch ungeduldiger zu fühlen?” Oder: “Wie kann ich dich dabei unterstützen, das Problem zu behalten?” Verschlimmerungsfragen dürfen durchaus provokativ sein, den Befragten einen Spiegel vorhalten und ihn mit seiner negativen Eigenschaft offen konfrontieren, z.B.: “Was ist, wenn deine Teammitglieder dir gar nicht zutrauen, dass du geduldiger sein kannst?”
Auf den Punkt gebracht: Paradoxe Fragen, wie die Verschlimmerungsfrage, sind auf den ersten Blick verrückt und irritieren das Selbstverständnis des Befragten. Auf diese Weise verrückt die Frage den Fokus und lädt zum Nachdenken in Lösungsbereichen ein, die bis dato möglicherweise unerforscht oder unberührt waren: Verrückt verrückt.

Diversität als Qualitätskriterium oder warum sich Scrum-Teams mit Locktänzen beschäftigen sollten

Es ist nach wie vor ein immer wieder anzutreffendes Problem, dass Software-Entwicklungsteams nicht so aufgestellt sind, wie ein Produkt-Entwicklungsteam, ein Scrum-Team, idealerweise aufgestellt sein sollte. Boris Gloger beklagt in seinem Buch „Scrum – Produkte zuverlässig und schnell entwickeln“, dass die Software-Entwickler unter sich und die Business-Analysten ebenfalls immer noch in vielen Organisationen separiert sind:
 
Anstatt gemeinsam zu arbeiten, schreiben die Analysten die Spezifikationen und reichen sie an die Entwickler weiter. In den meisten Firmen werden (immer noch) Teams entweder nach den Applikationen, für die sie arbeiten, oder nach ihren speziellen Fähigkeiten gruppiert.“ (Gloger, 2011, S. 67)
 
Und Boris Gloger hat recht, wenn er sagt:
 
Wenn die Verantwortung des Teams darin liegt, am Ende des Sprints potenziell auslieferbare, anwendbare Produktteile zu liefern, benötigen wir eine Mannschaft, die mehr kann, als „nur“ Software zu entwickeln.“
 
Diese Mannschaft muss multidisziplinär sein, sie muss heterogen sein, sie muss sich in ihren individuellen Fähigkeiten und Fertigkeiten unterscheiden. Hier liegt der Schlüssel für Qualität in der Entscheidungs- und Lösungsfindung. Ein Beispiel aus der Natur zeigt, wie effektiv Multidisziplinarität sein kann und dass Diversität in Gruppen ein echtes Qualitätskriterium ist.

Macht es wie die Bienen

Bienen haben eine faszinierend effiziente Art, Nahrung zu suchen. Ein Bienenstaat ist in der Lage, bis zu sechs Kilometer von seinem Stock auszuschwärmen und hat dabei eine mehr als 50-prozentige Chance, ein Blumenfeld im Umkreis von zwei Kilometern ausfindig zu machen. Dass Bienen das tun, ist schon bemerkenswert, aber wie sie es tun, das ist wirklich beeindruckend. Da sie nicht wie Menschen in einer Diskussionsrunde mit Agenda, Brainstorming und Moderator eine gemeinsame Entscheidung darüber treffen können, wo die jeweilige „Reise“ hingehen soll, schicken sie Kundschafterbienen aus, die ergiebige Nektarquellen ausfindig machen sollen. Hat eine von ihnen eine solche entdeckt, fliegt sie auf schnellstem Wege zum Bienenstock zurück und führt einen Locktanz auf, der anderen signalisiert, dass sie eine Entdeckung gemacht hat. Interessanterweise wird die Intensität des Tanzes durch die Qualität des Nektarvorrats bestimmt. Besonders gute, auffällige Tänze finden eine hohe Zahl an Gefolgschaft, weniger gute Tänze wenig Gefolgschaft, die ihre eigenen Fundstellen dafür manchmal sogar aufgeben. Als Ergebnis verteilen sich die nahrungssuchenden Insekten schließlich auf imponierende Weise über verschiedene Nektarquellen. Oder anders ausgedrückt: Sie organisieren eine im Verhältnis zur aufgewendeten Zeit und Energie größtmögliche Nahrungsmenge. Auf diesem Wege hat der Bienenstaat sein Nahrungsdefizit im Kollektiv gelöst.*
 

 
Das Bemerkenswerte an der Nahrungssuche der Bienen ist die Methode, mit der eine intelligente Lösung als Gruppe gefunden wird, nämlich nicht durch rationales Abwägen aller erdenklichen Optionen, um auf diese Weise eine Entscheidung über ein ideales Suchmuster zu treffen. Das wäre beziehungsweise ist auch unmöglich, weil die Bienen gar nicht wissen können, was an möglichen Alternativen (Blumenfeldern) sonst noch existiert. Daher schickt die Kolonie ihre Kundschafter in viele (nicht alle) Richtungen in dem Vertrauen los, dass mindestens eine das ergiebigste Feld ausfindig macht, zurückkehrt und eine gute Tanzperformance zeigt, die für viele andere Bienen (Ver-)Lockung genug ist.
 
Bei dieser Form der Problemlösung geht es – und das ist wichtig zu begreifen – nicht nur um die Aufgabe, bereits vorgegebene und fixierte Wahlmöglichkeiten zu beurteilen und ein klar vorgegebenes Problem zu bewältigen (z.B. wer gewinnt das Finale der Champions League – Bayern München oder Chelsea London?). Problementscheidungen wie die Nektarsuche des Bienenstaates verlangen eine Problemlösung in zwei Phasen: Zunächst müssen die Alternativen aufgespürt werden, erst dann kann man sich für eine der Alternativen entscheiden.

Diversität der Konzepte, des Erkennens und der Menschen

In der ersten Problemlösephase ist die Anzahl der in Frage kommenden Lösungsoptionen (noch) so groß, dass es mehr als sinnvoll ist, so viele Kundschafter (Wege, Meinungen, Ideen, Erfahrungen) wie möglich zu entsenden. Ein Schlüsselelement für dieses Vorgehen ist, dass es erst mal alle Ideen, also auch spekulative Ideen zulässt und fördert. Noch wichtiger ist in diesem Zusammenhang Diversität. Gemeint ist hier eine Diversität, die sich auf Konzepte und Erkennen bezieht, die eine reichhaltige Auswahl an grundsätzlich verschiedenen Konzepten statt leichten Varianten und Abwandlungen ermöglicht.
Darüber hinaus muss die Gruppe aber ebenso imstande sein, zwischen guten und schlechten Problemlösungen zu unterscheiden. Viele Experimente zeigen, dass sich Gruppen darauf recht gut verstehen. Interessanter ist die Frage, ob so denn ein vielfältiges Spektrum an Lösungen vorliegt, es einen großen Unterschied macht, ob sich die Gruppe aus verschiedenartigen Entscheidern zusammensetzt oder nicht?
 
Und ob es einen Unterschied macht! Diversität bringt nicht nur neue Perspektiven ein, die sonst ausbleiben würden, sondern verhindert einige für die Entscheidungsfindung gefährliche Eigenschaften von Gruppen. Nicht zuletzt, weil kleinere Gruppen schnell im ungebührlichen Einfluss voreingenommener Mitglieder stehen, die einen echten und gemeinsamen Gruppenentscheid vereiteln können. Scott Page, ein Politikwissenschaftler an der Universität in Michigan, fand in einer aufschlussreichen Testserie heraus, dass eine Gruppe aus klugen und weniger gescheiten Probanden fast immer besser abschnitt als eine Gruppe, die nur aus klugen Probanden bestand. Betraute Page eine willkürlich gewählte Gruppe mit einem Problem, dann war die Lösung dieser Gruppe immer besser, als die Lösung einer Gruppe, die ausschließlich intelligente Probanden hatte. Ich möchte damit mitnichten sagen, dass man sich einfach ein paar dumme Leute in ein Team holen soll und dann flutscht es von selbst. Keineswegs. Aber ich möchte betonen, dass die Zusammensetzung einer Gruppe aus unterschiedlichsten Personen zu einer optimaleren Lösung von Problementscheidungen führen kann. Und hierbei ist Erkenntnisvielfalt besonders hervorzuheben, was wieder nicht heißt, dass man bloß verschiedenartige, uninformierte Leute in eine Gruppe packt und eine kollektivere Weisheit erhält, als die eines Fachmanns. Aber: Bildet man eine Gruppe aus verschiedenartigen Menschen mit unterschiedlichem Wissensstand und Einsichten, dann erhält man eine bessere Lösung, als wenn man die Lösungsfindung einem oder zwei Menschen anvertraut, ganz gleich, wie intelligent diese sind.
 
Sorgt dafür, dass eure Teams unterschiedliche Skills abbilden und sucht nach Verschiedenartigkeit. Tester, Entwickler, Architekten stehen sich bei einem gemeinsamen Tun beim Schätzen, Planen oder auch Entwickeln nicht im Weg, sondern ergänzen sich und erschaffen Perspektiven, die in einer Spezialistengruppe niemals zustande kommen können. Grämt euch nicht, wenn ihr ein neues, unerfahrenes Teammitglied dazu bekommt. Erlebt es eher als Geschenk und als echte Chance, euch als Team und in eurer Performance und Produktivität weiterzuentwickeln. Diversität ist ein Qualitätskriterium und neue (Ein-)Sichten eröffnen neue, unberührte Denkpfade.
 
Liebe Scrum-Teams, was sind eure Locktänze? Wie schafft ihr es, dass euch eure Teammitglieder in den Plannings folgen und eure Lösungen gut finden? Ich empfehle euch die Kraft der Diversität auch in euren Schätzrunden (Magic Estimation, Planning Poker) zuzulassen und auszuweiten. Insbesondere das Review und die Möglichkeit, euch von außen Feedback geben zu lassen, erweitert eure Perspektiven und ergänzt ggf. eure Lösungsfindung.
Alles kann, nichts muss.
 
Literatur:
B. Gloger (2011). Scrum – Produkte zuverlässig und schnell entwickeln. Hanser
J. Surowiecki (2004). Die Weisheit der Vielen: Warum Gruppen klüger sind als Einzelne. Bertelsmann
 
*Wer noch mehr darüber erfahren mag, dem empfehle ich Thomas D. Seeley „The Wisdom of the Hive“ (Die Weisheit des Bienenstocks).

Versunkene Betrachtung von Pädagogik durch einen Laien und sein Weg zurück zu Scrum

Vor kurzem ist mir ein Buch über Montessori-Pädagogik in die Hände gefallen. Ich habe es aufgeschlagen und bin direkt im Kapitel “Polarisation der Aufmerksamkeit und Stille” gelandet. Nun bin ich kein Spezialist in der Pädagogik und das, was ich in den nächsten Minuten las, war sehr faszinierend.
Laut Maria Montessori versinken kleine Menschen (Kinder) immer wieder in Phasen von Stille und Konzentration. In diesen Phasen widmen sie sich ganz ihrer Tätigkeit und schaffen es, sich von Ablenkungen zu isolieren. Das gelingt ihnen, wenn sie
a) ihre Tätigkeit, wie auch das Material für die Tätigkeit frei wählen können,
b) sich in einer vertrauensvollen Arbeitsatmosphäre befinden,
c) und eine Umgebung vorfinden, die einen geeigneten Rahmen für die Tätigkeit zur Verfügung stellt.
Tritt nun diese Phase ein, passiert das: “Und jedes Mal, wenn eine solche Polarisation der Aufmerksamkeit stattfand, begann sich das Kind vollständig zu ändern. Es wurde ruhiger, fast intelligenter und mitteilsamer. Es offenbarte außergewöhnliche innere Qualitäten, die an die höchsten Bewusstseinsphänomene erinnern, wie die der Bekehrung.” [1](Montessori). Hier spricht man von einem großen Lernschritt mit persönlichkeitswirksamer Entwicklung.

Auch Erwachsene können versinken

Nun rückt mein Laienwissen in den Vordergrund: Ich persönlich denke, dass wir diese Entwicklung nicht nur als Kind durchleben, wir als Erwachsene haben es jedoch vermeintlich schwerer. Wie oben erwähnt sind für einen so intensiven Zustand bestimmte Faktoren notwendig: Selbstbestimmung sowie ein stabiles und vertrauensvolles Umfeld. In unserer heutigen Hektik ist das selten der Fall, außer man hat einen Rahmen, evtl. eine Methode, die dafür sorgt. Warum spreche ich von einer Methode und ja, im nächsten Satz dann genauer von Scrum? Meines Erachtens finden sich die drei Punkte in einem korrekt umgesetzten Scrum wieder:
a) Wenn jedes Teammitglied im Sprint die eigene Tätigkeit selbst wählt (PULL) und selbst bestimmt, WIE etwas umgesetzt wird (Autonomie des Teams). Wichtig ist auch die Gestaltung des Arbeitsplatzes anhand der eigenen Bedürfnisse.
b) Wenn sich ein Scrum-Team in einer vertrauensvollen Arbeitsatmosphäre befindet, da der Sprint stabil bleibt und kontinuierlich gemeinsam in Retrospektiven gegenseitiges Vertrauen aufgebaut wird.
c) Wenn der ScrumMaster dafür sorgt, dass die Organisation sich an den Bedürfnissen des Teams ausrichtet und er stetig daran arbeitet, dass der Rahmen den gegenwärtigen Ansprüchen gerecht wird.
Mihaly Csikszentmihalyi spricht von einem “Aufgehen im Tun”, das sich in einer “inneren Beteiligung” widerspiegelt. Diese Beteiligung ist notwendig für den Lernprozess und man spricht bei der “Selbstvergessenheit der Tätigkeit”  von “Flow”. [2] (Csikszentmihalyi) In diesem Zusammenhang steht ein weiterer Aspekt: “Der gelungene Abschluss einer Arbeit spornt zu weiteren Leistungen an und fördert die Ausbildung intrinsischer Motivation nachhaltig.” [3] (Klein-Landeck)
Auch hier sehe ich Parallelen zur agilen Organisation bzw. zur lernenden Organisation. Ein “Aufgehen im Tun” finde ich grundlegend im agilen Mindset wieder. Wir experimentieren und schaffen Ergebnisse, wir tun etwas und können aufgrund eines Ergebnisses – einer funktionsfähigen Lieferung – echte Fakten bewerten. Dass Individuen motivierter sind, wenn sie sich so beschäftigen können, verwundert nicht. Und ich denke, für Teams gilt das auch.
Alles in allem freue ich mich immer wieder, wenn ich Hintergründe aus anderen Fachbereichen finde, die mir in unterschiedlichen Facetten zeigen, warum Agilität funktioniert. Die Praxis zeigt es ja immer wieder, dass es klappt. Nur sind die theoretischen Hintergründe über die verschiedensten Disziplinen verteilt, zumeist jedoch schon sehr lange erforscht.
 
[1] – Mario M. Montessori (2008): The Human Tendencies and Montessori Education
[2] – Mihaly Csikszentmihalyi (1991): Das flow – Erlebnis: Jenseits von Angst und Langeweile: im Tun aufgehen
[3] – Michael Klein-Landeck (2009): Fundgrube für die Freiarbeit Englisch: Praxismaterialien zum selbsttätigen Lernen nach Montessori

ScrumMaster vs. ScrumMasterin

Zum Hintergrund: Es ging bei folgender Szenerie um das Schreiben von User Stories aus der Sicht einer Persona. Die Sicht des Kunden, also der der Persona, verstand mein Gegenüber als eine weibliche Eigenschaft.
 
„Na ist doch klar, als Frau achtet man auch mehr auf Details. Wir Männer sind da eher pragmatisch veranlagt!“
 
Nicht nur, dass er diese schon eingestaubte und marode Mann/ Frau-Schublade aufmachte. Nein, diese überholte Ablage, verstaut in den Tiefen einer Schublade, wurde durch einen weiteren Kommentar noch bildlich untermauert: „Na wenn ich Hunger habe“, so die Einleitung „dann mach ich mir ein Schnitzel, esse das, bin satt und gut ist. Was muss ich denn da noch viel Schi Schi machen. Das ist dann mehr so ein Frauending.“
 
Auch ich dachte, der Hauptteil und Schluss wäre bei der Ausführung spannender, aber es blieb bei einer Kurzgeschichte. „Schi Schi machen, was meinst du damit?“ Der Spannungsbogen war mir nicht spannend genug, es war nicht mal ein Bogen. Eine platte Attitüde längst vergessener Ansichten lag nun in meinem Kopf und arbeitete sich durch alle Etagen ins Oberstübchen.
 

Geht es bei einem Perspektivenwechsel tatsächlich um weibliche Fähigkeiten?

Wenn ich von einer Persona spreche, rede ich von einem Kunden, einem Stakeholder oder auch von einer klassifizierten, vielleicht stereotypischen Persona, die mein Produkt konsumiert, nutzt und repräsentiert. Je nach Kunde überlege ich mir also eine Persona mit entsprechenden Eigenschaften dazu, die den Kunden repräsentiert.
Diese Persona/ Kunde zahlt Geld, um die Funktionalität zu nutzen, die ich anbiete, oder auch nicht. Mein Ziel und Interesse ist demnach sehr pragmatisch. Ich will einen zufriedenen Kunden! Schi Schi ist in jedem Fall angebracht, wenn mein Interesse darin besteht, dass mein Produkt nicht nur genutzt wird, sondern dass ich im Idealfall auch noch Geld damit verdienen kann, weil der Kunde zufrieden ist.
Missachte, ignoriere ich bei der Umsetzung meines Produktes die User/ Kunden/ Persona Sicht, dann hat das für mich nichts mit typisch Frau oder typisch Mann zu tun. Meiner Ansicht nach fehlt hier all zu oft das allgemeine Interesse ein Produkt für real existierende Menschen/ Kunden/User -> Persona zu bauen.
 
Zum Abschluss: Wir sind ScrumMaster, wir schreiben keine User Stories, aber wir  helfen unserem Product Owner dabei. Ob da nun ein ScrumMaster neben dem PO sitzt, oder eine ScrumMasterin, hat für mich keinerlei Einfluss. Für mich ist wichtig, dass der ScrumMaster in der Lage ist, den Kunden zu kennen, oder kennenzulernen, um mit dem Product Owner eine oder mehrere Persona(e) zu kreieren.

Agiles Risikomanagement mit Scrum – empört euch!

Eine der spannendsten Definitionen für Risiko, die ich in der letzten Zeit gelesen habe, kommt von Peter Sandman: “Risiko = Gefahr + Empörung”. Im öffentlichen Leben, leider aber auch in vielen Organisationen bleiben die meisten Leute in der Empörung stecken und schüren negative Emotionen, statt sich mit der eigentlichen und drohenden Gefahr zu beschäftigen.
So kann es schnell passieren, dass man sich über eine große Gefahr zu wenig empört oder eine kleine Gefahr mit viel Empörung zu sehr aufbauscht. Sehen wir uns das Beispiel der Brent Spar aus dem Jahr 1995 an: Der Konzern Shell wollte einen schwimmenden Öltank in der Nordsee versenken. Greenpeace besetzte die Brent Spar und sorgte dadurch für großes Medienecho, das von der Bevölkerung stark aufgenommen wurde. Im Nachhinein stellte sich heraus, dass die Empörung stärker war als die angenommene Gefahr. Aber erst die große Empörung führte dazu, dass das Risiko für die Entsorgung so groß eingeschätzt wurde, dass der schwimmende Öltank nicht mehr versenkt wurde.
Vor allem, wenn wir über Zukünftiges diskutieren, empören wir uns schnell und werden emotional. Wir wissen nicht, was kommen wird. Diese Unsicherheit zwingt uns zu Vermutungen und bringt unsere Befindlichkeiten ins Spiel. Und während wir Zeter und Mordio schreien, verlieren wir den Kontakt zu den Tatsachen und geben einem Risiko manchmal mehr Macht, als es tatsächlich hat.
Viele der Risiken, die uns bei der Produktentwicklung begleiten, entstehen während der Entwicklung des Produkts. Dass man zu diesem Zeitpunkt genau hinsieht, ist umso wichtiger. An dieser Stelle befassen wir uns in Scrum, dank eines empirischen Prozesses, mit Fakten – wir brauchen also keine Vermutungen mehr. Denn oft sind es, neben Time to Market, die Probleme der Organisation, die die Produktentwicklung gefährden.
“Wie geht Scrum eigentlich mit Projektrisiken um?”, ist eine der Fragen, die in diesem Zusammenhang gerne gestellt wird. Hier 6 Punkte, die uns in der Agilen Software-Entwicklung und vor allem in Scrum helfen, effektiv mit Risiken umzugehen:

  1. Agile Werte und Prinzipien
  2. Impediment Backlogs und der ScrumMaster
  3. User Stories und die Frage “Wozu?”
  4. Schätzungen (Estimates)
  5. Schnelles Feedback durch End-User
  6. Potentially Shippable Increment

Agile Werte und Prinzipien

Durch einen offenen und mutigen Umgang mit Impediments gehen wir gemeinsam Risiken der Produktentwicklung an. Wir begrüßen Veränderung, sowohl organisatorisch, als auch auf das Produkt bezogen. Unseren Erfolg messen wir allein am Fortschritt des Produkts und setzen Kooperation an die Spitze unseres Handelns.
Wir sind uns also des Risikos bewusst, dass eine zu genau geplante Zukunft ein sehr großes Risiko ist. Stattdessen arbeiten wir in kurzen Zeitspannen (Sprints) und reagieren frühzeitig auf die Veränderungen der Geschäftswelt. Wir berücksichtigen die Kundenwünsche, nehmen sie auf und gehen sie zum richtigen Zeitpunkt an – und zwar zum Zeitpunkt der Umsetzung. Somit widmen wir uns immer nur den wichtigen Anforderungen und unterscheiden zwischen wichtig und unwichtig.
Ein offener und mutiger Umgang mit Herausforderungen, Fortschritt und Hindernissen hilft uns dabei, die Risiken aus dem Weg zu räumen.

Impediment Backlogs und der ScrumMaster

In Scrum beschäftigen wir uns an mehreren Stellen mit Hindernissen und Problemen (Impediments). Dabei handelt es sich um die Risiken, die während des Projekts auftreten und das Produkt gefährden. Wir sammeln und verwalten die Impediments transparent und öffentlich in Impediment Backlogs.
Aus dem Impediment Backlog können wir sehr gut ablesen, welche Risiken im Projektverlauf in der Praxis auftreten. Hier findet man bspw. die zwischenmenschlichen Probleme und organisatorischen Hindernisse, die während der Zusammenarbeit entstehen. Wir unterteilen Impediment Backlogs nach Kontroll- bzw. Einflussbereichen:

  1. Kann es vom Team gelöst werden, liegt die Verantwortung in der Zusammenarbeit zwischen den Teams oder in der Organisation. Folglich zeigt das Impediment Backlog des Teams die Hindernisse auf, die das Team betreffen und bei der Arbeit behindern.
  2. Abhängigkeiten zu anderen Teams findet man in der Skalierung auf dem Company Board.
  3. Im ScrumMaster Impediment Backlog verwalten die ScrumMaster gemeinsame, organisatorische Impediments und koordinieren über das Board ihre Vorgehensweise.

Dadurch, dass wir in Scrum echte Boards verwenden, machen wir Impediments für alle sichtbar. Damit können wir zum einen zeigen, dass Impediments vorhanden sind (Push-Prinzip), zum anderen steigert es die Empörung und es wird notwendig, einer Gefahr ins Auge zu sehen.
Der Umgang mit Impediments und der Organisationsentwicklung bekommt in Scrum einen besonderen Stellenwert: Der ScrumMaster ist organisatorisch eingesetzt, um die Veränderungen an der Organisation voranzutreiben, damit sie schnell den Anforderungen gerecht wird. Er muss den Status Quo der Organisation angreifen, damit sich die Organisation in punkto Zusammenarbeit und Kultur positiv verändert. Er stößt also mit den Anforderungen der Gegenwart an die Grenzen des organisatorischen Rahmens, der ja auf den Kenntnissen der Vergangenheit beruht. Aus der Erfahrung heraus wissen wir, dass das größte Risiko bei Veränderungen darin liegt, zu langsam zu sein. Dass Veränderung nicht fehlschlägt, weil sie zu früh kommt, sondern weil wir zu lange gewartet haben – weil es nur wenige gibt, die die Veränderung nach vorne tragen. Bei einem ScrumMaster steht das in der Jobbeschreibung, er wurde für den Wandel angestellt.

User Stories und die Frage “Wozu?”

User Stories fordern und fördern Diskussionen. Dadurch verteilen wir das Wissen um Domäne und Anwendungsfall im gesamten Team. Durch Diskussionen schaffen wir den Raum für Fragen, Mitdenken und Kritik, lösen die Mehrdeutigkeit der Sprache leichter auf und vervollständigen das gemeinsame Bild der Story. Sobald wir als Team diskutieren und wir den Zweck der Funktion kennen, entwickeln wir eine gemeinsame Verantwortung (Ownership).
Warum Diskussion zur Dokumentation? Mike Cohn bringt es auf den Punkt: “If you write them down, users will get exactly what they want. That’s not true. At best, users will get exactly what was written down, which may or may not be anything like what they really want.” (Mike Cohn, Succeeding with Agile, Addison-Wesley, 2010).  Durch Diskussion nutzen wir das Potential der Gruppe, wir schaffen ein gemeinsames Verständnis und geben jedem eine Stimme. Denn erst durch die Bilder aller Beteiligten erkennen das komplexe System, in dem wir uns bewegen.
Wozu das wozu?
Die Anforderungen an unser System ändern sich. Ich weiß nicht, wie oft ich das schon gesagt, gelesen, geschrieben, gehört, gesungen, getanzt und… okay… in jedem Fall hilft uns das “wozu” auf mindestens drei Arten:

  1. Es ist wertorientiert und der Wert ist beständiger als die beschriebene Funktion. Zudem lässt sich nur anhand eines Wertes bestimmen, ob die Funktion noch benötigt wird.
  2. Der Wert kommuniziert das benötigte Verhalten besser als die Funktion selbst. Versteht ein Team, wozu die Funktion notwendig ist, so kann es diese anhand des Wertes kontrollieren. Ist nur der Wert bekannt, so kann das Team die Funktion entwickeln. Sind Funktion und Wert bekannt, kann das Team die Funktion in Frage stellen und ein besseres Ergebnis liefern.
  3. Werte lassen sich anhand von Business Value vergleichen. D. h. Werte verstehen wir, sie sind eindeutiger und lassen weniger Spielraum für Interpretationen. Bei Funktionen muss jeder den Wert meist erst interpretieren, ihn sich “laden”. Im Gegensatz dazu ist meist jedem klar, wie ein Wert durch eine Funktion erreicht werden kann. Durch Werte engen wir den Interpretationsspielraum einer Funktion ein.

Letztlich entzerrt die Frage nach dem “wozu” die Anforderung von der Implementierung und hilft uns, den Wert der Story zu verstehen. Wir schränken dadurch im Vorfeld nicht unseren Lösungsraum ein, sondern lassen die Art der Implementierung frei. Wir benennen die Funktion, zeigen den Wert auf und geben diese Anforderung dann weiter. Jetzt kann das DevTeam seine Expertise einbringen.

Schätzungen (Estimates)

Wenn wir User Stories und Anforderungen betrachten, dann stolpern wir immer wieder über Probleme beim Verständnis und Detaillierungsgrad, sowie der technischen Umsetzung der Stories. Um die richtige Größe zu finden und Risiken bzgl. der technischen Umsetzung zu identifizieren, schätzen wir in Scrum regelmäßig unser Product Backlog.
Mit Schätzungen (Estimates) identifizieren wir die Stories, die fachlich zu ungenau oder technisch zu schwer zu realisieren sind. Wir schätzen und erarbeiten gemeinsam im Team die Stories und bilden dadurch die Grundlage für einen Releaseplan. Schätzt das DevTeam, dann bekommen die Spezialisten eine gewichtige Stimme. Dadurch adressieren sie Risiken bzgl. Verständnis oder Ungewissheit der Umsetzung. Sind solche kritischen Stories identifiziert, untersuchen wir sie schnellstmöglich durch Experimente (Sprints). Wir schaffen somit eine faktenbasierte Entscheidungsfindung durch Inspektion. Anhand der Ergebnisse können wir unser weiteres Vorgehen abstimmen, da wir die riskanten Punkte bereits getestet haben.
Ein wichtiger Punkt ist, dass wir nicht einmalig schätzen, sondern kontinuierlich. D. h. wir schätzen eine Story mehrmals und bringen sie in ein Größenverhältnis zu anderen Stories. Außerdem verändern sich Stories in ihrer Größe über die Zeit, auch das wird berücksichtigt (bspw. wird ein Prozess  für ein Audit relevant und muss nachverfolgt werden). Letztlich sind unsere Schätzungen die Grundlage für die Arbeit am Produkt in der Zukunft und auch hier kann wieder der Faktor Empörung eingesetzt werden, um besonders gefährliche Stories in einem Backlog auszumachen. Die Stimme der Experten im DevTeam müssen ein Gewicht für die strategische Entwicklung des Produkts bekommen. Umso wichtiger ist es daher, dass Estimation Meetings regelmäßig durchgeführt werden.

Schnelles Feedback durch End-User

Plan – Do – Check – Adapt: der Regelkreis der Qualitätssicherung nach William E. Deming ist die Grundlage kontinuierlicher Verbesserungsprozesse und die Hintergrundmusik von Scrum. In Scrum führen wir jedes dieser Elemente in Form von Arbeits-Meetings aus, denn Qualität ist die Grundlage der Risikominimierung.
Risiken sind wahrscheinlich eintretende Fehler. Um zu erkennen, ob ein Risiko eingetreten ist, müssen wir schnell und regelmäßig die Ergebnisse unserer Arbeit prüfen. Dazu brauchen wir Feedback vom Kunden und von End-Usern, die das Produkt einsetzen. Das Feedback holen wir am Ende eines Sprints im Review ein. Hier inspizieren wir die neuen Funktionen und verifizieren, ob wir das richtige Produkt gebaut haben. Wir verifizieren also nicht nur: “Läuft das Ding?” – nein, wir prüfen/validieren, ob es auch so läuft, wie es ursprünglich gewünscht war.
Konkret ist das Review der Zeitpunkt, an dem das DevTeam wieder mit dem End-User zusammenkommt. Hier tanken die Beteiligten Wertschätzung und Motivation für die eigene Arbeit, tauschen sich über den Nutzen der Funktionen aus und lernen, einander besser zu verstehen. Meines Erachtens lassen sich viele Risiken bei der Zusammenarbeit alleine dadurch auflösen, dass man Menschen zum einen zusammenbringt und dem Gegenüber ein Gesicht gibt, und zum anderen ein Ergebnis schafft, über das diskutiert werden kann.
Abstrakt gesehen führt uns das Review dazu, dass wir unsere Ergebnisse sichtbar und greifbar machen. Wir schaffen anschauliche Fakten, die eine konkrete Diskussion zulassen. Wir unterstützen das Verstehen der Beteiligten mit einer gemeinsamen Grundlage und erden das theoretische Verständnis durch praktisches Erfassen.
Das Review zeigt uns Folgendes frühzeitig auf: Große Empörung = frühes Scheitern, frühes Erkennen von Fehlern. Und auch frühe Erfolge mit und ohne Scheitern. Denn Scheitern und Fehler sind Entdeckungen, die wir im Vorfeld nicht erkennen konnten. Oft erkennen wir erst durch die neuerlangten Ergebnisse den nächsten Schritt für unser Produkt.

Potentially Shippable Increment

Besonders bei Neuentwicklungen steckt ein großer Teil der Arbeit bei klassischen Projekten in der Planungs- bzw. Erfindungsphase. Wieviel unnötig dokumentiert und wieviel Information auf Halde produziert wird, lässt sich oft nicht sagen. Solange kein Ergebnis im Sinne eines Produkts fertiggestellt wird, bleibt der geschaffene Wert von Dokumentation und Information unsichtbar. Darüber hinaus besteht die Gefahr, dass zu viel Dokumentation und Information gesammelt wird und dabei hohe Kosten ohne direkten Gegenwert entstehen. Seth Godin schreibt in seinem Buch Tribes dazu:  “The safer you play your plans for the future, the riskier it actually is.”
Priorisierung, kurze Sprints und dazu ein Potentially Shippable Increment am Ende jedes Sprints (Deliver every Sprint) helfen uns sehr, solche Risiken zu minimieren. Wir bekommen in jedem Sprint lauffähige, anwendbare Software, die Features mit dem höchsten Business Value liefert. Im Fall eines Projektabbruchs ist unsere Software lauffähig und kann eingesetzt werden. Funktionen sind durch alle Schichten hindurch implementiert und funktionsfähig. Wir können bspw. auch, sobald die wichtigsten Funktionen implementiert sind, die Entwicklung einstellen oder unmittelbar umschwenken. Dazu ist es wichtig, sich während des Sprints zu fokussieren. D. h., liefere Story für Story nach Business Value. Dadurch erhält man nach jedem Sprint ein System in einem lauffähigen Zustand.
“Liefere jeden Sprint” heißt auch, dass wir tatsächlich eine niedrige Time to Market haben und kurzfristig unser Produkt an neuen Kundenwünschen ausrichten können. Wir bekommen die Flexibilität, die wir benötigen und das bei konstanten Kosten. Zusätzlich können die End-User das Produkt frühzeitig nutzen, was wiederum auf die finanzielle Risikominimierung einzahlt.

Fazit

Die agile Produktentwicklung ist ein Baukasten, der stark darauf ausgerichtet ist, die Wahrscheinlichkeit von Fehlern bzw. Gefahren (Risiken) zu minimieren. Genauer gesagt haben wir damit einen Prozess für aktives Risikomanagement. Die Wahrnehmung von Risiken hängt sehr stark am Faktor der Empörung, der für die verbundenen Gefahren entstanden ist. Dazu kommt die Wahrscheinlichkeit, mit der ein Fehler eintritt, der die Gefahr auslöst.
Scrum trägt dazu bei, Fehler frühzeitig zu erkennen und wertvolle Ergebnisse zu schaffen. Erreicht wird das dadurch, dass frühzeitig Ergebnisse geschaffen werden, Unsichtbares visualisiert wird, Empörung an den wichtigen Stellen verstärkt wird und wichtige Erkenntnisse von Experten frühzeitig anhand von Fakten diskutiert werden. Denn komplexe Systeme benötigen ein Vorgehen, das Entscheidungen aufgrund von Fakten trifft. Mit Scrum haben wir zusätzlich eine Methode, die erfolgreich den Status Quo angreifen kann und uns dadurch überdurchschnittliche Gewinne beschert. Wenn wir in kurzen Zyklen Funktionen mit Produktreife liefern und unsere Ergebnisse verifizieren, vermeiden wir Fehler und wandeln Risiken in Wettbewerbsvorteile um. Und das alleine durch entschiedenes Handeln. In jedem Management-Magazin der letzten Jahre wird empfohlen: Lassen Sie sich auf Experimente ein und versuchen Sie, durch schnelle Erfolge oder schnelles Scheitern zu lernen. Scrum hilft dabei, diese Experiment durchzuführen. Experiment und Scrum bieten Rahmen und Raum, den Menschen benötigen, um effektiv zu arbeiten und setzen die notwendigen Kontrollpunkte, um Risiken zu minimieren. Viel Erfolg!

Brainstorming: Können wir ja alle … Wirklich?

Was ist das Erste, was uns allen einfällt, wenn wir im Team ein Thema angehen wollen, ein Problem lösen müssen? Versammeln wir uns doch mal im Besprechungsraum ums Flipchart und machen wir ein Brainstorming!
Jeder von uns hat es bestimmt schon unzählige Male gemacht – ich traue mich zu wetten, dass es 95% von uns meistens falsch gemacht haben. Und genau deshalb möchte ich zusammenfassen, wie es richtig gemacht wird. Denn das Brainstorming ist die einfachste und am meistgenutzte Möglichkeit, um kreativ(e) Lösungen für Probleme zu finden.

1. (und wichtigste) Regel: Raus mit der Sprache – Denk- und Sprechverbote waren gestern

Kommen euch folgende Sätze beim Brainstorming bekannt vor?

Und der absolute Dauerbrenner, einfach aber wirkungsvoll:

Diese Liste ließe sich schier endlos fortsetzen und auch noch um Mimik, Gestik und sonstige Zweifels- und Missfallensbekundungen ergänzen, die ähnliche Inhalte transportieren (Augen verdrehen, laut hörbar seufzen, anderen bedeutungsvolle Blicke im Stil von „so ein Schwachsinn“ zuwerfen, etc.). Das alles sind absolute Killer, die bewirken, dass der damit in „realistische Schranken“ gewiesene Brainstormer in seiner Kreativität blockiert wird. Erstens, weil er das Gefühl bekommt, dass seine Beiträge sowieso nicht angenommen werden, und zweitens, weil die Gedanken zum abgewürgten Input in seinem Gehirn endlose Kreise ziehen und damit neue Gedanken keinen Platz haben (so ungefähr wie: „Denk jetzt nicht an einen rosa Elefanten!“).
Wenn jeder Gedanke – egal ob er im Ergebnis als brauchbar in die Lösung mit einfließt, oder nicht – vorbehaltlos geäußert werden kann, ohne von den anderen bewertet oder gar abgewertet zu werden, dann ist er zumindest aus dem Kopf draußen und kann neuen kreativen Gedanken Platz machen. Macht euch daher vor jedem Brainstorming bewusst, dass ihr damit „nur“ eine erste Ideensammlung schafft, die ihr im Entstehungsprozess noch nicht an Machbarkeitskriterien messen müsst. Diese Ideensammlung werdet ihr in der Auswertung ohnedies noch clustern, ranken und Überlegungen zur Umsetzbarkeit unterziehen.
Und manchmal sind es genau die auf den ersten Blick völlig phantastisch erscheinenden Ideen, die – weiter gedacht, modifiziert und an die realen Umstände angepasst – im Ergebnis zur Lösung beitragen. Wollt ihr euch selbst um diesen wunderbaren, verheißungsvollen, ursuppenartigen Ideenpool bringen? Nein! Das wollt ihr nicht!

2. Regel: Ideenklau erwünscht

In unserer guten Kinderstube haben wir gelernt, dass man niemals die Ideen anderer Leute klaut und als die eigenen verkauft. Auch im Berufsleben haben wir uns schon mal die Nase gestoßen, wenn uns so etwas doch einmal unglücklicherweise passiert ist und der Ideenbeklaute dahintergekommen ist. Spätestens seit WWW und Intellectual Property Themen in aller Munde ist uns klar: geistiges Eigentum klauen ist gaaaaanz pfui (und kann auch noch ziemlich teuer werden)!
Fürs Brainstorming bitte wieder 180 Grad umdenken. Hier ist Ideenklau erwünscht.
Was meine ich damit? Damit meine ich, dass es beim Brainstorming ideal ist, auch auf den Inputs der anderen aufzubauen, sie weiter zu entwickeln, sie in einen anderen Rahmen zu setzen, etwas wegzunehmen hier, etwas hinzuzufügen dort, … Daraus kann im Idealfall in eurem Team eine starke kreative Dynamik entstehen, bei der eure Ideen nur so sprudeln. Und genau das ist es ja, was ihr wollt.
Damit das auch gut umgesetzt werden kann, platziert die bereits gesammelten Brainstorming-Inputs so, dass sie immer für alle Brainstormer gut sichtbar sind.

3. Regel: Wo die Depression am tiefsten, ist der Höhenflug am nächsten

Erfahrungsgemäß ist es so, dass irgendwann beim Brainstorming der Punkt kommt, an dem die Ideen versiegen. Wenn wir das merken, hören wir auf.
Mööööp.
Erfahrungsgemäß gibt es einen Punkt, an dem die Ideen vorübergehend versiegen. Die „Depression“. Hier bitte noch nicht zusammenpacken, Kaffee holen gehen und wieder jeder vor den eigenen Computer setzen. Denn wenn ihr dieses etwas unangenehme Schweigen der Ideen gemeinsam durchtaucht, kommt danach zumeist noch ein letzter kreativer Höhenflug, bei dem ihr noch einmal äußerst spannende Inputs sammeln könnt.

4. Regel: Abwechseln beim Schreiben am Flipchart

Ja, ich weiß.
Wir alle lieben es, beim Flipchart zu stehen und zu schreiben. Deshalb finden wir auch immer die wunderbarsten Ausreden, warum wir das nicht müssen – hier die fünf beliebtesten:

Beim Brainstorming ist es jedoch wichtig, dass nicht immer nur ein Teammitglied am Flipchart schreibt (auch wenn es jenes mit der schönsten Schrift ist oder zumindest jenes, das sich am wenigsten wehrt).
Warum? Weil man es trotz aller Multitasking-Fähigkeit als Schreiber einfach nicht schafft, alle auf einen einprasselnden Wortspenden (einigermaßen leserlich…) aufs Flipchart zu bannen und gleichzeitig selbst kreative Ideen zu entwickeln. Daher löst immer mal wieder die Schreiber ab, damit auch sie eine Chance bekommen, am kreativen Prozess teilzunehmen.

Variante mit Moderationskarten

Oft wird auch eine Variante des Brainstormings genutzt, bei der alle Brainstormer zu Beginn für sich ihre Ideen auf Moderationskarten schreiben. Das ist wunderbar, aber bringt euch damit nicht um den dynamischen, kreativen Prozess des gemeinsamen Brainstormings (siehe auch 2. Regel: Ideenklau erwünscht)! Das heißt: habt ihr einmal die Karten gesammelt und aufgepinnt, dann macht auch noch mal eine Runde gemeinsames Live-Brainstorming.

Beim nächsten Brainstorming daher beachten 

0. Regel: Zeitrahmen festlegen (ca 20 – 30 Minuten) und alle Regeln zu Beginn des Brainstormings kurz kommunizieren

  1. Regel: Denk- und Sprechverbote ade und raus beim Mund mit allem, was im Kopf herumschwirrt
  2. Regel: Ideenklau erwünscht
  3. Regel: „Depression“ durchtauchen für den letzten Höhenflug
  4. Regel: Abwechseln beim Schreiben am Flipchart

Probiert es doch aus und lasst mir bei Lust und Laune ein paar Kommentare hier, wie es euch damit gegangen ist!
Und zum Abschluss möchte ich noch mein persönliches Credo und damit sozusagen die hier 5. Regel festhalten: Arbeit darf auch Spaß machen. Spaß macht kreativ und Kreativität findet neue Lösungen!

Schätztauchen

In dem Boot auf dem Roten Meer in Ägypten, kurz vor meinem allerersten Tauchgang, habe ich nicht mit meinem Tauchlehrer diskutiert, ob es die richtige Methode ist, auf die Innenseite der Taucherbrille zu spucken und meinen Speichel zu verteilen. Damit sie nicht beschlägt, während ich mich in 25 m Tiefe befinde und ich dann blind herumschwimme. Mein Tauchlehrer hat lediglich die kurze Anleitung gegeben, ist abgetaucht und … ich habs einfach gemacht.

Warum?

Er ist der Profi, also könnte es funktionieren. Der potentielle Diskussionspartner schwieg sowieso unter der Wasseroberfläche und Zeichensprache kann ich nicht so besonders gut. Die Zeit war knapp und ich beschloss, eben diese für den eigentlichen Tauchgang zu nutzen und ihn später zur Rechenschaft zu ziehen.
Zehn Jahre später befinde ich mich als Consultant von bor!sgloger auf einem anderen Schiff, in einer interessanten Projektsituation:
Wir haben 15 Minuten pro Scrum-Team, um mit ihnen ihr erstes Estimation Meeting durchzuführen. In Anbetracht der Zeit(-Not) bat ich das Team, mir zu vertrauen und in den nächsten 13 Minuten (2 Minuten waren schon aufgrund einer knappen, aber herzlichen Begrüßung und Vorstellung vergangen) zu schweigen und sich auf das Magic Estimation Meeting einzulassen.
“Ich verspreche, euch nach dem Meeting, in den kommenden Tagen zu JEDER Frage, JEDER Skepsis, JEDER Kritik bzgl. unserer Art und Weise zu schätzen, Rede und Antwort zu stehen. Wenn wir uns in den nächsten 12 Minuten einfach darauf einlassen und… einfach machen.
1 heißt User Story ist klein
2 User Story ist doppelt so groß
3 User Story ist wie 1 & 2
Fibonacci eben.
Die 13 sollte quasi euer Sprint-Limit darstellen und bei der 20 ist die User Story nicht “Sprint-Ready”, sprich zu groß und/oder komplex und/oder hat zu viele Features etc.
Euer Product Owner verteilt nun die User Stories, jeder schätzt die User Story, die er soeben erhalten hat und legt sie an die entsprechenden Storypoints.
Im Anschluss seht ihr euch die von euren Teamkollegen geschätzte User Stories an und schätzt ab, ob sie mit eurem Bauchgefühl d’accord gehen. Wenn ja – einfach liegen lassen und falls nein – einfach umlegen. Er darf es selbstverständlich zurücklegen. Nach dem dritten Mal wird die User Story aus dieser Runde herausgenommen und ist somit JETZT nicht mehr relevant.
Vielleicht wisst ihr von einem Teamkollegen, dass er mit dem Feature bzw. dem Thema einer User Story Erfahrung hat, und vertraut ihm bei seiner Schätzung.    
Das einzige Instrument, das ihr nun braucht, ist euer Bauch. Beruhigt ihn damit, dass ihr mich in den nächsten Tagen auf ein heißen Stuhl setzen dürft.
Wir haben nun noch 10 Minuten – also: Ab geht`s!
Grinsen, Stirnrunzeln und ein letztes “der ganz heiße Stuhl… hihi” – und es wird geschätzt.
Bei allen drei Teams, die ich in den nächsten 45 Minuten betreut habe, hat es tatsächlich ohne Probleme funktioniert. Aber warum? Warum wird das Schätzen immer wieder thematisiert und so gern stundenlang diskutiert?
Weil die Zeit dafür “da” ist.
Selbstverständlich habe ich in den nächsten Tagen viele Gespräche geführt und Erklärungen geliefert. Sehr oft habe ich dasselbe in verschiedenen Formulierungen und Beispielen beschrieben, den hervorragenden Blog meiner Kollegin Klessmann verteilt, und habe sogar mit Müll geschätzt. (Die Putzkolonne hatte aufgeräumt, es standen verschiedene volle, blaue Müllsäcke und diverse Pappkartons herum … Doing as a way of recycling. True story.) Wenn wir keine Zeit haben, uns mit etwas genauer zu beschäftigen, fällt es uns Menschen doch wesentlich einfacher zu vertrauen, intuitiv Entscheidungen zu fällen und unseren Bauch gewähren zu lassen.

Natürlich werde ich weiterhin Erklärungen und Fragen zu unseren Methoden liefern. Die erste Erkenntnis hinkt jedoch oft dem Vertrauen und dem Tun hinterher. Die kleinen Verbesserungen kommen dann ganz von allein:

Ich schätze was, das du nicht schätzt …

… und das ist …

zumindest mal ein Dauerbrenner in der agilen Softwareentwicklung.

… zählbar

Oft stehe ich vor Teams und Entwicklern, die in ihrer Vergangenheit nicht die besten Erfahrungen mit dem Schätzen gemacht haben. Noch immer hat aber die Verknüpfung von Implementierung und zeitlichem Aufwand die Vorherrschaft. Meistens versuche ich zunächst, diese Verknüpfung in Frage zu stellen. Und zwar indem ich ihnen anbiete, nicht die Zeit für die Implementierung oder die Komplexität der Umsetzung, sondern einfach nur die Funktionalitäten zu schätzen, die in einer Story stecken. Ohne dabei die Dimension Zeit zu betrachten. Sie sollen die Story so nehmen, wie sie gerade ist – mit allen Unsicherheiten und sie sollen einfach mal betrachten, was nach ihrem Verständnis für den User an Funktionalität geboten wird.
Um es deutlicher zu machen, greife ich als Beispiel eine Story heraus, die in einem der nächsten Sprints umgesetzt werden soll und daher schon relativ detailliert beschrieben und verstanden ist. Dann lasse ich jemanden aus dem Team aufzählen, welche