Das Burndownchart: Erfolgsmesser und Analysewerkzeug

In einem Projekt saßen wir mit sechs ScrumMastern in einer Runde und diskutierten den Nutzen und das Führen eines Burndowncharts.
Es handelte sich um ein Projekt mit sechs Scrum-Teams und interessant dabei war, dass es erhebliche Unterschiede und Eigenkreationen in der Ausführung gab, die wir näher betrachteten. Einige ScrumMaster führten ihr Burndownchart auf Task-Ebene, einige auf Story-Ebene, beklagten aber, dass häufig kein Erfolg zu sehen sei und der Graph immer erst zum Ende eines Sprints abfalle. Es entstand eine spannende Diskussion mit fruchtbarem Ende.
Betrachten wir die beiden Beispiele näher und machen wir uns bewusst, was uns das Burndownchart zunächst einmal sagen soll:
Auf der horizontalen Achse finden wir die Sprinttage. Auf der vertikalen Achse finden wir die Anzahl der noch zu bearbeitenden Storypoints des aktuellen Sprints, die im Estimation Meeting geschätzt und im folgenden Sprint Planning 1 vom Entwicklungsteam committet, sprich als lieferbar zugesagt wurden.
Pro abgeschlossener Story kann im Sprint nun markiert werden, wie viele Storypoints noch zu bearbeiten sind. Im Normalfall ergibt sich so über den Sprint ein treppenförmiger Graph mit Abwärtstrend, der zum Sprintende oder auch schon vorher die horizontale Achse treffen sollte. Die Teammitglieder können so ihren Fortschritt auf einfache Art und Weise visualisieren.
Wie kann es nun im oben genannten Beispiel dazu kommen, dass sich der Graph in gewissen Fällen parallel zur horizontalen Achse bewegt und erst am Ende eines Sprints einen steilen Abfall nach unten macht, man also meinen könnte, es gäbe keinen Fortschritt?

First things first lautet doch die Devise. Wir arbeiten der Priorisierung nach eine Story nach der anderen ab. So ist die sinnige Idee.
In vielen Fällen wird jedoch über den gesamten Sprint gleichzeitig an mehreren Stories gearbeitet, was eigentlich nicht vorgesehen ist. Dadurch werden die Stories erst spät oder ganz zum Sprint-Ende abgeschlossen und man kann erst hier einen Erfolg ersichtlich machen. Auf die Frage, warum an mehreren Stories gearbeitet werde, sagte eine ScrumMasterin zu mir, es ginge nicht anders, da die Stories ja voneinander abhängig seien.
Das gibt einen Hinweis darauf, dass die Stories nicht der Abhängigkeit entsprechend im Backlog standen. Natürlich muss eine Story, die von einer anderen abhängig ist, weiter unten im Backlog stehen. Wir sehen also, dass das Burndownchart auch Analysezwecken dienen kann. In unserem Beispiel könnten wir also mit dem verantwortlichen Product Owner die Priorisierung des von ihm geführten Backlogs besprechen.
Ein zweiter, typischer Grund für ein Burndownchart, das erst zum Sprint-Ende abfällt, kann die Tatsache sein, dass eine/die Story/s schlichtweg so groß ist/sind, dass man den ganzen oder fast den ganzen Sprint an ihr/ihnen arbeitet. Das Risiko, nicht fertig zu werden, ist also zu groß. Wir können somit aus der Analyse des Charts lernen, dass unser Product Owner die Stories kleiner schneiden muss.
In beiden Beispielen zeigt sich also, dass das Burndownchart ein wunderbarer Indikator für die Priorisierung und Schätzung bzw die Größe der Stories ist.
Was bewegte nun den ScrumMaster, der das Burndownchart auf Taskebene führte? Auf diese Frage berichtete er, dass er täglich einen Erfolg sehen möchte, um mit gutem Gefühl nachhause zu gehen. Es störe ihn nämlich genau der zuerst beschriebene Fall, dass der Erfolg häufig gar nicht oder erst sehr spät zu sehen sei. Die Tatsache, dass er den Erfolg doch an den sich horizontal über das Taskboard bewegenden Tasks sehen kann und unsere Diskussion überzeugten ihn letztlich, das Burndownchart ebenso auf Story-Ebene zu führen. Tun wir dies nicht, stehen uns nämlich die beschriebenen Analysemöglichkeiten nicht zur Verfügung, zumal den Tasks ja keine Storypoints zugeordnet sind. Worauf sollte man also das Führen des Burndownchart dann basieren lassen?
In der beschriebenen Runde mit unseren ScrumMastern beschlossen wir, dass die Charts gesammelt an einer Wand im Büro aufgehängt werden, um so den Erfolg jedes einzelnen Teams transparent für alle zu machen und somit einen positiven Synergie- und Lerneffekt enstehen zu lassen.
Wenn wir nun zusammenfassen, sehen wir, welchen großen Sinn es macht, das Burndownchart auf Story-Ebene zu führen und dass es viel mehr ist, als nur eine visualisierte Information zum Fortschritt des aktuellen Sprints.

Wann ist ein ScrumMaster erfolgreich?

Woran erkennt man einen erfolgreichen ScrumMaster bzw. welche Kriterien könnten herangezogen werden, um einen ScrumMaster als erfolgreich zu bezeichnen
Ich selbst bezeichne mich als erfolgreichen ScrumMaster, wenn ich

In der Realität ist es etwas schwieriger, diese Vorhaben umzusetzen und somit als ScrumMaster erfolgreich zu sein. Es gibt immer wieder Teams, denen die Umstellung auf Scrum sehr schwer fällt und die neue Arbeitsweisen anfangs ablehnen.
In diesen Teams ist es umso wichtiger, einen ScrumMaster zu haben, der das Team an Scrum heranführt und den Sinn sowie den Zweck der Meetings, Artefakte und Rollen in Scrum dem Team näher bringt. Während sich dieses Vorgehen in der Theorie sehr einfach anhört, gibt es in der Realität Teams, die zu Meetings kommen und angeben, sie seien nur anwesend, “weil sie dazu ja gezwungen werden“. Diese Meetings verlaufen dann in etwa so: Die Teammitglieder sind demotiviert und geben dem ScrumMaster das Gefühl, dass sie dieses Meeting über sich ergehen lassen. Sie meckern bei jedem einzelnen Punkt gefühlte 20 Minuten, damit man auch ja weiß, dass sie keine Lust haben. In dem ganzen Unmut bin ich der ScrumMaster. Ich bin motiviert, ich glaube an mein Team und an mein Ziel. Ich weiß, dass ich es schaffe, das Team zu motivieren und anzuleiten um mitzumachen. Ich schaffe es, sie von den Vorteilen in Scrum zu überzeugen. Das sind mal Ambitionen. Leider vergehen diese, zwar nicht sofort, aber mit der Zeit, und das Team gibt einem auch noch das Gefühl, es hätte seine Sache doch gut gemacht. Das Team hat es schlussendlich doch geschafft, den ambitionierten ScrumMaster zu frustrieren.
In einem dieser Teams, bei dem ich glaubte, dass mein Tun einfach nichts weitergebracht hatte und nichts von dem angekommen war, was ich gesagt oder getan hatte, passierte etwas.
Ja, es passierte tatsächlich: Ich, der ScrumMaster, war erfolgreich. Nicht in dem Sinne wie ich mich persönlich als erfolgreich bezeichnet hätte, aber ich war es. In einer Diskussion zwischen dem Product Owner und der Geschäftsführung sagte der PO: “Ja, der ScrumMaster hat gesagt, wir sollen das so machen …“ Daraufhin mischte sich ein Teammitglied ein und sagte: “Der ScrumMaster hat so etwas nicht gesagt.“ Es war auch so gewesen: Ich, der ScrumMaster, hatte niemandem gesagt, wie er oder sie etwas zu tun hat – und das Team hat mich in Schutz genommen, vor dem Manager und dem PO. Ich hatte es geschafft! Es hatte sich etwas bewegt, ich war erfolgreich.
Wir ScrumMaster dürfen einfach nicht außer Acht lassen, was wirklich ein Erfolg ist und dieses unwillige und demotivierte Team hat mir gezeigt, was es heißt, erfolgreich zu sein. Ein ScrumMaster darf sich als sehr erfolgreich bezeichnen, wenn er es geschafft hat, dass sein Team hinter ihm steht. Ich habe es geschafft, mein Team steht hinter mir und es fühlt sich wirklich wirklich gut an.

Let's play a game

In einigen Organisationen beschleicht mich immer wieder das Gefühl, dass eines der Hauptziele des Managements die möglichst hundertprozentige Auslastung der Mitarbeiter ist. Ob diese Zeit wirklich sinnvoll für Projekte genutzt wird, ist in vielen Fällen zweitrangig. In Besprechungen, in denen diskutiert wird, wie die einzelnen Mitarbeiter für eine effiziente Auslastung zu Projekten zu „dispatchen“ sind, muss ich immer an folgende Melodie denken:

Ressourcen-Tetris

Als Kind konnte ich mich stundenlang mit Tetris beschäftigen und das Spiel fasziniert mich auch heute noch. Die Herausforderung besteht darin, verschiedenförmige Teile möglichst effizient zu vollständigen Reihen anzuordnen. Dieses Gefühl habe ich manchmal auch in den zuvor angesprochenen Meetings. Es wird versucht, verschiedene Mitarbeiter mit den unterschiedlichsten Kompetenzen so zwischen den Projekten zu drehen und zu wenden, dass sie optimal ausgelastet sind. Für mich klingt das eindeutig nach einem neuen Spiel namens „Ressourcen-Tetris“.
Was dieses „Spiel“ bei den Mitarbeitern anrichtet, ist hinlänglich bekannt und wird trotzdem oft nicht ernst genommen:

Gerade im agilen Umfeld, bei der Arbeit mit Scrum, sind diese Probleme verstärkt spürbar. Die Mitarbeiter verpassen die Scrum Meetings bzw. leidet während ihrer Arbeitszeit das Verhältnis von Meetings zu eigentlicher Arbeit an ihren Tasks, weil sie nicht voll verfügbar sind.
Ich erwarte kein Commitment, dass von nun an alle Mitarbeiter zu 100% ausschließlich an den jeweiligen Projekten und Aufgaben arbeiten dürfen. Das ist auch in unserem Consulting Business oft nicht möglich. Wir müssen uns nur bewusst sein, dass es Nebenwirkungen mit sich bringt, die oft ignoriert werden. In diesem Sinne muss daher verantwortlich abgewogen werden, welche Priorität die volle Auslastung von Mitarbeitern in der Organisation bekommt.

Eine Buchpräsentation der agilen Art

In einer netten Location im 15. Wiener Gemeindebezirk, deren schöne Dachterrasse wir wegen eines Unwetters leider nicht nutzen konnten, wurde letzte Woche ein neues Buch präsentiert. Als Gastgeber und Co-Autor präsentierte unser Kollege Jürgen Margetich den zahlreichen Gästen voller Stolz das Buch „Das Scrum-Prinzip: Agile Organisationen aufbauen und gestalten“, das er gemeinsam mit Boris Gloger geschrieben hat.
Boris und Jürgen widmen sich in diesem Buch den Führungskräften und Managern, ihrer wichtigen Aufgabe in der Organisationsentwicklung und im Change Management. Pauschallösungen dafür, wie man Organisationen zur Agilität entwickelt und verändert, findet man im Scrum-Prinzip aber nicht. Vielmehr ist es ein Handbuch, das Hinweise gibt, die aber an die jeweilige eigene Situation angepasst werden müssen. Der Leser wird durch konkrete und essentielle Fragen zu neuen Ideen verleitet. Noch während des Lesens ändert man die eigene Perspektive und erkennt andere Möglichkeiten, die helfen können, die eigene Organisation besser zu verstehen und somit einen gezielteren Change-Ansatz zu verfolgen.
Wie es bei Buchpräsentationen so ist, erwarteten die Gäste eigentlich eine Lesung – aber es gab keine. Jürgen machte klar: „Ein agiles Buch kann nur agil präsentiert werden!“. Die Teilnehmer bekamen die Aufgabe, sich mit 5 Kapiteln aus dem Buch zu beschäftigen:

  1. Auf der Suche nach der agilen Organisation cover_Scrum-Prinzip
  2. Scrum
  3. Die Arbeit am Widerstand
  4. Anleitung für die agile Organisation
  5. Der Manager als Gestalter

Schnell fanden sich die Gruppen zusammen und befassten sich mit dem jeweiligen Kapitel. Einige Passagen waren bereits markiert und führten in den Gruppen zu regen Diskussionen. Es war faszinierend zu beobachten, wie unterschiedliche Menschen zusammenfanden, das Gelesene reflektierten, interpretierten und sich austauschten. Eine großartige Atmosphäre wurde spürbar, als im Anschluss die vielen Meinungen, Ideen und neuen Impulse zusammengetragen und diskutiert wurden. Gestützt von Sekt und Brötchen hielten die Diskussionen noch weit über die eigentliche Präsentation hinaus an. Es traf ein, was Boris und Jürgen sich erhofft hatten: Die Gäste gingen mit Lösungen nach Hause, die sie sich mit Hilfe von „Das Scrum-Prinzip“ selbst erarbeitet hatten.
Erhältlich auf Amazon:
Boris Gloger, Jürgen Margetich: Das Scrum-Prinzip. Agile Organisation aufbauen und gestalten. Schäffer-Poeschel 2014.

Testautomatisierung – die Versicherung für Ihre Software!

Der Ausgangspunkt dieses Beitrags war eine Diskussion zum Thema Testautomatisierung und die Frage, wie deren Vorteile und Nutzen einfach kommuniziert werden können. Mit welchem Beispiel aus der alltäglichen Praxis lässt sich die Testautomatisierung für Software am besten vergleichen? Mir fiel folgender Vergleich ein: Ist denn die Testautomatisierung nicht eigentlich eine Versicherung für die entwickelte Software?
Aber der Reihe nach. Per Definition sind Versicherungen dazu da, ein mögliches Risiko für einen Schadenseintritt abzusichern [1]. Da Software heute in vielen Unternehmen essentiell für deren Wertschöpfungsprozesse ist oder sogar die Wertschöpfung darstellt, ist deren Berücksichtigung für das Risikomanagement des Unternehmens nicht nur sinnvoll, sondern notwendig. Im Rahmen des Risikomanagements müssen mögliche Schadensfälle definiert und bezüglich ihrer Eintrittswahrscheinlichkeit und -schwere klassifiziert und priorisiert werden.
Stellt euch vor, dass das betrachtete Unternehmen 50% seines Umsatzes mit Hilfe eines Online-Shops erwirtschaftet und in diesem wegen eines Softwarefehlers mehrere Stunden keine Bestellungen getätigt werden können. Im realen Leben ein Worst-Case-Szenario, das immer wieder auch renommierte Shop-Betreiber trifft.
In der Lehre des Risikomanagements gibt es verschiedene Varianten, mit einem Risiko umzugehen. Das Risiko kann in Kauf genommen, minimiert, an Dritte übertragen oder gar vermieden werden. [2]
Viele Firmen entscheiden sich bei Software unbewusst für die erste Variante, da sie diese Schadensfälle gar nicht berücksichtigt, geschweige denn berechnet haben. Erst wenn der Schaden eintritt, wird sich ein Unternehmen seines ausgesetzten Risikos bewusst. Dabei wäre es doch so einfach, das Risiko mit Hilfe einer Versicherung auf ein akzeptables Maß zu minimieren. Diese Versicherung ist die Testautomatisierung. Mit Hilfe unzähliger automatisierter Tests werden regelmäßig alle wichtigen Funktionalitäten der Software auf ihre Funktionstüchtigkeit getestet. Diese Tests liefern somit regelmäßig Feedback über das aktuelle Risiko, das von der Software ausgeht. Mit Hilfe von Statistiken und Auswertungen können diese Daten dann in eine unternehmensweite Risikoüberwachung integriert werden.
Testautomatisierung sichert so nicht nur nachhaltig die Qualität und Wartbarkeit der Software, sondern verschafft auch ein Gefühl der Sicherheit, die eigene Software „im Griff“ zu haben. So let us start coding test driven!
[1]  Wiktionary: http://de.wiktionary.org/wiki/Versicherung
[2]  Ahrendts, F.; Martin, A.: IT-Risikomanagement leben! Wirkungsvolle Umsetzung für Projekte in der Softwareentwicklung. Berlin: Springer Verlag, 2008.

Köstlichkeiten und Kostenloses im Alltag eines Unternehmensberaters

Es ist Donnerstag. Böse Zungen sagen auch gerne mal Beraterfreitag. Aber das perlt ab.
Ich habe eingecheckt und befinde mich im Abflugterminal des Flughafens. In dieser speziellen Ausgabe von Flughafen hat sich ein besonders schlauer Fuchs gedacht, es sei geschickt, die kleinen gelben Automaten, an denen man Gefrierbeutel für den sicheren Transport 10x100ml hochexplosiver Flüssigkeiten erwerben kann, 20 Meter hinter der Taschen- und Personenkontrolle aufzustellen. Dann können die Passagiere die Flüssigkeiten, die sie vor dem Sicherheitscheck schon längst entsorgen mussten, endlich in die Plastiktüten packen. Toll!
Mein Tag verlief so lala – der Kunde wusste es mal wieder besser als ich und stellte mich dann gleich noch zusammen mit „dieser ganzen Beraterbande“ grundsätzlich in Frage. Widerstand zwecklos. Definitiv Grund genug, sich mit dem Gedanken an ein kühles Bier anzufreunden. Ich überschlage kurz das verbleibende Reisebudget und stelle fest, dass ich bei Verzehr eines Flughafenbieres wohl noch 4,50 Euro drauflegen müsste, da ich ja bereits heute morgen unbedingt das S-Bahnhof-Ciabatta und den korrespondierenden Kaffee beanspruchen musste. Mittags musste es dann selbstverständlich auch das Mittagsmenü der örtlichen Crossover-Kitchen sein, weil der Kollege, mit dem dieses eine superwichtige Thema besprochen werden wollte, eben dort schon einen Tisch reserviert hatte. Und das im schwäbischen Teil Baden Württembergs – also keine Chance, eingeladen zu werden.
Zurück ins Jetzt. Ich könnte natürlich auf ein kleineres Bier ausweichen…Naääh komm, das würde den Literpreis schlagartig dreistellig werden lassen. Außerdem ist heute Beraterfreitag. Ich entscheide mich für den halben Liter Weißbier vom Fass. Hmmm, wie es so schön in der Abendsonne schimmert, die hinter der Landebahn untergeht. Ich mache noch schnell ein Foto mit meinem inneren Auge und reiße sogleich der Bedienung den Kelch aus der Hand. Dabei verschütte ich etwas von dem kostbaren Gut auf den bereits klebrigen Tresen. Bin wohl nicht der erste halbverdurstete Hobbybierologe heute.
Da vorne am Fenster ist noch ein Plätzchen frei. Ich setze mich und hole meinen Laptop raus. Es ist noch etwas Zeit und ich überlege, einen kleinen Beitrag für unseren Blog zu schreiben. Thema: such dir was aus. Na gut, schreib ich halt was über Leute am Flughafen. Ha! Direkt neben mir hat jemand sein Bier nicht ausgetrunken. Das ist ja noch dreieurofünfzig voll! Also entweder, es war ihm wirklich egal, oder demjenigen ist wieder eingefallen, dass es ein Flughafen mit angeschlossener Kneipe ist und nicht umgekehrt. Oder ihr? Gibt es Frauen, die am Flughafen einen halben Liter Weißbier bestellen und dann die Hälfte zurücklassen? Unwahrscheinlich. Derart leichtsinnig sind doch bestimmt nur Menschen die es gewohnt sind, von einer Sekunde zur maximal übernächsten zu denken (das Bier im 30 Minuten später startenden Flugzeug ist kostenlos!).
Ein paar Meter weiter, eine Tafel: „Jede Pizza nur 10 Euro!!“ Wow, ich bin kurz davor zu Hause Bescheid zu sagen, dass ich im Begriff bin, das Schnäppchen der Woche zu schlagen und zu fragen, ob ich vielleicht noch eine zweite mitbringen soll. Ich schaue mich um, um zu sehen, ob sich dieser Anbieter eventuell in einem erbitterten Preiskampf mit unzähligen weiteren Pizzabäckern befindet. Natürlich nicht. „Do people at the airport know what the prices are at any other place in the world?“, fragte einst der amerikanische Comedian Jerry Seinfeld. Nun ja, ich habe vor ein paar Minuten ein Bier für 6,90 Euro gekauft – bin also Teil des Problems. Der randvollen Auslage nach zu urteilen hat die Pizza heute auch schon einmal 15 Euro gekostet und nun wird voller Enthusiasmus diese Wahnsinnsreduktion beworben. Ausgang ungewiss.
Gegenüber steht das Regal mit dem Zeitschriftenangebot der Airline. Eine Ausgabe des PLAYBOY mit jugendfreiem Einband – zu sehen ist das Bild einer verlassenen Karibikinsel in Häschenkopfform aus der Vogelperspektive – liegt dort aus. Und, was ist das? Ein Mittvierziger mit seinem maximal 10-jährigen Spross geht schnurstracks darauf zu, lenkt den Jüngsten noch kurz mit einer SportBild, auf deren Cover Manuel Neuer gerade irgendwen anbrüllt ab, um dann beherzt ins obere Regal zu greifen. Bold move, daddy! Was wohl Mama dazu sagen würde? Kriegt sie ja nicht mit. Und wenn doch, wird auch er behaupten, es ginge ihm lediglich um die super Reportagen.
Oh, der Flug wird aufgerufen. Für’s Priority Boarding habe ich noch nicht genügend Meilen – Anfänger! Aber ich habe noch etwas Zeit, um den Passagieren bei ihrer besten Engländer-Imitation zuzusehen und die restlichen 2,90 Euro auszutrinken. Nicht dass sich am Ende jemand über mein halb volles (!!) Glas lustig macht. Wie sie sich alle brav anstellen, obwohl sie doch noch laaaange nicht dran sind. Vielleicht sollte ich mal hingehen und darauf aufmerksam machen, dass sich die Sitzplatznummern auch in den verbleibenden 30 Minuten nicht mehr ändern werden. Und „ja, Sie werden mit sehr sehr großer Wahrscheinlichkeit der erste auf dem ausschließlich für Sie reservierten Platz sein“. Mich beschleicht der Verdacht, es könnte sich um traumatisierte Bahnkunden handeln, die auch Angst davor haben, nachts aus ihren Betten geschmissen zu werden, weil sie das „ggf. freigeben“-Schild einfach ignoriert haben. Ich beobachte das Schauspiel noch eine Weile und verpasse um ein Haar noch meine Boarding-Gruppe.
Im Flugzeug komme ich mit meinem Sitznachbarn ins Gespräch. Er erzählt mir davon, wie er aufgrund seiner Leibesfülle schonmal aus den komfortablen Sitzen vor den Notausgängen komplimentiert wurde. „Jaja, Alte, Kinder und Dicke haben keine Chance“, sagt er. Und ich weiß in dieser Situation nicht, wer mir mehr Leid tut: dieser arme Kerl, dem seine stattliche Physis so deutlich vor Augen geführt wurde, oder ich, der auf einmal mit der Hälfte des bezahlten Sitzplatzes auskommen muss. Ich versuche trotzdem, es mir ein bisschen bequem zu machen. Über die Lautsprecher hauchen Simply Red: „I wanna fall from the stars“ in die Kabine. Bei dem Gedanken an den Marketingmitarbeiter mit dem Einfühlvermögen einer Tiefkühltruhe, der tagelang gegrübelt und letztlich beschlossen hat, dass nur genau dieser der richtige Song vor jedem Take-off sein kann, lasse ich mich langsam in den Schlaf rütteln. Das kostenlose Bier werde ich natürlich verpassen.

"Wir müssen nur noch unsere ScrumMaster überzeugen"

Habt ihr diesen Satz auch schon einmal zu hören bekommen? Ich war absolut überrascht bzw. fast schon überrollt von der Aussage: „Mein Ziel ist es, bis zum nächsten Treffen meinen ScrumMaster von Scrum zu überzeugen.“ Getätigt von einer Führungskraft. Ich kenne eher Fragen wie: „Wie überzeuge ich mein Team?“ oder „Wie überzeuge ich das höhere Management von Scrum?“ Aber „Wie überzeuge ich meinen ScrumMaster von Scrum“ war mir absolut neu.
Ein ScrumMaster ist wie das Fundament, auf dem man ein Haus baut, und wenn bereits das Fundament bröckelt, wird auch der Rest des Hauses nicht sonderlich stabil sein. Kann man denn mit einem ScrumMaster, der noch von Scrum überzeugt werden muss, überhaupt eine erfolgreiche Prozessveränderung durchführen? Meistens ist den ScrumMastern ihre Bedeutung nicht bewusst, daher ist es essenziell, ihnen ihre Rolle im Scrum-Prozess genau zu erklären. Erst wenn man die eigene Rolle versteht, kann man sie auch leben. Ihr habt es sicher schon tausend Mal gehört, aber scheinbar ist es nötig, die Rolleninhalte des ScrumMasters immer wieder zu wiederholen. Was genau sind denn die Aufgaben eines ScrumMasters im Veränderungsprozess mit Scrum?
Scrum implementieren – bzw. Scrum einführen
Erste und wichtigste Aufgabe eines ScrumMasters ist es, Scrum im Unternehmen zu verwirklichen, die Regeln von Scrum einzuführen und den Veränderungsprozess anzustoßen. Jede noch so geringe Abweichung von Scrum ist – zumindest in der Lernphase – zu vermeiden.
Abarbeiten von Impediments und Entscheidungen treffen bzw. Hindernisse aus dem Weg räumen
Alle Impediments, die das Team und die Organisation daran hindern, effektiv zu sein, werden vom ScrumMaster gelöst.
Arbeit mit dem Team
Der ScrumMaster arbeitet mit dem Team daran, die Entwicklung eines Produktes selbst in die Hand zu nehmen.
Arbeit mit dem Product Owner
Der ScrumMaster unterstützt nicht nur sein Team, damit es Scrum versteht und umsetzen kann, sondern auch den Product Owner, damit auch dieser seine Aufgaben in Scrum versteht und erledigen kann.
Scrum in die Organisation hineintragen und die Organisation ändern
Die mit Scrum erzielten Erfolge werden in der/die Organisation kommuniziert, um auch eine Änderung in der Organisation anstoßen zu können. Der ScrumMaster erzählt von den Ergebnissen, die sein Team und er mit Scrum erzielt haben. Ja, ScrumMaster sollten daran arbeiten, ihre Chefs und andere Teams von Scrum zu überzeugen, um Scrum im gesamten Unternehmen zu etablieren.
Die Produktivität des Teams steigern
Das wird durch das Ausleben von Scrum erreicht!
Ausgehend von den Aufgaben als ScrumMaster, sollte es überhaupt nicht mehr nötig sein, einen ScrumMaster von Scrum zu überzeugen. Ohne Überzeugung kann er oder sie diese Aufgaben nämlich gar nicht übernehmen und noch weniger Erfolge erzielen.

Symptome und Ursachen

Wenn wir aber genau hinsehen, liegt hinter der Aussage „Ich muss nur noch den ScrumMaster von Scrum überzeugen“ noch eine andere Ursache. In diesem Fall war es so: Man nehme mehrere Development Teams und ein Management, das merkt, dass eine Prozessänderung nötig ist, um besser und schneller zu werden. Also entscheidet sich das Management für Scrum. Die Rollen werden schnell verteilt, alle bisherigen „Anforderer“ werden zu Product Ownern und die ScrumMaster sind einfach die Teamleads, die auch bisher die Teams geleitet haben (es spricht ja absolut nichts dagegen). Also nehmen alle an den einschlägigen Trainings teil und werden – juhu – ScrumMaster. Und einige Zeit später kommt man drauf, dass man die Leute vielleicht ein wenig überrumpelt hat. Statt zu verstehen, dass man es hier mit einem massiven persönlichen Veränderungsprozess zu tun hat, wird Etikettenschwindel betrieben: Die einzige Veränderung besteht darin, den Titel auszutauschen. Während das Management von einem Tag auf den anderen ScrumMaster haben will, sind die ScrumMaster im Geiste noch Teamleiter – und das ist nur allzu verständlich. Vom Titelträger zum Change Agent zu werden, ist ein ziemlich großer Schritt und nicht von heute auf morgen zu bewerkstelligen. Ein echter ScrumMaster kennt Scrum, will Scrum und arbeitet nach Scrum – ein ScrumMaster lebt nun mal Scrum.
Wenn man sich nun schon in diese etwas missliche Lage gebracht hat: Wie kommt man da wieder raus? Manager sollten wahrnehmen und wertschätzen, was ScrumMaster im Unternehmen mit ihren Teams leisten. Auch kleinere Erfolge, wie ein erfolgreich abgeschlossener Sprint, gehören gefeiert und gelobt. ScrumMaster leisten den höchsten Beitrag für den Veränderungsprozess und sollten auch seitens der Führungskräfte und Product Owner dementsprechend wahrgenommen werden. Positives Feedback ist für viele ScrumMaster die größte Motivation in ihrer Arbeit.
Vielleicht muss gar nicht der ScrumMaster von Scrum überzeugt werden, sondern dem Management sollte bewusst werden, was ihre ScrumMaster im Veränderungsprozess leisten. Es kann nämlich auch gut sein, dass ScrumMaster sich denken: „Ich muss noch meine Führungskraft von meiner Rolle und meiner Leistung überzeugen.“

Von Zahlenfetischismus und anderen Angewohnheiten

Letztens im Sprint Planning 1: Der Product Owner stellt gerade die 7. Story vor. Bereits das Commitment der 6. Story hatte einigen Teammitgliedern Bauchschmerzen bereitet. Doch zu meiner Überraschung ist das Team schnell zu dem Entschluss gekommen, auch diese weitere Story zu committen.
Szenenwechsel: Die Nachbesprechung des Meetings in kleinem Kreis. “Warum wart ihr euch als Teammitglieder bei der letzten Story so sicher?”, lautet meine Frage als ScrumMaster. Kleinlaut wird mir erklärt, dass ein Teil der Storys vorab im Aufwand mit Manntagen geschätzt wurde. Und das alles, nachdem wir die letzten Schätzungen mit Hilfe von Magic Estimation [1] auf der Basis des relativen Funktionsumfangs sehr effizient durchgeführt hatten und das Team überzeugt von den Vorteilen wirkte.
Das Beispiel zeigt, wie schwierig es doch ist, alte Gewohnheiten hinter sich zu lassen. Obwohl mir doch in den Diskussionen mit dem Team bestätigt wurde, dass alle bisherigen Aufwandschätzungen keineswegs genau und richtig waren. Zudem sind viele der traditionellen Software-Schätzverfahren mit hohem Aufwand verbunden, da viele Faktoren erhoben und Bewertungen durchgeführt werden müssen, wie beispielsweise in der Function Point Methode [2]. Und doch scheint es schwierig zu sein, die alten Angewohnheiten einfach einmal beiseite zu legen.
Doch was ist es, das uns an den Schätzungen mit Aufwand festhalten lässt? Ist es das Gefühl der vermeintlichen Sicherheit, die Größe der Story bestimmt zu haben? Ist es die Annahme, das Projekt mit Hilfe dieser Zahlen „im Griff“ zu haben? Oder ist es der reine Zahlenfetischismus, der von Jahr zu Jahr zuzunehmen droht? Oder sind es ganz andere Gründe, die wir gar nicht benennen können?
[quote author = “Heinrich Heine”] “Man kann die Ideen, wie sie in unserem Geiste und in der Natur sich kundgeben, sehr treffend durch Zahlen bezeichnen; aber die Zahl bleibt doch immer das Zeichen der Idee, nicht die Idee selbst. Der Meister bleibt dieses Unterschieds noch bewusst, der Schüler aber vergisst dessen und überliefert seinen Nachschülern nur eine Zahlenhieroglyphik, bloße Chiffren, deren lebendige Bedeutung niemand mehr kennt und die man mit Schulstolz nachplappert.”[/quote]
Mein Tipp: Lasst euch auf neue Methoden ein, wenn die bisher verwendeten keinen Erfolg versprechen. Lasst euer Bauchgefühl entscheiden und verschwendet keine Stunden und Tage für kompliziert berechnete Schätzungen, die nicht halten. Benutzt Magic Estimation, mit dessen Hilfe ihr die Storys schneller und fokussierter schätzen könnt. Ich bin mir bewusst, dass dies auch Mut erfordert. Den Mut, bisher jahrelang verwendete Verfahren in Frage zu stellen. Glaubt mir, es lohnt sich!
[1] Gloger, B.: Scrum. Hanser Verlag (4. Auflage), 2013.
[2] Poensgen, B.: Function-Point-Analyse: Ein Praxishandbuch. dpunkt Verlage (2. Auflage), 2012.
Übrigens frisch im Buchhandel: “Wie schätzt man in agilen Projekten – oder wieso Scrum-Projekte erfolgreicher sind” von Boris Gloger. Hanser Verlag 2014.

Mit Agil richtig dokumentieren

Agilen Entwicklungsmethoden hängt immer noch der Ruf unzulänglicher Dokumentation nach. Gerade in hoch regulierten Branchen wie der Medizintechnik geht es um Verifikation und Validation der Entwicklung, um Rückverfolgbarkeit der Anforderungen und um ein gescheites Risikomanagement. All das macht durchaus Sinn, will man doch sicher gehen, dass ein Produkt am Ende das tut, wozu es entwickelt wurde.
Da ist die Vorstellung von Scrum-Teams, die allein von Sprint zu Sprint planen, natürlich ein Graus. Dennoch passiert genau das immer wieder: Die Entwicklung ist viel zu sehr auf die nächsten Schritte fokussiert, es fehlt jegliche Besinnung auf die langfristigen Ziele und die regulatorischen Bedingungen, die zwingend zu erfüllen sind. Wenn ich neu konstituierte Scrum-Teams dann frage, weshalb sie mmer nur von Sprint zu Sprint leben, dann wird schnell klar: Sie sind es gar nicht anders gewohnt. Es ist ja nicht so, als ob die Dokumentationsarbeit in klassichen Entwicklungsprojekten funktionieren würde. Hier wird häufig ganz zum Schluss “nachgearbeitet”. Unvergessen bleibt mir ein Projektleiter, der sich kurz vor Produkt-Launch tagelang im Home-Office einschloss, um den (O-Ton) “Q-Rotz” fertigzustellen.
Das Validationstool
Wenn wir z.B. in der Medizintechnik agile Produkte entwickeln möchten, dann dürfen wir nicht zu konservativ oder ehrfürchtig vorgehen. Es kann nicht darum gehen, bestehende Prozesse mit Scrum abzubilden – dann brauchen wir erst gar nicht mit dem agilen Change anzufangen. Es geht vielmehr darum, mit Scrum einen neuen Prozess aufzusetzen, der das Thema Dokumentation zuverlässig in den Griff bekommt. Und hier sehen wir vor lauter Bäumen bisweilen den Wald nicht mehr: Das Skelett, das Grundgerüst von Scrum, ist nichts anderes als ein Validationstool. In regelmäßigen, kurzfristigen Abständen wird geplant und anschließend verifiziert, ob das Geplante tatsächlich erreicht wurde. Diese Verifikation findet nicht nur auf funktionaler, sondern auch auf formaler Ebene statt. Wenn beispielsweise jede entwickelte Funktionalität nicht nur in gewisser Weise funktionieren, sondern auch in bestimmter Weise getestet und bewertet sein muss, dann lässt sich diese Anforderung über eine Definition of Done abbilden.
Spannend dabei ist: Meistens stellt sich heraus, dass Scrum-Teams noch gar nicht in der Lage sind, von Sprint zu Sprint die dokumentatorischen Anforderungen zu erfüllen. In Scrum fällt so etwas schnell auf – das Team wird am Ende eines Sprints einfach nicht fertig. Sie haben zwar entwickelt, aber das Drumherum fehlt. Also kann der Product Owner die Ergebnisse nicht abnehmen und die Aufgaben wandern zurück ins Backlog. Wenn wir jetzt nichts unternehmen, dann sind wir wieder im klassichen Projekt: Es türmt sich ein Haufen unerledigter Arbeit auf, sodass am Ende der Entwicklung nichts wirklich fertig ist.
Hier hilft Scrum, indem es das ganze Ausmaß der Unzulänglichkeiten offenlegt. Und zwar alle
zwei Wochen. Am Ende läuft es darauf hinaus, dass das Scrum-Team lernen muss, wie Dokumentation funktioniert. Dazu brauchen sie Unterstützung von Experten, die meistens aus der QM-Abteilung kommen. Häufig sieht eine QM-Abteilung ihre Mission darin, die Entwicklung zu überwachen und auf Missstände hinzuweisen bzw. diese auszubügeln. Dadurch wird der Entwicklungsprozess an sich aber nicht verändert, denn die Zweiteilung zwischen Entwicklung einerseits und Qualitätsmanagement andererseits bleibt bestehen. Eine Möglichkeit, diese Zweiteilung aufzuheben, ist die Eingliederung der QM-Experten in die Scrum-Teams, damit praxisnaher Wissenstransfer statt finden kann.
Das Erfüllen von dokumentatorischen Anforderungen ist kein irrsinnig komplexes Unterfangen. Da ist nichts drinnen, das den menschlichen Verstand übermäßig herausfordern würde. Aber es will gelernt sein. Das ist in anderen Bereichen nicht anders: Für viele Entwickler ist das integrative Testen eine Selbstverständlichkeit, ohne dass sie niemals etwas als lauffähig präsentieren würden. Aber auch das war nicht immer so.
Mit Scrum haben wir die Möglichkeit, Teams aufzubauen, die sich mit regulatorischen Anforderungen so gut auskennen, dass ihre Berücksichtigung eine Selbstverständlichkeit wird. Dann – und erst dann – können wir davon sprechen, dass das Team mit dem letzten Sprint fertig ist und das Produkt auf den Markt gehen kann. Alles andere ist Augenwischerei.

Die Kraft der Begeisterung

Vor ein paar Tagen erlebte ich (endlich) einmal wieder so einen Moment … einen Moment, der mich wissen lässt, dass es nicht reiner Idealismus ist zu glauben, dass Menschen Spaß an ihrer Arbeit haben und aus ihr Energie ziehen können.
Einen Moment des Leuchtens in den Augen, der Begeisterung, des Mutes, des Gestaltungswillens! Der PO – der mit dem Leuchten in den Augen – war in ein Projekt reingeraten, bei dem politische Zwänge, künstliche System- und Entwicklungstrennungen und vermehrte Absicherungsaktivitäten das Arbeiten alles andere als agil machten. Vorherige Anläufe waren bereits gescheitert bzw. die Live-Stellung war schon einige Male verschoben worden. Zur Absicherung der eigenen Abteilung ließ man höchste Vorsicht walten in der Zusammenarbeit. Man bestand auf lupenreine Schnittstellendefinitionen im Vorfeld, Abnahmen ohne Anbindung des Systems an die Schnittstelle bzw. das Frontend, parallele Abarbeitung unterschiedlicher Anforderungen und und und …  Zwar wurde in 2-Wochen-Sprints gearbeitet, doch die Resultate waren für niemanden wirklich zufriedenstellend. Man hatte sich allerdings irgendwie damit abgefunden, vielleicht gerade aufgrund der Projekthistorie.
Aufgrund einer unabhängigen Anfrage des Fachbereichs/Kunden zur Umsetzbarkeit einer Funktionalität im System wurde sich der PO aber wieder darüber bewusst, was sein System eigentlich drauf hatte. Aufgrund dieses Impulses traute man sich plötzlich, das vermeintlich Offensichtliche zu denken: “Können wir nicht die Funktionalitäten, die der Kunde sich seit Jahren durch die Einführung eines neuen Systems erhofft hat, nicht auch viel einfacher im eigenen System abbilden?”
Als der PO diesen Gedanken aussprach, erinnerte er sich daran, dass er genau dies als Vision für sein neugegründetes Team vor einem Jahr formuliert hatte. Und auch damals schon war plötzlich eine Energie und Klarheit im Raum, wie sie keine schriftliche Dokumentation und Absicherung jemals erzeugen kann. Sie war positiv! Damals wie heute bei der gleichen Sache.
Diese positive Energie zeigte mir als ScrumMaster, in welche Richtung ich weiterarbeiten musste.