Train. Scrum Kompakt. Angelika Drach, Christoph Mathis

Transkript

1 Train Scrum Kompakt Angelika Drach, Christoph Mathis

2 !! Inhalt! Inhalt' Inhalt!!1! 1! Agile!Grundlagen!..!3! 1.1! Das!Agile!Manifest!..!3! 1.2! Softwareentwicklung!ist!empirisch!.!4! 2! ScrumGKonzepte!!6! 2.1! Wesentliche!ScrumGBegriffe!..!6! 2.2! Ready!and!Done!!9! 2.3! ScrumGRollen!!10! 2.3.1! Product!Owner!..!10! 2.3.2! Umsetzungsteam!.!12! 2.3.3! Der!Scrum!Master!!13! 2.3.4! Wo!ist!der!Projektleiter!geblieben?!!14! 2.3.5! Und!die!Linienmanager?!..!14! 2.4! ScrumGArtefakte!!15! 2.4.1! Product!Backlog!!15! 2.4.2! Der!Sprint!Backlog!!17! 2.4.3! Sprint!Burn!Down!Chart!!18! 2.4.4! Release!Burn!Down!Chart!!19! 3! Agiles!Planen!und!Schätzen!..!20! 3.1! Arbeiten!am!Product!Backlog!.!20! 3.1.1! Pflege!des!Product!Backlog!.!21! 3.1.2! Backlogpflege!( Backlog!Grooming! )!!23! 3.1.3! Technische!und!FeatureGPrioritäten!..!24! 3.1.4! Nichtfunktionale!Anforderungen!und!Restriktionen!.!25! 3.2! Arbeiten!mit!User!Stories!.!25! 3.2.1! User!Story!Format!!26! 3.3! Planen!und!Schätzen!!30! 3.3.1! Relative!Schätzungen!mit!Story!Points!.!33! 3.3.2! Die!Kunst!des!Schätzens!!34! 3.3.3! Planning!Poker!..!35! 4! Scrum!im!Unternehmen!.!37! 4.1! Organisatorische!Gründe!für!Ineffektivität!..!37! 4.2! Agile!Werte!im!Unternehmen!verankern!.!40! 4.3! Agiles!Controlling!und!Reporting!..!41! 4.4! Das!Projektgedächtnis!organisieren!!42! 4.5! Buchhaltung!und!Abrechnung!!43! Index!..!44!!improuv!GmbH!! 1!

3 Inhalt!!!!!!!! 2!!!improuv!GmbH!!

4 !! Agile!Grundlagen!! 1! Agile'Grundlagen' Agile!Strukturen!und!Entwicklungen!haben!sich!durchgesetzt,!weil!sie!nachhaltig!einige! Vorteile!für!Unternehmen!und!Entwickler!bieten.!Das!ist!eine!WinGWinGSituation!und! wenn!wir!diese!nutzen!wollen,!um!unsere!kollegen!und!unsere!firma!von!agilen! Arbeitsweisen!zu!überzeugen,!sollten!wir!die!Vorteile!für!beide!Seiten!parat!haben.! In!diesem!Abschnitt!wollen!wir!über!diese!Vorteile!reden!und!die!allgemeinen! Hintergründe!etwas!ausleuchten.! 1.1! Das'Agile'Manifest' Das! Agile!Manifest,!das!im!Jahr!2001!von!17!prominenten!Personen!aus!der! Softwareentwicklung!geschrieben!wurde,!beschreibt!folgende!grundlegenden!Werte! und!prinzipien:! Agile'Werte' Im!Agilen!Manifest!sind!folgende!Prinzipien!als!grundlegend!aufgeführt:!! Individuen und Interaktionen über Prozesse und Werkzeuge Laufende Software über umfassende Dokumentation Kooperation mit dem Kunden über Vertragsverhandlungen Reaktion auf Veränderung über Planerfüllung Abbildung!1.1:!Prinzipien!im!Manifest!!!improuv!GmbH!! 3!

5 Agile!Grundlagen! Ausführlicher!heißt!es:!!! Unsere!erste!Priorität!ist!es!den!Kunden!durch!frühe!und!kontinuierliche!Lieferung! werthaltiger!software!zufriedenzustellen!!!! Wir!begrüßen!veränderte!Anforderungen,!auch!in!einer!späten!Entwicklungsphase.! Agile!Prozesse!nutzen!Veränderungen!als!Konkurrenzvorteil.!!!! Häufige!Auslieferung!laufender!Software!alle!paar!Wochen!bis!alle!paar!Monate,!mit! einer!präferenz!zu!kürzeren!intervallen.!!!! Anwender!und!Entwickler!arbeiten!das!ganze!Projekt!täglich!zusammen!!!! Projekte!werden!um!motivierte!Personen!aufgebaut.!Gib!ihnen!die!nötige!Umgebung! und!unterstützung!und!vertraue!ihnen,!ihre!arbeit!zu!machen.!!!! Die!effizienteste!und!effektivste!Methode!zur!Übermittlung!von!Informationen!mit! und!innerhalb!eines!entwicklungsteams!ist!die!direkte!kommunikation!(facegtogface).!!!! Laufende!Software!ist!das!primäre!Maß!für!den!Arbeitsfortschritt.!!!! Agile!Prozesse!fördern!nachhaltige!Entwicklung.!Sponsoren,!Entwickler!und! Anwender!sollten!kontinuierlich!ein!konstantes!Entwicklungstempo!beibehalten.!!!! Kontinuierliche!Aufmerksamkeit!für!technische!Exzellenz!und!gutes!Design!stützt! agile!entwicklung!!!! Einfachheit!G!die!Kunst,!unnötige!Arbeit!zu!vermeiden!G!ist!essentiell.!!!! Die!besten!Architekturen,!Anforderungen!und!Designs!entwickeln!sich!in! selbstorganisierenden!teams!!!! Das!Team!reflektiert!in!regelmäßigen!Abständen!über!die!Verbesserung!seiner! Arbeitsweise,!verbessert!sie!und!passt!sie!an.! 1.2! Softwareentwicklung'ist'empirisch' Seit!vielen!Jahren!hat!es!eine!Menge!Bestrebungen!gegeben,!die! handwerkliche!und! unkontrollierte!softwareentwicklung!unter!kontrolle!zu!bringen.!dabei!stand!das! Paradigma!der! Industrialisierung!im!Vordergrund!mit!dem!in!anderen!Industrien! bisher!als!unerreichbar!erscheinende!produktivitätssteigerungen!erreicht!worden!waren.!! Die!wesentlichen!Elemente!davon!sind:!!! Eine!Festlegung!des!Prozesses! von!außen,!d.h.!die!einzelnen!arbeitsschritte!werden! vor!der!ausführung!festgelegt!g!in!der!regel!von!einer!anderen!person!als!den! Ausführenden.!!! Aufteilung!in!viele!kleine!Einzelschritte,!die!jeder!für!sich!gut!messbar!und! kontrollierbar!sind.!! Um!diese!Ziel!in!der!SoftwareGEntwicklung!zu!erreichen,!unternahm!man!große! Anstrengungen,!standardisierte!Prozesse!zu!entwerfen!und!zum!Teil!mit! Toolunterstützung!durchzusetzen.!Beispiele!hiefür!sind!das!VGModell,!Prince2!und! 4!!!improuv!GmbH!!

6 !! Agile!Grundlagen! andere.!dieser!ansatz!hat!in!der!softwareentwicklung!allerdings!nie!wirklich!gut! funktioniert!g!so!war!in!den!1980er!jahren!viel!die!rede!von!der! Softwarekrise.!! So!lange!man!in!einem!relativ!stabilen!Umfeld!überschaubare!BatchG!und!ReportingG Systeme!schrieb,!konnte!man!aber!einigermaßen!über!die!Runden!kommen.!! Mit!den!heutigen!Softwaresystemen!ist!man!damit!endgültig!an!eine!Grenze!gestoßen! und!man!kommt!nicht!mehr!umhin!anzuerkennen,!dass!softwareentwicklung!(fast! immer)!ein!empirischer!prozess!ist:!!!! Heutige!Softwaresysteme!sind!wesentlich!umfangreicher.!!!! Die!Umgebung!und!Voraussetzungen!sind!nicht!vollständig!definiert.!!!! Anforderungen!ändern!sich!über!die!Zeit.!!!! Das!Wissen!über!die!beste!Vorgehensweise!ist!unvollständig.!!!! Das!System!ist!komplex.! Abbildung!1.2:!Definierter!Prozess,!empirischer!Prozess! In!der!Konsequenz!hängt!der!Erfolg!eines!SoftwareGSystems!von!folgenden!Prämissen! ab:!!!! Frühes!und!häufiges!Feedback!zum!entstehenden!System!zu!bekommen,!sowohl!zu! Anforderungen!als!auch!zur!Lösung!G!z.B.!durch!frühzeitiges!und!häufiges! Demonstrieren!der!laufenden!Teillösungen!( running!increments ).!!!! Alle!Beteiligten!können!problemlos!Änderungen!und!neue!Erkenntnisse!reagieren! und!die!anforderung!und!die!lösung!anpassen.!!!improuv!gmbh!! 5!

7 ScrumGKonzepte!!! Effektive!Kommunikation!zwischen!allen!an!der!Entwicklung!Beteiligten,!so!dass!das! geschäftliche!und!technische!wissen!für!jeden!verfügbar!ist,!der!es!benötigt.!oft!ist! das!effektivste!mittel!zur!kommunikation!das!gesprochene!wort.! Agile!Prinzipien!basieren!auf!diesen!Einsichten.!Daher!eignet!sich!agile!Entwicklung!für! den!allergrößten!teil!der!softwareentwicklung.! 2! Scrum?Konzepte' 2.1! Wesentliche'Scrum?Begriffe' In!Scrum!gibt!es!einige!Begriffe,!die!im!normalen!Sprachgebrauch!nicht!verwendet! werden!oder!mit!etwas!anderen!bedeutungen!verbunden!sind:!! <;&($"=/'> H2#/I"<;&($ K02$ ABC"D00E4 Return Return Cancel Gift-wrap Voucher Gift-wrap Cancel Voucher Abbildung!2.1:!Scrum!Flow!! Der'Product'Owner'' hat!die!rolle!des!auftraggebers!bzw.!kunden!und!trägt!die!hauptverantwortung!für!den! geschäftlichen!erfolg!des!zu!entwickelnden!produkts.!im!scrumgprozess!ist!er!oder!sie! während!der!gesamten!projektdauer!präsent!und!u.a.!für!die!erstellung!und!pflege!einer! priorisierten!liste!offener!features,!des!product!backlog!zuständig.!! Der'Scrum'Master'' ist!der!hauptverantwortliche!für!die!implementierung!des!scrumgprozesses,!d.h.!der! Organisation!der!Zusammenarbeit!mit!dem!Mitteln!von!Scrum!und!die!Einhaltung!der! 6!!!improuv!GmbH!!

8 !! ScrumGKonzepte! dazugehörigen!prinzipien.!er!oder!sie!ist!moderator!und!coach,!beseitigt!hindernisse! und!stellt!sicher,!dass!das!team!effektiv!arbeiten!kann.!! Das'Team'oder'auch'Umsetzungsteam' ist!nach!scrum!das!team!der!programmierer,!systemarchitekten,!tester!und!allen! anderen!beteiligten!softwarespezialisten!und!trägt!die!hauptverantwortung!für!die! technische!umsetzung!der!anforderungen.!dazu!gehören!die!selbstorganisierte! Entwicklungsarbeit!während!des!Sprints!und!die!Beratung!des!Product!Owner.! Das'Scrum?Team' Product!Owner,!Scrum!Master!und!Team!haben!ein!gemeinsames!Interesse!an!einem! Projekterfolg!!in!ihren!jeweiligen!Rollen.!Sie!bilden!damit!auch!so!etwas!wie!ein!Team.! Um!die!beiden!TeamGBegriffe!abzugrenzen,!nennt!man!diese!alle!zusammen!das!ScrumG Team.! Der'Sprint' ist!eine!meist!zweig!bis!vierwöchige!entwicklungsphase,!in!der!das!team! selbstorganisiert!an!der!umsetzung!der!für!diesen!zeitraum!festgelegten!anforderungen! arbeitet!und!dabei!potenziell!auslieferbare!produktinkremente!erstellt.!! Der'Product'Backlog' ist!eine!priorisierte,!dynamische!anforderungsliste!für!ein!projekt.!alle!anforderungen! an!das!umsetzungsteam!stehen!im!product!backlog.!die!obersten!einträge,!die!in! nächster!zeit!umgesetzt!werden,!sind!detailliert,!die!späteren!können!noch!allgemeiner! formuliert!sein!und!werden!kontinuierlich!konkretisiert,!wie!sie!nach!oben!wandern.!er! ist!eigentum!des!product!owner.! Der'Sprint'Backlog' ist!eine!priorisierte!liste!aller!aufgaben!zur!umsetzung!der!features,!die!für!den! aktuellen!sprint!ausgewählt!wurden!!er!enthält!die!aktivitäten,!die!für!den!aktuellen! Sprint!geplant!sind.!Er!ist!Eigentum!des!Teams.! Das'Sprint'Burn'Down'Chart' ist!die!täglich!aktualisierte!visuelle!darstellung!der!aufgaben,!die!das!team!während!des! aktuellen!sprints!noch!zu!erledigen!hat,!und!ist!ebenfalls!eigentum!des!teams.! Der'Impediment'Backlog' ist!eine!liste!mit!hindernissen,!die!das!entwicklungsteam!bei!der!arbeit!stören.!es!wird! vom!scrum!master!geführt,!der!dafür!sorge!trägt,!diese!hindernisse!möglichst!schnell!zu! beseitigen!und!dies!mit!dem!impediment!backlog!transparent!macht.!!improuv!gmbh!! 7!

9 ScrumGKonzepte! Das'Daily'Scrum'Meeting' ist!ein!(maximal!15gminütiges)!zusammentreffen,!in!dem!sich!die!teammitglieder! während!eines!sprints!täglich!synchronisieren.! Das'Sprintplanungs?Meeting' vor!jedem!sprint!ist!ein!zusammentreffen,!in!dem!das!team!entscheidet,!wie!viele!der! am!höchsten!priorisierten,!vom!product!owner!definierten!features!es!im!nächsten! Sprint!fertigstellen!kann,!und!diese!in!technische!Aufgaben!(Tasks)! übersetzt.!am!ende! des!meetings!steht!ein!abgestimmtes!sprintgziel,!zu!dem!sich!das!team!verpflichtet! (commitment).! Das'Sprint'Review'Meeting' am!ende!eines!sprints!ist!ein!termin,!in!dem!das!team!die!im!sprint!umgesetzten! Features!beziehungsweise!Tasks!dem!Product!Owner!und!gegebenenfalls!weiteren! Stakeholdern!demonstriert!und!der!Product!Owner!diese!abnimmt.! Die'Retrospektive' ist!der!rückblick!nach!jedem!sprint,!in!dem!das!team!den!entwicklungsprozess!und!die! Zusammenarbeit!in!der!vorangegangenen!Phase!darauf!hin!analysiert,!welche!Dinge! hinderlich!und!welche!förderlich!waren.!ziel!ist!es,!die!gewonnenen!erkenntnisse!bereits! im!projektverlauf!umzusetzen,!sodass!ein!kontinuierlicher!verbesserungsprozess! entsteht.!! Lernen"O"Was"lief"gut,"was"lief"weniger"gut?! Abbildung!2.2:!Sprint!Retrospektive! "improuv"gmbh""agile"leadership" "h7p://improuv.com"! 8!!!improuv!GmbH!!

10 !! ScrumGKonzepte! 2.2! Ready'and'Done' Die!Zielsetzung,!nach!jedem!Sprint!fertige!Software!abzuliefern,!führte!in!Scrum!zu!zwei! weiteren!fachbegriffen,!die!den!inhalt!des!wortes! fertig!etwas!genauer!definieren:! ready!und! done.! Ready!bezieht!sich!auf!die!Anforderung:!Ein!Feature!muss!vollständig!geklärt!sein!(das! heißt:!priorisiert,!geschätzt!und!verstanden),!damit!sich!das!team!zu!seiner!umsetzung! verpflichten!kann.!nur!wenn!es!in!diesem!sinne! ready!ist,!darf!es!in!einen!sprint! aufgenommen!werden.! Done!bezieht!sich!auf!die!geschriebene!Software.!Eine!Umsetzung!ist! done,!wenn!sie! den!vereinbarten!qualitätskriterien!genügt!(definition!von!done)!und!wenn!sie!im!sprint! Review!präsentiert!und!abgenommen!wurde.! Zum!Beispiel!können!Team!und!Product!Owner!vereinbaren:!Sie!muss!nachhaltig!und! beweisbar!funktionieren,!getestet!sein!und!über!eine!automatisierte!testsuite!verfügen.! Das!kann!man!sehr!weit!treiben:!zum!Beispiel!mit!der!Forderung,!dass!das!Team!nach! jedem!sprint!oder!sogar!nach!der!integration!jeder!einzelnen!user!story!lieferfähig!ist.!!,-.$-/!"#$%&,-&#01"-23.- ()*%%$%+!"#$% &'(")*+#,$", &'-"*./0+1+ &'2)34)3*3")+ 54," &'3627"6",8")+ &'-"+"*+"+ &'3,+"-)3")+ 5 9*")':+4)3"* ;<*73"=")>#)"*?)4$<@8,@)"6",+ Abbildung!2.3:!Definintion!of!Ready!and!Done! Manche!ScrumGTeams!erstellen!spezifische!Definitionen!von!Done!auch!für!Tasks,! Sprintziele!und!Releases.! Diese!Konzepte!stammen!ursprünglich!aus!der! LeanGProzess!Organisation:!bei! Übergaben!fokussiert!man!auf!perfekte!Qualität!des!übergebenen!Produkts,!d.h.!man! verlagert!eine!eingangskontrolle!eines!fertigungsschritts!hin!zum!lieferanten!und! etabliert!dort!eine!ausgangskontrolle.!ready!und!done!sind!solche!übergaben:!ready!ist! '!improuv!gmbh!! 9!

11 ScrumGKonzepte! die!übergabe!einer!ausreichend!aufgearbeiteten!anforderung!an!das!team!und!done!ist! die!übergabe!des!integrierten!produktginkrements!zurück!an!den!product!owner.! 2.3! Scrum?Rollen' Scrum!beschreibt!drei!Rollen,!die!gemeinsam!dafür!sorgen,!dass!im!ScrumGProjekt! produktiv,!regelmäßig!und!zuverlässig!neue!wertvolle!funktionalität!geliefert!wird:!!!! Product!Owner!!!! Umsetzungsteam!!! Scrum!Master! Daneben!gibt!es!noch!weitere!Personengruppen,!wie!die!Kunden,!Benutzer!,! Fachbereiche!oder!Management,!die!jedoch!in!Scrum!keine!eigene!Rollenbezeichnung! erhalten,!häufig!wird!für!diese!personen!auch!der!begriff! Stakeholder!verwendet.! Scrum Master Team Product Owner Benutzer Lieferung Abbildung!2.4:!Das!Scrum!Team! Scrum Team Kunden Stake Holder 2.3.1! Product'Owner' Product!Owner!ist!immer!eine!einzelne,!konkrete!Person,!denn!nur!so!ist!gesichert,!dass! es!konsistente!antworten!auf!rückfragen!und!eine!eindeutige!priorisierung!gibt.!in! größeren!projekten!kann!er!oder!sie!aber!durchaus!ein!eigenes!unterstützungsteam!von! Spezialisten!(Product!Owner!Team)!haben.!Möglicherweise!gibt!es!mehrere! Entwicklungsteams!mit!jeweils!einem!Product!Owner,!und!diese!bilden!selbst!ein!Team.! Ist!Letzteres!der!Fall,!ist!in!der!Regel!ein!Chief!Product!Owner!für!die!Integrität!und!die! Qualität!des!Gesamtprodukts!verantwortlich.!Und!es!bleibt!dabei:!Jedes! Entwicklungsteam!hat!genau!einen!Product!Owner!als!primären!Ansprechpartner.! Dieser!trifft!die!relevanten!Entscheidungen!über!Details!der!Anforderungen!und!deren! Priorität.! Der!Product!Owner!!! definiert!produktgfeatures!und!beantwortet!fragen!zur!geforderten!funktionalität,!!! priorisiert!product!backloggeinträge!abhängig!von!ihrem!geschäftlichen!wert!und! ihrem!risiko!und!konsolidiert!die!anforderungen!der!anderen!stakeholder,!!!! entscheidet!über!releasegdaten!und!den!umfang!des!produkts,!! 10!!!improuv!GmbH!!

12 !! ScrumGKonzepte!!! passt!die!featuregliste!beziehungsweise!product!backloggeinträge!und!prioritäten!vor! jedem!sprint!an,!!!! akzeptiert!ergebnisse!als! done!oder!weist!sie!zurück,!!! ist!verantwortlich!für!das!finanzielle!ergebnis!des!projekts!(engl.! Return!On!Invest,! ROI).!! Unterschiede'zum'traditionellen'Auftraggeber' Insgesamt!hat!der!Product!Owner!eine!wesentlich!aktivere!Rolle!während!der!gesamten! Projektlaufzeit!als!der!traditionelle!Auftraggeber.!Bei!Projektstart!hat!er!noch!nicht! notwendig!alle!anforderungen!im!detail!formuliert,!sondern!minimal!nur!die!für!die! ersten!sprints.!während!die!entwickler!an!der!ersten!umsetzung!arbeiten,!muss!der! Product!Owner!mit!Unterstützung!des!Teams!die!nächsten!Anforderungen!präzisieren.! Außerdem!ist!es!seine!Aufgabe,!für!Fragen!und!Klärungen!während!des!Sprints!zur! Verfügung!zu!stehen.!In!der!Realität!gehören!Präzisierungen!und!sinnvolle!Anpassungen,! die!sich!aus!den!erfahrungen!während!der!umsetzung!ergeben,!zum!ganz!normalen! Tagesgeschäft.!Keiner!erwartet,!dass!Anforderungen!unveränderlich!vollständig!definiert! sind.!! Generell!vertraut!Scrum!im!Hinblick!auf!die!Schnittstelle! AnfordererGEntwickler!lieber! auf!facegtogfacegkommunikation!anstelle!von!geschriebener!dokumentation.! Anforderungen!sind!also!bevorzugt!das!Resultat!von!Gesprächen!und!Verhandlungen!als! von!verträgen.!typischerweise!kommt!das!geschäftsgknowghow!vom!product!owner,! das!technische!knowghow!kommt!vom!entwicklungsteam,!gemeinsam!können!sie!dann! das!beste!resultat!konzipieren.! Die!zweite!Aufgabe!des!Product!Owner,!die!er!kontinuierlich!zu!erfüllen!hat,!ist!die! Abnahme!der!Ergebnisse!am!Ende!jedes!Sprints!!im!traditionellen!Projekt!geschieht!das! oft!ganz!am!ende!der!projektlaufzeit.!! Der!Product!Owner!hat!noch!eine!zweite!Sichtweise!neben!der!Arbeit!mit!dem!Team:!Er! muss!mit!verschiedenen!stakeholdern!kommunizieren!und!eine!gesamtsicht!des! Produktes!!herstellen,!die!in!den!linearen,!priorisieren!Backlog!eingeht.! Normalerweise!braucht!der!Product!Owner!50!bis!100!%!seiner!Zeit!für!die!Arbeit!im! Projekt.! Wünschenswerte'Attribute'eines'Product'Owner' Um!seine!Rolle!adäquat!ausfüllen!zu!können,!sollte!ein!Product!Owner! Entscheidungskompetenz!bezogen!auf!das!Produkt!haben,!das!im!Projekt!realisiert! werden!soll.!auch!hohe!fachliche!kompetenz!ist!für!diese!rolle!unverzichtbar:!er!oder! sie!muss!den!anwendungsbereich!der!künftigen!software!gut!kennen!und!die! Konsequenzen!von!geschäftlichen!und!technischen!Entscheidungen!verstehen.!! Generell!ist!es!nicht!ungewöhnlich,!dass!ein!Linienvorgesetzter!der!Teammitglieder!die! Rolle!des!Product!Owner!übernimmt.!Es!ist!aber!nötig,!dass!er!die!Selbstorganisation!des!!improuv!GmbH!! 11!

13 ScrumGKonzepte! Teams!respektiert!und!seine!persönlichen!oder!Bereichsziele!nicht!im!Widerspruch!zu! den!projektzielen!stehen.! 2.3.2! Umsetzungsteam' Das!Team!wandelt!gemeinsam!effektiv,!regelmäßig!und!zuverlässig!Anforderungen!in! ProduktGInkremente!um.!Seine!Mitglieder!haben!mehr!Freiheiten!und! Entscheidungskompetenz!als!Programmierer!in!Softwareentwicklungsprojekten!mit! traditioneller!steuerung.!das!umsetzungsteam!!! organisiert!sich!und!seine!arbeit!selbst,!!! schätzt,!wie!viele!der!am!höchsten!priorisierten!features!aus!dem!product!backlog!es! in!einem!sprint!liefern!kann,!!! verpflichtet!sich!auf!ein!sprintgziel!(engl.! commitment! )!,!!! besteht!typischerweise!aus!5!bis!9!personen,!!! arbeitet!in!einem!gemeinsamen!teamraum!zusammen,!!! verfügt!über!alle!notwendigen!kenntnisse,!um!das!zielprodukt!zu!liefern:!entwickler,! GUIGDesigner,!Tester!etc.! Performing Forming Storming Norming Adjourning (Tuckman 1965, 1970, Bates, 1965) Abbildung!2.5:!Teamphasen!nach!Tuckmann! Die!TeamGMitglieder!!! arbeiten!idealerweise!funktionsübergreifend!und!ohne!festgelegte!rollen,!wie!tester,! Entwickler,!Designer.!In!der!Praxis!ist!das!nicht!immer!möglich,!wir!erwarten!aber!auf! jeden!fall,!dass!die!teammitglieder!bereit!sind,!auch!die!kollegen!in!aufgaben!neben! ihrem!spezialgebiet!zu!unterstützen.!!! arbeiten!normalerweise!vollzeit!im!projekt!mit!(ausnahmen!möglich!bei! unterstützenden!funktionen!z.b.!für!systemadministratoren).!!!! wechseln!bei!mitarbeit!in!mehreren!teams!ihre!zugehörigkeit!niemals!während!eines! Sprints.!! 12!!!improuv!GmbH!!

14 !! ScrumGKonzepte!!! sind!kollektiv!für!die!umsetzung!des!commitments!und!die!demonstration!des! ProduktGInkrements!zum!SprintGEnde!verantwortlich.!! Scrum!beschreibt!keine!spezialisierten!Rollen!für!die!einzelnen!Teammitglieder.! Vielmehr!wird!nur!definiert,!dass!das!Team!kollektiv!für!die!Erreichung!des! versprochenen!projektfortschritts!verantwortlich!ist.!daraus!ergibt!sich!die!forderung,! dass!alle!notwendigen!fähigkeiten!im!team!verfügbar!sein!müssen.! 2.3.3! Der'Scrum'Master' Der!englische!Begriff! Servant!Leader,!ins!Deutsche!übersetzt!etwa! dienender! Leiter!trifft!prototypisch!auf!die!Rolle!des!Scrum!Masters!zu,!wobei!der!G!dieser! Formulierung!inhärente!G!Mangel!an!Macht!eine!Stärke!und!keineswegs!eine!Schwäche! darstellt.!denn!das!fehlen!einer!typischen!chefrolle!ist!notwendige!voraussetzung!für! das!angestrebte!hohe!maß!an!selbstorganisation!und!dynamik!im!team!und!hilft!dem! Team!dem!Scrum!Master!zu!vertrauen.!Der!Scrum!Master!hat!aber!durchaus!Funktionen,! die!den!erfolg!des!projekts!entscheidend!mitbestimmen.!er!oder!sie!!! hilft!dem!team,!seine!arbeit!zu!organisieren,!!!! stellt!sicher,!dass!das!team!funktional!und!produktiv!sein!kann,!!!! beseitigt!hindernisse,!!!! schützt!das!team!vor!externen!störungen,!!!! unterstützt!die!enge!zusammenarbeit!zwischen!allen!projektbeteiligten,!!!! stellt!die!einhaltung!der!scrumgwerte!und!gprinzipien!sicher,!!! moderiert!projektsitzungen,!!! moderiert,!z.b.!bei!entscheidungsprozessen,!problemlösungen!und!konflikten,!!! führt,!leitet!an,!berät,!coacht!und!unterstützt!das!team,!um!letztendlich!ein! selbstorganisierendes,!hochproduktives!team!zu!werden.! In!vielen!Fällen!unterstützt!er!auch!den!Product!Owner,!z.B.!bei!der!Bearbeitung!des! Product!Backlog!oder!beim!Anstoßen!von!notwendigen!Veränderungen!in!der! Organisation.! Qualifikationen'des'idealen'Scrum'Master' Er!oder!sie!ist!eine!Mischung!aus!Moderator,!Teamcoach!und!Mediator.!Der!Scrum! Master!organisiert!effektive!Meetings!und!bringt!Techniken!ein,!damit!das!Team!seine! Kreativität!entfalten!kann.!Er!hilft!dem!Team,!sich!weiter!zu!entwickeln,!und!seinen! einzelnen!mitgliedern,!ihr!jeweiliges!potenzial!auszuschöpfen.!gute!scrum!master! schaffen!ein!projektumfeld,!in!dem!die!arbeit!spaß!macht.!! Erfahrung!in!Softwareentwicklung!ist!für!diese!Rolle!zwar!nützlich,!aber!es!gibt!auch! durchaus!erfolgreiche!scrum!master!ohne!tiefere!programmierkenntnisse,!die!darauf!!improuv!gmbh!! 13!

15 ScrumGKonzepte! schwören,!dass!ihnen!gerade!diese!tatsache!die!nötige!neutralität!erlaubt,!im!team! erfolgreich!zu!moderieren.!! Was'ein'Scrum'Master'nicht'ist' Es!kommt!natürlich!immer!auf!die!einzelne!Person!an,!ob!und!wie!es!einem!Scrum! Master!gelingt,!verschiedene!Aufgaben!parallel!zu!verantworten.!Probleme!gibt!es! allerdings!in!den!meisten!fällen,!wenn!der!scrum!master!noch!folgende!rollen!hat:!!! traditioneller!projektmanager!!! Linienvorgesetzter!von!Teammitgliedern!!! Product!Owner!in!demselben!Projekt!!! Vertreter!des!abwesenden!Product!Owner.!! Alle!diese!Doppelrollen!sind!Hindernisse,!die!den!ScrumGProzess!stören!und!die! Produktivität!verringern.!Die!Rollenkombination!mit!dem!Product!Owner!ist! erfahrungsgemäß!ein!fast!unüberwindbares!hindernis.!denn!der!product!owner!stellt! tendenziell!anforderungen,!der!scrum!master!hat!den!schutz!des!teams!als!seine! Kernaufgabe.!Selbst!wenn!eine!Person!diese!beiden!Hüte!auseinanderhalten!kann,!wie! können!die!teammitglieder!erkennen,!welchen!hut!er!gerade!trägt?! 2.3.4! Wo'ist'der'Projektleiter'geblieben?' Die!Funktionen!des!klassischen!Projektleiters!oder!Gmanagers!sind!zwischen!den! beschriebenen!scrumgrollen!aufgeteilt:!der!product!owner!bestimmt!den!umfang!und! damit!die!lieferzeit!eines!releases!und!durch!die!auswahl!der!features!auch!wesentlich! die!produktqualität.!der!scrum!master!moderiert!und!schafft!geeignete! Arbeitsbedingungen,!das!Team!organisiert!seine!gesamte!Zusammenarbeit!während!des! Produktentwicklungsprozesses.!Die!Kommunikation!nach!außen!wird!vom!Product! Owner!verantwortet,!was!aber!keinesfalls!bedeutet,!dass!das!Team!nicht!mit! Außenstehenden!reden!darf!!es!ist!ausdrücklich!erwünscht,!auf!kurzem!Wege!zu! kommunizieren.!zudem!treten!alle!teammitglieder!beim!reviewgmeeting!auf!und! berichten.!! 2.3.5! Und'die'Linienmanager?' Scrum!konzentriert!sich!in!seinen!Aussagen!auf!das!Team!und!wie!es!seine!Arbeit! organisiert.!doch!auch!wenn!scrum!keine!direkten!aussagen!über!firmen!und!prozesse! macht,!basieren!seine!ideen!doch!in!einer!umfassenden!erfahrung!mit!den!typischen! Prozessen!in!den!Unternehmen!und!üben!umgekehrt!einen!starken!Einfluss!auf!sie!aus.! Es!ist!deshalb!sehr!schwer,!ein!Projekt!mit!Scrum!zu!organisieren!und!die!dazugehörigen! Werte!zu!leben,!wenn!diese!Methode!von!der!übrigen!Organisation!bekämpft!wird.! Besonders!die!Linienmanager!müssen!ihr!Verständnis!von! Command!and!Control!auf! Servant!Leader!umstellen!und!es!dem!Team!erlauben,!selbstorganisiert! Höchstleistungen!zu!erbringen.! 14!!!improuv!GmbH!!

16 !! ScrumGKonzepte! 2.4! Scrum?Artefakte' Scrum!beschreibt!drei!zentrale!Dokumente,!um!die!agile!Zusammenarbeit!zu! strukturieren:!!! Product!Backlog!!!! Sprint!Backlog!!!! Sprint!Burn!Down!Chart!!! Und!optional:!Release!Burn!Down!Chart.! 2.4.1! Product'Backlog' Der!Product!Backlog!enthält!eine!vollständige,!dynamische!Auflistung!aller! Anforderungen!des!Product!Owner!in!der!Gestalt!von!Features,!die!untereinander! priorisiert!sind.!dabei!bezieht!sich! vollständig!darauf,!dass!alle!anforderungen!über! den!product!backlog!an!das!umsetzungsteam!gegeben!werden.!es!heißt!nicht,!dass! diese!schon!zu!projektbeginn!bekannt!sein!müssen.!! Product owner Idea User User Story Epic Story Vision Product Backlog User User Story User Story Story Team Prioritize Estimate Other sources Release Plan Creativity User centered Design Abbildung!2.6:!Start!eines!Projektes! Sprint Planning Dynamisch!bedeutet,!dass!immer!nur!jene!Anforderungen!detailliert!beschrieben!sind,! die!schon!bekannt!sind!und!die!kurz!vor!der!umsetzung!stehen,!während!die!anderen! zunächst!bewusst!allgemein!gehalten!werden.!denn!die!detaillierung!von! Anforderungen!ist!eine!Aufgabe,!die!in!das!laufende!Projekt!gehört.!Das!aktuelle,!im! Projekt!erworbene!Wissen!soll!unmittelbar!in!die!Präzisierung!der!gewünschten! Features!einfließen,!der!Product!Backlog!wird!ständig!dynamisch!angepasst!und!mit! neuen!erkenntnissen!aktualisiert.!!!!improuv!gmbh!! 15!

17 ScrumGKonzepte! Mike!Cohn!spricht!explizit!von!einem!so!genannten! Produkt!Backlog!Eisberg 1,!also! einer!form,!des!backlogs,!die!der!eines!eisbergs!entspricht.!elemente,!die!ganz!oben! stehen,!also!hohe!priorität!haben,!sollen!sehr!detailliert,!also!klein!sein,!elemente!mit! mittlerer!priorität!in!der!mitte!sollen!bereits!deutlich!weniger!details!aufweisen!und! Elemente!mit!sehr!niedriger!Prioriät!sollten!keine!Details!aufweisen.! Zu!den!Erfahrungen,!die!den!Product!Backlog!beeinflussen!können!und!sollen,!gehören! vor!allem!erkenntnisse!und!anregungen,!die!sich!durch!das!ausprobieren!der!fertigen! SoftwareGInkremente!nach!jedem!Sprint!ergeben.!Das!während!des!gesamten!Projekts! stetig!wachsende!wissen,!wie!viel!aufwand!bestimmte!features!benötigen!und!wie!viel! Wert!sie!haben,!hilft!dem!Product!Owner,!den!Geschäftswert!des!Produktes!zu! optimieren.! ID Priorität Titel User Story Akzeptanz-Kriterien Schätzung (Story Points) Auto-Versicherungs-Rabatt Als Versicherungsvertreter will ich einem potentiellen Kunden einen Rabatt anbieten, um den Abschluss zu gewinnen Feste Liste von Rabattsätzen auswählbar (5, 10, 15%)? Rabatt in der Übersicht der Versicherungpolice dargestellt? Korrekt an den Mainframe übertragen? Liste der rabattierten Verträge, die auf Genehmigung warten Als Rabattprüfer will ich die Liste der zu prüfenden Policen sehen, damit ich mein Budget unter Kontrolle halten kann Finanzielle Konsequenz des Rabatts sichtbar? Liste offener Rabattentscheidungen sichtbar? Rabatt akzeptieren, zurückweisen oder ändern Abbildung!2.7:!Ein!Beispiel!Product!Backlog! Als Rabattprüfer will ich in der Lage sein, einen Rabatt zu genehmigen, zu verweigern oder zu verändern, um mein Budget unter Kontrolle zu halten Akzeptiere einen Rabatt, prüfe ob korrekt in die DB eingetragen Weise einen Rabatt zurück, prüfe ob korrekt in die DB eingetragen Ändere einen Rabatt, prüfe DB Die!einzelnen!Features!des!Product!Backlogs!werden!in!Scrum!meist!als! User! Stories!formuliert,!kurze!Aussagen!aus!Sicht!des!künftigen!Nutzers,!was!das!Feature! leisten!soll:! Ich!als!!möchte!!wenn!ich!!Der!Product!Backlog!ist!also!keine! komplette!spezifikation,!wie!man!sie!von!traditionellen!projekten!her!kennt.!aber!er!ist! die!wesentliche!schnittstelle!zwischen!dem!product!owner!und!dem!team,!grundlage! der!arbeit!des!teams!und!der!diskussion!der!beteiligten.!die!liste!ist!eigentum!des! Product!Owner!und!wird!von!diesem!laufend!gepflegt!und!aktualisiert.!Das!Team! unterstützt!ihn!dabei,!indem!es!die!relative!größe!der!features!schätzt,!dem!product! Owner!hilft,!Risiken!und!Abhängigkeiten!zu!erkennen,!und!damit!wesentlichen!Input!für! die!priorisierung!liefert.! Die!Erforschung!und!die!Realisierung!der!Anforderungen!überlappen!sich,!es!gibt!keine! getrennten!anforderungsg!und!realisierungsphasen.!das!bedeutet:!!! Anforderungen!in!Scrum!sind! emergent,!sie!können!während!der!projektlaufzeit! neu!auftauchen!oder!neu!erkannt!werden.! 8!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! !!!improuv!GmbH!!

18 !! ScrumGKonzepte!!! Das!Team!erfährt!im!Projektverlauf!mehr!darüber,!wie!es!die!Anforderungen!des! Kunden!erfüllen!kann.!!!! Bestehende!Anforderungen!ändern!sich.! Physische'Formen' Es!gibt!verschiedene!Möglichkeiten,!den!Product!Backlog!vorzuhalten:!!!! als!eine!sammlung!von!karteikarten!oder!postgits!an!der!wand,!!!! auf!einem!flipchart,!!!! in!einem!werkzeug!für!anforderungsmanagement,!!!! in!einer!tabellenkalkulation,!zum!beispiel!open!office!oder!microsoft!excel.! Da!der!Product!Backlog!so!etwas!wie!die!Langzeitplanung!repräsentiert,!verwenden!viele! Teams!eine!elektronische!Form!der!Speicherung.! 2.4.2! Der'Sprint'Backlog' Wenn!die!vom!Product!Owner!gewünschten!Features!für!den!nächsten!Sprint! gemeinsam!definiert!wurden,!entwickelt!das!team!eine!liste!von!aufgaben,!die!für!die! Realisierung!notwendig!sind:!Das!Sprint!Backlog:!Was!genau!müssen!wir!tun,!um!jede! einzelne!user!story!zu!verwirklichen?!und!wie!viel!zeit!werden!wir!voraussichtlich!dafür! benötigen?!! As a user I want Test Develop Develop Design Test Develop Design Develop Develop As a user I want Test Develop Develop Build Check Test Develop As a user I want Test Develop Develop Check Refactor Refactor Develop Test Develop Abbildung!2.8:!Sprint!Backlog! Der!Sprint!Backlog!ist!Eigentum!des!Entwicklerteams,!wird!von!diesem!in! Gemeinschaftsarbeit!gepflegt,!manchmal!auch!stellvertretend!vom!Scrum!Master.!Er!ist! ein!lebendes!dokument,!in!dem!das!gemeinsame!zeitmanagement!des!teams!steckt.! Denn!anhand!dieser!Liste!diskutiert!und!aktualisiert!das!Team!den!geschätzten! Restaufwand!für!die!Erreichung!des!Sprintziels.!Neu!entdeckte!Schwierigkeiten!können! dazu!führen,!dass!neue!aufgaben!hinzukommen!oder!ursprünglich!geplante!wegfallen.! So!registriert!das!Team!tagesaktuell,!wenn!der!Zeitplan!ins!Wanken!gerät!und!kann! sofort!reagieren,!wenn!das!sprintziel!gefährdet!erscheint.!!improuv!gmbh!! 17!

19 ScrumGKonzepte! Aufgaben!( Tasks )!repräsentieren!aufwände,!abgeschlossene!user!stories!stellen! geschaffene!werte!dar.!das!spiegelt!sich!auch!in!der!regel!wider,!dass!nur! abgeschlossene!stories!in!einem!sprint!review!meeting!präsentiert!werden.! Verantwortlich!für!die!Umsetzung!des!Sprint!Backlogs!und!damit!für!Erreichen!des! Sprintziels!ist!immer!das!gesamte!Team.!Auch!wenn!einzelne!Aufgaben!davon!von! bestimmten!teammitgliedern!bearbeitet!werden,!bleibt!die!verantwortung!kollektiv.! Was'ist'ein'guter'Task?' Die!Formulierung!guter!Tasks!hilft!dabei,!abrechenbare!Fortschritte!in!der!Arbeit!zu! formulieren.!dazu!hat!sich!die!eingängige!formulierung!smart!eingebürgert.!ein!task! sollte!smart!sein:!!!! Specific!G!spezifisch!genug,!damit!jeder!verstehen!kann,!was!sich!dahinter!verbirgt!!!! Measurable!G!können!wir!feststellen,!ob!er!erledigt!ist?!!!! Achievable!G!ist!er!(im!Sprint)!erreichbar?!!!! Relevant!G!trägt!er!zur!Realisierung!der!Story!bei?!!!! Timely!G!kann!man!schätzen,!wie!viel!Aufwand!seine!Realisierung!braucht?!!!! 2.4.3! Sprint'Burn'Down'Chart' Im!Sprint!Burn!Down!Chart!visualisiert!das!Team!den!Arbeitsfortschritt!im!Sprint,!indem! es!zum!daily!scrum!die!aktuell!verbleibenden!restaufwände!zur!erreichung!des! Sprintziels!einträgt,!wobei!die!xGAchse!für!die!Zeitachse!(Tage)!während!eines!Sprints! steht.!! Sprint 15 - Burndown Abbildung!2.9:!Sprint!Burndown!Chart!mit!zwei!Varianten!für!den!Restaufwand:!Anzahl!der!Aufgaben!und! Summe!der!Story!Points.!!!! Als!Maßeinheit!für!die!Restaufwände!(yGAchse)!können!für!die!Tasks!oder!die!User! Stories!geführt!werden:! 18!!!improuv!GmbH!!

20 !! ScrumGKonzepte!!! Die!Summe!der!restlichen!Stunden!für!nicht!abgeschlossene!Tasks!(wenn!diese! geschätzt!werden),!!! Die!Anzahl!der!verbleibenden!Tasks,!!! Die!Summe!der!Story!Points!der!noch!nicht!abgeschlossenen!User!Stories!(diese! Kurve!wird!typischerweise!größere! Treppenstufen!aufweisen!als!die!vorigen! Varianten).! Optimal!fällt!diese!Kurve!regelmäßig!ab,!um!am!Ende!der!XGAchse!den!Wert!Null!zu! erreichen.!sie!kann!aber!auch!einmal!ansteigen,!nämlich!dann,!wenn!sich!zeigt,!dass!das! Team!einen!Aufwand!zu!gering!eingeschätzt!hat!oder!wenn!neue!notwendige!Tasks!zu! einer!story!entdeckt!werden.! 2.4.4! Release'Burn'Down'Chart' Viele!Product!Owner!führen!ein!Diagramm!zu!Verfolgung!der!realisierten!User!Stories! pro!sprint!und!zur!releaseplanung.!dieses!release!burn!down!chart!hat!sich!als!ein! ausgesprochen!wirksames!hilfsmittel!erwiesen,!um!das!eigentliche!projektziel!im!auge! zu!behalten,!so!dass!am!ende!tatsächlich!eine!lauffähige,!in!sich!geschlossene!software! existiert.!! In!diesem!Diagramm!stellt!ebenfalls!die!XGAchse!die!Zeitachse!dar,!allerdings!nicht! begrenzt!auf!die!dauer!eines!sprints,!sondern!für!die!mehrere!sprints!umfassende! Releasedauer.!Die!Einheit!auf!der!xGAchse!ist!im!Gegensatz!zum!SprintGBurndown!nicht! Tage,!sondern!ganze!Sprints.!Auf!der!YGAchse!trägt!der!Product!Owner!nach!jedem! Sprint!die!Story!Points!der!noch!offenen!Features!ein.! Abbildung!2.10:!Release!Burndown! Das!Release!Burn!Down!Chart!wird!vom!Product!Owner!jeweils!am!Ende!eines!Sprints! aktualisiert,!um!den!aktuellen!fortschritt!zu!spiegeln!und!eine!realistische!planung!! sprich!vorhersage!über!den!weiteren!fortschritt!auf!basis!des!bisherigen!!zu!machen.!!improuv!gmbh!! 19!

21 Agiles!Planen!und!Schätzen! 3! Agiles'Planen'und'Schätzen' 3.1! Arbeiten'am'Product'Backlog' Ein!Product!Backlog!enthält!die!am!höchsten!priorisierten!Features!in!einem! Detaillierungsgrad,!der!ausreichend!ist,!um!sie!umsetzen!zu!können.!Die!niedriger! priorisierten!features!werden!während!der!projektzeit!nach!und!nach!weiter!detailliert.! Idealerweise!gehören!in!einen!Product!Backlog!nicht!Hunderte!oder!Tausende!von! Stories!!das!verstellt!den!Blick!des!Teams!auf!die!als!nächstes!umsetzbaren.!Gleichzeitig! sollte!er!aber!dennoch!einen!ausblick!auf!das!gesamtprojekt!ermöglichen.! Typischerweise!gehören!in!einen!Product!Backlog:!!! Die!Stories!und!Items!für!den!nächsten!Sprint.!Diese!müssen!zu!Beginn!der! Sprintplanung! Ready!sein,!d.h.!eindeutig!priorisiert,!geschätzt!und!vom!Team! verstanden.!!! Die!Stories,!an!denen!gearbeitet!werden!muss,!zu!denen!das!Team!noch!Rückfragen! hat,!die!technologisch!nicht!klar!sind!oder!zu!grob,!um!sie!in!einem!sprint! abzuarbeiten.!!! Die!Features!oder!Epics!(übergreifende!Stories),!die!noch!nicht!detailliert!oder!noch! nicht!priorisiert!sind.! *&2B(/2&#=L=44=(C0B Fein-granular: Bereit für den nächsten Sprint. User stories. Priorität Mittel-granular. Größere User Stories. Grob-granular. Epics. Abbildung!3.1:!Granularitätsstufen!im!Product!Backlog!! 20!!!improuv!GmbH!!

22 !! Agiles!Planen!und!Schätzen! In!einem!Backlog!sollten!dagegen!nicht!enthalten!sein.!!! Verfeinerungen! auf!vorrat :!die!items!veralten!nicht!nur,!sondern!je!weiter!sie!in!die! Zukunft!weisen,!um!so!höher!ist!das!Risiko,!dass!sie!veraltet!sind!und!nie!umgesetzt! werden!!! Tasks!und!Aktivitäten:!Agile!Planung!basiert!auf!der!Zerlegung!in!Features.! Aktivitäten!werden!erst!in!der!SprintGPlanung!abgeleitet!und!sind!eine!lokale!Aufgabe! des!teams! Ein'guter'Product'Backlog'ist'DEEP'!! D!!detailed!appropriately,!angemessen!detailliert!(s.!oben)!!! E!!estimated,!geschätzt!!! E!!emergent,!entwickelt!sich!im!Projekt!weiter!!! P!!prioritized,'priorisiert! Im!weiteren!Verlauf!dieses!Abschnitts!beschreiben!wir,!wie!man!mit!einem!Product! Backlog!arbeitet!und!diesen!pflegt.! 3.1.1! Pflege'des'Product'Backlog' Product!Backlogs!enthalten!die!Anforderungen!des!Product!Owners,!der!diese!mit! seinen!stakeholdern!abgestimmt!und!eindeutig!priorisiert!hat.!man!bezeichnet!sie! neutral!als!backlog!items.!backlog!items!können!sein:!!! neue!funktionalität,!bevorzugt!formuliert!als!user!stories.!!! Versuche,!Experimente!und!Vorarbeiten!( spikes ),!mit!denen!man!unsicherheit!über! das!weitere!vorgehen!reduziert,!z.b.!einen!durchstich!für!die!anbindung!einer!neuen! mobilen!plattform!an!die!applikation.!das!können!technische!spikes!sein,!mit!denen! man!unsicherheiten!über!die!realisierung!und!machbarkeit!beseitigen!kann!oder! funktionale!spikes,!mit!denen!man!funktionen!für!kunden!testen!kann.!!! Folgearbeiten!für!technologische!Schulden!wie!Wartungsarbeiten,!größere!Bugfixes,! Refactoring!oder!das!nachträgliche!Erstellen!von!Tests!für!bestehenden!Altcode.! Bevorzugt!sollte!man!sich!auf!neue!Funktionalität!konzentrieren!und!Spikes!auf!das! Notwendige!begrenzen!!sie!stellen!im!Prinzip!wieder!Arbeiten!auf!Vorrat!und!damit! potenziell!verschwendung!im!sinne!des! Lean!Ansatzes!dar.!Gute!Spikes!sollten!auf! jeden!fall:!!! Schätzbar!sein!!im!Notfall!muss!man!mit!einer!Timebox!zur!Begrenzung!des! Aufwands!arbeiten!!! Demonstrierbar!sein!!sie!sollten!ein!abrechenbares!Ergebnis!liefern!!! Akzeptierbar!sein!!eine!Entscheidung!über!die!Zielerreichung!ermöglichen.!!improuv!GmbH!! 21!

23 Agiles!Planen!und!Schätzen! In!manchen!Umgebungen!ist!es!ausreichend,!die!User!Stories!zu!formulieren!und!in!den! Product!Backlog!einzutragen.!In!anderen!Fällen,!z.B.!bei!komplexen!Produkten!oder! hohem!regulierungsbedarf,!braucht!der!product!owner!mehr!unterlagen.!der!product! Backlog!ist!dann!nicht!Ersatz!für!jegliche!Spezifikation!bzw.!eine!saubere!Produktplanung.! Dann!besteht!nach!wie!vor!die!Notwendigkeit,!Kundenwünsche!zu!erfragen,!sie! abzubilden!und!zu!dokumentieren.! Waterfall/Tradi^onal Agile Requirements Fixed Resources Date Value Driven Plan Driven Es^mated Resources Date Requirements Source:"Dean"Leffingwell Abbildung!3.2:!Good!Bye!Eisernes!Dreieck!!! Für!den!Product!Owner!heißt!das!je!nach!Projekt!und!Zielgruppe,!andere!Dokumente!zu! pflegen,!die!features!in!user!stories!zu!zerlegen!und!in!eine!eindeutige!reihenfolge!zu! bringen.! Wichtig!für!das!Team:!!! Der!Product!Backlog!ist!die!zentrale!Schnittstelle!zum!Product!Owner.!Die!am! höchsten!priorisierten!product!backlog!einträge!müssen!weit!genug!vorbereitet!sein,! damit!sie!verlässlich!umsetzbar!sind.!!! Das!Team!unterstützt!den!Product!Owner!beim!Schätzen!und!beim!Aufteilen!der! Produktfeatures!in!Stories,!die!in!einem!Sprint!umsetzbar!sind.!!! Das!Team!weist!auch!auf!Unklarheiten!und!technische!Unsicherheiten!in!den!Product! Backlog!Items!hin.!Das!kann!dazu!führen,!dass!man!einen!Prototyp!oder!Spike! (Machbarkeitsstudie)!baut,!um!ein!Feature!oder!eine!vorgesehene!Lösung!genauer! beurteilen!zu!können.!umgekehrt!kann!auch!der!product!owner!einen!spike! anfordern,!um!optionen!für!features!zu!sehen!oder!sie!mit!kunden!durchzusprechen.!!! Das!Team!hat!auch!die!Aufgabe,!auf!technologische!Schulden!hinzuweisen!und!Zeit! für!umbauten!oder!refactoring!einzufordern,!wenn!diese!vorhanden!sind.!es!kennt! das!softwaresystem!am!besten!und!kann!daher!oft!exklusiv!die!notwendigkeiten!zur! Sicherung!der!inneren!Produktqualität!erkennen!und!formulieren.!Selbstverständlich! ist!der!richtige!weg,!erst!gar!keine!technischen!schulden!aufzubauen!!aber!oft!hat! man!eine!vergangenheit!zu!bewältigen.! 22!!!improuv!GmbH!!

24 !! Agiles!Planen!und!Schätzen!!! Das!direkte!Gespräch!( face!to!face )!ist!durch!nichts!zu!ersetzen.!voraussetzung!für! die!umsetzung!ist,!dass!das!team!die!anforderung!verstanden!hat.!das!kann!oft!nur! in!einem!gespräch!erreicht!werden!und!die!diskussion!kann!eine!umfangreiche! fehlerträchtige!spezifikation!überflüssig!machen.! 3.1.2! Backlogpflege'( Backlog'Grooming' )'' Es!ist!notwendig,!das!Product!Backlog!regelmäßig!zu!verfeinern,!Stories!aufzuteilen!und! zu!schätzen.!diese!regelmäßige!product!backlog!pflege!nennt!man!im!englischen!! Product!backlog!grooming.! Viele!Teams!liefern!die!Unterstützung!bei!der!Product!Backlog!Pflege!in!regelmäßigen,! z.b.!wöchentlichen!anforderungsgworkshops.!diese!sollen!sicherstellen,!dass!zu!beginn! jeden!sprints!die!höchst!priorisierten!features!ausreichend!detailliert!und!vorbereitet! sind.!! Review Meeting Planning Meeting Ready - understood - estimated - prioritized Sprint Backlog Grooming Meeting - refine - split - estimate new Stories Done - implemented - tested - integrated Retrospektive 5 5 User stories shippable product increment Abbildung!3.3:!Backlog!Grooming! Der!große!Nutzen!dieser!Workshops!ist:!!! Sie!finden!regelmäßig!statt,!sind!also!berechenbar!in!den!Arbeitsablauf!einzuplanen.!!! Sie!sind!fokussiert!auf!jeweils!wenige!neue!Features!oder!Stories.!!! Wenn!offene!Fragen!auftreten,!kann!man!die!Stories!bis!zur!Klärung!vertagen!und! nochmals!bearbeiten!!anders!als!bei!der!sprintplanung,!in!der!nur!in!!improuv!gmbh!! 23!

25 Agiles!Planen!und!Schätzen! Ausnahmefällen!geschätzt!werden!sollte.!Schlimmstenfalls!besteht!beim!Sprint! Planning!der!Druck,!sofort!mit!der!Umsetzung!zu!beginnen,!auch!wenn!noch!zu!viel! unklar!ist.!!! Es!muss!nicht!immer!das!ganze!Team!teilnehmen!!wobei!hier!zu!beachten!ist,!dass! die!einbeziehung!der!übrigen!teammitglieder!dann!in!der!sprintplanung!erfolgen! muss!und!dies!dann!zusätzlichen!zeitaufwand!bedeutet.! Agile!Teams!arbeiten!typischerweise!sehr!fokussiert!und!intensiv.!Während!das! ungeahnte!reserven!in!der!produktivität!freisetzen!kann,!führt!es!manchmal!dazu,!dass! sich!die!teammitglieder!auf!die!nächstliegenden!aufgaben!konzentrieren.!ein! regelmäßiger!blick!auf!den!größeren!zusammenhang!bekämpft!auch!den!tunnelblick,! unter!dem!manche!teams!leiden!und!kann!ihnen!helfen,!die!perspektive!auf!die! Produktvision!präsent!zu!halten.! 3.1.3! Technische'und'Feature?Prioritäten' Mancher!Product!Owner!wird!tendenziell!dazu!neigen,!Aufwände!für!rein!technische! Verbesserungen!oder!Refactoring!zu!verschieben!und!kurzfristige!Interessen!zu! überschätzen.!hier!muss!das!team!gegensteuern.!umgekehrt!entwickeln!manche! Softwareentwicklungsteams!gerne!eine!gewisse! künstlerische!ader!und!neigen!dazu,! sich!in!technischen!spielereien!zu!ergehen!oder!die!sprichwörtlichen!goldenen! Wasserhähne!einzubauen,!bevor!das!Dach!fertig!gedeckt!ist.!Dann!wiederum!kann!der! Product!Owner!übertriebene!Höhenflüge!stoppen.!! Was"steht"im"Backlog + User Stories $: Neue Funktionalität Größere Refactorings Größere Bugs, technische Schulden Vergangenheit Research, Spikes, Experimente Zukunft Abbildung!3.4:!Was!steht!im!Product!Backlog!! Dazwischen!muss!eine!gesunde!Balance!gefunden!werden.!Ein!gutes!Diskussionsklima,! in!dem!jeder!die!interessen!des!jeweils!anderen!versteht!und!respektiert,!hilft!einen! gesunden!ausgleich!zu!schaffen.! Ebenfalls!beim!Team!liegt!die!Verantwortung,!die!Systemsicht!einzubringen.!Denn!meist! verfügt!nur!das!team,!nicht!der!product!owner!über!die!kompetenz,!die!gefahr! technologischer!schulden!!offene!fragen,!unfertige!teile!oder!schlechte!lösungen!!zu! erkennen!und!maßnahmen!zu!ihrer!vermeidung!für!den!product!backlog!vorzuschlagen.! Für!den!Product!Owner!sind!viele!Mängel!in!der!Programmierung!bzw.!der! 24!!!improuv!GmbH!!

26 !! Agiles!Planen!und!Schätzen! Softwarestruktur!gar!nicht!ersichtlich,!vor!allem,!wenn!er!selbst!keine!Kenntnisse!in!der! Softwareentwicklung!hat.!Wenn!ein!Problem!aufgetreten!ist!oder!sich!bei!den! Planungen!abzeichnet,!müssen!die!Entwickler!deshalb!stellvertretend!für!externe! Stakeholder!(der!Betrieb)!oder!virtuelle!Stakeholder!(das!System)!auftreten!und!den! Product!Owner!davon!überzeugen,!die!notwendigen!Maßnahmen!einzuplanen.!! 3.1.4! Nichtfunktionale'Anforderungen'und'Restriktionen' Zu!jedem!BacklogGEintrag!kann!es!einen!Satz!von!nichtfunktionalen!Anforderungen!und! Restriktionen!geben.!Da!solche!Anforderungen!potentiell!mehrere!Einträge!betreffen! können!(sie!bilden!eine!m:n!relation!mit!den!einträgen),!ist!es!sinnvoll,!diese!an!einem! zentralen!platz!niederzuschreiben.! Wir!schlagen!dafür!die! Definition!of!Done!als!zentralen!Platz!vor.! 3.2! Arbeiten'mit'User'Stories' Eine!User!Story!ist!eine!in!Alltagssprache!formulierte!SoftwareGAnforderung.!Sie!ist! bewusst!kurz!gehalten!und!umfasst!in!der!regel!nicht!mehr!als!zwei!sätze.!das!konzept! und!die!verbreitung!von!user!stories!in!agilen!projekten!hat!mike!cohn![coh2004]! [Coh2005]!entscheidend!beeinflusst.!Inzwischen!sind!User!Stories!ein!integraler! Bestandteil!von!Scrum!und!der!agilen!Methodik!im!Allgemeinen 2.!! In!manchen!Unternehmen!haben!sind!andere!Mechanismen!und!Formen!wie!z.B.!Use! Cases!etabliert!oder!es!sind!formelle!Pflichtenhefte!vorgeschrieben!und!allen!Beteiligten! vertraut.!auch!unter!diesen!vorgaben!kann!man!ein!projekt!agil!durchführen.!wir!finden! User!Stories!ein!faszinierendes!Konzept,!da!sie!die!Maxime,!miteinander!von!Angesicht! zu!angesicht!zu!kommunizieren,!exemplarisch!unterstützen.! Reichweite'einer'User'Story' Der!Inhalt!einer!User!Story!kann!sehr!allgemein!!!wir!sprechen!dann!von!einem! Epos!(engl.!epic)!oder!einem!Thema!(engl.!theme) 3!!oder!sehr!detailliert!und! spezifisch!sein.!beide!formen!haben!ihre!berechtigung,!wenn!sie!im!richtigen!kontext! verwendet!werden.!so!besteht!die!produktvision!häufig!erst!einmal!aus!mehreren!epen,! also!sehr!allgemeinen!stories.!damit!alle!beteiligten!in!die!konkrete!planung!einsteigen! können,!zerlegt!der!product!owner!dann!mit!unterstützung!des!teams!die!wertvollsten,! d.h.!am!höchsten!priorisierten!epen!in!kleinere!user!stories!und!priorisiert!wiederum! diejenigen!mit!dem!größten!wert!oder!dem!höchsten!risiko.!! Epen!sind!typischerweise!eher!für!den!Kunden!und!den!Product!Owner!interessant:!Sie! repräsentieren!real!nutzbare!und!auslieferbare!produktfeatures.!das!team!benötigt!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! Die Größenordnung eines Thema korrespondiert mit dem oben genannten Begriff Feature. Wir verwenden wahlweise beide Begriffe in der traditionellen Entwicklung hat der Begriff einen festen Platz erobert. Wen wir diesen Begriff verwenden, reduzieren wir manchmal die Verständigungshürde mit traditionellen Projektmanagern.!improuv!GmbH!! 25!

27 Agiles!Planen!und!Schätzen! kleinere!stories,!um!mehrere!davon!in!einem!sprint!abarbeiten!und!ergebnisse!liefern!zu! können.! 3.2.1! User'Story'Format' Ein!User!Story!beschreibt!ein!Szenario!und!beantwortet!dabei!die!Fragen:!Wer,!Was!und! Warum.!Ein!oft!verwendetes!Muster!sieht!so!aus:!!!! Der!!(wer:!Rolle)!!! möchte!!(was:!anwendungsganforderung)!!!! weil!!(warum:!nutzen,!geschäftlicher!wert)!! Wer' Die!User!Story!nimmt!die!Perspektive!eines!Endnutzers!ein!und!beschreibt!eine! Forderung!aus!Sicht!einer!konkreten!Rolle.!Je!präziser!diese!formuliert!ist,!desto!besser.!!!! Nicht!gut:! Als!User!!!!! Besser:! Als!für!Flugbuchungen*zuständige*Sekretärin!eines!Vielfliegers!!! Je!anschaulicher!die!User!Story!das!Arbeiten!des!Endnutzers!mit!dem!System!vor!Augen! führt,!desto!klarer!wird!automatisch!die!zielrichtung.! In!Ausnahmefällen!kann!man!bei! Wer!auch!ein!SoftwareGSystem!eintragen,!zum! Beispiel,!wenn!man!BackendGSysteme!entwickelt!und!keinen!menschlichen!Benutzer!hat.! Dann!beginnt!die!User!Story!z.B.!mit!der!Formulierung:! Als!WebserviceGClientG Programm!!! Story Rolle Inhalt Größe Geschäfts- Ziel Abbildung!3.5:!User!Story!Format! 26!!!improuv!GmbH!!

28 !! Agiles!Planen!und!Schätzen! Was' Wichtig!ist,!dass!ein!klares!Szenario!beschrieben!wird,!und!zwar!ein!geschäftliches! Szenario!und!nicht!eine!technische!Lösung!(das!wäre!ja!ein! Wie ).!!!! Nicht!gut:!!möchte!ich!ein!System,!das!Prioritäten!im!Hinblick!auf!Platzwahl! automatisch!speichert.!!!! Besser:!!!möchte!ich!bei!der!Flugbuchung,!dass!die!von!mir!einmal!eingegebene! Priorität!bei!der!Sitzplatzwahl!!Fenster!oder!Gang!!als!Voreinstellung!erhalten! bleibt,!ich!sie!aber!bei!bedarf!verändern!kann.! Warum' Dieser!Teil!der!User!Story!repräsentiert!den!geschäftlichen!Wert,!der!mit!der!Lösung!des! Problems!erzielt!werden!soll.!Er!hat!die!wichtige!Funktion,!alle!Beteiligten!auf!die! Wertschöpfung!zu!fokussieren.!In!vielen!Fällen!ist!es!auch!so,!dass!uns!als!Entwickler!oft! das!wissen!über!die!arbeitswelt!des!anwenders!fehlt.!zu!verstehen!warum!ein!feature! gebraucht!wird,!ist!eine!wertvolle!information,!die!meist!das! Was!nochmals!vertieft! oder!aufklärt.!!!! Nicht!gut:!!um!mir!die!Flugbuchung!zu!erleichtern.!!!! Besser:!!damit!ich!bei!den!einzelnen!Buchungen!Zeit!spare.! User!Stories!kann!man!auf!eine!normale!Karteikarte,!ein!DinGA5GBlatt!oder!eine!speziell! für!scrumgprojekte!entworfene!usergstorygkarte!schreiben!oder!drucken.!es!ist!sinnvoll,! dass!das!material!etwas!stabiler!ist!als!ein!dünnes!blatt!papier,!damit!die!karte!auch! hektische!teamsitzungen!gut!übersteht.! Details' Auf!der!Rückseite!der!jeweiligen!Karte!werden!die!Akzeptanzkriterien!formuliert.!Die! besten!akzeptanzkriterien!sind!konkrete!beispiel!von!erwarteten!ergebnissen,!die!sich! zur!überprüfung!eignen.!!!! Nicht!gut!wäre!in!unserem!Beispiel:! Die!Priorität!bei!der!Sitzplatzwahl!lässt!sich!gut! eintragen.!!!! Besser:! Bei!der!ersten!Flugbuchung!werde!ich!nach!meiner!Vorliebe!bei!der! Sitzplatzwahl!fragt.!Zugleich!stellt!mir!das!System!die!Frage:! Möchten!Sie!diese! Auswahl!für!künftige!Buchungen!speichern?!Wenn!ich!hier!mit! Ja!antworte,!ist!die! Priorität!bei!der!nächsten!Flugbuchung!voreingestellt.!Es!gibt!jedoch!den!Button:! Platzauswahl!ändern.! Die!Akzeptanzkriterien!bilden!oft!den!Anfangspunkt!für!das!Schreiben!von! Akzeptanztests,!die!nachweisen!müssen,!dass!die!User!Story!wie!erwartet!implementiert! ist.!oft!wird!erst!durch!diese!klar,!welcher!aufwand!hinter!einer!benutzergeschichte! steht!oder!welche!granularität!sie!verlangt.!es!kann!sich!z.b.!herausstellen,!dass!der! Product!Owner!viel!mehr!erwartet,!als!das!Team!auf!den!ersten!Blick!sieht.!!!improuv!GmbH!! 27!

29 Agiles!Planen!und!Schätzen! Manchmal!nimmt!man!auch!nichtfunktionale!Eigenschaften!in!die!Liste!der! Akzeptanzkriterien!auf.!Man!sollte!sich!dann!auch!überlegen!!! ob!sich!eine!klare!formulierung!finden!lässt,!die!einfach!zu!überprüfen!ist.!z.b.!ist!die! Formulierung! wenn!ich!eine!suche!mit!folgenden!parametern!auslöse,!habe!ich!eine! Suchzeit!von!nicht!mehr!als!1,5!Sekunden!besser!als! hohe!performance!bei!der! Suche!!! Bei!sich!wiederholenden!Kriterien!sollte!man!auch!überlegen,!ob!man!die!Definition! of!done!erweitert,!um!redundante!beschreibungen!zu!vermeiden.! In!der!ursprünglichen!Formulierung!von!Ron!Jeffries!sind!die!wesentlichen!Attribute! einer!user!story!die!drei! C :!!!! Card:!Stories!werden!traditionell!auf!Karteikarten!geschrieben.!Die!Karteikarten! können!durch!notizen,!schätzungen,!etc.!ergänzt!werden!!! Conversation:!Die!Details!hinter!einer!Story!offenbaren!sich!oft!erst!während!einer! Diskussion,!wenn!sie!aus!mehreren!Blickwinkeln!betrachtet!werden!!! Confirmation:!Akzeptanzkriterein!und!daraus!abgeleitete!Akzeptanztests!bestätigen,! dass!die!richtige!funktionalität!implementiert!wurde.! Independent Negotiable Vertical Estimable Small Testable Abbildung!3.6:!Eine!gute!User!Story! INVEST' 'ein'schneller'check'für'die'user'story' Ob!eine!User!Story!eine!gute!Qualität!erreicht!hat,!lässt!sich!mit!einer!kurzen!Checkliste! kontrollieren.!eine!gute!user!story!ist:!!! Independent,!unabhängig!und!unabhängig!von!Nutzen!!die!Unabhängigkeit! vermeidet!probleme!beim!priorisieren!von!stories.!der!unabhängige!nutzen!hilft! auch,!kleine!funktionen!so!früh!wie!möglich!dem!benutzer!zur!verfügung!zu!stellen! und!feedback!zu!erhalten.!!! Negotiable,!verhandelbar!und!verhandelt!!eine!Story!ist!ein!Katalysator!für!eine! Diskussion!und!kein!Vertrag.!Sie!sollte!also!auch!als!Grundlage!für!eine!Diskussion! 28!!!improuv!GmbH!!

30 !! Agiles!Planen!und!Schätzen! benutzt!werden.!eine!story!wird!auch!dadurch!wertvoll,!dass!man!tatsächlich!über! ihre!details!verhandelt!hat.!!! Vertical!G!repräsentiert!ein!Stück!Funktionalität!über!die!verschiedenen! Softwareschichten!hinweg!oder!Valuable,!wertvoll!!bringt!einen!Mehrwert!für!das! Geschäft.!!! Estimable,!schätzbar!!die!Stories!stellen!über!den!Product!Backlog!die!Basis!unseres! Projektplans!dar.!Mit!der!Schätzung!werden!häufig!verborgene!Anforderungen! sichtbar.!!! Small,!klein!!große!Stories!sollten!zerlegt!werden!damit!sie!in!Iterationen!umsetzbar! sind.!außerdem!wächst!die!komplexität!großer!stories!überproportional,!mit! kleineren!stories!kann!man!besser!auf!ein!ergebnis!fokussieren.!!! Testable,!testbar!!wenn!man!eine!Story!nicht!testen!kann,!gibt!es!kein! Erfolgskriterium,!wann!die!Story!abgeschlossen!ist.!Testbarkeit!wirkt!oft!wie!ein! Katalysator!zum!Aufdecken!verborgener!Komplexität.!Deshalb!prüfen!erfahrene! Teams!auch!immer,!ob!und!wie!eine!Story!verifizierbar!ist,!bevor!sie!mit!der! Umsetzung!starten.! Client WebhServer ApphServer" DBhServer Presentation Control Application Data"management" Data"storage" Abbildung!3.7:!Eine!gute!User!Story!ist!vertikal! Darüber!hinaus!gibt!es!einige!AntiGPatterns,!die!oft!auf!grundlegende!Mängel!in!einer! User!Story!hinweisen:!!! Der!generische!Stakeholder:! Als!Benutzer!will!ich!oder!noch!schlimmer:! Als! Product!Owner!will!ich.!Das!kann!man!weder!hinterfragen,!da!dieser!allgemeine! Benutzer!sich!nicht!wirklich!ermitteln!lässt.!Darüber!hinaus!verpasst!man!die! Gelegenheit,!die!benötigten!Features!wirksam!einzugrenzen!und!zielgenau!die! Bedürfnisse!einer!Rolle!zu!implementieren.!!! Der!unbekannte!Benutzer:!wenn!man!über!einen!Benutzer!zu!wenig!oder!gar!nichts! weiß,!ist!das!nennen!dieses!benutzers!in!der!user!story!von!geringem!nutzen.!man! sollte!in!diesem!fall!mehr!zeit!investieren,!um!diesen!benutzer!kennen!zu!lernen!! durch!befragung,!beobachtung,!die!entwicklung!von!personas!etc.!!! Technische!Features:!man!sollte!sich!Mühe!geben,!einen!Stakeholder!für!technische! Features!zu!finden.!Es!schützt!davor,!Infrastruktur! auf!vorrat!zu!implementieren.!!improuv!gmbh!! 29!

31 Agiles!Planen!und!Schätzen!!! Akzeptanzkriterien!sind!nicht!testbar:!Wenn!man!aus!Akzeptanzkriterien!keine! Akzeptanztests!ableiten!kann,!könnte!das!bedeuten,!dass!die!Kriterien!nur!Platzhalter! sind!und!die!story!nicht!wirklich!testbar!ist.! 3.3! Planen'und'Schätzen' Planen'und'Schätzen' Ein!wichtiger!Erfolgsfaktor!auch!bei!agilen!Projekten!ist!eine!längerfristige!Planung!die! vorausschauend!und!flexibel!ist!und!risiken!einbezieht.!gerade!hier!mangelt!es!oft!am! richtigen!verständnis.! Beispiele!für!eine!schlechte!Planung!sind:!!! Das!falsche!Produkt!wird!entwickelt.!Mike!Cohn![Coh2005]!nennt!das!als!eine! Hauptursache!für!das!Scheitern!von!Projekten.!!! Der!Plan!wird!nicht!auf!Features!aufgebaut,!sondern!auf!Aktivitäten.!Letztere!messen! den!getriebenen!aufwand,!nicht!den!geschaffenen!wert!und!sind!deshalb!keine!gute! Grundlage!für!den!Projektstatus!und!die!Erfolgsmessung.!!! Wunschdenken!G!neue!Informationen,!Unsicherheiten!und!Risiken!werden!nicht! angemessen!berücksichtigt.!!! Ein!Plan,!der!ein!Eigenleben!entwickelt,!bis!schließlich!seine!Einhaltung!wichtiger! wird!als!das!produkt.!!! Keine!oder!zu!seltene!Überprüfung!des!Plans.! Das'richtige'Produkt'entwickeln' Der!offensichtlichste!Fall,!dass!das!falsche!Produkt!entwickelt!wurde,!ist,!wenn!bei!der! Auslieferung!die!Features!fehlen,!die!das!Produkt!der!Konkurrenz!erfolgreich!machen.!! Da!aber!das!Budget!so!gut!wie!immer!begrenzt!ist,!wird!die!Entscheidung!wichtig,! welche!features!es!in!ein!release!oder!ein!produkt!schaffen!und!welche!außen!vor! bleiben!!in!anderen!worten:!auf!die!priorisierung.! Folgende!Faktoren!sollte!man!für!die!richtige!Priorisierung!von!Features!und!User! Stories!berücksichtigen:!!! Technisches!Risiko!und!Unsicherheit:!Technische!Risiken!z.B.!mögliche!PerformanceG Probleme!einer!bestimmten!Lösung!sollte!man!früh!genug!kennen.!!!! Geschäftswert!( Business!Value )!und!marktrisiko!!!! Kosten/Nutzen!Relation!eines!Features!!!! Opportunitätskosten,!Cost!of!Delay:!Was!kostet!es,!mit!einem!Feature!zu!spät!zu! kommen.! Für!die!Priorisierung!sind!dann!Kombinationen!dieser!Faktoren!hilfreich.! 30!!!improuv!GmbH!!

32 !! Agiles!Planen!und!Schätzen! Das!Team!spielt!eine!wichtige!Rolle!bei!der!Produktentwicklung!und!richtigen! Priorisierung!indem!es!technische!Risiken!thematisiert!und!die!Aufwände!zur! Realisierung!von!Features!schätzt.!Diese!Rolle!kann!es!umso!besser!ausfüllen,!wenn!die! Teammitglieder!über!den!Tellerrand!hinausblicken!und!sich!mit!der!längerfristigen! Planung!und!dem!Produkt!als!Ganze!auseinandersetzen.! Die'Planung'auf'Features'aufbauen' Die!traditionelle!Projektplanung!nutzt!eine!WorkGBreakGDownGStructure!und! Balkenpläne!(GanttGCharts)!um!die!zeitliche!Abfolge!von!Aktivitäten!zu!beschreiben!und! zu!verfolgen.!damit!verfolgt!man!streng!genommen!aber!nicht!den!projektfortschritt!im! Sinn!von!geschaffenem!Wert,!sondern!nach!geleistetem!Aufwand,!von!dem!man!hofft,! dass!er!mit!dem!projektfortschritt!korreliert.! Eine!Struktur,!die!sich!nach!Aktivitäten!gliedert!macht!eine!NeuG!und!Umplanung! ziemlich!komplex,!denn!jedes!feature!wird!typischerweise!in!mehreren!verschiedenen! Aktivitäten!repräsentiert.!Eine!Umplanung!für!ein!neues!oder!verändertes!Feature!wird! aufwändig,!weil!man!alle!aktivitäten!anpassen!und!bei!änderungen!zudem!neu!prüfen! muss,!welche!anderen!features!davon!wiederum!betroffen!sind.! Features!als!Grundlage!der!Planung!bieten!folgende!Vorteile:!!! Features!helfen,!die!Planung!auf!eine!wertschöpfungsorientierte!Entwicklung!und! Projektsteuerung!einzustellen.!!! Features!erlauben!eine!einfachere!Anpassung!der!Planung!an!geänderte! Anforderungen.! Product Backlog füllen Backlog Einträge schätzen Velocity bestimmen Release Plan erstellen Abbildung!3.8:!Der!Releaseplanungsprozess!! Realistisch'bleiben' Wunschdenken!ist!in!Projekten!erstaunlich!weit!verbreitet.!Trotz!der!Erfahrungen,!dass! Entwickler!mit!steigendem!Termindruck!immer!schlechtere!Software!liefern,!wird! ständig!versucht,!unrealistische!ziele!zu!setzen.! Manchmal!wird!der!Product!Owner!schon!im!Vorfeld!genötigt,!zu!viel!zu!versprechen.!Es! hilft!dabei!wenig,!wenn!das!team!diese!illusionen!mitträgt.!im!gegenteil:!je!später!die! Realität!anerkannt!wird,!desto!schmerzhafter!wird!es.!! Wir!haben!mit!einem!agilen!Vorgehen!ein!mächtiges!Mittel!in!der!Hand,!empirische! Erkenntnisse!zum!Arbeitsfortschritt!zu!messen!und!in!die!Planung!einfließen!zu!lassen.! Die!Planung!wird!dadurch!genauer!und!zuverlässiger.!Das!Team!hat!die!Pflicht,!Fakten!zu!!improuv!GmbH!! 31!

33 Agiles!Planen!und!Schätzen! artikulieren!und!damit!zu!einer!realistischen!planung!beizutragen!!auch!wenn!wir!uns! dabei!manchmal!fühlen!wie!das!kind!im!märchen! des!kaisers!neue!kleider.! Unrealistische!Planung!!! führt!zu!einer!riesigen!verschwendung,!denn!es!werden!features!begonnen,!die! nicht!ausgeliefert!werden,!!! führt!zu!zusätzlichem!multitasking!und!damit!zu!stress!und!zu!schlechteren! Resultaten,!!! demotiviert!alle!beteiligten!und!hindert!uns!daran,!in!einer!nachhaltigen! Geschwindigkeit!zu!arbeiten!!der!langfristig!effektivsten!Arbeitsweise.! Die'Planung'ist'wichtiger'als'der'Plan' Eine!Planung!hat!immer!zwei!Effekte:!zum!einen!das!Artefakt! Plan,!zum!anderen!ein! genaueres!verständnis!des!gegenstands!bei!den!an!der!planung!beteiligten.! Letzteres!ist!für!uns!der!wichtigere!Effekt,!denn!ein!genaueres!Verständnis!hat!eine! direkte!auswirkung!auf!die!fokussierung!der!arbeit,!auf!die!entstehung!neuer!ideen!und! die!zusammenarbeit!der!teammitglieder.!das!ist!auch!einer!der!gründe,!warum!in! einem!scrum!projekt!alle!teammitglieder!bei!einer!sprintplanung!teilnehmen!müssen!! die!vordergründige!argumentation!mit!einer!einsparung!von!meetinggzeiten!hat!nur!den! Plan!als!Artefakt!im!Visier,!nicht!aber!das!während!der!Planung!aufgebaute!Wissen.! Planung'erfolgt'während'der'ganzen'Projektlaufzeit' Entscheidungen!sollte!man!dann!treffen,!wenn!man!möglichst!viele!Grundlagen!dafür! hat.!in!einer!umgebung,!in!der!wir!bei!der!arbeit!neue!erkenntnisse!erhalten!und!in!der! sich!anforderungen!ändern!können,!heißt!das,!so!spät!wie!möglich.! Das!bedeutet!aber!nicht,!dass!man!immer!aufschieben!sollte:!Ab!einem!bestimmten! Punkt!braucht!man!feste!Vorgaben!fürs!weitere!Arbeiten.!Im!Lean!Thinking!nennt!man! das!den!letzten!verantwortlichen!zeitpunkt!( last!responsible!moment )!für! Entscheidungen.! In!der!Konsequenz!bedeutet!das:!!! nach!prioritäten!vorgehen,!!! entsprechend!dieser!prioritäten!die!planung!verfeinern,!!! während!des!ganzen!projektes!planen.! Planungsebenen' Agile!Projekte!haben!im!Normalfall!zwei!wesentliche!Planungsebenen:!!!! die!projektg!bzw.!releaseplanung!und!!! die!sprintplanung.! 32!!!improuv!GmbH!!

34 !! Agiles!Planen!und!Schätzen! Manchmal!unterscheidet!man!die!beiden!Ebenen!auch!als! strategische!und! taktische!planung.! In!der!Projektplanung!versuchen!wir,!die!Entwicklung!in!auslieferfähige!Teile,!in!Releases,! zu!gliedern.!die!releaseplanung!deckt,!je!nach!größe!und!komplexität!des!projektes!bzw.! Produktes,!eine!Periode!von!drei!bis!sechs!Monaten!ab!und!versucht,!die!Zahl!der! Sprints!für!eine!bestimmte!Menge!an!Features!vorherzusagen.!Oder!sie!hat!einen!festen! Zeithorizont!und!schätzt!die!realisierbaren!Features!ab.!! Für!die!Vorbereitung!der!Sprintplanung!werden!die!am!höchsten!priorisierten!Features! auf!user!stories!heruntergebrochen.!in!der!sprintplanung!wird!das!ziel!für!den! kommenden!sprint!festgelegt!und!es!erfolgt!ein!commitment!des!teams!über!das! Sprintziel.!Dieses!Ziel!korrespondiert!mit!einer!bestimmten!Menge!von!User!Stories.! Jetzt!werden!die!dafür!benötigten!Aktivitäten!oder!Tasks!bestimmt!!in!der! Sprintplanung!oder!zum!Teil!erst!während!des!Sprints.!Wir!unterscheiden!dabei!die! Außensicht,!also!das!Commitment!gegenüber!dem!Product!Owner,!von!der!Innensicht,! in!der!sich!das!team!einen!plan!macht,!um!dieses!commitment!umzusetzen.!die!tägliche! Planung!wird!im!Daily!Scrum!synchronisiert!und!!ähnlich!einer!Einsatzplanung!!wird! der!tag!des!entwicklerteams!geplant.! 3.3.1! Relative'Schätzungen'mit'Story'Points' Schätzen!und!Planen!wird!einfacher,!wenn!man!nicht!gleich!in!Zeiteinheiten!wie! Personentagen!denkt,!sondern!zunächst!eine!Basisgröße!für!eine!User!Story!wählt!und! dann!die!größe!der!anderen!stories!in!relation!dazu!setzt.!für!diese!abstrakte!einheit! hat!sich!die!bezeichnung! Story!Point!eingebürgert.!Diese!Einheit!liefert!zunächst!zwar! noch!keine!information!darüber,!wie!viele!personentage!ein!punkt!bedeutet,!aber!nach! dem!sprint!zählt!man!die!story!points!der!fertigen!user!stories!zusammen!und!die! Umrechnung!in!Personentage!auf!Basis!der!verbrauchten!Zeit!ist!eine!einfache! Dreisatzrechnung.! Die!Schätzung!läuft!z.B.!wie!folgt!ab:!Für!die!Story!A,!die!mir!bereits!vertraut!ist,!setze!ich! 2!Story!Points!an.!Den!Aufwand!für!Story!B!schätze!ich!halb!so!groß!wie!A,!also!einen! Story!Point,!die!Story!C!halte!ich!für!viermal!so!groß!wie!Story!A!und!gebe!ihr!8!Story! Points.!Noch!besser!wird!das!Ergebnis!oft,!wenn!jeder!Schätzer!jede!User!Story!mit!zwei! anderen!ihm!bereits!vertrauten!stories!größenmäßig!in!beziehung!setzt,!eine!methode,! die!man!auch!als! Triangulation!bezeichnet.! Story'Points'als'Stabilitätsfaktor'für'die'Aufwandschätzung' Das!Arbeiten!mit!Story!Points!hat!mehrere!Vorteile.!Zum!einen!geht!die!von!konkreten! Aufwänden!losgelöste!Schätzung!schneller,!Komplexität!und!Größenverhältnisse!der! Features!im!Projekt!werden!sichtbar.!Da!Story!Points!nur!eine!Vergleichsgröße! darstellen,!bleiben!sie!stabil,!selbst!wenn!erste!aufwandschätzungen!korrigiert!werden! müssen.!gleiche!große!stories!bekommen!auch!später!die!gleiche!zahl!von!story!points.!!!improuv!gmbh!! 33!

35 Agiles!Planen!und!Schätzen! Und!das!Ganze!hat!noch!eine!psychologische!Komponente:!Mit!Story!Points!als!relative! Größe!ohne!konkrete!Maßeinheit!überlistet!man!das!eigene!Unterbewusstsein,!das!dazu! tendiert,!mit!sätzen!wie! Das!darf!doch!nicht!so!viel!kosten!!die!Schätzung!zu! manipulieren.! Bestimmung'der'Velocity' Nach!einem!Sprint!addiert!man!die!Story!Points!der!fertigen!und!abgenommenen!Stories,! und!berechnet!so!die!erreichte!velocity!eines!sprint.!die!durchschnittliche!velocity!pro! Sprint!gibt!dem!Product!Owner!die!Möglichkeit,!die!Restdauer!des!Releases!zu!schätzen! und!einen!releasetermin!zu!planen.! Nach!Abschluss!des!ersten!Sprints!kann!man!erste!Prognosen!darüber!aufstellen,!wie! viele!story!points!das!team!in!einem!sprint!abarbeiten!kann.!allerdings!schwanken!bei! neuen!teams!die!werte!für!die!velocity!oft!stark,!ein!gutes!team!erreicht! erfahrungsgemäß!nach!drei!bis!fünf!sprints!eine!stabile!velocity,!die!zuverlässige! Hochrechnungen!für!das!Gesamtprojekt!bzw.!das!Release!möglich!macht.! Was!kann!man!tun,!wenn!der!Product!Owner!am!Anfang!eine!Schätzung!braucht?!Wenn! das!gleiche!team!schon!vorher!zusammengearbeitet!hat,!helfen!auch!hier!story!points,! man!kann!die!kalibrierung!der!stories!aus!dem!vorigen!projekt!auf!die!neuen!stories! anwenden.!! Story'Points'gelten'nur'für'das'eigene'Team' Aber!Vorsicht:!Die!Natur!der!Schätzung!macht!Story!Point!nur!innerhalb!eines!Teams!zu! einem!brauchbaren!prognosemittel,!sie!sind!nur!bedingt!zwischen!teams!übertragbar:!!! Jedes!Team!hat!andere!Stories!als!Basis!der!Kalibrierung!gewählt.!!! Auch!bei!gleichen!Stories!ist!nicht!gewährleistet,!dass!in!einem!anderen!Team! dieselbe!verteilung!von!fähigkeiten!und!erfahrungen!gegeben!ist,!sodass!das!andere! Team!andere!Aufgaben!schwer!bzw.!leicht!finden!wird.!!! Ein!Versuch,!über!Vergleich!der!Velocities!zweier!Teams!einen!Leistungsvergleich! durchzuführen,!macht!sofort!die! Währung!Story!Point!unbrauchbar:!Nichts!ist! leichter!für!ein!team!als!einfach!höhere!schätzungen!abzugeben!!die!währung! Story!Point!erleidet!eine!Hyperinflation!und!ist!wertlos.! Um!Story!Points!in!einem!größeren!Projekt!mit!mehreren!Teams!vergleichbar!zu!machen! und!für!die!releaseplanung!nutzen!zu!können,!ist!es!notwendig!die!größenskala! zwischen!den!teams!z.b.!durch!referenzgstories!zu!kalibrieren.!! 3.3.2! Die'Kunst'des'Schätzens' Eine!wichtige!Voraussetzung,!um!bei!der!Aufwandschätzung!verschiedener!User!Stories! gut!voranzukommen,!liegt!in!der!wahl!geeigneter!größen.!wer!in!zu!kleinen!einheiten! denkt,!verzettelt!sich!unweigerlich!in!diskussionen!im!kampf!mit!völlig!unnötigen!! Genauigkeiten.!Kann!ich!eine!1GPunktGStory!von!einer!2GPunktGStory!unterscheiden?!In! aller!regel!ja,!denn!die!zweite!braucht!schließlich!den!doppelten!aufwand.!kann!ich! 34!!!improuv!GmbH!!

36 !! Agiles!Planen!und!Schätzen! auch!eine!17gpunktgstory!von!einer!18gpunktgstory!unterscheiden?!nein,!mit!sicherheit! nicht.!denn!hier!würde!es!um!eine!präzisierung!gehen,!die!dem!verständnis!von! Schätzung!widerspricht.!Plausibel!sind!Skalen,!die!intuitiv!sind,!bei!denen!mit! zunehmenden!werten!auch!die!abstände!wachsen!oder!die!den!teilnehmern!aus! Erfahrung!vertraut!sind,!wie!zum!Beispiel:!!! Zweierpotenzen:!1,!2,!4,!8,!16!oder!!! Verschwommen!wirkende!Skalen!wie!1,!2,!3,!5,!8,!13,!die!die!ersten!Zahlenwerte!aus! der!fibonaccigreihe!entlehnt!hat!oder!!! TGShirt!Größen:!XS,!S,!M,!L,!XL,!XXL.! Für!User!Stories,!die!keinen!oder!nur!marginalen!Aufwand!erfordern,!ist!es!auch!einmal! möglich.!die!größen!0!oder!½!zu!verwenden 4.!Wichtig!ist!es,!dass!die!einmal!gewählte! Skala!während!der!gesamten!Projektlaufzeit!möglichst!stabil!bleibt,!denn!nur!so!kann! sich!die!gewünschte!planungserfahrung!in!einer!stabilen!velocity!niederschlagen.! Wenn!das!Team!im!Lauf!der!Zeit!schneller!wird,!wird!man!das!allein!an!der!wachsenden! Velocity!sehen,!es!besteht!kein!Grund,!die!Kalibrierung!zu!ändern.! 3.3.3! Planning'Poker' Diese!Schätzmethode!baut!auf!der!BreitbandGDelphiGMethode!auf 5,!bei!der!mehrere! Experten!herangezogen!werden,!die!sich!untereinander!abstimmen.!Als!Messgröße! dienen!story!points!oder!auch!(wenn!die!tasks!im!sprint!planning!geschätzt!werden)! Zeiteinheiten!wie!Entwicklerstunden!oder!Gtage.!Wichtige!Anforderung!für!die!Skala!ist,! wie!oben!beschrieben,!dass!die!abstände!nach!oben!größer!werden.!! Im!Schätzmeeting!diskutieren!Product!Owner!und!Team!zunächst!jede!einzelne!User! Story,!so!dass!ein!gemeinsames!Verständnis!dieser!Aufgabe!entsteht.!Der!Product! Owner!erläutert!die!Anforderungen,!die!hinter!den!Product!BacklogGEinträgen!stehen,! und!das!team!stellt!fragen!dazu.!wenn!das!team!die!story!verstanden!hat,!macht!jedes! Teammitglied!seine!(verdeckte)!Schätzung,!dann!decken!alle!gemeinsam!ihre! Wertungen!auf.!! Die!Resultate,!insbesondere!die!Ausreißer,!werden!diskutiert,!bis!das!Team!eine! gemeinsame!meinung!erzielt!hat.!! Wir!empfehlen:!!! insbesondere!über!die!größten!und!kleinsten!werte!zu!diskutieren:!dahinter! verbergen!sich!oft!lösungsansätze!oder!umgekehrt!das!wissen!um!probleme,!die!den! anderen!teammitgliedern!entgangen!sind!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 4 ein Beispiel für 0 ist eine externe Zulieferung, die zwar keinen eigenen Aufwand erfordert, aber der Vollständigkeit halber integriert werden muss. Die Notwendigkeit zur Verwendung von ½ ist ein Hinweis darauf, dass das Team nicht die optimale Basis gewählt hat und eine falsche Granularität verwendet !

37 Agiles!Planen!und!Schätzen!!! Echter! Poker!!die!Karten!zuvor!verdeckt!hinlegen!und!wirklich!gleichzeitig! aufdecken,!keine!beeinflussung!der!anderen!teammitglieder!!! Vertreten!und!Argumentieren!meiner!Schätzung!!nicht!einfach!um!des!lieben! Friedens!wegen!nachgeben!( gut,!dann!nehme!ich!auch!eine!2 )! Planning!Poker!hat!eine!Menge!wertvoller!Seiteneffekte,!die!die!Vorteile!dieser! Methode!noch!erhöhen.!Planning!Poker!!! gewährleistet,!dass!das!team!auf!bisherigen!erfahrungen!aufbaut,!!! unterstützt,!dass!das!team!sich!besser!kennenlernt!und!zusammenwächst,!!! bezieht!ausnahmslos!alle!teammitglieder!ein,!!! lässt!das!expertenwissen!und!unterschiedliche!sichtweisen!wirksam!werden,!!! verhindert!manipulation!durch!dominante!teammitglieder,!!!! fördert!die!kommunikation!des!teams!mit!dem!product!owner,!!!! eliminiert!unterschiede!in!risikosicht!und!zeitgefühl,!!! führt!in!aller!regel!einen!konsens!herbei,!!! bringt!gerade!in!situationen!mit!unvollständigem!wissen!sehr!gute!ergebnisse.! Beim!Planning!Poker!gilt!exemplarisch,!was!wir!bereits!über!die!Planung!allgemein! gesagt!haben:!durch!das!gemeinsame!schätzen!lernen!die!teammitglieder!eine!menge! über!den!gegenstand!und!über!die!herangehensweise!der!andern.!es!hat!dadurch!einen! eigenen!wert,!der!über!die!gewonnenen!zahlen!hinausgeht.! Affinity'Estimation' Affinity!Estimation!ist!ein!ähnliches!Verfahren!wie!Bucket!Estimation,!aber!es!kommt!am! Anfang!ohne!einen!Kalibrierungsschritt!aus.!Zuerst!werden!die!Stories!nach!ihrer!Größe! sortiert!ausgelegt,!mit!ähnlichen!vorgaben!wie!bei!der!bucket!estimation.!das!ziel!ist,! dass!die!stories!in!einer!reihe!liegen!mit!der!größten!story!an!einem!ende!und!der! kleinsten!am!anderen!ende!der!reihe.!erst!danach!werden!die!pokerkarten!mit!den! Schätzgrößen!parallel!dazu!ausgelegt.!Die!Stories!sind!demnach!schon!der!Größe!nach! geordnet,!wenn!ihnen!jetzt!eine!skala!zugeordnet!wird.!! Der!Skalierungsschritt!liegt!also!am!Ende!des!Vorgangs.!Das!vermindert!das!Risiko,!dass! man!eine!zu!grobe!oder!zu!feine!skala!gewählt!hat!und!mit!ungünstigen!zahlen!leben! muss.! 36!!!improuv!GmbH!!

38 !! Scrum!im!Unternehmen! 4! Scrum'im'Unternehmen' Die!Ziele!eines!Unternehmens!laufen!nicht!immer!konform!mit!den!Zielen!eines!agilen! Projektes.!In!einem!agilen!Projekt!haben!die!Beteiligten!das!Ziel,!mit!minimalem! Aufwand!einen!maximalen!Wert!und!das!bestmögliche!Produkt!zu!liefern.!Dem!stehen! häufig!unternehmensziele!entgegen,!die!z.b.!ein!detailliertes!finanzcontrolling,! Dokumentationspflichten!oder!ein!standardisiertes!InfrastrukturG!und! Personalmanagement!erfordern.!Bei!der!Anwendung!agiler!Praktiken!gibt!es!daher! häufig!konflikte!mit!bestehenden!unternehmensgregeln.!! Als!Teammitglieder!aber!auch!als!agile!Manager!oder!Product!Owner!können!wir!diese! Konflikte!oft!nicht!abstellen!!sie!bleiben!uns!als!organisatorische!Hindernisse!erhalten!! aber!wir!können!sie!verstehen!und!damit!!!! Argumente!für!den!Einzelfall!entwickeln,!um!Entscheidungen!zu!beeinflussen,!!! ein!verständnis!zu!entwickeln,!um!die!dahinter!stehende!logik!zu!begreifen!und!ggfls.! zu!nutzen.! 4.1! Organisatorische'Gründe'für'Ineffektivität' In!jedem!Unternehmen!gibt!es!Regeln!und!Richtlinien,!die!auf!effiziente!Prozesse,!hohe! Qualität!und!Controlling!abzielen!und!damit!letztendlich!gewährleisten!sollen,!dass!mit! den!vorhandenen!ressourcen!höchstmögliche!produktivität!erreicht!wird.!allerdings! haben!diese!normen!nicht!immer!die!gewünschte!wirkung.!oft!blockieren!richtlinien! den!idealen!entwicklungsprozess!durch!wartezeiten!oder!prozesse!werden!mit! vielfältigen!controllinggmechanismen!überfrachtet.! Für!uns!in!der!Softwareentwicklung!ist!dieses!Phänomen!in!zweierlei!Hinsicht!relevant:! Zum!einen!wird!der!kreative!Entwicklungsprozess!von!manchen!Vorgaben!eingeschränkt.! Zum!anderen!werden!die!zu!entwickelnden!Systeme!immer!komplexer!und!die! Rahmenbedingungen,!die!man!uns!einräumt,!immer!unrealistischer.!! Das'Problem'der'Komplexität'?'Less'is'more' Die!Komplexität!eines!Gesamtsystems!steigt!mit!jedem!neuen!Element!exponentiell.! Viele!Softwaresysteme!werden!zu!komplex,!da!Anforderungen!und!Features!nicht! priorisiert!sind!und!der!kundennutzen!nicht!hinterfragt!wurde.!übergabeformalien!oder! falsches!erwartungsmanagement!suggerieren,!der!umfang!der!systeme!sei!nicht! verhandelbar.!warnungen!von!entwicklungsspezialisten!werden!als!renitenz!oder! Bequemlichkeit!interpretiert,!und!das!Management!entscheidet!sich!unbeeindruckt!von! allen!einwänden!für!eine!komplexe! Goldrandlösung.!Das!Ergebnis!kennen!wir,! unfertige!systeme,!die!mit!vielen!fehlern!ausgeliefert!werden!und!nur!mit!hohem! Aufwand!wartbar!sind.!!!!improuv!GmbH!! 37!

39 Scrum!im!Unternehmen! Wunschdenken' 'Unrealistische'Ziele' Nicht!nur!in!der!Softwareentwicklung!herrscht!ein!allgegenwärtiges!Wunschdenken:! Man!wünscht!sich!das!System!mit!all!den!vielen!Features,!die!auf!der!langen! Wunschliste!stehen.!Nachdem!dann!eine!erste!Planung!und!Schätzung!zeigt,!dass!nicht! alles!in!der!gewünschten!zeit!realisierbar!ist,!wird!trotzdem!versucht,!so!viel!wie!möglich! zu!bekommen,!auf!kosten!der!qualität.! Dasselbe!gilt!für!den!Entwicklungsprozess!selbst:!Wir!prüfen!nicht!die!Nützlichkeit!eines! neuen!werkzeugs,!produzieren!keine!prototypen,!haben!keine!systematische!methode,! aus!unserer!arbeit!erkenntnisse!zu!gewinnen.!wir!wollen,!dass!es!so!klappt,!also!wird!es! das!auch!!oder?! Technische'Schulden' Ein!Resultat!von!unrealistischen!Projektzielen!sind!Technische!Schulden.!Viele! Unternehmen!tolerieren!unfertigen!Code,!drängen!Entwickler!zu!unrealistischen! Zeitplänen!und!sparen!am!Refactoring,!um!die!Illusion!aufrecht!zu!erhalten,!das!Ziel!sei! doch!noch!zu!erreichen.!die!auswirkungen!unzureichender!qualität!wie!steigende! Wartungskosten!und!unzufriedene!Kunden!werden!meist!zu!spät!wahrgenommen.!! In!Unternehmen,!in!denen!eine!fehlende!Priorisierung!und!unrealistische!Ziele!einen! guten!entwicklungsprozess!verhindern,!ist!es!oft!die!reine!notwehr!der!entwickler,!die! zu!technischen!schulden!führt.!schlechte!software!ausliefern!heißt!technologische! Schulden!machen.!Und!wie!andere!Schulden!muss!man!auch!die!zurückzahlen.! Remaining Effort Sprint 3 Unit Unit Unit Sprint 2 Unit Unit Unit Unit Technical Debts Sprint 1 Unit Unit Unit Unit Time Abbildung!4.1:!Die!Auswirkungen!von!Technischen!Schulden! Zielvereinbarungen'und'Performance'Kennzahlen' Viele!Performance!Kennzahlen!in!Unternehmen!messen!die!individuelle!Auslastung!der! Mitarbeiter!und!verhindern!damit!eine!gute!Teamleistung.!Tom!DeMarco!und!Timothy! 38!!!improuv!GmbH!!

40 !! Scrum!im!Unternehmen! Lister 6! nennen!dieses!phänomen! teamicide,!wenn!durch!individuelle! Leistungsbewertung!die!Stimmung!und!TeamGMoral!untergraben!wird.!! Dinge!können!sich!rapide!in!die!falsche!Richtung!entwickeln,!wenn!man!versucht,!die! Leistung!eines! Wissensarbeiters!zu!messen.!Ein!Belohnungssystem!auf!der!Basis!von! Lines!of!Code!verführt!z.B.!dazu!viele!Zeilen!fehlerhaften!Code!zu!schreiben.!Falls!das! Unternehmen!dann!beschließt,!eine!Strafe!für!die!Anzahl!von!Fehlern!im!Code! einzuführen!wird!jeder!versuchen,!die!fehler!einfach!zu!verstecken.!! Wir!empfehlen!als!entscheidende!Bewertungsgröße!die!TeamGProduktivität!zu!nutzen.! Wir!interessieren!uns!vornehmlich!für!die!Kundenzufriedenheit,!Teamzufriedenheit!und! die!wertschöpfung.!das!diese!zugegebenermaßen!nicht!einfach!zu!messen!sind,!kann! man!auf!abgeleitete!kennzahlen!zurückgreifen:!teamgkennzahlen!wie!stabile!velocity,! TestGAbdeckung!und!Fehlerhäufigkeit!sollten!regelmäßig!gemessen!und!mit!dem!Team! analysiert!werden!(der!wichtige!aspekt!ist:!mit!dem!team).!jedes!team!wird!versuchen,! auf!basis!seiner!bewertung!kontinuierlich!besser!zu!werden.!wir!glauben!nicht,!dass! finanzielle!belohnungssysteme!die!produktivität!eines!teams!weiter!verbessern!können.! Auslastung'und'Effektivität' Lange!Zeit!galt!es!als!oberste!Maxime,!dass!eine!optimale!Einsatzplanung!darin!besteht,! alle!mitarbeiter!möglichst!zu!jedem!zeitpunkt!hundertprozentig!auszulasten.!das!war! nicht!auf!die!softwareentwicklung!beschränkt!und!es!ist!den!meisten!von!uns!in!fleisch! und!blut!übergegangen,!dass!es!nicht!schlimmeres!gibt!als!eine!nicht!ausgelastete! Ressource!!und!darunter!zählte!man!wie!selbstverständlich!auch!die!Mitarbeiter.! Doch!Anfang!der!achtziger!Jahre!reifte!in!der!Umgebung!industrieller!Fertigungsanlagen! die!erkenntnis,!dass!eine!hundert!prozent!auslastung!einige!unerwünschte! Nebeneffekte!hat.!Ausschlaggebend,!so!die!neue!Erkenntnis,!sei!die!Optimierung!des! Systems!insgesamt!und!nicht!die!lokale!Optimierung!in!den!einzelnen!Arbeitsschritten.! Unter!normalen!Bedingungen,!so!das!Ergebnis!umfassender!Testläufe,!ist!das!Optimum! erreicht,!wenn!die!einzelnen!stationen!zu!zirka!achtzig!prozent!ausgelastet!sind.!das!ist! eine!ziemlich!überraschende!zahl,!aber!sie!ist!mit!vielen!praxiserfahrungen!abgesichert! und!hat!eine!solide!mathematische!entsprechung!in!der!warteschlangentheorie.! Eliyahu!M.!Goldratt!hat!das!in!seiner! Theory!of!Constraints 7!(TOC)!bewusst!gemacht! und!in!einem!unterhaltsamen!buch! Das!Ziel!anschaulich!verpackt.!Vor!allem!gelte!es,! so!seine!botschaft,!engpässe!zu!erkennen!und!an!diesen!den!durchfluss! aufrechtzuerhalten.! Dieser!Ansatz!lässt!sich!teilweise!in!die!SoftwareentwicklungsGPerspektive!übertragen.! Der!erste!Teil!ist!die!Betrachtung!der!Auslastung:!es!dürfen!nicht!immer!alle! Teammitglieder!komplett!oder!!auch!das!ergibt!sich!aus!der!HundertGProzentG Forderung!schnell!!sogar!zu!mehr!als!hundert!Prozent!ausgelastet!sein!!Die!Gründe! liegen!eigentlich!auf!der!hand:!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 6 Tom DeMaro und Timothy Lister, Peopleware: Productive Projects and Teams, Eliyahu Goldratt: Das Ziel. Campus Verlag 2001!improuv!GmbH!! 39!

41 Scrum!im!Unternehmen!!! Wenn!eine!vollständige!Auslastung!vorliegt,!kann!das!Team!keinerlei!neue! Anforderungen!oder!überraschende!Informationen!mehr!verkraften.!!! Mit!Scrum!kann!ein!erfahrenes!Team!sehr!schnell!erkennen,!wann!eine!Aufgabe!in! einem!sprint!auf!dem!kritischen!pfad!ist.!das!team!braucht!dann!genügend!freie! Kapazität,!um!das!Augenmerk!auf!diese!Aufgabe!richten!zu!können!und!zu! verhindern,!dass!diese!aufgabe!von!anderen!aufgaben!blockiert!wird.!!!! Bei!einer!vollständigen!Auslastung!ist!keine!kreative!Arbeit!mehr!möglich.!Man!kann!!für!eine!begrenzte!Zeit!!funktionieren,!aber!das!ist!keine!Zielsetzung,!die!der! nachhaltigen!weiterentwicklung!der!mitarbeiter!oder!der!firmenziele!dient.! Es!gibt!aber!einen!wichtigen!Unterschied!zwischen!der!Theory!of!Constraints!und!dem! Funktionieren!eines!ScrumGTeams:!Bei!der!TOCGFertigung!ist!es!von!zentraler!Bedeutung,! dass!die! kritische!ressource!optimal!ausgelastet!ist.!oft!ist!das!eine!besonders!teure! Maschine!oder!ein!aufwändiger!Prozessschritt.!Übertragen!auf!ein!Softwareteam!wäre! das,!dass!der!mitarbeiter,!dessen!spezielles!knowghow!im!projekt!gerade!am!meisten!! gefragt!ist!!optimal!arbeiten!kann.!das!ist!aber!sowohl!unnötig!als!auch!gefährlich:!!! Kopfmonopole!gefährden!den!Projekterfolg:!die!jeweiligen!unentbehrlichen! Mitarbeiter!können!im!Zweifelsfall!nicht!einmal!mehr!in!Urlaub!fahren.!Wir!kennen! ein!team,!das!eine!grobe!formulierung!dafür!gefunden!hat,!sie!reden!vom!truckg Faktor:!Wie!viele!Teammitglieder!müssen!mindestens!vom!Truck!überfahren!werden,! bis!das!projekt!blockiert!ist?!!! Kopfmonopole!neigen!dazu,!sich!zu!verfestigen.!Da!der!Kollege!die!wichtigsten!und! anspruchsvollsten!aufgaben!übernimmt,!bekommt!er!auch!die!beste!weiterbildung.!!! Kopfmonopole!führen!dazu,!dass!im!Extremfall!fast!das!ganze!Team!wartet!und!nicht! arbeiten!kann.! Wir!bauen!statt!dessen!darauf,!dass!das!kritische!KnowGHow!besser!im!Team!verteilt! wird.!deshalb!sind!techniken!wie!pair!programming!auch!ein!zentrales!mittel!zur! Verbesserung!der!Gesamtperformanz!des!Teams!und!ein!Mittel!zur!Wissensverbreitung! und!risikominimierung!in!der!softwareentwicklung.! 4.2! Agile'Werte'im'Unternehmen'verankern' Lean!Thinking!ist!wie!schon!beschrieben!ein!Konzept,!das!auf!die!Schaffung!von! Werten!ohne!Verschwendung!abzielt.!Es!breitet!sich!immer!mehr!in!Unternehmen!aus.! Mary!und!Tom!Poppendieck 8!!haben!in! Lean!Software!Development!gute! Handlungsmuster!geliefert!wie!man!Software!Entwicklung!schlanker!machen!kann.!Ihre! wichtigsten!prinzipien!sind:!vermeide!verschwendung,!ermögliche!lernen,!liefere!so! schnell!wie!möglich!und!stärke!das!team.!! Je!besser! Lean!Thinking!bereits!in!der!Unternehmenskultur!verankert!ist,!desto! leichter!ist!es!für!agile!softwareentwickler,!anerkennung!und!respekt!zu!ernten.!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!! 8 Mary and Tom Poppendieck, Lean Software Development, An agile Toolkit, !!!improuv!GmbH!!

42 !! Scrum!im!Unternehmen! Vertraut!das!Unternehmen!hingegen!auf!eine!relativ!akribische!PlanungsG!und! Controllingkultur,!muss!man!das!agile!Gedankengut!erst!aktiv!im!Unternehmen! verbreiten!was!nicht!immer!einfach!ist.! Die!Rolle!eines!Evangelisten!liegt!nicht!jedem,!aber!die!ersten!agilen!Erfolge!in!einem! Unternehmen!verbreiten!sich!oft!von!selbst.!Wer!mehr!tun!möchte!kann!in!Gesprächen! mit!kolleginnen!und!kollegen!oder!bei!firmeninternen!veranstaltungen!versuchen,! gezielt!um!verständnis!für!agile!werte!zu!werben.!beim!management!wirkt!es!oft! Wunder,!wenn!ein!Product!Owner!über!seine!positiven!Erfahrungen!berichtet.!Ziel! solcher! Öffentlichkeitsarbeit!kann!nicht!nur!sein,!die!Akzeptanz!für!die!Arbeit!eines! agilen!entwicklerteams!zu!fördern.!es!ist!durchaus!sinnvoll,!sich!dafür!einzusetzen,!dass! auch!geschäftsbereiche!außerhalb!der!it!von!den!vorteilen!der!agilität!profitiert.!! 4.3! Agiles'Controlling'und'Reporting' Scrum!hat!gegenüber!dem!traditionellen!Projektmanagement!den!entscheidenden! Vorteil,!dass!es!ohne!aufwändige!Controlling!und!Dokumentationsinstrumente!jederzeit! eine!hohe!transparenz!über!den!projektfortschritt!liefert.!die!ständige!rückkopplung! nach!jedem!sprint!mit!dem!product!owner!und!anderen!stakeholdern!ist!klassischen! Statusberichten!und!Ampelgrafiken!weit!überlegen.!Am!Ende!des!Sprints!weiß!jeder!was! fertig!ist!oder!nicht,!software!zum!anfassen,!fertig!entwickelt,!getestet!und! demonstriert.!! Lines of Code Unrefaktorierter Code Rechtzeitige Lieferung Schlampige Software Abbildung!4.2:!Menschen!passen!ihr!Verhalten!an!die!Bewertung!an! Ein!noch!intensiveres!ControllingGInstrument!ist!das!ständige!Feedback!im!Scrum!Team:! Tägliche! Daily!Scrum!mit!Kurzberichten!und!Bewertung!der!restlichen!Arbeit!im!Sprint! Burndown,!Messung!der!TeamGVelocity!!bei!all!diesen!Feedback!Loops!ist!es!kaum! möglich,!dass!jemand!unbemerkt!wochenlang!einem!irrweg!folgt!und!dies!nicht! korrigiert!wird.! Als!geeignete!Methode,!um!iterative!Entwicklungsprojekte!auch!längerfristig!planen!und! verfolgen!zu!können!hat!sich!die!projektverfolgung!in!einem!release!burndown!(wie!in! Bild!03G08!gezeigt)!bewährt.!Dadurch!wird!einprägsam!visualisiert,!welche!Fortschritte! erzielt!wurden,!wo!es!verzögerungen!gab!und!auch!wie!sich!der!scope!entwickelt!hat.! Zudem!ist!dieses!Dokument!in!der!Sprache!des!Kunden!verfasst,!die!Ergebnisse!sind!für! Controlling!und!Management!verständlich!und!nachvollziehbar.!!improuv!GmbH!! 41!

43 Scrum!im!Unternehmen! In!vielen!Scrum!Teams!hat!es!sich!außerdem!eingebürgert,!am!Ende!jedes!Sprints!einen! Sprint!Report!zu!erstellen,!um!messbare!Ergebnisse!an!die!Stakeholder!und!das! Management!zu!kommunizieren.!Ein!Sprint!Report!kann!z.B.!folgende!Punkte!enthalten:!!! Sprint:!Datum!von!Start!und!Ende!!!! Teammitglieder,!Arbeitstage!!geplant!und!erbracht!!!! fertiggestellte!und!unfertige!user!stories!!!! ungeplante!arbeit!(defects,!productiongissues,)!!! Story!Points!geplant!und!geliefert!(d.h.!die!Velocity)!!!! aufgetretene!und!beseitigte!hindernisse!!!! Testabdeckung!durch!UnitG!und!Akzeptanztests! Einen!gewissen!Lerneffekt!im!Projektumfeld!kann!man!manchmal!mit!der! Veröffentlichung!bzw.!dem!sichtbaren!Aufhängen!des!Impediment!Logs!erreichen.! Wenn!hier!z.B.!dokumentiert!wird,!wie!oft!Mitarbeiter!unerwartet!für!andere!Projekte! abgezogen!werden,!kann!das!den!impuls!geben,!auch!an!anderen!orten!die!planung!zu! verbessern.! 4.4! Das'Projektgedächtnis'organisieren' Wie!lässt!sich!sicherstellen,!dass!längerfristige!Entwicklungen!in!einem!Projekt!und!die! Erfahrungen!aus!einem!ScrumGProjekt!für!neue!und!alte!TeamGMitglieder! nachvollziehbar!bleiben?!als!ein!passendes!medium!haben!sich!projektgwikis!erwiesen,! die!sehr!gut!der!philosophie!von!agil!entsprechen:!man!kann!sehr!klein!anfangen!und! muss!nicht!alle!eventualitäten!voraussehen.!im!verlauf!des!projekts!wächst!das!medium! mit!seinen!aufgaben.!zudem!verträgt!es!nicht!nur!text,!sondern!nimmt!auch!andere! Formate!wie!Fotoprotokolle!auf.!! Für!die!Organisation!und!Struktur!des!Wikis!gibt!es!viele!Möglichkeiten.!Man!sollte! darauf!achten,!dass!die!team!unmittelbar!nutzen!daraus!ziehen!und!das!wiki!nicht! ausschließlich!etwa!der!dokumentation!für!die!nachwelt!dient.!! Folgende!Inhalte!haben!sich!in!ProjektGWikis!als!nützlich!erwiesen:!!! Was!wurde!gemacht?!!! Welche!Entscheidungen!wurden!warum!getroffen?!!! Was!muss!der!Entwickler!wissen?!!! Was!muss!der!Nutzer!wissen?!!! Was!muss!der!Betrieb/der!User!Helpdesk!wissen?! Weitere!Punkte!können!sein:!!! Zusätzliche!Dokumentation,!z.B.!DeploymentGInformationen,!Nachweise!für! Compliance!! 42!!!improuv!GmbH!!

44 !! Scrum!im!Unternehmen!!! Mitarbeiter,!Zugänge,!Abgänge,!Urlaubszeiten!!! Log!wichtiger!ProjektGInformationen,!z.B.!Entscheidungen!oder!Ereignisse!!! Dokumentation!der!Hindernisse!und!der!herbeigeführten!Ergebnisse!z.B.!im! ImpedimentGBacklog!! 4.5! Buchhaltung'und'Abrechnung' Für!die!!ProjektGBuchhaltung!in!einem!ScrumGProjekt!gibt!es!sowohl! unternehmensinterne!als!auch!externe!möglichkeiten!der!leistungsg!und! Kostenverrechnung.!! Unternehmensintern!steht!beispielsweise!ein!Budget!für!eine!SoftwareGEntwicklung!zur! Verfügung.!Idealerweise!ist!der!Product!Owner!Eigentümer!bzw.!Verwalter!dieses! Budgets!und!bezahlt!daraus!die!Kosten!des!Scrum!Teams.!Er!kann!vor!jedem!Sprint! entscheiden,!welche!stories!das!team!liefern!soll.!bei!einem!team!mit!stabiler!velocity! kann!man!die!kosten!eines!features!anhand!der!story!points!einfach!ermitteln.!anhand! der!durchschnittlichen!kosten!eines!sprint!kann!man!ausserdem!hochrechnen,!wann!das! Budget!verbraucht!sein!wird.!Diese!Information!braucht!der!Product!Owner,!um!die! Erwartungen!der!Stakeholder!entsprechend!managen!zu!können.! Eine!erprobte!Abrechnungsform!für!ScrumGProjekte!mit!externen!Kunden!ist!die! Vereinbarung,!dass!der!Kunde!pauschal!die!Kosten!für!das!Team!je!Sprint!bezahlt,!wobei! im!vorfeld!vereinbart!wird,!was!am!ende!des!sprints!geliefert!werden!soll.!dafür!erhält! der!kunde!das!sprintgresultat,!d.h.!neue!produktinkremente,!bestehend!auf!den! fertiggestellten!user!stories.!dieses!vorgehen!ist!transparent!und!nachvollziehbar!und! erspart!komplizierte!vertragsvereinbarungen.!andererseits!muss!der!lieferant!keinen! Aufschlag!für!unternehmerisches!Risiko!wie!bei!einem!Festpreis!kalkulieren.! Viele!Projekte!verlangen!eine!Arbeitszeiterfassung!bezogen!auf!einzelne!Tasks.!Dies!ist! aus!sicht!von!scrum!nicht!nur!verschwendung,!sondern!wirkt!sich!in!der!regel!auch! negativ!auf!die!effektivität!des!teams!aus,!das!ja!gemeinsam!die!insgesamt!beste!lösung! finden!soll.!! Gerade!in!projektbasierten!Dienstleistungsorganisationen!ist!eine!Granularität!auf! Ebene!Sprint!und!Team,!also!das! Buchen!auf!einen!Sprint!(noch)!nicht!möglich.!Eine! gute!lösung!für!eine!zeitaufzeichnung!in!solchen!fällen!wäre!zum!beispiel!die!anzahl! der!geleisteten!stunden!(des!gesamten!teams)!pro!usergstory!aufzuzeichnen,!also! auf! eine!story!zu!buchen.!!!improuv!gmbh!! 43!

45 Scrum!im!Unternehmen! 44!!!improuv!GmbH!! Index' Affinity!Estimation!.!36! Agiles!Manifest!..!3! Auftraggeber!!11! Auslastung!..!38,!39! Backlog!Grooming!.!23! BreitbandGDelphiGMethode!..!35! Chief!Product!Owner!!10! Command!and!Control!!14! commitment!.!8,!12! Controlling!.!37! Daily!Scrum!..!8! DEEP!.!21! Definition!of!Done!!9! done!!9! emergent!!16! FaceGtoGfaceGKommunikation!..!11! Feedback!..!5! Feedback!Loops!..!41! Festpreis!.!43! Fibonacci!!35! Fotoprotokolle!.!42! funktionale!spikes!.!21! grooming!!23! Hinderniss!.!7! Impediment!.!7! Impediment!Backlog!..!7! Industrialisierung!..!4! Komplexität!..!37! Kopfmonopol!!40! Lean!Thinking!..!40! Mediator!!13! Moderator!.!13! nachhaltigen!weiterentwicklung!..!40! Öffentlichkeitsarbeit!!41! Pair!Programming!..!40! Planungsebenen!.!32! Product!Backlog!..!15! Product!Owner!!6,!10! Product!Owner!Team!..!10! Produkt!Backlog!Eisberg!.!16! ProduktGInkrement!!12! Projektleiter!.!14! ProjektGWikis!!42! ready!..!9! Release!Burn!Down!Chart!.!19! ReleaseGDaten!.!10! Respekt!!40! Ressourcenauslastung!.!39! Restaufwände!.!18! Return!On!Invest!!11! Risikominimierung!.!40! ROI!..!Siehe!Return!On!Invest! Rollenkonflikt!..!14! Scrum!Master!.!6! ScrumGTeam!!7! selbstorganisiertes!team!.!7! Servant!Leader!.!13,!14! SMART!.!18! spikes!!21! Sprint!Backlog!..!7,!17! Sprint!Burn!Down!Chart!.!18! Sprint!Review!.!8! Sprintplanung!.!8! SprintGZiel!.!8! Stakeholder!..!8,!10! Systemadministrator!!12! Team!!7! Teamcoach!!13! Teamrollen!!12! technische!schulden!.!38! technische!spikes!..!21! Tester!..!12! Theory!of!Constraints!..!39! TruckGFaktor!.!Siehe!Kopfmonopol! Tunnelblick!!24! Umsetzungsteam!.!7! unternehmerisches!risiko!.!43! User!Story!..!16! Wissensverbreitung!..!40! Wunschdenken!!38!!!

46 improuv GmbH Brecherspitzstr München training@improuv.com PDF-Version