5Ein Gefühl der Dringlichkeit erzeugen

Wenn ein Unternehmen erfolgreich am Markt agiert, so baut es sich über die Jahre einenFundus an Prozessen, Strukturen und Vorschriften auf. Diese sind zum Zeitpunkt ihrerEinführung in der Regel sehr sinnvoll und hilfreich für die Organisation. Häufig lässt derNutzen mit der Zeit aber nach, da die Welt sich – insbesondere in unserem heutigen glo-balisierten und schnelllebigen Umfeld – verändert, die Prozesse aber starr bleiben. WennSie IhreMitarbeiter über den gefühlten Nutzen der vorhandenen Prozesse, Strukturen undVorschriften befragen, so werden Sie vermutlich feststellen, dass diese als Belastung undnicht als Unterstützung empfunden werden. Beweisen lässt sich dies – gerade bei Prozes-sen außerhalb der Produktion – leicht mit Wertstrom-Analysen1. Auf der anderen Seitegeben diese Strukturen aber Halt und Sicherheit. Jeder Mitarbeiter weiß genau, wo er sichimGesamtgefüge befindet, was seinMacht- und Einflussbereich ist.Wenn Sie tief greifendeVeränderungen umsetzenwollen, greifen Sie direkt das Sicherheitsbedürfnis derMenschenan. Maslow hat in seiner „Bedürfnispyramide“ deutlich gezeigt, dass „Sicherheit“ in derWichtigkeit für jeden Einzelnen gleich nach „physiologischen Bedürfnissen“ kommt unddamit weit entfernt von „Individualbedürfnissen“ und „Selbstverwirklichung“ steht. Sieerschüttern dieMitarbeiter also in ihrenGrundfesten. Entsprechendwerden Sie aufWider-stand treffen, der Ihren Veränderungsprozess scheitern lassen kann, noch bevor Sie richtigbegonnen haben. Sie müssen daher ein Gefühl der Dringlichkeit erzeugen, das von allenBetroffenen wahrgenommen wird und Ihr Änderungsvorhaben nicht nur als gerechtfer-tigt, sondern für das Überleben notwendig erscheinen lässt. Kurz: Machen Sie die Krisedeutlich, die IhremVeränderungswunsch zugrunde liegt. Bei kleinen Veränderungen kannes sein, dass es nicht um das Überleben des Unternehmens geht – meist geht es aber trotz-dem umdie Profitabilität und damit langfristig um dieWettbewerbsfähigkeit. Es gibt einen

1 In einer Wertstromanalyse führen Sie zunächst alle Prozessschritte auf, ergänzen Ein- und Aus-gangsgrößen, teilen sie in wertschöpfende, unterstützende sowie verschwendende Schritte auf undmessen die Durchlaufzeiten. Ziel ist es, die unterstützenden Prozesse zu minimieren und die ver-schwendenden auszuschalten.

27D. Maximini, Scrum - Einführung in der Unternehmenspraxis,DOI 10.1007/978-3-642-34823-5_5,© Springer-Verlag Berlin Heidelberg 2013

28 5 Ein Gefühl der Dringlichkeit erzeugen

Grund dafür, dass Sie die von Ihnen angestrebte Veränderung wollen. Machen Sie diesensichtbar.

BeispielBei einemmeiner Kunden fand ich eine verheerende Situation vor: Die entwickelte Soft-ware hatte keine nennenswerte Qualität, da nicht einmal ansatzweise getestet wurde.Teilweise starteten die Applikationen nach Auslieferung bei keinem einzigen Kunden –ein Problem, das man mit einem einfachen Start des Programms vor Auslieferung hät-te feststellen können. Die Entwicklungsumgebung war für die Größe der Organisationnicht geeignet (die Integration des Codes war beispielsweise nicht möglich) und dieMitarbeiter waren teilweise nicht für ihre Aufgaben qualifiziert (sowohl fachlich alsauch technisch). Trotzdem sah das Unternehmen keine Notwendigkeit, sich zu ver-ändern. Dies rührte von einer allgemeinen „In der Vergangenheit waren wir auch soerfolgreich“-Mentalität her, die von einer Kultur unterstützt wurde, in der man keineFehler zugab und schlechteNachrichten nicht offen nach oben kommunizierte. DieMa-nagementpräsentationen zeigten immer, dass die Softwareentwicklung gute Ergebnisseerzielte, denn es wurde ausschließlich „grün“ berichtet, ohne auf Probleme einzugehen.Diese waren daher lange kein Thema in diesen Gremien. Erst als ich zusammen miteinem der Product Owner und den Scrum Mastern anfing, mittels einer Impediment-Tiefenanalyse konkrete Daten darüber zu sammeln, wie viel Zeit sinnlos verschwendetwurde (es waren damals 80%) und offen zeigte, dass wir keinerlei Aussage darüber tref-fen konnten, ob die entwickelten Funktionen überhaupt beim Kunden liefen, begannenalle Beteiligten ihre Verhaltensweisen zu ändern. Wir hatten ein Gefühl der Dringlich-keit erzeugt.

Suchen Sie sich keine abstrakten Probleme. Die Realität ist meistens voll von gut geeig-neten, schwer wiegendenMissständen. Fragen Sie so viele Personenwie möglich, was ihrerMeinung nach ein Risiko darstellt oder bereits schief läuft. Achten Sie dabei darauf, dassalle Informationen vertraulich behandelt werden und nicht auf einzelne Personen negativzurückfallen können. Vermeiden Sie Beschönigungen. Erlauben Sie sich, in die Vogelper-spektive zu wechseln und Ihre bisherige Denkweise zu erweitern. Seien Sie schonungslosehrlich zu sich selbst und allen Beteiligten. Machen Sie die vorhandene Krise deutlichsichtbar.Wählen Sie dabei eine einfache, spezifische und eher bildhafte Sprache, keine kom-plizierten Fachbegriffe. Vergleichen Sie diese beiden Aussagen:

• Durch die geringe Qualität unserer Software haben wir eine Innovationsrate von 30%.Die restliche Zeit verbringen wir mit dem Fixen von Bugs.

• Unsere Software ist Müll. Wir bauen so viele Fehler ein, dass wir jeden Monat für 3 Mil-lionen Euro Reparaturen durchführen müssen.

Urteilen Sie selbst:Welche dieser Aussagenwird eher dieAufmerksamkeit der Entschei-der auf sich ziehen?

5.1 Die Impediment-Tiefenanalyse 29

Manchmal ist es nicht einfach, konkrete Zahlen zu präsentieren. Dies ist aber meistnotwendig, um ein Gefühl der Dringlichkeit zu erzeugen. Egal ob es in Ihrem Fall umMarktanteile, Zeit, Kosten oder etwas anderes geht: Es hilft immer, Zahlen nennen zu kön-nen. Auch im Kontext einer Scrumeinführung ist dies wichtig. Häufig treffen Sie auf einenProzess, der vom Unternehmen Scrum genannt wird, aber dies de facto nicht ist. Trotz-dem können Sie sich dort die Mechanismen und Metriken von Scrum zu Nutze machen.Manchmal reicht die Velocity, um zu demonstrieren, wie produktiv ein Team ist.

Im Folgenden finden Sie zwei Werkzeuge, die Sie mit bestehenden Scrum-Teams (z. B.Pilotteams oder während einer bereits begonnenen Transition zu Scrum) einsetzen kön-nen.

5.1 Die Impediment-Tiefenanalyse

Dieses Vorgehen ist entstanden, als bei einem schwierigen Projekt einer der ProductOwnerzu mir kam und wissen wollte, warum sein Team gefühlt so unproduktiv sei. Er wollte ge-naue Zahlen, wie viel Zeit für welche Tätigkeit aufgewendet wurde. Wir wollten aber beidekeine Zeiterfassung einführen oder das Team durch aufwändigeMethodenweiter belasten.Mein Product Owner schlug vor, die Zeit nach bestimmten Kategorien zu schätzen. Darausentwickelte sich die Impediment2-Tiefenanalyse:

1. Rufen Sie Ihr Team zu einer Retrospektive zusammen.2. Geben Sie ein paar Hauptkategorien vor (z. B. Bugfixing, Meetings, Hilfe für Kollegen

anderer Teams, manuelles Testen usw.) und stellen Sie klar, dass dies nur Vorschlägesind, die jederzeit vom Team ergänzt werden können. Es macht Sinn, die Kategorienanhand der Beobachtung des ScrumMasters oder von Ihnen selbst vorzubereiten.

3. Machen Sie den Teilnehmern klar, dass es sich nicht um eine normale Retrospektive,sondern um eine Tiefenanalyse der Impediments handelt. Das bedeutet, dass auch dieProbleme auf den Tisch müssen, an die man sich schon längst gewöhnt hat. Zum Bei-spiel langsame Antwortzeiten von Servern o. ä.

4. Lassen Sie dann jeden für sich fünf Minuten lang Impediments aufschreiben, die imvergangenen Sprint Zeit gekostet haben. Die verschwendete Zeit wird noch nicht ge-schätzt. Unterhaltungen sind hier nicht erlaubt.

5. Lassen Sie das Team die Ergebnisse zusammentragen, erläutern und gruppieren.6. Bilden Sie, wenn nötig, neue Hauptkategorien.7. Führen Sie eine Brainstorming-Runde imTeamdurch, in der weitere Impediments auf-

gedeckt werden sollen.

2 „Impediment“ ist ein Scrum-Begriff. Er bedeutet soviel wie „Problem, das den Projektfortschrittaufhält“.

30 5 Ein Gefühl der Dringlichkeit erzeugen

8. Lassen Sie die benötigte Zeit für jeden einzelnen Punkt durch das Team schätzen. Ichnehme dazu normalerweise Planning Poker3, damit auch stillere Kollegen gehört wer-den.

9. Summieren Sie die Einzelpunkte jeweils auf der Ebene der Kategorien auf.10. Ermitteln Sie anhand der Schätzungen der Tasks des vergangenen Sprints, wie viel Zeit

das Team vermutlich in produktive Arbeiten investiert hat.11. Die Summe der Impediments und der geleisteten Arbeit müssten zusammen annä-

hernd 100% der Verfügbarkeit des gesamten Teams ergeben. Liegt ihre Schätzung über110% prüfen Sie, ob bei den Impediments Punkte doppelt geschätzt wurden (beispiels-weise ein Unterpunkt „RC Phase“ und zusätzlich die Hauptkategorie „manuelles Tes-ten“). Landet die Summe bei weniger als 85% sollten Sie Ihr Team dazu anhalten, dieverlorene Zeit zu finden.

12. Greifen Sie sich jetzt die Hauptkategorie heraus, in der die meiste Zeit verloren geht.Hier können Sie mit Ihrem Team Verbesserungsmaßnahmen definieren. Gleichzeitigkönnen Sie jetzt mit konkreten Zahlen belegen, dass hier ein Problem vorliegt.

Dieses Vorgehen funktioniert dann besonders gut, wenn Ihr Team schon eingespielt ist4

und Ihnen vertraut. Fehlt dieses Vertrauen, so besteht die Gefahr, dass die Entwickler sichnicht trauen, Probleme offen auszusprechen. Achten Sie besonders darauf, dass auch dieDinge auf den Tisch kommen, an die man sich bereits gewöhnt hat. Diese machen häu-fig die weit größeren Probleme aus, als herausstechende singuläre Ereignisse eines Sprints.Ihre Glaubwürdigkeit erlangt die Methode dadurch, dass die Gegenprobe anhand der ge-leisteten Arbeit erfolgt. Das erfordert, dass Ihr Sprint Backlog gut gepflegt ist. Es reicht,die Schätzungen der Tasks heranzuziehen – Ungenauigkeiten gleichen sich normalerweiseüber die Summe der Tasks wieder aus.

5.2 Velocity-Extrapolation

Die Velocity-Extrapolation ist etwas, das jeder Product Owner sowieso tun sollte. In Or-ganisationen, die Fassaden-Scrum implementiert haben, fehlt diese wichtige Metrik aberoft. Die Velocity-Extrapolation ist nichts anderes als eine ehrliche Releaseplanung (sieheAbb. 5.1).

3 Planning Poker ist ein Verfahren zur Schätzung von Aufgaben. Normalerweise wird dabei relativgeschätzt. Man kann damit allerdings auch absolute Zahlen schätzen, was im vorliegenden Fall denVorteil hat, dass nicht eine dominante Person die Höhe der Werte über die Maßen beeinflusst. Auchregt dieses Vorgehen Diskussionen an. Mehr dazu finden Sie im vierten Teil dieses Buches. PlanningPoker® ist ein registriertes Warenzeichen von Mountain Goat Software, LLC.4 Ist Ihr Team noch nicht eingespielt, so sind normalerweise teaminterne Probleme so wichtig, dassSie nicht bis zu den Problemen der Organisation durchdringen. Auch macht eine mangelhafte Ver-trautheit mit der Organisation oder dem Projekt es manchmal schwer, echte Probleme aufzudecken.

5.2 Velocity-Extrapolation 31

0

20

40

60

80

100

120

1 2 3 4 5 6 7 8 9 10 11

Zeit / Monate

gemesseneVelocity = 10

erwarteteVelocity = 25

Abb. 5.1 Realistische Zeit bis zur Fertigstellung aller Features

1. Der Product Owner entscheidet, wann ein Release ausgeliefert wird und was darin aus-gehend von der aktuellen Velocity des Teams enthalten sein soll.

2. Der Product Owner lässt alle entsprechend benötigten Anforderungen (Product Back-log Items) durch das Team schätzen.

3. Die Kosten (Zeit) für das Release lassen sich so exakt dem erwarteten Nutzen (Features)gegenüberstellen.

Allein diese Transparenz führt oft zu Erstaunen bei den Beteiligten. Schließlich stehtim Projektplan etwas ganz anderes. Zumindest viel mehr. Theorie und Praxis passen nichtmehr zusammen und führen zu Überlegungen, ob unter diesen Umständen die Kosten fürdie Produktentwicklung noch gerechtfertigt sind.

BeispielIn einem von mir betreuten Unternehmen wurden die Releasepläne meist mit Magie(zumindest nicht mit empirischen Daten) erstellt. Der Ärger war am Ende der Releaseszwar immer groß darüber, dass wieder nicht alles umgesetzt worden war, jedoch trugdies nicht zu einer Veränderung des Verhaltens bei. Erst als ich alle für die Releasepla-nung verantwortlichen Personen an einen Tisch holte und sie mit den realen Zahlender Teamgeschwindigkeiten konfrontierte, setzte ein Umdenken ein. Trotzdem dauertees noch drei Monate, bis dieser Personenkreis in den „Krisenmodus“ schaltete und dasTop-Management darüber informierte, dass die geplanten Ziele nicht erreicht werdenwürden. Erst ab diesemZeitpunkt existierte einDringlichkeitsgefühl unddasUnterneh-

32 5 Ein Gefühl der Dringlichkeit erzeugen

men konnte offen darüber nachdenken,mit welchenMaßnahmen dieKrise abgewendetwerden und wie solche Situationen auch in Zukunft vermieden werden konnten.

5.3 Allgemeine Hinweise zur Erzeugung der Dringlichkeit

Egal ob bereits eine Form von Scrum eingeführt ist oder nicht, benötigen Sie Zahlen, dieeine Dringlichkeit erzeugen. Lassen Sie eine Krise im Bewusstsein der Beteiligten entste-hen5 bzw.machen Sie eine ignorierte Krise transparent. Bleiben Sie dabei glaubwürdig. Daskann auch bedeuten, dass Privilegien bestimmter Personenkreise abgeschafft werdenmüs-sen, da diese nicht zur Krise passen.Wenn es eine Krise gibt, müssen alle Betroffenen auchentsprechend handeln! In einer existenzbedrohenden Krise ist es zum Beispiel nicht ange-bracht, mit dem Firmenjet zu fliegen, sondern ein Bahnticket zweiter Klasse tut es auch.Um aus Krisen auszubrechen, reichen auch keine normalen Zielvorgaben – wäre das an-ders, hätten die Ziele der Vergangenheit das Unternehmen ja besser geleitet. Setzen Sie dieZiele so hoch an, dass sie mit normalem Arbeitseinsatz nicht zu erreichen sind, sonderndass sie außergewöhnlichen Einsatz und kreative Lösungen erfordern. Sorgen Sie außer-dem dafür, dass im ganzen Unternehmen keine persönlichen, sondern nur noch auf denGesamterfolg bezogene Ziele eingesetzt werden. So sitzen alle im selben Boot.

Sorgen Sie dafür, dass die Mitarbeiter sich mit unzufriedenen Kunden, Aktionärenund Lieferanten auseinandersetzen, damit entsprechende Probleme nicht ignoriert wer-den können. Kommunizieren Sie die Dringlichkeit auf allen nötigen Kanälen so oft wiemöglich. Vergessen Sie dabei nicht, die Chancen aufzuzeigen, die eine Veränderung bietenwürde. Scrum ist ein exzellentes Werkzeug, um so ein Gefühl der Dringlichkeit zu er-zeugen: In jeder Retrospektive und jedem Planning kann auf die Krise Bezug genommenwerden. Außerdem können die durch die Teams aufgezeigten Impediments Probleme sehrschnell transparent machen. Auch eine Abnahme der Velocities6 kann zur Erzeugung vonDringlichkeit beitragen.

Je nachdem, was genau Sie erreichen wollen, variiert natürlich die Ausprägung derDringlichkeit. Wenn Ihr Scrum-Team bessere Code-Qualität produzieren soll, macht eskeinen Sinn, Ferienreisen auf Firmenkosten abzuschaffen. Wenn auch wünschenswert, sohilft es doch nichts, wenn das Marketing seine persönlichen Ziele gegen Unternehmens-ziele tauscht. Wichtig ist hier lediglich, dass das Team die Dringlichkeit erkennt und dasManagement (bzw. der Product Owner) entsprechend Zeit bereitstellt.

Anders sieht es aus, wenn das gesamte Unternehmen auf Scrum umgestellt werden soll:Dann müssen auch die Personalabteilung, das Top-Management und alle anderen Abtei-

5 Das bedeutet nicht, dass Sie eine künstliche Krise schaffen sollen, sondern lediglich, dass Sie eszulassen, dass eine bestehendeKrise an dieOberfläche und in das Bewusstsein der Beteiligten gelangt.6 Die „Velocity“ bezeichnet die Geschwindigkeit, mit der ein ScrumTeamKundennutzenproduziert.Dabei wird nicht die gearbeitete Zeit gemessen, sondern die relative Größe der für den Kunden re-levanten Arbeiten gezählt. Halb fertige Features, Bugfixes und stützende Aufgaben zählen nicht zurVelocity dazu.

5.4 Das sollten Sie sichmerken 33

lungen an einem Strang ziehen. Das werden sie nur dann tun, wenn Ihnen die Dringlich-keit entsprechend bewusst ist und eine Krise droht. Machen Sie allen Beteiligten bewusst,warum der Wechsel zu Scrum so wichtig für das Unternehmen ist.

Wahren Sie die Verhältnismäßigkeit. Im Zweifel sollten Sie aber eher alle in diesem Ka-pitel genannten Punkte berücksichtigen, als durch unzureichende Vorbereitung Ihr Ziel zuverfehlen und dadurch eine für das Unternehmen notwendige Veränderung nicht umset-zen zu können.Wenn Sie es nicht schaffen, ein angemessenes Gefühl der Dringlichkeit beiden Betroffenen zu erzeugen, wird Ihre Veränderungsinitiative scheitern.

5.4 Das sollten Sie sich merken

Um ein Gefühl der Dringlichkeit im Zusammenhang mit einer Scrum-Einführung zu er-zeugen, sollten Sie wie folgt vorgehen:

1. Stellen Sie fest, wer aus welchen Gründen Scrum einführen (oder nicht einführen) will.2. Analysieren Sie die Situation des Unternehmens und die der Wettbewerber.3. Machen Sie die Situation Ihres Unternehmens transparent und zeigen Sie allen Beteilig-

ten die Dringlichkeit einer Veränderung auf.4. Analysieren Sie, was sich für das Unternehmen durch die Einführung von Scrum ver-

ändert.5. Analysieren Sie, was sich für jede Einzelperson durch die Einführung von Scrum ver-

ändert.6. Kommunizieren Sie allen Betroffenen, welche Chancen undRisiken in der Veränderung

liegen. Zeigen Sie jedem Einzelnen auf, was ein Beharren in den alten Prozessen für ihnoder sie bedeutet. Zeigen Sie außerdem, welche Chancen für jeden Einzelnen in derVeränderung begründet liegen.

7. Leben Sie die Folgen der Dringlichkeit vor. Wenn es eine Krise gibt, müssen Sie sichauch so verhalten.

8. Sorgen Sie dafür, dass das Top-Management des Unternehmens die Dringlichkeit ver-steht und vorlebt. Alle Kommunikationsmaßnahmen sind wertlos, wenn das Manage-ment durch sein Verhalten Ihre Aussagen negiert.