Scrum - Einführung in der Unternehmenspraxis || Schnelle Erfolge erzielen

10Schnelle Erfolge erzielen

Sie haben Ihre Dringlichkeit analysiert, Ihre Vision bis ins Details ausgearbeitet und soeindringlich kommuniziert, dass sogar die Reinigungskräfte genau wissen, wohin die Rei-se gehen soll. Auch haben Sie Ihre Mitarbeiter auf breiter Basis befähigt und die gröbstenHindernisse aus demWeg geräumt. Sehr gut! Wenn Sie jetzt allerdings glauben, die Arbeitwäre getan und Sie könnten sich zurücklehnen, dann haben Sie sich leider geirrt. Selbstwenn Sie wirklich alles getan haben, was für den langfristigen Erfolg benötigt wird, sostimmt das nur für den Moment. Um die Motivation Ihrer Mitarbeiter – inklusive Ihrereigenen – auch langfristig aufrecht zu erhalten, müssen Sie auch für kurzfristige Erfolgesorgen. In diesem Kapitel lernen Sie, warum das so wichtig ist und worauf Sie dabei achtensollten.

10.1 Warum Träumer einenWecker brauchen

Um eine Vision zu kreieren, die sowohl Herz als auch Verstand anspricht, braucht es Träu-mer. Nur Träumer können sich eine Welt ausmalen, die in der erträumten Form noch garnicht existiert. So entstehen geniale Produktideen und Strategien, ein Segen für Ihr Un-ternehmen. Das Problem mit Träumern ist allerdings, dass sie die ganze Welt um sichherum vergessen können, während sie träumen. Das ist bei der Umsetzung strategischerMaßnahmen schädlich – es muss also ein Wecker her! Stellen Sie sich vor, Ihre Verände-rungsinitiative dauert nur fünf Jahre (was unwahrscheinlich ist): Jemanden zu haben, dersich IhrUnternehmen in verbesserter Form in fünf Jahren vorstellen kann, ist sehrwertvoll.Jemanden zu haben, der fünf Jahre lang schläft, kann irritierend wirken.

In den vorangegangenenKapiteln habe ich Sie dazu aufgefordert,mit der gesamten Füh-rungskoalition eine Vision zu erstellen. Damit habe ich Sie dazu aufgefordert, zu träumen.Was glauben Sie passiert, wenn die Führungskoalition nicht mehr erwacht und einfach im-mer weiter träumt? Richtig – Ihr Unternehmen steuert führungslos durch die TurbulenzendesMarktes undwird früher oder später auf ein Riff laufen. Entweder, weil die Ruderermü-

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

66 10 Schnelle Erfolge erzielen

de geworden sind, oder weil die Richtung nicht mehr stimmt, in die Sie das Unternehmennavigieren. Bei allen strategischen Überlegungen dürfen Sie nie die Realität aus den Augenverlieren. Mutig und visionär voranzuschreiten ist Ihr Privileg – bedacht und sorgfältig dieGegenwart wahrzunehmen Ihre Pflicht.

Etwas weniger bildhaft ausgedrückt muss Ihre Vision stets gegen die aktuellen Erfor-dernisse geprüft werden. Außerdem müssen Sie sicherstellen, dass die Motivation allerbeteiligten Mitarbeiter nicht nachlässt. Der einzig sinnvolle Weg zu diesem Ziel sind kurz-fristige Erfolge. „Kurzfristig“ darf dabei durchaus auch sechs Monate bedeuten, wobei abereinige Wochen oder wenige Monate zu bevorzugen sind. Je mehr eindeutige Erfolge Siesichtbar machen, desto erfolgreicher werden Sie mit IhremWandel sein.

Bei allem Enthusiasmus dürfen wir nie vergessen, dass wir ein Unternehmen nicht di-rekt verändern können, sondern die Menschen, die in einem Unternehmen arbeiten, be-flügeln müssen. Erst wenn diese Personen ihre Verhaltensweisen geändert haben, wird sichganz allmählich auch die Unternehmenskultur verändern. Menschen werden mit der Zeitmüde, besonders wenn sie sich anstrengen. Veränderungen desUnternehmens gehören da-bei mit zu den anstrengendsten Veränderungen, denen sich IhreMitarbeiter gegenüber se-hen können. Kurzfristige Erfolge geben dabei Kraft, weiterzumachen. Im Übrigen werdennicht nur Ihre Mitarbeiter gestärkt, sondern auch Sie selbst: Erfolge geben Ihren Bemü-hungen Recht, sorgen häufig für eine schnellere Amortisierung der Kosten undmotivierenauch die Führungskoalition.

Im Sinne der Risikominimierung sollten Sie ebenfalls großen Wert auf kurzfristige Er-folge legen: Wenn Ihre kurzfristigen Ziele im Kontext der langfristigen stehen, dann kannIhnen das Erreichen eben dieser kurzfristigen Ziele zeigen, ob Ihre Vision realistisch istoder nicht. Im Kontext einer Scrumeinführung könnte zum Beispiel die Umstellung ei-nes einzelnen Teams auf Scrum Ihnen und allen Kritikern beweisen, dass es funktioniert.Eine Umstellung der gesamten Softwareentwicklung Ihres Unternehmens wird damit rea-listischer. Wenn dieses zuerst umgestellte Team dann damit beginnt, die Vorzüge mit denKollegen zu erörtern, haben Sie sich Multiplikatoren geschaffen, die Ihrem Veränderungs-projekt neuen Aufschwung geben. Die nächsten Teams werden bereitwilliger die neue Ar-beitsform ausprobieren und vielleicht sogar von selbst darum bitten, mit Scrum arbeitenzu dürfen.

10.2 Was kurzfristige Erfolge auszeichnet

Das dominanteste Kriterium für kurzfristige Erfolge ist der schnelle Eintritt. Die genaueZeitspanne bis zum Erfolg hängt dabei immer von der Größe des Gesamtunterfangens ab.Wenn Sie zum Beispiel davon ausgehen, dass eine kleine Reorganisation nur sechs Monatedauert, dann sollten Sie Ihren ersten kurzfristigen Erfolg vielleicht nicht erst nach 5 Mo-naten erreichen, sondern schon nach achtWochen. John Kotter beschreibt in seinem Buch

10.2 Was kurzfristige Erfolge auszeichnet 67

„LeadingChange“, dass auch Erfolge, die nach 18Monaten1 erreichtwerden, noch kurzfris-tig sein können. Dem widerspreche ich vehement: In unserer schnelllebigen Welt werdenhäufig schon sechs Monate als eine Ewigkeit wahrgenommen. Ein Jahr gilt meist schon alslangfristig.

BeispielEin Kunde implementierte Scrum zunächst vorbildlich mit einem Pilotteam. Das Pro-jekt war auf sechs Monate ausgelegt. Nach nur drei Monaten hatte sich die Welt bereitsweitergedreht und das ursprüngliche Ziel war obsolet geworden. Das Pilotteam wurdeaufgelöst, wir mussten wieder von vorne beginnen. Trotz des unerwarteten Abbruchshatten wir ein funktionierendes Produkt mit reduziertem Funktionsumfang vorzuwei-sen. Ein toller Erfolg, den wir bei der Ausrichtung auf weiter entfernte Zeitpunkte viel-leicht nicht erreicht hätten.

Daher empfehle ich Ihnen dringend, besser viele kleine Erfolge zu generieren, statt einesgroßen nach einer langen Zeit. Wenn es Ihnenmöglich ist, erschaffen Sie zu jedem Quartaleindeutige Erfolge.

Führen Sie sich zunächst die Gesamtsituation vor Augen: Das Unternehmen steckt ineiner Krise (oder hat zumindest eine hohe Dringlichkeit). Es gibt eine Vision, die einenmeist langen und beschwerlichen Weg aus dieser Krise aufzeigt. Alle Blicke sind auf dieFührungskoalition gerichtet, die dasUnternehmen auf diesemWeg aus der Talsohle führensoll.

Hier hilft Ihnen Geheimniskrämerei nichts. Im Gegenteil: Selbstmarketing ist für dieFührungskoalition essentiell. Jeder Erfolgmuss daher uneingeschränkt sichtbar sein. Sicht-bar heißt nicht nur, dass jeder Mitarbeiter die Informationen über den Erfolg hat, sonderndiese auch so aufbereitet sind, dass alle sie verstehen. Auch müssen die Daten durch dieMitarbeiter nachprüfbar sein. Niemand wird Ihnen glauben, wenn der Erfolg nur als Be-hauptung im Raum steht und nicht „anfassbar“ ist. Sobald die Mitarbeiter Zugang zu denErfolgen haben, werden sie diese auf Herz und Nieren prüfen. Teilweise wird man Ihnenfreundliche Verbesserungsvorschläge anbieten, an anderer Stelle wird man harsche Kritiküben und laut nach Ihrem Rücktritt rufen. Stellen Sie daher sicher, dass Ihr präsentier-ter Erfolg eindeutig ein solcher ist. Es darf keinerlei Kritikpunkte daran geben. Wenn dieGlaubwürdigkeit Ihrer Erfolge wankt, so hängt auch die Führungskoalition und damit dergesamte Veränderungsprozess an einem seidenen Faden.

Viele Wandelinitiativen führen nicht zum Erfolg, weil zu viel Wert auf kurzfristige Er-folge gelegt wird. Wer nur kurzfristig denkt, wird nie seine Vision erreichen und wirklichetwas bewegen. Daher ist es enorm wichtig, dass Sie bei allem, was Sie tun, immer die Vi-sion im Blick behalten und auch die kurzfristigen Ziele sorgfältig planen. Stellen Sie in derKommunikation Ihrer kurzfristigen Erfolge stets denBezug zu den langfristigenZielen und

1 Er schreibt bei einem vier Jahre dauernden Beispiel: „Wie können wir innerhalb von 6 bis 18 Mo-naten diverse eindeutige Leistungsverbesserungen planen und umsetzen?“.


der Vision her. Machen Sie jedem klar, dass Sie immer noch dabei sind, die Veränderungvoranzutreiben.

Als Führungskoalition müssen Sie hier sowohl Führungs- als auch Managementfähig-keiten an den Tag legen. Neben der Vermittlung von Dringlichkeit und Vision müssen Sieeindeutige kurzfristige Erfolge erreichen und dabei immer denWeg imAuge behalten. Un-terschätzen Sie den Schwierigkeitsgrad dieser Aufgabe nicht! Es kann helfen, wenn Sie sichin der Führungskoalition gegenseitig unterstützen und je nach Aufgabe größeres Gewichtauf die Hinweise der Visionäre oder derManager legen. Der schmale Grat zwischen zu vielVision und zu viel Management verläuft genau durch dieses Gremium.

10.3 Piloten

Egal für welche Art der Scrumeinführung Sie sich entscheiden, Sie werden einige Pilot-projekte benötigen, um Erfolge zu generieren. Von dieser Regel ausgenommen sind ledig-lich Scrum PRN-Einführungen. Hier hat jedes Projekt Pilotcharakter, auch wenn es dashundertste ist. Die Auswahl des richtigen Projektes als Pilot ist nicht einfach. Auch die ent-sprechendeVorbereitung unddie darauf folgende Implementierung haben ihre Tücken. ImFolgenden werden Sie lernen, wie Sie die häufigsten Fallstricke vermeiden können. Dabeiist es unerheblich, ob Sie ein Scrum Software Studio oder Tiefen-Scrum anstreben – dasVorgehen für die Piloten bleibt im Wesentlichen gleich.

10.3.1 Identifikation

Angenommen, Sie haben die Erlaubnis, ein Pilotprojekt für Scrum zu suchen – wie gehenSie vor?Worauf sollten Sie achten? Es hat sich bewährt, zunächst alle grundsätzlich in Fragekommenden Projekte aufzulisten. Das sind in der Regel solche, die neu begonnen werdensollen. Bereits laufende Projekte erhöhen den Schwierigkeitsgrad, da hier die Mitarbeiterbereits an bestimmte Prozesse gewöhnt sind und sich auch die Arbeit mit anderen Abtei-lungen wie zum Beispiel dem Controlling eingespielt hat. Je größer Ihr Unternehmen ist,desto mehr Kandidaten stehen am Ende auf Ihrer Liste. Beginnen Sie dann damit, dieseProjekte zu analysieren. Halten Sie fest, welche Budgets und Personen diesem Projekt be-reits zugewiesen sind. Auch die Rollen der Beteiligten sind interessant. Führen Sie auf, wasdas Ziel des jeweiligen Projektes ist, welcheTechnologien bereits feststehen undwie kritischdas Projekt für dieOrganisation ist. Start- und angepeiltes Enddatum sollten natürlich auchnicht fehlen. Jetzt können Sie zum ersten Mal aussortieren: Sie werden für Ihre Vorberei-tungen ein bis drei Monate benötigen. Frühere Startzeitpunkte müssten Sie also verlegen.Falls das nicht geht, scheiden entsprechende Projekte aus (Ausnahme: Sie haben bereits einScrum Software Studio in Betrieb oder die unter „Vorbereitung“ aufgeführten Punkte aufandere Weise erledigt.). Projekte mit zu langer Laufzeit eignen sich ebenfalls schlecht alsPiloten. Zwar haben Sie dort viel Raum für Verbesserungen, jedoch dauert es zu lange, den

10.3 Piloten 69

Erfolg nachzuweisen. Dieser wird in aller Regel nämlich nur nach dem vollständigen Ab-schluss des Projektes anerkannt – alle vorhergehenden Errungenschaften gelten zwar alsschön, aber nicht als entscheidend. Wenn Sie die Chance dazu haben, sollten Sie sich einProjekt mit einer Laufzeit von drei bis sechs Monaten aussuchen.

Die Kritikalität des Projektes ist ebenfalls von erheblichem Interesse. Ist das Projektnicht wichtig genug, so wird man all Ihre Erfolge mit einem Achselzucken abtun: Schließ-lich wäre Ihnen das aus Sicht Ihrer Kritiker mit einem der wirklich wichtigen Projekte nichtgelungen. Dieses Argument ist zwar oberflächlich und kurzsichtig, lässt sich aber dennochnicht aus der Welt schaffen. Ist das Projekt andererseits zu wichtig, wird jede Führungs-kraft des Unternehmens versuchen, mitzureden. Ihre Entscheidungen wird man in Fragestellen, der Druck auf Sie wird erheblich sein. Allerdings haben Sie dann ein As im Ärmel:Man wird Ihnen jede erdenkliche Unterstützung gewähren, um das Projekt zum Erfolg zuführen. Vorausgesetzt natürlich, dass man Ihnen vertraut. Am Stärksten gilt das selbstver-ständlich beim wichtigsten Projekt. Suchen Sie sich daher eines der wichtigen Projekte aus.Nehmen Sie IhrenMut zusammen, richten Sie sich auf eine harte Zeit ein und legen Sie los –mehr Unterstützung oder eine höhere Sichtbarkeit werden Sie in keinem anderen Projekterfahren. Bei sehr wichtigen Kandidaten kommt ein weiterer Aspekt hinzu: Die Projekt-mitarbeiter sind mit höherer Wahrscheinlichkeit vollständig für das Projekt verfügbar. IhrZiel sollte sein, alle Teammitglieder zu 100% für Ihr Projekt zu bekommen. In der Praxismüssen Sie die Entwickler aber meist mit anderen Kollegen teilen. Projektzugehörigkeitenvon 30% und weniger sind keine Seltenheit. Machen Sie sich bewusst, dass Ihre Mitarbei-ter mit jedem zusätzlichen gleichzeitig laufenden Projekt etwa 20% Ihrer Gesamtkapazitätverlieren. Bei mehr als vier Projekten erhalten Sie keine nennenswerten Ergebnisse mehr.Grund dafür sind die Zeiten, die der Mitarbeiter benötigt, um sich in die jeweils andereAufgabe hineinzudenken, den Arbeitsplatz zu wechseln, die Arbeitsumgebung auf seinemPC so zu konfigurieren, dass sie für das neue Projekt passt und so weiter. Auch steigen dieBesprechungen und Zeiten für die Bearbeitung von E-Mails erheblich an, da jedes Projektmindestens eine Grundlast an Kommunikation erzeugt. Schon bei zwei parallel laufendenProjekten erzielen Sie in der Regel eine in Summe höhere Produktivität, wenn Sie diesenacheinander abwickeln. Ich empfehle Ihnen, dies an sich selbst mehrere Tage lang auszu-probieren. Sie werden vermutlich überrascht sein.

Die Produktivität können Sie ebenfalls positiv beeinflussen, indem Sie sich ein Pro-jekt aussuchen, dessen Teammitglieder bereits an einem Standort konzentriert sind. Es istwesentlich schwieriger, verteilte oder verstreute2 Teams zu führen, als ein an einem Ortkonzentriertes Team. Das macht sich auch spürbar bei der Produktivität bemerkbar: Vier-zig Prozent ist eher die untere Grenze dessen, was Sie an Produktivität gewinnen, wennSie Ihr Team an einem Ort zusammenbringen. Zwar liegt der Schwellwert zum verstreu-

2 Ihre Teams sind verteilt, wenn jeweils komplette Teams an unterschiedlichen Standorten sitzen.Beispielsweise Team Rot in der Schweiz und Team Blau in Deutschland. Verstreut ist Ihr Team, wenndie einzelnen Teammitglieder eines Teams an verschiedenen Standorten sind. Peter in Bulgarien,Marc sowie Steffi in Deutschland, Uta in den USA und so weiter.


ten Arbeiten bei etwa dreißig Metern Entfernung (Kraut und Streeter 1995) zwischen denTeammitgliedern. Jedoch haben Sie erheblich bessere Chancen, Ihre Mitarbeiter in einemRaum zu konzentrieren, wenn diese nur eine Treppe und keinen Kontinent überwindenmüssen. Sie können natürlich auch mit Teams arbeiten, auf die das nicht zutrifft. Dannmüssen Sie aber die Produktivitätsverluste hinnehmen.

Ein weiterer Faktor kann die Nationalität der Projektmitarbeiter sein. Die allermeistenMenschen kommunizieren in ihrerMuttersprache schneller, effizienter und auchmotivier-ter, als in einer Fremdsprache. Falls Sie die Möglichkeit haben, suchen Sie sich daher einProjekt, das Sie mit hoherWahrscheinlichkeit mit Entwicklern einer einzigen Nationalitätabwickeln können.

Falls die Projektmitarbeiter bereits feststehen, sollten Sie auch deren Enthusiasmus prü-fen. Handelt es sich um Piraten, die gerne in unbekannte Gewässer segeln, um dort reicheBeute zu machen? Dann werden sie begeistert sein, Scrum als Pilotteam ausprobieren zudürfen. Sind die Kollegen eher skeptisch und arbeiten lieber in ihren Routineprozessen?Sind sie mit allen Abläufen zufrieden, so wie sie heute sind? Dann haben Sie eine schwe-re Zeit vor sich. Vielleicht sollten Sie dann doch noch ein wenig weitersuchen. Eine PriseScrumerfahrung schadet Ihren Projektmitarbeitern auch nicht.

Ein weiterer Faktor ist die Komplexität der Technologie im Projekt. Handelt es sich umein Projekt, bei dem Hardware, Serversoftware, Clientsoftware, Datenbanken und mög-licherweise noch mehr integriert werden müssen? Das ist schon mit erfahrenen Teamsschwierig. Suchen Sie für Ihr Pilotprojekt lieber etwas Einfacheres aus. Auch die zugrun-de liegenden Technologien sind bei diesem Punkt relevant. Kennen die Entwickler dieProgrammiersprachen, Klassen, Entwicklungsumgebung, Zulieferprodukte und so weiterbereits, oder ist alles neu?

Solche Projekte eignen sich hervorragend als zweites Pilotprojekt für ein Team, das sichgefunden hat, gerne zusammenarbeitet und auch Scrum bereits beherrscht. Als erstes Test-projekt sollten Sie es eher meiden.

Trotzdem müssen Sie sich die Frage stellen, ob das Projekt überhaupt grundsätzlich fürScrum geeignet ist. Scrumwurde für komplexe Situationen erschaffen, also für Situationen,in denen viele Unklarheiten bestehen. Wenn Sie in der Lage sind, Ihr Projekt bereits imVorfeld präzise zu planen und auch davon ausgehen können, dass diese Planung eintretenwird, dann sollte IhreWahl nicht auf Scrum fallen. In solchen Projekten kann Scrum seineStärken nicht ausspielen.

Der letzte Punkt, auf den Sie achten sollten, ist die Interessenslage Ihrer Stakeholder.Wenn Management und Kunden bereits bestimmte Vorlieben haben, sollten Sie diese be-rücksichtigen. Das gilt auch dann, wenn dafür andere Kriterien nicht mehr erfüllt sind.Sie benötigen unbedingt die Unterstützung dieser Menschen. Verhandeln Sie mit ihnen –wenn sich aber keine Einigung abzeichnet, geben Sie besser nach. Ohne Ihre Stakeholderwird auch das einfachste Projekt scheitern.

In einem Satz zusammengefasst ist ein optimales Pilotprojekt also:Ein wichtiges, nationales, nicht zu komplexes Projekt, das in einem bis drei Monaten

beginnt, nicht länger als sechsMonate dauert, dessenMitarbeiter bereits an einem Standort

10.3 Piloten 71

konzentriert undVollzeit für dieses Projekt abgestellt sowie als Piraten offen fürNeues sind,und das von Ihren Stakeholdern favorisiert wird.

Häufig haben Sie nicht den Luxus, sich Ihr erstes Pilotprojekt aussuchen zu können.Nutzen Sie in diesem Fall das Wissen aus diesem Buch, um eine Risikoanalyse durchzu-führen und einige der vorhandenen Barrieren zu beseitigen. Das Zusammenführen IhrerProjektmitarbeiter in einem Teamraum ist zum Beispiel immer ein lohnenswertes Unter-fangen.

10.3.2 Vorbereitung

Mit der richtigen Vorbereitung können Sie die Erfolgswahrscheinlichkeit Ihres Pilotpro-jektes erheblich steigern. Leider treffe ich bei meiner täglichen Arbeit häufig auf Unter-nehmen, die überhaupt keine Vorbereitung leisten – und dann überrascht sind, wenn dasProjekt Anlaufschwierigkeiten hat. Scrum ist kein Allheilmittel für Ihre Probleme undScrum funktioniert auch nicht von selbst. Es ist harte Arbeit nötig. Bei der Vorbereitungdes Pilotprojektes geht es hauptsächlich darum, die Komplexität3 so weit wie möglich zureduzieren und die Arbeitsfähigkeit des Teams bereits im Vorfeld sicherzustellen.

Nach der Auswahl Ihres Projektes müssen Sie Ihr Team zusammenstellen. Der ProductOwner liegt meistens auf der Hand: Es ist die Person, die das Produkt aus Kundensicht ambesten kennt. Das ist in aller Regel ein Produktmanager. Damit erfüllt er einige der Auf-gaben eines Product Owners – wie zum Beispiel Anforderungen aufnehmen, mit Kundensprechen, Strategien entwickeln und soweiter – sowieso.Was noch fehlt, ist die Zusammen-arbeit mit dem Entwicklungsteam und die ständige Überarbeitung des Product Backlogs.Falls Sie den zuständigen Produktmanager nicht für Ihr Vorhaben gewinnen können, su-chen Sie jemanden, der die Aufgaben so gut wie möglich erfüllen kann – Entwickler sinddazu normalerweise nicht in der Lage. Suchen Sie dann einen Scrum Master. Da Sie sichoffensichtlich aktiv mit der Materie befassen, könnten Sie die richtige Besetzung sein. An-sonsten benötigen Sie eine Person, die Scrumgut kennt undüber psychologischesGeschickverfügt. Je wichtiger das Projekt ist, desto besser muss Ihr ScrumMaster sein. Behalten Sieim Blick, dass Ihr ScrumMaster für die Produktivität des Entwicklungsteams zuständig ist.Er wird auch mit anderenAbteilungen und demManagement über Prozessverbesserungenverhandeln. Wenn sich einer Ihrer Entwickler zu dieser Rolle berufen fühlt, spricht nichtsdagegen. Sorgen Sie aber dafür, dass sowohl Product Owner als auch Scrum Master keineDoppelrollen ausfüllen müssen. Selbst wenn die Personen über alle benötigten Fähigkei-ten verfügen, sind Interessenskonflikte vorprogrammiert. Stellen Sie sich vor, das Projektgerät unter Druck. Soll IhrDoppelrollen-Scrum-Master dann Probleme lösen odermitent-

3 Ich gebrauchedenBegriff „Komplexität“ im Sinne von „Unklarheit“. Je höher die Komplexität, destomehr Unklarheit besteht. In der Folge nimmt die Planungsgenauigkeit ab und die Risiken nehmenzu.Da Sie bei der Einführung von Scrum schon genugUnsicherheit hinsichtlich des Prozesses haben,lohnt es sich, andere Einflussfaktoren zu reduzieren.


wickeln? Soll Ihr Doppelrollen-Product-Owner den nächsten Sprint vorbereiten oder imaktuellen programmieren? Solche Situationen können Sie vermeiden.

Beginnen Sie dann, Ihr Entwicklungsteam zusammenzustellen. Falls bestimmte Per-sonen bereits feststehen, müssen Sie diese lediglich noch bezüglich des weiteren Vorge-hens einbeziehen und an der Auswahl der übrigen Entwickler beteiligen. Alle zusätzlichenTeammitglieder sollten Sie sorgfältig auswählen. Sorgen Sie dafür, dass alle technischenFähigkeiten (Programmierer, Tester, Datenbankspezialisten, Softwarearchitekten, Hardwa-respezialisten, Designer, Anforderungsingenieure . . . ), die für Ihr Produkt relevant sind, imTeam vertreten sind. Insbesondere die Tester sollten Sie nicht vernachlässigen, da Sie nurfertige Software liefern können, wenn diese auch getestet wurde. Eine Gruppe von Men-schen muss erst zu einem Team zusammenwachsen. Diesen Prozess können Sie beschleu-nigen, wenn die bestehenden Teammitglieder in die Auswahl neuer Kollegen einbezogenwerden. Das bedeutet nicht, dass die Entscheidung durch die Entwickler getroffen wer-den muss. Es bedeutet aber durchaus, dass die Meinung der Entwickler ernst genommenwird. Neben den technischen Fähigkeiten müssen auch die weichen Faktoren stimmen.Die Kollegen müssen miteinander arbeiten wollen und können. Dabei darf es auch Kon-flikte geben, solange diese professionell ausgetragen werden. Schwierig sind Situationen,in denen Mitarbeiter überhaupt nicht miteinander arbeiten wollen. In einem Pilotprojekthaben Sie weder die Zeit noch die Nerven, solche Fälle aufzulösen. Suchen Sie daher liebernach einem anderen Mitarbeiter. Ebenfalls schwierig sind Liebeleien zwischen Kollegen.Persönliche Höhen und Tiefen wirken sich unmittelbar negativ auf das Projekt aus undmultiplizieren sich dort, da die übrigen Teammitglieder direkt einbezogen werden.

Wie im vorigen Kapitel schon beschrieben, sollten Sie außerdem auf eine einheitlicheNationalität sowie die Verfügbarkeit an einem einheitlichen Standort pochen. Die einhun-dertprozentige Bereitstellung für das Projekt ist ebenfalls von großer Bedeutung für dieProduktivität. Der wichtigste Punkt ist jedoch, dass die Personen an einem Pilotprojektmit Scrum teilnehmen wollen. Sie werden auf jeden Fall Schwierigkeiten begegnen. WillIhr Team ein Pilot sein, so wird es diese Probleme genießen und mit Leichtigkeit überwin-den. Fühlt sich Ihr Team gezwungen, so wird jedes Hindernis zu einer Tortur.

Haben Sie Ihr Team beisammen, führen Sie schon zwei bis vierWochen vor Projektstartein Kickoff mit allen Teammitgliedern durch. Holen Sie auch den Scrum Master und denProduct Owner dazu. Ziel dieses Kickoffs ist nicht der Projektstart, sondern das gegenseiti-ge Kennenlernen. Lassen Sie den Product Owner kurz in die fachlicheThematik einführen.Auch sollten sich alle Teammitglieder vorstellen. Es hat sich bewährt, anschließend ge-meinsam ein Lokal aufzusuchen. In lockerer Atmosphäre kann man sich ungezwungener„beschnuppern“, als das in Arbeitsräumenmöglich wäre. Ein guter ScrumMaster wird hierzur Hochform auflaufen und die Kommunikation zwischen allen Teilnehmern zum Brum-men bringen.

Neben der Vorbereitung des Teams muss natürlich auch die Umgebung passen. Küm-mern Sie sich um das Projektbudget. Sorgen Sie dafür, dass Sie eine Summe für ungeplanteSonderausgaben haben, die Sie zum Beispiel für zusätzliche Raumausstattung, IT-Zubehöroder auch Pizza ausgeben können. Einige tausend Euro reichen hier und können viel be-

10.3 Piloten 73

wirken. Falls dasmöglich ist, sollten Sie auch dafür sorgen, dass dieses Teilbudget nicht vonanderen Personen abgezeichnet werden muss. Es ist erbärmlich, wenn der Geschäftsfüh-rer eine Pizzabestellung über 100 Euro abzeichnen muss oder das Controlling die Orderwieder zurückpfeift.

BeispielBei einem großen Unternehmen gab es sehr unflexible Prozesse. Insbesondere derGenehmigungs- und Bestellprozess erinnerte an einen Tausendfüßler. Zur Feier einesgelungenen Softwarereleases wurde den Entwicklern ein gemeinsames Pizzaessen inAussicht gestellt, dessen Kosten etwa 240 Euro betrugen. Dieses Versprechen wurdevon einem Mitglied des unteren Managements gemacht und war vom Abteilungsleiterabgesegnet. Als der Tag kam, an dem das Versprechen eingelöst werden sollte, sorgtedas Controlling dafür, dass es keine Pizza gab. Dies sei zu teuer, außerdemwäre dafür zuAnfang des Jahres kein Budget eingestellt worden. Die Folge der Ablehnung war, dassdasManagement des Unternehmens schlagartig jegliches Vertrauen der Entwickler ver-lor. Die Motivation nahm rapide ab und die Kollegen verschwendeten erhebliche Zeitdarauf, sich über Controlling und Management aufzuregen. Das Unternehmen verloran dem Tag das Hundertfache der Pizzakosten durch nicht geleistete Arbeit und in denfolgenden Monaten weitere erhebliche Summen durch eine geringere Motivation. Bisheute wird Aussagen des Managements jeglicher Art sehr kritisch begegnet.

Kümmern Sie sich als nächstes umRäumlichkeiten.Die höchste Produktivität erreichenSie, wenn Ihr komplettes Team inklusive Scrum Master und Product Owner gemeinsamin einem Raum sitzt. Andere Teams sollten nicht dort untergebracht sein. Neben einemBereich für Besprechungen sollte es auch einen abgetrennten Stillarbeitsplatz geben, anden sich Einzelpersonen zurückziehen können, wenn sie besondere Ruhe für eine Aufga-be benötigen. Fenster sollten eine Selbstverständlichkeit sein. Große Whiteboards an denWänden sowie mobile Pinnwände erleichtern die Arbeit insbesondere an schwierigen Zu-sammenhängen. Auch Moderationsmaterial wie Stifte und Klebezettel sollten bereits imVorfeld beschafft werden. Die Kür stellen Pflanzen und anderer Schmuck dar. Am bestenist hier, das Entwicklungsteam mit ein paar Euros ausgestattet selbst in den Baumarkt zuschicken. Diese Maßnahme sorgt dafür, dass der Raum akzeptiert und gemocht wird.

Neben dem Raum, müssen Sie auch für sehr gute Arbeitsmittel sorgen. Von einemTischler würden Sie auch nicht erwarten, ohne Hammer und Säge zu arbeiten. Inter-essanterweise erwarten aber manche Unternehmen von ihren Entwicklern, ohne adäquateWerkzeuge zurechtzukommen. Professionelle Werkzeuge können manchmal teuer sein.Diese Kosten relativieren sich aber sehr stark wenn Sie bedenken, dass schon 1% Pro-duktivität bei einem einzelnen Entwicklungsteam ungefähr 1000 Euro entspricht4. Das

4 Meiner Erfahrung nach kostet ein Entwicklungsteam mit sieben Entwicklern mindestens100.000 Euro imMonat. Natürlich hängt das sehr davon ab, ob Sie es mit internenMitarbeitern oderFremdarbeitskräften zu tun haben. Auch variieren die Stundensätze teilweise stark. Als Daumenwerthat sich dieser Betrag aber bewährt.


Gleiche gilt für die Arbeitsstationen der Entwickler. Eine höhere Leistung der Systemezahlt sich sehr schnell wieder aus. Wenn beispielsweise eine höhere Prozessorleistung desRechners dafür sorgt, dass der Buildvorgang nur eine Minute schneller ist, so sparen Siebei fünf Builds am Tag etwa 100 Minuten pro Monat. Hinzu kommt, dass Entwickler inaller Regel technikverliebt sind. Ihre Motivation steigt, wenn sie auf aktueller Hardwarearbeiten dürfen. Ihr Ziel muss sein, dass Ihre Entwickler auf ihre Arbeitsumgebung stolzsind. Dann werden sie diese lieben, gerne darin arbeiten und sich um sie kümmern.

Hinsichtlich der Arbeitsumgebung sollte Ihr Ziel sein, dass alle Entwickler vom ers-ten Projekttag an reibungslos arbeiten können. Das bedeutet, dass Sie Rechner benötigen(Laptops sind Stand der Technik. Das erleichtert auch Besprechungen, Umzüge und dieKommunikation mit anderen Abteilungen.), ausreichend große Bildschirme, eine schnelleNetzwerkanbindung auch ins Internet, eine geeignete Entwicklungsumgebung (Ihre Ent-wickler wissen, was sie brauchen) und eine Integrationsumgebung, welche die ständigeIntegration des Codes (continuous integration) ermöglicht. Diese Softwarekomponentenmüssen installiert, aber nicht zwingend fertig konfiguriert sein.

BeispielEin Kunde hatte sich keinerlei Gedanken um den Eintritt neuer Mitarbeiter ins Unter-nehmen gemacht. Dadurch geschah es, dass neue Kollegen am ersten Arbeitstag erstden Bestellantrag für Ihren Rechner unterschreiben mussten. War der Rechner dannendlich da – was oft genug sechs Wochen dauerte – so fehlten viele der nötigen Be-rechtigungen. Für jedes Recht und jeden Dienst mussten dann eigene Anträge gestelltwerden. Selbst ein E-Mailkonto wurde nicht automatisch bereitgestellt. Im günstigstenFall dauerte es bei diesem Kunden eine volleWoche, bis ein neuerMitarbeiter halbwegsarbeitsfähig war. Im Regelfall eher drei bis vier.

Bei einem anderen Kunden gab es wohl definierte Eintrittsprozesse. Kam ein neuerMitarbeiter an Bord, so erhielt er am ersten Tag eine etwa einstündige Einführung inseinen Rechner, der selbstverständlich bereits vorhanden, eingerichtet und getestet war.Das größte Problem neuer Kollegen war in aller Regel, sich ein neues Passwort auszu-denken. Arbeiten konnten Sie ab dem ersten Tag.

Haben Sie zudem das Pech, mit verteilten oder verstreuten Teams arbeiten zu müs-sen, so benötigen Sie außerdem sehr gute Konferenztelefone,Webcams für alleMitarbeiter,Headsets für alle Mitarbeiter und eine mobile, hoch auflösende Netzwerkkamera, mit derPlakate,Wände undRäume gezeigt werden können. In solchenKontexten brauchen Sie au-ßerdem Kommunikationssoftware, mit der die einzelnen Teammitglieder sich über eineneinzigen Klick per Videotelefonie5 kontaktieren können. Auch Programme zur Freigabedes Bildschirminhalts sind dann wichtig. Die Freigabe von Quelltexten, Dokumenten undDiensten muss natürlich ebenfalls im Vorfeld geregelt sein.

5 Verwendet habe ich dazu bereits Skype und den Office Communication Server. Andere Produk-te funktionieren natürlich auch, wichtig ist aber, dass die psychologische Hürde die Software aucheinzusetzen gering ist.

10.3 Piloten 75

Eine weitere Dimension der Vorbereitung liegt in der Kommunikation. Einerseits müs-sen Sie dafür sorgen, dass alle Stakeholder wissen, wie das Pilotprojekt ablaufen wird, wannes beginnt, welche Inhalte es hat und so weiter. Andererseits müssen Sie sicherstellen, dassAnforderungen an das Produkt über einen wohl definierten Weg zum Product Owner ge-langen. In vielen Fällen reicht es deutlich zu sagen, dass Anforderungen bei dieser Personeingebracht werden können.Wird dies nicht transparent gemacht, so erschwert das sowohldie Vorbereitung als auch die Durchführung des Projekts. Helfen Sie dem Product Owner,bereits im Vorfeld des Projekts die Produktvision, die Releaseziele und die Sprintziele zudefinieren. Machen Sie allen Projektbeteiligten bewusst, dass nur dann das Projektergebnisstimmen kann, wenn auch der Projektinput passt. Die einzelnen Anforderungen auf Fea-tureebene müssen zu diesem Zeitpunkt noch nicht zwingend vorliegen. Das geschieht inaller Regel in der Vorbereitungsphase. Bei diesen vorbereitenden Tätigkeiten geht es alsoum die grobe strategische Planung.

Sie haben jetzt ein Projekt, ein Team, Räumlichkeiten und Arbeitsmittel. Außerdemsind alle Stakeholder auf das vorbereitet, was als nächstes kommt. Ihr Product Owner weißzumindest grob, was er will. Fangen Sie an!

10.3.3 Implementierung

Die Implementierung eines Pilotprojektes mit Scrum unterscheidet sich nicht von ande-ren Scrum-Implementierungen. Egal ob Pilot oder nicht, sie haben immer mit ähnlichenSchwierigkeiten zu kämpfen. Rechnen Sie damit, dass Ihr Team drei Sprints braucht, umsich zu finden und produktiv zu arbeiten. Je komplexer der Gesamtkontext ist, desto längerkann sich die Findungsphase hinziehen. Ein guter Scrum Master kann sie etwas reduzie-ren. Drei Sprints sind dabei ein guter Daumenwert, nach dem Sie sich richten können. ZuBeginn sollte eine kurze Sprintdauer – ein bis zwei Wochen – festgelegt werden. Das gibtIhnen die Möglichkeit, schneller dazuzulernen und auf Probleme zu reagieren. Ein Pilot-team sollten Sie im Gegensatz zu einem erfahrenen Team nicht zu Beginn vor die Wahlstellen. Geben Sie eine Sprintdauer vor und bitten Sie die Entwickler darum, das für zweibis drei Sprints auszuprobieren, bevor die Dauer nachWunsch des Teams verändert wird6.So vermeiden Sie sinnlose (weil nicht auf Erfahrung basierende) Diskussionen7 und gebeneinen sicheren Rahmen für die Beteiligten vor. Halten Sie sich an die Schritte, die Sie in die-sem Buch gelernt haben. Vermitteln Sie die Dringlichkeit sowie die Strategie. Machen Sie

6 Verschiedene Sprintlängen auszuprobieren macht nicht in jedem Fall aus Sicht des Prozesses Sinn.Oft haben ScrumMaster oder Coach einen recht guten Eindruck davon, was für ihr Team eine guteSprintlänge wäre. Trotzdem ist es wichtig, das Team einzubinden, dessen Meinung wertzuschätzenund die Selbstorganisation zu fördern. Dies kann auch bedeuten, für eine gewisse Zeit eine subopti-male Sprintlänge zu nutzen.7 Die häufigste Diskussion dreht sich dabei darum, dass aus Sicht mancher Entwickler vier Wochen„viel zu kurz“ sind, um ein „sinnvolles“ Produktinkrement zu erstellen. Diese Diskussion verebbtnormalerweise recht schnell, wenn das Team gelernt hat, mit Scrum zu arbeiten.


dem Pilotteam klar, warum es so wichtig ist. Machen Sie es zu etwas Besonderem. SorgenSie für größtmögliche Transparenz.

Bedenken Sie auch, dass ein Pilotteam erst noch lernen muss, wie Scrum funktioniert.Planen Sie daher für die ersten Sprints Zeit für Schulungen ein. Auch werden die normalenScrum Besprechungen länger dauern als bei einem erfahrenen Team.

VorbereitungsphaseDie Vorbereitungsphase dient dazu, alle noch nötigen Vorbereitungen zu treffen, umwirklich loslegen zu können. Diese Vorbereitungsphase wird von manchen Autoren auch„Sprint 0“ genannt. In der Scrum Community gibt es heftige Diskussionen darüber, ob esso etwas wie einen Sprint 0 geben darf. Das besondere an der Vorbereitungsphase ist dabei,dass sie nicht fordert, ein vom Kunden nutzbares Produktinkrement zu erstellen. Dieswiderspricht der Logik eines Sprints jedoch, da die Kernelemente eines jeden Sprints „Fo-kussierung auf den Kunden“ und „Lieferung eines fertigen Produktinkrementes“ sind. DasProdukt dieser Phase ist die Arbeitsfähigkeit des Scrum-Teams, nichts für den EndkundenRelevantes. Daher ist die Bezeichnung „Sprint 0“ unzutreffend und kann im schlimmstenFall ein falsches Verständnis von Scrum fördern. Nehmen Sie besser Abstand von derBezeichnung „Sprint 0“.

Es ist sehr wichtig, dass dieser Zeitraum so kurz wie irgend möglich gehalten wird, aufkeinen Fall länger als vier Wochen. Gerne tendiert man dazu, diese Phase auszudehnen,um möglichst umfassende Konzepte zu entwickeln. Das schießt aber über das Ziel hinaus.Es gibt fünf Aufgaben in der Vorbereitungsphase:

1. Die Entwicklungsumgebung inklusive aller Server muss so konfiguriert werden, dass sieproduktiv für dieses Projekt genutzt werden kann.

2. Der Product Owner muss seine ersten drei Sprints planen, sein Product Backlog erstel-len und schätzen lassen.

3. Das Entwicklungsteam muss sich erste Gedanken zum Aufbau der Software, insbeson-dere zu Technologien und Architektur machen.

4. Der ScrumMaster muss beginnen, aus einem Haufen Individuen ein Team zu formen.5. Alle sonstigen Tätigkeiten, umdieArbeitsfähigkeit des Scrum-Teams herzustellen,müs-

sen ausgeführt werden.

Die Standardkonfiguration erfordert eine lokale Entwicklungsumgebung, in der auchlokal gebuildet und getestet werden kann. Grundsätzlich muss jeder Entwickler auch beimAusfall aller Serversysteme jederzeit voll arbeitsfähig bleiben. Damit später bei der Inte-gration des Codes aller Entwickler möglichst wenige Probleme auftreten, müssen auch soviele Tests wie möglich lokal durchgeführt werden können. Stellen Sie sicher, dass ein ho-her Grad der Testautomatisierung angestrebt wird. Bei einem klassischen Vorgehen habenSie nur eine Testphase am Ende der Implementierungsphase. Die Tests können dort alsoauch manuell erfolgen, da sie sich kaum wiederholen. Das ist bei Scrum anders, denn hiermüssen Sie jeden Sprint – also alle ein bis vier Wochen – vollständig getestete Software be-

10.3 Piloten 77

reitstellen. Das ist mit manuellen Tests nicht zu bewältigen. Entsprechend müssen die Ent-wicklungssysteme in der Lage sein, neben Builds auch automatisierte Tests durchzuführen.Spätestens wenn mehrere Teams am selben Produkt arbeiten, empfiehlt es sich außerdem,eine mehrstufige Serverinfrastruktur zur Verfügung zu stellen. Auf einem System kanndann noch entwickelt und ausprobiert werden, während auf der nächsten Stufe nur voll-ständig lauffähige Software bereitgestellt wird. Dieses Systemkann dann als Abnahme- undReferenzsystem dienen. Einen ähnlichen Effekt erreichen Sie durch eine entsprechendeBranchingstrategie. Was auch immer Sie tun: Stellen Sie sicher, dass Sie zu jedem Zeitpunkteinen vollständig integrierten undmöglichst fehlerfreien Softwarestand zur Verfügung ha-ben. Wenn Sie diese Anforderungen an Ihre Entwickler weitergeben, werden diese dasSystem schnell entsprechend konfigurieren und vermutlich danach auch selbst warten. Ausdiesem Grund ist es auch nicht notwendig, die Konfiguration schon vorab vornehmen zulassen. Das Risiko, dass vorkonfigurierte Systeme den Anforderungen des Entwicklungs-teams nicht genügen und in der Folge neu konfiguriert werden müssen, ist hoch.

Zu Beginn des Projekts hat der Product Owner oft nur eine diffuse Vorstellung vondem, was er umgesetzt haben möchte. Seine Aufgabe während der Vorbereitungsphase istes, seinen Stakeholdern alle initialen Anforderungen zu entlocken. Diese müssen hinsicht-lich ihres Geschäftswertes bewertet und ins Product Backlog eingetragen werden. Hierbeikann der Product Owner sich natürlich auch vom Entwicklungsteam helfen lassen. Dieanschließende Priorisierung kann er allerdings nicht delegieren. Jedes Element des Pro-duct Backlogs muss einen eindeutigen Platz in der linearen Liste zugewiesen bekommen.Dabei hat es sich bewährt, Kriterien mit den Stakeholdern zu vereinbaren, anhand dererdie Einordnung erfolgt. Ein solches Vorgehen objektiviert die Entscheidungen des ProductOwners und vermeidet Konflikte. Ist die erste Version des Product Backlogs fertig, musses vom Entwicklungsteam geschätzt werden. Es ist normal, dass es während der Vorbe-reitungsphase drei oder vier Schätzklausuren8 gibt. Sofern noch nicht geschehen, müssenauch die Release- und Sprintziele für das Projekt erstellt werden. Je zeitlich näher der je-weilige Termin rückt, desto präziser müssen die Ziele formuliert sein. Während der Vor-bereitungsphase muss also für Sprint 1 sehr genau festgelegt werden, was auf Ziel- undFeatureebene erreicht werden soll, während für Sprint 5 auch eine grobeÜberschrift reicht.Erst wenn Product Owner, Stakeholder und Entwicklungsteam verstanden haben, was siein den nächstenWochen undMonaten erwarten dürfen, hat der Product Owner seine Auf-gabe während der Vorbereitungsphase erfüllt.

Ist dem Entwicklungsteam klar, was fachlich von ihm erwartet wird, so muss es begin-nen, sich über die zu verwendendenTechnologien und SoftwarearchitekturenGedanken zumachen. Hüten Sie sich davor, eine komplette Architektur im Voraus definieren zu wollen.Ich habe noch kein Team gesehen, das dies wirklich umfassend geschafft hätte. Viel wichti-ger und zielführender ist es, ein Architekturkonzept zu definieren, das einfach erweiterbarist. Wie Legosteine müssen neue Features ein- und ausbaubar sein. In einem guten Scrum-projekt wächst und verändert sich die Architektur während der gesamten Lebensdauer des

8 Vergleichen Sie dazu auch das Kapitel „Estimation Meeting“ im letzten Teil dieses Buches.


Produktes. Sie werden auch nicht in der Lage sein, alle Technologieentscheidungen vor-ab treffen zu können. Fangen Sie bei den wichtigsten Fragen an und hören Sie auf, wennder Sprint vorbei ist. Die restlichen Fragen müssen Sie dann zu späteren Zeitpunkten klä-ren – was meist auch einfacher ist, da Sie dann bereits über erste Erfahrungen mit demProdukt verfügen. Viele Entwickler versuchen zu argumentieren, dass ohne umfassendeVorarbeiten Entscheidungen irreversibel sein werden. Dahermüssten alle technischen Fra-gen bereits im Vorfeld geklärt werden. Das ist Unsinn. Zum einen werden Sie irgendwannfeststellen, dass die Welt sich weiter dreht und Ihre ursprünglichen Überlegungen falschwaren. Zum anderen sprechen wir hier von Softwareentwicklung und nicht vomHausbau.Selbstverständlich können Sie das Fundament der Software erweitern, wenn Sie bereit sind,die Aufwände dafür zu tragen. Um diese Aufwände so gering wie möglich zu halten ist esbesonders wichtig, Ihre Software modular aufzubauen. Hüten Sie sich davor, auf Kostender Modularität zu schludern – das rächt sich später bitter.

Der ScrumMaster läutet die Vorbereitungsphase normalerweisemit einer Besprechungein, in der nochmals die Ziele, Anforderungen und Beteiligten des Projektes vorgestelltwerden. Man lernt sich kennen und vereinbart, wie man gemeinsam arbeiten wird. Geradein der Anfangszeit eines Pilotprojektes hat der Scrum Master das Risiko und die Chance,großen Eindruck auf sein Team zu machen. Moderiert er überlegt und löst er schon zudiesem frühen Zeitpunkt dringliche Probleme, so gewinnt er den Respekt seines Teamsund hat in der Folge größeren Einfluss. Zeigt er sich als zögerlich und unfähig, so wirder einen bleibenden schlechten Eindruck bei seinem Team hinterlassen. So kann er seinerAufgabe in der Vorbereitungsphase nur noch schwer gerecht werden: damit zu beginnen,aus den Kollegen ein Team zu formen. Dieser Prozess ist zwar nur selten bereits nach ei-nem Sprint abgeschlossen, die entscheidenden Weichen werden aber bereits hier gestellt.Wie genau er das anstellt, ist sehr von der jeweiligen Situation abhängig. Als hilfreich hatsich erwiesen, Besprechungen stark zu moderieren, die Spielregeln (des Teams, von Scrumund des Unternehmens) transparent zu machen, sich auch von seiner menschlichen Seitezu zeigen sowie nach Dienstschluss mit den Kollegen Zeit zu verbringen. Vorzugsweise beiBBB – Billard, Bowling und Bier. Bevor er dafür sorgen kann, dass Spielregeln eingehaltenwerden, muss er diese natürlich erst gemeinsam mit dem Rest des Scrum-Teams erarbei-ten. Besonders wichtig ist dabei die „Definition of Done“9. Sind die Regeln erarbeitet undtransparent, so muss der Scrum Master auch für deren Einhaltung sorgen, bis das Teamsich auf neue Regeln einigt.

Es hängt stark vom jeweiligen Projektkontext ab, welche zusätzlichenMaßnahmennochnotwendig sind, um die Arbeitsfähigkeit des Scrum-Teams herzustellen. Sehr häufig sindSchulungen in Scrumund technischenGebieten notwendig. DieVorbereitungsphase bietetoptimale Bedingungen, um diese durchzuführen, da noch kein konkretes Produkt geliefertwerden muss.

9 Mehr zur Definition of Done erfahren Sie in den weiterführenden Informationen am Ende desBuches.

10.3 Piloten 79

Oft sind auch umfangreiche Beschaffungen nötig. Vielleicht handelt es sich nur umTastaturen und Netzwerkkabel – fehlen diese jedoch, stellt dies ein ernst zu nehmendesProblem dar.

Nicht zu unterschätzen ist außerdem die Kommunikation mit allen Projektbeteilig-ten. Nur wenn diese vollständig informiert und ihre Erwartungshaltungen realistisch sind,kann das Pilotprojekt ein Erfolg werden. Kommunizieren Sie daher so viel Sie können –und darüber hinaus. Nicht umsonst finden Sie in nahezu jedem Kapitel dieses Buches Hin-weise darauf, dass Sie intensiv kommunizieren müssen.

Analysieren Sie, was Ihnen außerdem noch für einen erfolgreichen Entwicklungsstartfehlt. Fragen Sie auch Ihr Team und Ihre Stakeholder. Zögern Sie die notwendigen Maß-nahmen nicht hinaus, sondern schaffen Sie Vertrauen, indem Sie diese ernst nehmen undsofort adressieren.

Sprint 1Im ersten Sprintmuss Ihr Team zumerstenMal etwas potentiell Auslieferbares nach Scrumfertig stellen. Ausgeliefert wird dabei an den Product Owner. Dieser entscheidet dann, obdas Release auch den Kunden erreichen soll. Das gelieferte Produkt muss immer vomKun-den (oder dem Product Owner, seinem Vertreter) nutzbar sein. Quellcode, Testfälle oderPowerPoint-Folien werden normalerweise10 nicht gezeigt. Die ausführbare Software ist dasMaß für die Beurteilung, ob Product Backlog Items umgesetzt wurden, oder nicht.

Im ersten produktiven Sprint ist es normal, dass relativ wenig Funktionalität geliefertwird. Meist sind noch eine Menge organisatorischer Themen zu bewältigen. Auch sindmehr Aufwände für Softwarearchitektur und Konzepte notwendig, als zu späteren Zeit-punkten. Trotzdem ist es absolut notwendig, dass fertige Features produziert werden. Nurwenn die Software das tut, was sie soll, können Sie sicher sein, dass Ihr Teaman alles gedachthat. Fast immer argumentieren unerfahrene Teams, dass sie im ersten Sprint noch nichtsliefern könnten, da zunächst die „Grundlagen“ geschaffen werdenmüssten. DieseMeinungrührt von einer tief verwurzelten traditionellen Arbeitsweise her, in der oft am Anfang dieArchitektur erstellt wurde und später nicht mehr verändert werden durfte. Dieser Ansatzgilt bei Scrum nicht. Im Gegenteil: Die ständige Verbesserung der Architektur gehört zurtäglichen Arbeit dazu. Auch hat Scrum erkannt, dass vorab definierte Architekturen seltenalles können, was die Software benötigt, aber immer Elemente enthält, die nicht gebrauchtwerden. Lassen Sie daher entsprechende Einwände Ihres Teams nicht gelten. Fordern Siees auf, Ihrem Product Owner zu sagen, was es im ersten Sprint an Funktionalität liefernkann. Auch ein „Hello World“ kann im ersten Sprint akzeptabel sein, wenn dadurch be-wiesen wird, dass alle Schichten der Architektur miteinander kommunizieren.

10 Es kann sehr spezielle Konstellationen geben, in denen der Product Owner nur eine Dokumen-tation benötigt. In Forschungsteams ist dies häufiger der Fall. Ähnlich verhält es sich mit Quellcodeund Tests: Es gibt Ausnahmen, aber im Normalfall geht es um ausführbare Software.


BeispielEines meiner Teams – wie schon viele zuvor – ging im ersten Sprint auf die Barrikaden,als ich es ablehnte, vier Wochen lang nur Architekturthemen zu behandeln. Argumentegab es viele, wobei dieWörter „nicht möglich“ die Diskussion dominierten. Ich erklärtedem Team daraufhin ausführlich, welche Kosten es verursachte und welche Umsätzeuns durch einen Monat Verspätung entgingen. Dann fragte ich es, wie sicher sie sichdenn seien, dass die Architektur in einemMonat wirklich fertig wäre? Die Antwort warernüchternd: Die höchste Schätzung lag bei 60%. Ich fragte daraufhin die Entwickler,wie sicher sie sich seien, dass die Architektur in 3Monaten fertig sei. Keine Antwort lagüber 80%. Zuletzt fragte ich, wie sicher sie sich seien, dass die Architektur nach sechsMonaten so perfekt sei, dass wir nicht mehr daran arbeiten müssten? Nur die unerfah-renen Kollegen, frisch von der Uni, wagten hier Schätzungen oberhalb der 80%. Wirdiskutierten daraufhin, wie wir die Funktionsweise des grundlegenden Architekturkon-zepts beweisen könnten. Heraus kam, dass die kleinste Funktion der Softwaremit einerprovisorischen GUI durch alle Schichten umgesetzt werden sollte. Das geschah aucherfolgreich. Das Team hatte das Prinzip verstanden und begann, seine Architektur ge-mäß den jeweiligen Anforderungen Sprint für Sprint zu erweitern. Selbstverständlichmussten oft Teile der Architektur umgeschrieben („refactored“) werden. Das war aberimmer noch billiger, als eine allumfassende Architektur im Voraus zu implementieren.

Im ersten Sprint werden auch erstmals alle Sprint-Meetings11 durchgeführt. BeginnenSie mit einem Review der Ergebnisse aus der Vorbereitungsphase. Wurden die Ziele er-reicht? Welche Restarbeiten sind noch offen? Führen Sie dann eine Retrospektive durch.Wie hat die Zusammenarbeit geklappt? Welche Verbesserungen sollen für Sprint 1 bereitsumgesetzt werden? Lassen Sie sich allerdings nicht darauf ein, Scrum zu verändern, bevores für wenigstens drei Sprints vollständig gelebt wurde.

Fahren Sie mit einem Sprint Planning fort. In diesem Planungsmeeting erhält das Ent-wicklungsteam nochmals einenÜberblick über die angestrebten Ziele des Releases und desSprints. Die zu erarbeitenden Features werden besprochen und imDetail geplant. Falls dasnoch nicht geschehen ist, muss spätestens hier die Definition of Done erstellt werden. Da-vor ist jedeZusage des Teams obsolet, da niemandweiß, was da eigentlich genau inAussichtgestellt wurde. Auch wird spätestens hier ein Task Board für das Team erstellt. Die bestenErgebnisse erzielen Sie mit Papier an der Wand – nutzen Sie dieses Wissen!

BeispielIn einemManagement-Workshop hatte ich meinen Moderatorenkoffer mit vielen bun-ten Klebezetteln dabei. Die anwesenden Manager belächelten mich dafür und fragtennach „richtigen“ Tools. Ich bat sie darum, für die ersten Aufgaben mit dem Papier vor-lieb zu nehmen und sie stimmten zu. Die Arbeit war sehr produktiv. Nach der Mittags-pause wurde dann der Ruf nach einem digitalen Tool wieder lauter. Ich riet davon ab, da

11 Vergleiche auch mit dem Kapitel „Ereignisse“ am Ende dieses Buches.

10.3 Piloten 81

damit nur einer schriebe, während alle anderen Teilnehmer nur zusehen könnten. MeinRat wurde nicht befolgt und es kam genauso, wie es zu erwarten war. Nach wenigenMinuten sprach der Geschäftsführer ein Machtwort: Wir stiegen wieder auf Klebezettelum. Zwar fuhr ein Kollege fort, zu tippen, aber die übrigen Teilnehmer arbeiteten par-allel produktiv mit Klebezetteln. Seitdem wird in jedem Workshop des Unternehmensnur noch mit Klebzetteln gearbeitet. Digitale Tools werden anschließend befüllt.

Es startet die eigentliche Arbeit im Sprint. Die Entwickler beginnen damit, die An-forderungen in ausführbare Software zu verwandeln. Der Product Owner verfeinert seinProduct Backlog, beantwortet Fragen der Entwickler und bereitet den nächsten Sprint imDetail vor. Die schwierigste Aufgabe hat allerdings der Scrum Master: Er muss dafür sor-gen, dass die Entwickler alle Anfangsschwierigkeiten überwinden und zu einem Team zu-sammenwachsen. Es ist völlig normal, dass der Prozess am Anfang noch ein wenig „hakt“,also zu Problemen führt. Teilweise kommt das durch noch auf die alten Prozesse ausge-richtete Schnittstellen zu anderen Abteilungen, teilweise sind aber auch die Menschen imProzess noch unsicher. Beide Themenfelder müssen durch den Scrum Master adressiertwerden. Zusätzlich wird der Sprint 1 dadurch verkompliziert, dass die Entwickler sich inaller Regel in der „Storming“-Phase der Teamwerdung befinden. Das bedeutet, dass jederversucht, seinen Platz im Team zu erkämpfen, die Grenzen austestet und Konflikten nichtaus demWeg geht. Diese Konflikte können nicht vermieden, sondernmüssen ausgetragenund konstruktiv gelöst werden. Die Moderation dieses Prozesses ist Aufgabe des ScrumMasters. Durch die produktiven Auseinandersetzungen entstehen Regeln, an die sich dasTeam fortan hält und das Vertrauen, dass auch mal die Fetzen fliegen dürfen, ohne dassman sich dafür bis ans Ende aller Tage böse ist. Versuchen Sie nicht, diese Konflikte zu un-terdrücken, denn sonst schwelen diese ewig unter der Oberfläche weiter. Unterstützen Siestattdessen deren zügige Lösung.

Am Ende des Sprints sollten Sie unbedingt die erzielten Erfolge feiern. Loben Sie dasScrum-Team, spendieren Sie Pizza oder veranstalten Sie ein Team-Event (Klettergarten,Floßbau oder ähnliches). Das schweißt das Team noch enger zusammen und zahlt sich inForm höherer Motivation und verkürzter Teambildungsphasen schnell aus.

Besonderes Augenmerk sollten Sie auch auf die Retrospektive werfen. Gerade am An-fang ist dieses Instrument besonders wertvoll, da durch den Übergang von alten in neueProzesse noch ein unbefangener Blick vorhanden ist. Die Ergebnisse der ersten Retrospek-tiven holen auch die Probleme an die Oberfläche, über die das Team später sagen wird:„Das ist hier halt so.“

Sprint nZu allen folgenden Sprints kann ich Ihnen nur wenig raten. Der Ablauf ist immer gleich,lediglich die Sprintlänge kann (muss aber nicht) variieren. Jeden Sprint wird ein fertiges,ausführbares Produkt geliefert. Jeden Sprint werden Prozessverbesserungen in der Retro-spektive geplant. Sie werden feststellen, dass sich der Fokus des Entwicklungsteams ganzallmählich weg von Problemen innerhalb des Teams hin zu Impediments in der Organisa-


tion verschiebt. Das ist gut so und zeigt, dass sich das Team gefunden hat.Wenn Sie mit dergleichen Sorgfalt, die Sie für Sprint 1 aufgewendet haben, auch die nachfolgenden Sprintsplanen, stehen Ihre Chancen auf Erfolg gut. Lassen Sie hingegen nach und haben zum Bei-spiel einen unvorbereiteten Product Owner oder einen ScrumMaster, der keine Problemelöst, dann schwinden Ihre Aussichten.

Lassen Sie Fehler zu, aber lernen Sie daraus. Bleiben Sie offen für Neues. Hören Sie an-deren Menschen zu, wenn diese Ihnen einen Rat erteilen. Setzen Sie aber nicht jeden Ratum – wägen Sie gut ab, ob der Vorschlag wirklich auf Sie zutrifft. Sorgen Sie für größtmög-liche Transparenz. Das vermeidet Überraschungen für Sie und für Ihre Stakeholder undermöglicht es Dritten, Sie konstruktiv zu unterstützen sowie aus ihren eigenen Fehlern zulernen.

10.3.4 Häufige Probleme

Die meisten Probleme bei der Durchführung von Pilotprojekten mit Scrum rühren daher,dass darauf verzichtet wird, sich einen Experten an Bord zu holen. Man liest ein Buch oderbesucht ein Training und glaubt danach, man könnte auf erfahrene Coaches verzichten.Oder man versucht Geld zu sparen, indem man sich nur für einige Tage einen Berater anBord holt. Dieses Vorgehen funktioniert zwar, allerdings mussman als Unternehmen dannbereit sein, mehr Fehler zu machen und langsamer vorwärts zu kommen, als das bei einerintensiveren Begleitung durch Berater der Fall wäre.

BeispielIn einem kleinen Unternehmen besuchten einige Führungskräfte Scrum-Trainings undlasen zwei Bücher, die man ihnen als Referenz empfohlen hatte. Man nahm sogar füreinige Tage die Unterstützung eines erfahrenen Coaches in Anspruch. Anschließendversuchte man, Scrum einzuführen. Dabei ging man sehr hemdsärmelig vor und ver-zeichnete neben ein paar Erfolgen auch mehrere Misserfolge. Probleme traten an dieOberfläche, denen man sich jedoch nicht stellen wollte. Das führte zu einer Ablehnungexterner Expertise. Man begann auf diese „Buchschreiber“ zu schimpfen und vertratnach innen und außen, dass die Scrum-Standards einfach nicht auf diesesUnternehmenzuträfen. Sobald ein Berater den „Geruch“ eines Experten hatte, wurde er abgelehnt. DiePraxis sei halt nicht so eindeutig wie die Theorie in den Büchern.

Obwohl dies natürlich stimmt, wurde doch dieHauptregel verletzt: Lerne aus deinenFehlern und löse Probleme, wenn sie auftreten. Heute lebt das Unternehmen weitge-hend chaotische Prozesse und ist nicht weiter als vor fünf Jahren.

Auch wird des Öfteren der Inhalt von Büchern oder Trainings falsch verstanden. OhnePraxiserfahrung sind nur Ausnahmepersönlichkeiten in der Lage, ihre jahrelang antrai-nierten und mehr oder weniger erfolgreich eingesetzten Handlungsmuster aus der Vogel-perspektive zu betrachten und zu verändern. Pilotteams sind häufig so sehr mit den neuen

10.3 Piloten 83

Prozessen beschäftigt, dass sie gar nicht auf die Idee kommen, den Blick zu erheben undaktiv nach Problemen zu suchen. Viele Hindernisse fallen dem Pilotteam daher erst nacheinigen Sprints auf, wenn das Flair des Neuen der Routine gewichen ist. Betrachten wireinige der Fehler etwas genauer, denen ich bei meiner täglichen Arbeit immer wieder be-gegne:

1. Der Glaube, Scrum sei die Lösung für alle ProblemeObwohl so gut wie jede Einführung in das Thema eindeutig darauf hinweist, dassScrum keine Probleme löst, sondern sie nur transparent macht, gibt es immer nocheine Vielzahl von Menschen, die glauben, allein die Einführung von Scrum würde alleProbleme auf einen Schlag lösen. Das ist eine falsche Annahme. Scrum ist wie IhreSchwiegermutter12 : Sie weiß ganz genau, dass ihr Sohn/ihre Tochter eine/n besserenhätte finden können. Da sie aber eine nette Person ist, wird sie Ihnen all Ihre Schwä-chen und Fehler jeden Tag vor Augen halten. Das tut weh. Aber es ermöglicht Ihnen,Ihre Schwächen zu adressieren. Selbstverständlich wird Ihre Schwiegermutter sofortneue Handlungsfelder identifizieren, so dass Sie ständig einem hohen Maß an Kritikausgesetzt sind.Auch wenn Ihre eigene Schwiegermutter diesem Bild nicht entspricht, somacht Scrumgenau das: Die Unzulänglichkeiten Ihrer Organisation aufzeigen, ohne die Problemeselbst zu lösen.Schärfen Sie die Erwartungshaltungen aller Projektbeteiligten (inklusive Ihrer eigenen)dahin gehend. Stellen Sie sicher, dass niemand Scrum für ein Allheilmittel hält. Auchmuss sich jeder darüber im Klaren sein, dass Scrum arbeitsintensiv ist.

2. Falscher/nicht vorhandener Product OwnerViel zu häufig wird auf die Rolle des Product Owners verzichtet, um vermeintlich Geldzu sparen. Die Aufgaben des Product Owners werden dann durch den Scrum Mas-ter oder ein Teammitglied mit übernommen. Das führt zu Rollenkonflikten und einerunzureichenden Aufbereitung der Anforderungen. Wenn aber unklar ist, was erstelltwerden soll, kann auch nichts Vernünftiges dabei herauskommen. Diese Projekte ha-ben in aller Regel mit erheblichen Problemen zu kämpfen, da sich der fehlende ProductOwner in immer neuen Symptomen äußert.Stellen Sie sicher, dass jedem Projektbeteiligten klar ist, dass der Product Owner dieAufgaben eines Produktmanagers hat und das Team inhaltlich führenmuss. Die Abwe-senheit eines guten Product Owners können Sie mit der Abwesenheit eines Taxifahrersin einer fremden Stadt vergleichen. Selbstverständlich können Sie selbst fahren, aberwound wann Sie ankommen, steht in den Sternen. In einem Pilotprojekt fällt die falscheBesetzung dieser Rolle nochmals stärker ins Gewicht, da die übrigen Projektbeteiligtenmit den neuen Prozessen undder Teamfindung beschäftigt sind und somit nicht einmaleinen ernsthaften Versuch unternehmen können, den Mangel zu kompensieren.

12 Dieses Beispiel ist Bestandteil der aktuellen (Februar 2012) Kursunterlagendes Professional ScrumMaster Kurses der Scrum.org.


Wählen Sie den richtigen Product Owner13 aus. Sorgen Sie außerdem dafür, dass erfür das Projekt verfügbar ist. Diese Person muss außerdem den Erfolg des Projekteswollen. Machen Sie ihr die Dringlichkeit bewusst und verstärken Sie ihre intrinsischenMotivatoren.

3. Falscher/nicht vorhandener ScrumMasterÄhnlich wie beim Product Owner wird manchmal zu wenig Wert auf die richtige Aus-wahl des ScrumMasters gelegt. Nach der Lektüre der obigen Kapitel wissen Sie, welcheAufgaben ein ScrumMaster hat. Sie wissen damit auch, dass es hier hauptsächlich umweiche Fähigkeiten geht, Programmierwissen steht nicht imVordergrund.Oftmals ent-scheidet sich einUnternehmen für einen der Entwickler als ScrumMaster. ImEinzelfallkann diese Wahl durchaus richtig sein, jedoch wird in der Praxis selten geprüft, ob diePerson über die psychologischen und soziologischen Fähigkeiten verfügt, die benötigtwerden. Gerade während eines Pilotprojektes ist ein guter ScrumMaster essentiell. Erträgt maßgeblich dazu bei, dass das Projekt zu einem Erfolg oder Misserfolg wird. Ineinem erfahrenen Team kann ein schlechter Scrum Master durch das Entwicklungs-team undden ProductOwner kompensiert werden. In einemPilotprojekt hatman aberkein erfahrenes Team und kann daher auch keineMangelleistung kompensieren. Auchdie Verfügbarkeit des Scrum Masters wirkt sich unmittelbar auf den Projekterfolg aus.Spätestens, wenn Probleme des Teams mit den Worten: „Ich kann dir nicht helfen, ichhabe gerade Wichtigeres zu tun!“ abgelehnt werden, wissen Sie, dass Sie einen Fehlergemacht haben.Sorgen Sie dafür, dass gerade in einem Pilotprojekt ein erfahrener Scrum Master ein-gesetzt und Vollzeit zur Verfügung gestellt wird.

4. Fehlende Fähigkeiten im EntwicklungsteamFehlende Fähigkeiten liegen dann vor, wenn entweder niemand im Team über sie ver-fügt, oder wenn die wissenden Teammitglieder nicht dann verfügbar sind, wenn siegebraucht werden. Das ist zum Beispiel der Fall, wenn der Datenbankspezialist nur zu20% im Projekt ist – wennman ihn braucht, ist er nicht da. Leider ist es zum Zeitpunktder Durchführung eines Pilotprojekts oft nicht möglich, alle Teammitglieder zu 100%bereitzustellen.Analysieren Sie zunächst, welche Fähigkeiten im Entwicklungsteam überhaupt ge-braucht werden. Daraus entstehen Rollen. Besetzen Sie alle Rollen mit fähigen Köpfen.Wo immer möglich, sogar doppelt. Sollten trotz sorgfältiger Besetzung immer nochFähigkeiten fehlen, bauen Sie diese durch Schulungsmaßnahmen auf. Das Einkaufenexterner Ressourcen kann Ihnen zwar kurzfristig helfen, löst aber langfristig Ihr Pro-blem nicht. Machen Sie allen Beteiligten klar, welche Folgen es für die Produktivitäthat, wenn eine Person an mehreren Projekten gleichzeitig arbeiten muss (20% Verlust(vgl. Weinberg 1991) pro zusätzlichem Projekt).

13 Ein paar Hinweise, wie Sie das richtig tun, finden Sie im vierten Teil dieses Buches.

10.3 Piloten 85

5. Fehlende Schulungen„Wer braucht schon Scrum-Schulungen? Immerhin haben wir den ScrumMaster zweiTage lang auf ein Training geschickt!“Solche und ähnliche Denkweisen führen dazu, dass die nötige Ausbildung währendder Projektarbeit erfolgt. Jedes Unternehmen muss die Lernkurve seiner Mitarbeiterbezahlen, daran führt kein Weg vorbei. Sie entscheiden selbst, zu welchem ZeitpunktSie die Kosten tragen wollen undwie transparent diese anfallen. Seien Sie sich aber dar-über imKlaren, dass fehlende Schulungen dazu führen, dass Ihr Team in der Pilotphasemehr Fehler macht als nötig und sich möglicherweise sogar falsche Verhaltensweiseneinschleifen, die Sie später wieder ausbügeln müssen. In jedem Fall billiger und effek-tiver ist es, das komplette Team gemeinsam auszubilden.Auch an fachlichen Schulungen sollte nicht gespart werden.Wenn ein Entwickler nichtweiß, was ein Unit-Test ist oder wie man eine Grenzfallanalyse durchführt, dann istwohl eine Testschulung fällig. Bei anderen Themen gilt das analog. Auch hier müssenSie dieKosten sowieso bezahlen – Sie entscheiden,wann undmit wie vielen Zinsen.DieZinsen entstehen insbesondere bei fachlichen Themen dadurch, dass Ihre Entwicklertechnische Schulden (ohne böse Absicht) aufbauen. Je länger Sie warten, die entspre-chenden Fähigkeiten zu vermitteln, desto größer wird der Berg. Je länger die Kredit-aufnahme zurückliegt, desto höher sind die Zinsen, da der Entwickler sich erst wiederin den alten Code hineindenken und auch entsprechende verbundene Codestellen an-passen muss. Im Schnitt kostet die Beseitigung technischer Schulden das Vierfache14

von dem, was die Vermeidung gekostet hätte.Gerade bei Pilotprojekten müssen Sie darauf achten, auch über alle benötigten Fähig-keiten zu verfügen. Scrum verlangt von Entwicklern mehr, als klassische Prozesse dastun.Natürlichmuss nicht jeder alles können.Aber dieGrundlagen guter Entwicklungs-arbeit15 muss jeder beherrschen. Ihre Mitarbeiter werden sich ungleich schwerer tun,wenn Ihnen diese grundlegenden Fähigkeiten fehlen.

6. Testen außerhalb des TeamsIn Projektkontexten, die nach dem Phasenmodell organisiert sind, erfolgt zunächst diePlanung des Vorhabens, dann die Implementierung des Codes und am Ende die Test-phase. Dies führt dazu, dass der voraussichtliche Fertigstellungszeitpunkt des Projektesbis zumAbschluss der letzten Phase unklar ist. Auchwerden die Fehler erst amEnde ge-funden, was erhebliche Mehrkosten verursacht. Manchmal werden sogar systemischeFehler aufgedeckt, die zu diesem späten Zeitpunkt nicht mehr korrigierbar sind. Trotz-dem hat sich dieses Vorgehen tief in die Köpfe der Menschen gegraben. In der Folgewerden dann Prozesse etabliert, die pseudo-agil den Code implementieren, aber erst in

14 Das glauben Sie nicht? Nun, überlegen Sie einmal, wie teuer es ist, einen Bug während der Ent-wicklung zu fixen. Oder während der Testphase. Oder wenn er beim Kunden ist. Nehmen Sie dazuruhig die Zahlen Ihres eigenen Unternehmens – das ist besser als irgendwelche Statistiken.15 Das englische Wikipedia hat eine recht gute Übersicht über das Thema: http://en.wikipedia.org/wiki/Software_craftsmanship.

http://en.wikipedia.org/wiki/Software_craftsmanship



einer nachgelagerten Testphase validieren. Damit verschenken Sie einige der Vorteileder Agilität. Es liegt de facto kein Scrummehr vor, denn hier ist gefordert, jeden Sprintfertige Software zu liefern. Fertig bedeutet aber in jedem Fall auch getestet.Lösen Sie dieses Problem, indem Sie die Testexperten mit in Ihr Entwicklungsteamintegrieren. Selbst wenn das bedeutet, dass Sie zweimal testen: Einmal während desSprints und einmal in der offiziellen Testphase. Das ist zwar in vielen Fällen Geld-und Zeitverschwendung16 , aber meist prozesskonform genug, um die Erlaubnis zumsprintbegleitenden Testen zu erhalten. Während einer Pilotphase sollten Sie die größt-mögliche Produktivität innerhalb des Rahmens von Scrum erreichen – wenn Sie da-durch gleichzeitig beweisen, dass andere Maßnahmen nicht mehr nötig sind, umsobesser.

7. Zu starker Fokus auf Frameworks und ArchitekturWieweiter oben schon angedeutet, tendieren Softwarearchitekten und andere Entwick-ler häufig dazu, zunächst die gesamte Architektur vorzubereiten, bevor anderer Codeeingecheckt wird. Dieser Ansatz ist leider in den meisten Projekten nicht zielführend,da sich die Anforderungen an die Software selbst und damit auch an die Architek-tur ständig verändern. Es entsteht eine mitunter sehr lange Periode, in der keinerleiGeschäftswert im Sinne von potentiell auslieferbarer Software produziert wird. Selbstwenn das Unternehmen bereit ist, diese Kosten in Kauf zu nehmen, so wird das Ergeb-nis doch meist nicht ausreichen, um alle Anforderungen der finalen Software abzude-cken. Wenn Sie mit agilen Methoden arbeiten, muss auch Ihre Softwarearchitektur denagilen Anforderungen genügen. Sie muss sich also ständig verändern und erweiternlassen, ohne dafür den gesamten bereits erstellten Code ändern zu müssen.Implementieren Sie nur die absolut grundlegenden Dinge vorab. Stellen Sie mit Ih-ren Architekten sicher, dass Ihr Architekturkonzept ständige Veränderungen erlaubt.Bemühen Sie sich, immer nur so viel derArchitektur zu erstellen, wie für die Funktions-fähigkeit der geforderten Features des aktuellen Releases nötig ist. Das ist insbesonderebei relativ kurzen Pilotprojekten wichtig. Beherzigen Sie diesen Rat nicht, so laufen SieGefahr, am Ende nur ein Architekturkonzept und keine lauffähige Software präsentie-ren zu können.

8. Anpassungen an ScrumAchten Sie sehr genau darauf, ob jemand behauptet, dass bestimmte Elemente vonScrumnicht für denKontext diesesUnternehmens passen.Weltweit setzen hunderttau-sende von Unternehmen Scrum ein. Dazu gehören auch Automobilhersteller, Firmenaus dem Militärbereich und Medizintechnikentwickler. Kleine Unternehmen genausowie Großkonzerne.Wenn bei diesen Organisationen Scrum funktioniert, warum solltees bei Ihnen dann nicht funktionieren? Es fällt Menschen schwer, eigenes Fehlverhal-ten einzugestehen. Das gilt auch für die eigenen Unternehmensprozesse. Schließlich

16 Vorsicht: Es gibt auch Kontexte, in denen das sehr sinnvoll ist. Zum Beispiel bei sicherheitskriti-scher Software oder bei Tests, die nicht vom Team innerhalb eines Sprints geleistet werden können.Oder schicken Sie Ihre Entwickler jeden Sprint zur Fahrzeugerprobung nach Skandinavien?

10.3 Piloten 87

hatte man in der Vergangenheit viel Mühe, diese zu implementieren und die Erfolgewaren auch gegeben. Hören Sie den Scrum-Kritikern sehr genau zu. In aller Regel lie-fern sie wertvolleHinweise auf einen Punkt, an demdasUnternehmen ein systemischesProblem hat, das durch Scrum aufgedeckt wird. Nehmen wir ein häufiges Beispiel: „InunseremUnternehmen funktionieren Daily Scrums nicht, weil unsere Entwickler überdrei Zeitzonen verteilt sind. Also machen wir nur noch einmal pro Woche ein DailyScrum.“Die Aussage, dass Daily Scrums über drei Kontinente hinweg nicht richtig funktio-nieren, ist vollkommen korrekt. Der Schluss aber, dass dann Scrum verändert werdenmüsste, ist falsch.Das eigentliche Problem ist, dass das Teamglobal verteilt ist. Auchmitklassischer Produktentwicklung werden Sie feststellen, dass die Kommunikation zwi-schen den Personen nicht wirklich funktioniert. Scrum hat daran nichts verändert –aber es hat das Problem offensichtlich gemacht.Begreifen Sie Vorschläge, Scrum zu verändern, als wertvolle Hinweise für Ihre Wan-delbemühungen. Gerade bei Pilotprojekten, in denen sowieso alles neu und schwierigerscheint, werden solche Wünsche sehr oft vorgetragen. Hören Sie genau hin, bleibenSie hart und lösen Sie die dahinter liegenden Probleme.

9. Flexible SprintdauerWer kennt das nicht: Kurz vor Ende des Sprints kommen die Entwickler vorbei undbehaupten steif und fest, dass sie mit nur einem zusätzlichen Tag Arbeit alles nochschaffen könnten, was im Moment noch unerledigt ist. Warum also nicht das Reviewum einen Tag verschieben?Wenn Sie jetzt dem Vorschlag folgen, haben Sie verloren. Ihre Velocity ist nicht mehrvergleichbar, somit verliert Ihre mittelfristige Planung ihre Gültigkeit. Das Team wirdVorgaben als interpretierbar ansehen – insbesondere, wenn diese zeitlicher Natur sind.Auch haben Sie keinerlei Sicherheit, dass es wirklich bei der angegebenen Überziehungbleibt.In Pilotprojekten geht es darum, Scrum zu erlernen. Bleiben Sie hart. Geben Sie keineMinute Extrazeit. Führen Sie das Review wie geplant durch und übernehmen Sie un-fertige Arbeiten in den nächsten Sprint. Bringen Sie dem Entwicklungsteam bei, dasses die Verantwortung für seine Arbeit selbst trägt.

10. Behandeln eines Pilotprojektes als SerienprojektEin Pilotprojekt beinhaltet größere Risiken als ein Projekt, das in ähnlicher Form schonmehrfach abgewickeltwurde.Gerade bei einer Scrumeinführung trifftdas zu, da Scrumvieles anders macht, als es die Projektbeteiligten gewöhnt sind. Gefährlich wird es,wenn von einem Pilotprojekt die gleiche Prognosesicherheit und Produktivität wie vonanderen Projekten erwartet wird. Damit werden Äpfel mit Birnen verglichen, was Sieals Verantwortlichen für das Pilotprojekt sofort in eine schlechtere Position versetzt.Kommunizieren Sie klar und deutlich, dass es sich um ein Pilotprojekt handelt unddass Vorhersagen entsprechend unsicherer sind. Stellen Sie daher sicher, dass alle In-teressierten ständig ausreichend informiert sind. Das reduziert die Angst vor einemFehlschlag.


11. Fehlende KommunikationKommunikation ist gerade bei Pilotprojekten von immenser Wichtigkeit. Zum einensteht das Pilotprojekt im Kontext eines Organisationsveränderungsprojektes. Zum an-deren hat der Pilot eigene Ziele, die erreicht werden wollen. Scrum ist noch neu füralle Beteiligten, entsprechend groß sind die Spannung und die Unsicherheit. WennSie Glück haben, ist auch die Aufmerksamkeit für Ihr Projekt wesentlich größer alsdas bei normalen Projekten der Fall wäre. Diese Aufmerksamkeit will durch Infor-mationen befriedigt werden. Kommunizieren Sie nicht ausreichend, so kann sowohldas Pilotprojekt als auch Ihr Wandelunterfangen gefährdet werden. Sie verlieren denRückhalt Ihrer Stakeholder. Gerüchte machen die Runde und heizen die Stimmungauf.Tun Sie sich selbst einen Gefallen und informieren Sie alle Beteiligten proaktiv überden Projektfortschritt und Ihr Vorgehen. Stellen Sie darüber hinaus tiefer gehen-de Projektinformationen (Product Backlog, Teamgeschwindigkeiten, Releaseziele,Burndown-Diagramme, usw.) bereit, die sich Interessierte bei Bedarf ansehen können.Dazu darf keine separate Freischaltung in irgendwelchen Programmen nötig sein, dadies die Schwelle erhöht, sich diese Informationen wirklich anzusehen. Vergessen Sieauch nicht, stets Bezug auf die Dringlichkeit und die Vision Ihres Wandelprojektes zunehmen.

12. Unzureichende Kommunikation von ErfolgenEin besonderer Fall der Kommunikation bei Pilotprojekten sind Erfolge. Ein Pilot-projekt hat das Ziel, schnelle Erfolge zu generieren und Erfahrungen für die Zukunftzu sammeln. Diese Erfolge sollten Sie unbedingt auch transparent machen. Das hilftIhren Wandelbestrebungen ebenso, wie Ihnen persönlich und dem Pilotteam. Auchwenn Sie Selbstmarketing nicht mögen, so müssen Sie doch anerkennen, dass Erfolgetransparent gemacht werden müssen, wenn die Organisationsentwicklungsmaßnah-men greifen sollen. Nur zu oft sind Pilotteams erfolgreich, aber keiner weiß es. Tun SieGutes und reden Sie darüber!

13. Pochen auf WerkverträgenInsbesondere Einkauf und Controlling vieler Unternehmen sind es gewöhnt, Fest-preisprojekte zu beauftragen. Scrum ist eher für Dienstverträge geeignet, da nur relativkurzfristige Prognosen über Lieferumfänge gemacht werden und den Mitarbeiternvertraut wird, dass sie gute Arbeit leisten. Auch ist Scrum bewusst, dass Mitarbeiterunter Druck (der automatisch bei Werkverträgen entsteht) anfangen, zu sparen – ins-besondere an der Softwarequalität. Verfügen Sie bereits über ein eingespieltes Team,das an einem bekannten Produkt arbeitet, so sind Werkverträge möglich. Im Kontexteines Pilotprojektes verfügen Sie aber normalerweise weder über das eine noch überdas andere.Versuchen Sie zunächst dieAnforderer von denVorteilen desDienstvertragsmodells zuüberzeugen. Gelingt Ihnen dies nicht, so können Sie das Dilemma nicht selbst lösen.Ihnen bleibt nichts anderes übrig, als eine klassische Planung vorzubereiten, anhandderer Sie ein Festpreisangebot abgeben. Danach können Sie innerhalb des Projektes

10.3 Piloten 89

agil planen. Stellen Sie dabei aber sicher, dass zwei Klauseln17 in den Festpreisvertragmit einfließen: Einerseits muss das Risiko für den Auftraggeber minimiert werden, dasheißt, dieser muss das Recht haben, jederzeit aus dem Vertrag auszusteigen (unter Be-zahlung von ca. 20% des noch nicht geleisteten Auftragsvolumens). Andererseits musssichergestellt werden, dass Änderungswünsche berücksichtigt werden können. Hier-zu sollte eine Klausel besagen, dass der Auftraggeber jederzeit Änderungen einbringenkann, dafür aber Anforderung in gleicher Größe (oder Aufwand oder Kosten) aus dennoch nicht umgesetzten Features (also aus Ihrem Product Backlog) herausstreichenmuss. So schaffen Sie Vertrauen und können vielleicht das nächste Projekt ohne Fest-preisangebot abwickeln.

14. Unzureichende RäumlichkeitenDurch die richtigen Räumlichkeiten können Sie die Produktivität nachhaltig erhöhen.Genauso nachhaltig können Sie diese durch Fehler senken.Wie man einen Raum rich-tig einrichtet, ist eine Wissenschaft für sich und würde den Rahmen dieses Buchessprengen. Für den Anfang reicht es, die Grundregeln zu beachten, damit Sie keine ne-gativen Folgen zu fürchten haben: Setzen Sie das gesamte Scrum-Team in einen Raumohne teamfremde Personen. Dieser Raummuss Fenster haben. Tische und Stühlemüs-sen selbstverständlich den ergonomischen Standards entsprechen. Es sollte Flächen fürStillarbeit und für Besprechungen geben. Die Besprechungsecke darf gerne gemütlicheingerichtet sein, das schafft eine angenehme Atmosphäre. Pflanzen, Bilder und Ähnli-ches sollten durch die Bewohner selbst ausgesucht werden. Beziehen Sie die Teammit-glieder auch in sonstige Fragen der Raumplanung mit ein. Wenn das Team sich etwaswünscht, stehen die Chancen gut, dass dies die Motivation und damit die Produktivitätpositiv beeinflusst. Suchen Sie das Gespräch und hören Sie zu.

15. Nicht ausreichende ArbeitsumgebungObwohl das eine Selbstverständlichkeit sein sollte, statten Unternehmen ihreMitarbei-ter häufig mit veralteten Arbeitsmitteln aus. Das geht so weit, dass mancheMitarbeitersogar ihre privaten Arbeitsgeräte mit ins Unternehmen bringen – der Albtraum jedesSystemadministrators. Von einem Handwerker wird nicht erwartet, dass er mit einemHandbohrer arbeitet, obwohl der auch mal Stand der Technik war. Warum wird dannvonEntwicklern erwartet, dass siemit veraltetenRechnern arbeiten?DieArbeitsstationist der wichtigste Motivationsfaktor für einen Entwickler. Ist sie veraltet und langsam,ist der Mitarbeiter unzufrieden. Ist sie schnell und auf dem neuesten Stand, ist derEntwickler begeistert (es ist erstaunlich, wie viel ein Solid State Laufwerk bringt). Dasrechnet sich für Sie nicht nur in einer höherenMotivation, sondern auch in schnellerenEntwicklungszeiten.Neben der Arbeitsstation selbst lohnt es sich auch, Zeit und Geld inMäuse, Tastaturen,Bildschirme, Webcams, Konferenztelefone, Headsets und so weiter zu stecken. Je ver-streuter ihr Team ist, desto besser muss die Kommunikationsinfrastruktur sein. Ist die

17 Dieses Prinzip heißt „Money for Nothing and Changes for Free“. Es wurde 2008 zum ersten Malvon Jeff Sutherland vorgestellt.


Sprachqualität zu schlecht, werden die Entwickler nicht mehr miteinander sprechen.Denken Sie auch daran, adäquate Entwicklungsserver bereitzustellen. Deren genaueAusgestaltung hängt von Ihrem Projekt ab.Neben der Hardwaremüssen Sie auch einen Blick auf die Software werfen.Word, Excelund Power Point sind ebenso wie andere Büroanwendungen wichtig. Möglicherweisebrauchen Ihre Mitarbeiter auch Visio, ein Dokumentenmanagementsystem oder einProgrammzurMindmap-Erstellung. Fragen Sie Ihr Team, was es braucht, und beschaf-fen Sie entsprechende Lizenzen.

16. Der Glaube, alle meinten es gut mit IhnenAuchwenn dieseAussagewenig populär ist, somuss Sie Ihnen dennoch klar sein: Nichtjeder meint es gut mit Ihnen. Aus den unterschiedlichsten Gründen gibt es Menschen,die gegen Sie arbeiten. Manchmal ist es Angst vorMachtverlust. In anderen Fällen gehtes um eine persönliche Fehde. In wieder anderen Situationen kann es eigenes Karriere-streben sein. Es gibt noch viele weitere Gründe, das Ergebnis ist aber immer dasselbe:Man arbeitet gegen Sie und versucht, Ihr Pilotprojekt zu sabotieren oder Erfolge kleinzu reden.Ich bin der festen Überzeugung, dass Sie damit grundsätzlich umgehen können.Wich-tig ist jedoch, diese Angriffe auch wahrzunehmen. Wenn Ihnen beispielsweise Mitar-beiter verspätet bereitgestellt werden, so wird der Kollege selbstverständlich Gründedafür haben und Ihnen diese auch nennen. Ob er jetzt für oder gegen Sie arbeitet, isteine Frage, die Sie sich stellen müssen. Denken Sie daran: Ihr Pilotprojekt verfügt übereine sehr hohe Visibilität im Unternehmen und ist ein kritischer Erfolgsfaktor für Ih-re Wandelbestrebungen. Scheitert der Pilot, steht auch Ihre Scrumeinführung auf derKippe. Stellen Sie sich daher immer wieder die Frage, welche Ihrer Kollegen zu denUnterstützern und welche zu den Gegnern Ihres Vorhabens zählen.

17. Erfolgreiche Team werden wieder auseinander gerissenEin erfolgreiches Pilotprojekt hat zwei Ergebnisse. Zum einen das Produkt selbst. Zumanderen das erfolgreiche Scrum-Team. Menschen sind keine Ressourcen. Einen Hau-fen Individuen zu einem Team zusammenzuschweißen ist eine nicht zu verachtendeLeistung und gelingt nicht immer. Mit diesem Team können Sie vermutlich noch wei-tere erfolgreiche Projekte stemmen. Reißen Sie die Kollegen jedoch auseinander, so istdie Wahrscheinlichkeit, dass Sie sie in derselben Konstellation wieder vereinen kön-nen, minimal. Mit Ihrem nächsten Projekt fangen Sie also wieder bei Null an. Behal-ten Sie Ihre Teammitglieder im Auge oder lassen Sie das Team zusammen. StartenSie am besten direkt das nächste Projekt mit diesem Team. Wenn Sie das Team tei-len müssen, versuchen Sie möglichst viele der Kollegen gemeinsam einem anderenProjekt zuzuteilen. So haben Sie bereits eine Keimzelle für das nächste erfolgreicheScrum-Team.

18. Sonstige ProblemeEs gibt eine Vielzahl weiterer Probleme. Bei jedem Kunden lerne auch ich etwas da-zu. Wenn Sie ein Hindernis identifiziert haben, benutzen Sie das wichtigste Scrum-Werkzeug – Ihren Kopf. Analysieren Sie die Situation und setzen Sie sich mit Ihrem

10.3 Piloten 91

Team zusammen. Wenden Sie an, was Sie in diesem Buch gelernt haben. Wenn sonstnichts mehr hilft, ziehen Sie einen Experten hinzu. Lernen Sie aus Ihren Fehlern.

10.3.5 Erfolgskontrolle und Reporting

Es gibt Scrum-Berater, die jegliche Form von Kontrolle und Reporting verteufeln. Die-se Haltung ignoriert allerdings die grundlegenden Bedürfnisse einer sich veränderndenOrganisation: zu wissen, wohin der Weg führt und an welcher Stelle wir bereits ange-kommen sind. Es ist von immenser Wichtigkeit, dass Sie sowohl Ziele festlegen als auchkommunizieren, welche Sie bereits erreicht haben. Bei Pilotprojekten bietet es sich an,Zeit-, Kosten-, Qualitäts- und Umsetzungsziele (Features) festzulegen. Mit Scrum solltees Ihnen recht einfach möglich sein, die Zeitziele zu halten – schließlich arbeiten Sie time-boxed18, der Endtermin steht also fest. Auch die Kostenziele sollten kein Problem sein, daIhr Team einmal definiert wird und sich dann nicht mehr verändern sollte, da dies kurz-fristig nur Produktivitätsverminderungen bringt. Klären Sie mit Ihren Stakeholdern dieErwartungshaltung bezüglich der Produktqualität. Beschaffen Sie sich Referenzwerte ausvergangenen Projekten. Bewährt haben sich hier die Metriken „Bugs innerhalb von dreiMonaten nach Auslieferung an den Kunden“ sowie „Summe noch offener Bugs“. SobaldSie die Erwartungen Ihrer Stakeholder kennen, können Sie gemeinsam mit dem Team ei-ne Definition of Done entwickeln, welche die Erreichung der Qualitätsziele gewährleistet.Die unbekannte Größe ist die Anzahl der zu erreichenden Features. Auch hier sollten Siesich um Referenzwerte aus der Vergangenheit bemühen, wobei das sehr schwierig ist. Ei-ne Function-Point-Analyse ist zwar recht objektiv, allerdings auch aufwändig. Selbst diesesVerfahrenberücksichtigt besondereUmstände nicht. Die Vergleichbarkeit mit IhremTeamist daher schwierig. Fokussieren Sie sich lieber auf das Team selbst. Bewerten Sie, wie vielGeschäftswert Ihr Team pro Sprint liefert. Das setzt natürlich voraus, dass die Elemen-te des Product Backlogs hinsichtlich ihres Geschäftswertes vom Product Owner bewertetwurden. Dieser KPI (Key Performance Indicator) zeigt Ihnen buchstäblich, wie viel Siefür Ihr Geld bekommen. Eine zweite sinnvolle Metrik ist die Messung der Teamvelocity19.Diesen Wert müssen Sie sowieso ermitteln, um eine Releaseplanung erstellen zu können.Zwischen mehreren Teams sind die Velocities zwar in der Regel nicht vergleichbar, aller-dings kann die Steigerung gemessen werden. So lassen sich Produktivitätszuwächse sehreinfach ermitteln und darstellen. Aber Vorsicht vor Scharlatanerie: Es ist gängige Praxis,als Basiswert das Ergebnis des ersten Sprints zu nehmen und davon ausgehend Produkti-vitätssteigerungen zu berechnen. Das ist jedoch Augenwischerei, da im ersten Sprint nochviel Unsicherheit herrscht und das Team auchmit anderenDingen wie Architektur und derEinrichtung der Arbeitsumgebung beschäftigt ist. Auch ist eineVelocity erst nach ungefährdrei Sprints stabil. Erst dann ist das Team so eingespielt, dass die Zahl als Referenz taugt.

18 Bei den weiterführenden Informationen finden Sie eine Erläuterung des Begriffes „Timebox“.19 Mehr zumThema Velocity finden Sie am Ende dieses Buches.


Seien Sie sehr vorsichtig mit dem Einsatz von KPIs. Wenn Sie eine Messgröße nichtwertneutral sondern wertend betrachten, wird sich deren Wert verbessern aber der inten-dierte Zweck verschlechtern20 . Ein Beispiel illustriert das besser: Wenn Sie die Anzahl derBugs messen, ist dies erst einmal eine neutrale Information. Sobald Sie diese Informati-on werten und beschließen, dass Ihre Mitarbeiter in Zukunft weniger Bugs produzierenmüssen (vielleicht incentivieren Sie das auch noch), werden diese dafür sorgen, dass diegemessene Zahl der Bugs sinkt. Ihre Kollegen haben dann allerdings nur noch die Zahl vorAugen, nicht mehr die Verursacher der Probleme. Sie werden die einfachstenWege finden,den KPI zu optimieren. Möglicherweise werden Bugs nicht mehr in das zugehörige Systemeingetragen. Oder Bugs werden unbearbeitet geschlossen. Es gibt sogar Fälle, in denen dieEntwickler ihre Telefonnummer in Fehlermeldungen geschrieben haben, damit die Anrufenicht im Support, sondern direkt in der Entwicklung ankommen. Die Kennzahl sieht danntoll aus – der angestrebte Nutzen wird aber nicht erreicht.

Befolgen Sie die folgenden Grundregeln:

1. Messen Sie so wenig wie möglich, aber soviel wie nötig. In den meisten Fällen reichenzwei bis drei gemessene Werte, um daraus vier bis sechs Kennzahlen abzuleiten.

2. Lassen Sie das Entwicklungsteam selbst beurteilen, was eine Kennzahl bedeutet undwasaus dieser Bedeutung an Handlungen abgeleitet werden muss.

3. Versuchen Sie nicht, Ihre Mitarbeiter über Kennzahlen zu motivieren. Wenn Sie Pechhaben, funktioniert das nämlich.

4. Velocity, Geschäftswert und die Anzahl der Bugs sind ein guter Startpunkt für Ihr Kenn-zahlensystem in einem agilen Projekt.

5. Machen Sie die gemessenen Werte für alle Projektbeteiligten transparent.

Der Punkt der Transparenz ist besonders wichtig. Den Erfolg zu messen ist nicht ge-nug. Ihre Stakeholder müssen auch selbst nachprüfen können, ob diese Erfolge wirklicheingetreten sind. Es hat sich bewährt, die gemessenen Größen nicht nur gut sichtbar imTeamraum aufzuhängen, sondern auch bei jedem Sprint Review zu kommunizieren. Invielen Unternehmen gibt es außerdem digitale Dashboards, die sich jederManagementver-treter von seinem Arbeitsplatz aus ansehen kann. In manchen Firmen werden bestimmteFormen des Reportings erwartet. Dies können bestimmte Kennzahlen sein oder bestimmteFormatvorlagen. Machen Sie sich das Leben nicht unnötig schwer und folgen Sie wäh-rend des Pilotprojekts diesen Vorgaben. Falls aus Ihrer Sicht sinnlose Kennzahlen dabeisind, kommunizieren Sie diese nicht aktiv, sondern nur in dem angeforderten Bericht. Ins-besondere Ihr Entwicklungsteam sollten Sie nicht mit unnötigen Zahlen belästigen. Diebestehenden Kennzahlensysteme können Sie später durch ein agiles ablösen. DazumüssenSie aber erst Vertrauen schaffen. Ein Pilotprojekt bietet dafür wunderbare Voraussetzun-gen. Beweisen Sie, dass Ihre Kennzahlen aussagekräftig sind und die wesentlichen Datenliefern!

20 Bekannt geworden ist dieses Prinzip als „Campbell’s law“ beziehungsweise „Goodhart’s law“.

Literatur 93

10.4 Das sollten Sie sich merken

Mit der Vision alleine werden Sie Ihren Wandel nicht erfolgreich umsetzen können. Siebenötigen auch kurzfristige Erfolge. Dabei ist Folgendes wichtig:

1. Je mehr echte Erfolge Sie in kurzer Zeit generieren können, desto besser.2. Streben Sie an, nach spätestens sechs Monaten erste Erfolge vorweisen zu können.3. Nutzen Sie kurzfristige Erfolge, um Ihre Strategie und Vision daraufhin zu prüfen, ob

sie tragfähig sind.4. Menschen werden müde. Wecken Sie sie durch Erfolge wieder auf!5. Kurzfristige Erfolge können Ihre Bemühungen – und deren Kosten – gegenüber der

Geschäftsleitung rechtfertigen.6. Je mehr Erfolge Sie verbuchen können, desto weniger Kritiker werden sich Ihnen in

den Weg stellen.7. Erfolge müssen sichtbar sein.8. Erfolge müssen eindeutig sein, d. h. sie dürfen keinen Makel aufweisen.9. Erfolge müssen für die Mitarbeiter nachvollziehbar und nachprüfbar sein.10. Jeder kurzfristige Erfolgmuss klar im Zusammenhangmit der Vision und der Strategie

stehen.11. Dieser Zusammenhang muss auch stets eindeutig kommuniziert werden.12. Sie benötigen sowohl Führung als auch Management, um kurzfristige Erfolge im Kon-

text langfristiger Visionen zu erschaffen.13. Piloten sind ausgezeichnete Mittel, um Erfolge zu generieren.

Literatur

Kraut R, Streeter L (1995) Coordination in software development. Communications of the ACM38(3):69–81Weinberg G (1991) Quality Software Management: SystemsThinking. Dorset House, New Yorkhttp://en.wikipedia.org/wiki/Software_craftsmanship. Zugegriffen: 25.11.2012Sutherland J (2008) Präsentiert auf der Agile in Toronto, S 30–38. http://jeffsutherland.com/Agile2008MoneyforNothing.pdf. Zugegriffen: 25.11.2012


http://jeffsutherland.com/Agile2008MoneyforNothing.pdf

http://jeffsutherland.com/Agile2008MoneyforNothing.pdf

Scrum - Einführung in der Unternehmenspraxis || Schnelle Erfolge erzielen

Documents

Transcript of Scrum - Einführung in der Unternehmenspraxis || Schnelle Erfolge erzielen