Scrum und CCPM+ zwei Erfolgsmodelle mit den gleichen Wurzeln GPM Düsseldorf,

Transkript

1 Scrum und CCPM+ zwei Erfolgsmodelle mit den gleichen Wurzeln GPM Düsseldorf,

2 2 Situation im IT-Projektmanagement Boston, Massachusetts, April 23, New Standish Group report shows more project failing and less successful projects. The Standish Group's just-released report, "CHAOS Summary 2009," "This year's results show a marked decrease in project success rates, with 32% of all projects succeeding which are delivered on time, on budget, with required features and functions" says Jim Johnson, chairman of The Standish Group, "44% were challenged which are late, over budget, and/or with less than the required features and functions and 24% failed which are cancelled prior to completion or delivered and never used." "These numbers represent a downtick in the success rates from the previous study, as well as a significant increase in the number of failures", says Jim Crear, Standish Group CIO, "They are low point in the last five study periods. This year's results represent the highest failure rate in over a decade"

3 3 Zwei Erfolgsmodelle Scrum Critical Chain-Projektmanagement (CCPM) P1 P2 P3 P1 P2 Puffer P3 Puffer

4 4 Scrum-Master.de Agiles Projektmanagement Alexander Kriegisch Freiberuflicher agiler Coach & Projektmanager # 20 Jahre kommerzielle Programmier-Erfahrung 15 Jahre Vollzeit in Software-Industrie 10 Jahre Beratung 7 Jahre Projektmanagement Scrum-Master.de Training, Coaching, Supervision Themen: Agile Enterprise, Scrum (Multi-)Projektmanagement Troubleshooting Interim-Management

5 5 Referenzen Scrum-Master.de Parallels Einführung des Scrum-Vorgehensmodells (Standort Moskau) Coaching und Training Meta Scrum im Management-Team skalierter Multi Team Scrum-Prozeß Einführung von SW-Engineering-Praktiken (Unit Testing, Continuous Integration) 1&1 Internet AG Einführung des Scrum-Vorgehensmodells Coaching und Training bereichsübergreifend Leitung zweier Software-Großprojekte und zweier Forschungsprojekte im Bereich Webhosting Beratung als "Scrum-Evangelist" für Management (Agile Enterprise) und Teams (Scrum im Projekt) Sun Microsystems GmbH Entscheider-Workshop "Selling Agile" Beratung bzgl. der Frage, wie Scrum komplexe Kundenprojekte und deren Preisfindung verbessern kann Projekttyp: Rechenzentrums-Aufbau bzw. -Migration 42media group GmbH Scrum-Coaching und -Training für Geschäftsführung und Entwicklungsabteilung Verbesserung des bestehenden Scrum-Prozesses Agile Aufwandschätzung und Release-Planung Scrum-Rollen im Unternehmen (Agile Enterprise) Elektrobit Automotive GmbH Offene Scrum-Einführungsveranstaltung für Belegschaft am Standort Erlangen + Webcast an alle Standorte Supervision und Mentoring für Scrum-Projekt im Bereich Automotive Besondere Herausforderung: Projektmitarbeiter über zwei Standorte verteilt Autoliv Scrum-Workshop am Standort Elmshorn Projekttyp: ERP-Eigenentwicklung Großrechner (Host) in COBOL Besondere Herausforderung: Legacy-Umgebung, traditionelle IT-Prozesse Kassenärztliche Vereinigung Bayerns Erste positive Scrum-Erfahrungen im Entwicklungsbereich Einige anstehende Projektvorhaben geplant mit Scrum als agilem Vorgehensmodell Scrum-Training für Fachbereichsvertreter unterschiedlicher Standorte als Vorbereitung auf Product Owner-Rolle

6 6 Wer sonst arbeitet mit Scrum? Nokia Microsoft Yahoo! Google Allianz Siemens XING O2 Vodaphone Netviewer Intel Adobe Sun Philips Xerox State Farm State Street Bank British Telecom Bose BBC IBM SAIC LMCO APL Ariba Federal Reserve Bank TransUnion IDX Die Frage also lautet eher: PayPal HP Wer arbeitet noch nicht mit Scrum? Motorola Patient Keeper Conchango BMC Lexis-Nexis CapitalOne u.v.m.

7

8 8 Scrum-Rollen die drei Manager in Scrum Product Owner verantwortlich für geschäftliche und fachliche Entscheidungen (Anforderungen und deren Priorisierung) Proxy für sämtliche Stakeholders ("one face to the team") Team verantwortlich für technische Entscheidungen (wie werden Anforderungen umgesetzt und wer macht was) selbstorganisierend, kein "Teamleiter" akzeptiert Aufgaben, bekommt sie nicht zugewiesen interdisziplinär, kann Anforderungen komplett ("end to end") umsetzen Scrum Master verantwortlich für den Scrum-Prozeß und die Einhaltung seiner Regeln Moderator, Kommunikationsförderer, Hindernisbeseitiger verantwortlich für maximale Effizienz in der Umsetzung des Projektauftrags In Scrum treffen Geschäftsleute geschäftliche, Techniker technische Entscheidungen. Jeder tut, was er am besten kann und verantwortet es auch!

9 9 Scrum-Prozeß Sprint und Time-Box Scrum ist ein iterativ-inkrementeller Prozeß, d.h. es wird in kurzen, regelmäßigen Iterationen (max. 1 Monat), sog. Sprints gearbeitet; in jedem Sprint wird ein vertikaler, voll funktionsfähiger Produktbestandteil entwickelt, getestet und ausgeliefert; das Produkt entsteht in Inkrementen, also finden auch Analyse, Design, Umsetzung, Test und Dokumentation in jedem Sprint statt, nicht z.b. eine vollständige Spezifikation zu Beginn des Projekts; Änderungen der Anforderungen und ihrer Prioritäten seitens Product Owner sind legitim und erwünscht ("embrace change"), aber niemals während eines laufenden Sprints, nur zu Beginn eines neuen. Jeder Sprint und jedes Meeting in Scrum sind "time-boxed", d.h. streng zeitlich abgegrenzt. Eine Time-Box wird niemals überzogen! Ein Termin ist ein Termin ist ein Termin.

10 10 Scrum-Grundidee: Entwickeln in Inkrementen 1. Apply: Anwenden endlich mal anfangen(!) etwas entwickeln aktiv eine Idee umsetzen überprüfbare Fakten schaffen 2. Inspect: Prüfen kritische Erfolgskontrolle Fehler in Produkt und Prozeß analysieren 3. Adapt: Anpassen Spezifikation präzisieren Prozeß verbessern ggf. alternativ vorgehen auch mal (rechtzeitig!) etwas wegwerfen Apply Adapt Inspect

11 11 Scrum-Prozeß Daily Scrum Meeting Sprint Planning Meeting 24 Std. Teil 1 Teil 2 Sprint Review Meeting Sprint Backlog Backlog Tasks (durch dasteam ausgearbeitet) Sprint (30 Tage) Product Backlog (priorisiert duch Product Owner) Potenziell auslieferbares Produkt-Inkrement Quelle: Adaption gemäß Agile Software Development with Scrum von Ken Schwaber & Mike Beedle

12 12 Scrum Aufwandschätzung und Planung Die wichtigsten Planungsartefakte in Scrum sind sog. Backlogs: Product Backlog Makrokosmos Produkt-/Releaseplanung strategisch Product Owner fachlich Anforderungs-Ebene eindeutig priorisiert nach Business Value enthält Aufwandschätzungen des Teams Sprint Backlog Mikrokosmos Sprint-Planung operativ Team technisch Task-Ebene Restaufwandschätzungen werden täglich aktualisiert Aufwände werden immer im und vom Team geschätzt, nicht von einzelnen Experten und auch nicht von Vorgesetzten. Wer die Arbeit später macht, schätzt auch den Aufwand! Weiter in der Zukunft liegende Anforderungen werden gröber und grobgranularer geschätzt, höher priorisierte (=demnächst umzusetzende) genauer und feingranularer. Das Product Backlog und damit die Spezifikation ist also ständig im Fluß, wird gepflegt, verbessert und verfeinert, denn während des Projekts lernen wir etwas über selbiges.

13 13 Scrum Tracking und Reporting Fortschritt wird in Scrum auf operativer Ebene taggenau ermittelt und graphisch im sog. Sprint Burndown Chart dargestellt. Probleme werden sofort sichtbar, man kann rechtzeitig reagieren und Gegenmaßnahmen einleiten. Auf strategischer Ebene (Gesamt- oder Teilprojekt) gibt es das sog. Product Burndown Chart (PBC), in welchem der gesamte Projektfortschritt dargestellt und über Trends prognostiziert werden kann. Im PBC werden auch die sog. Velocity (Geschwindigkeit) des Teams und ihre Schwankungen sichtbar. Die Velocity ist ein wichtiger Indikator für die Gesundheit von Team und Projekt.

14 14 Klassisches Product Burndown Chart (PBC) durchgezogene Linie für reale Restaufwände gestrichelte Trendlinie für Prognose des Fertigstellungs-Zeitpunkts

15 15 Erweitertes Product Burndown Chart (PBC)

16 16 Erweitertes Product Burndown Chart (PBC) Gesamt-Burndown (altbekannt) Bereinigter Team-Burndown Zusatzanforderungen, unterhalb der x-achse abgetragen Aus der Summe der Zusatzaufwände ergibt sich eine neue virtuelle Nullinie

17 17 Erweitertes Product Burndown Chart (PBC) Gesamt-Burndown (altbekannt) Gemessen an den Anforderungen zu Beginn des Projekts, hätten wir hier bereits fertig sein können, wenn keine Zusatzanforderungen vom Product Owner gekommen wären. Bereinigter Team-Burndown Wenn der Product Owner ab jetzt keine neuen Anforderungen mehr stellt, kann das Team zu diesem Zeitpunkt den Restaufwand abgearbeitet haben. Zusatzanforderungen, unterhalb der x-achse abgetragen Aus der Summe der Zusatzaufwände ergibt sich eine neue virtuelle Nullinie Bei gleicher Menge neuer Anforderungen pro Sprint wie bisher, sieht es aber eher nach diesem Release- Zeitpunkt aus...

18 18 Erweitertes Product Burndown Chart (PBC) Gesamt- Burndown Zusatzanforderungen Team- Burndown Übrigens gilt immer: Der verbleibende Gesamtaufwand (gelber y-wert)... Virtuelle Nullinie entspricht exakt dem jeweiligen Abstand zwischen der blauen und der roten Linie. Das ist nicht weiter erstaunlich, summieren sich doch der bereinigte Burndown und die Zusatzanforderungen gerade wieder zum Gesamtaufwand.

19 19 Scrum Zusammenfassung Scrum ist einfach wenige Rollen (3) mit klaren Verantwortlichkeiten wenige, aber klare und einzuhaltende Regeln Scrum ist lean Vermeidung von Overhead und Verschwendung write less, talk more Scrum ist flexibel (=agil) Anforderungen und Prioritäten dürfen sich ändern Planung ist wichtig, aber Reaktionsfähigkeit auf geänderte Umgebungsbedingungen ist wichtiger Scrum erzeugt Transparenz gnadenlos!

20

21 21 CCPM Vorstellung W.Müller Beratung, Training und Coaching TOC, CCPM, HSP Process Management special Projects Project Controlling IT-Security Leitung des Project Office Projekte mit 40 Projektmanagern 2010 im Team mit fünf erfahrenen TOC Experten aus unterschiedl. Branchen mit Produktions- und Projekthintergrund. Softwareentwicklung Schlund+Partner Entwicklung und Prozessentwicklung Studium Maschinenbau TH-Karlsruhe Freelancer in Softwareentwicklung Studium Mechatronik FH-Karlsruhe 1991

22 22 CCPM Testimonials Berichte auf TOC Anwenderkonferenz 2009 in Darmstadt

23 23 CCPM zwei Angriffspunkte #1 korrektes Management P1 P2 P3 der Ressourcen P1 P2 P3 Puffer #2 korrekter Umgang mit Schätzungen Puffer

24 24 CCPM Staffelung (strategische Priorisierung) P1 Prj. Prj Prj. Prj. Prj. Prj. P2 Prj. P2 P2 Prj. Prj. Prj. viele Projekte + relativ. statische Ressourcen produktionsähnliches Prj. Prj. Prj. Prj. Umfeld

25 25 CCPM Staffelung (strategische Priorisierung) optimale Produktion : 1 Einlastung muss langfristig mit Leistung des Systems im Gleichgewicht sein Work-In-Progress begrenzen 2 Durchlaufzeit ist bei FiFo optimal eindeutige Reihenfolge P1 Prj. Prj. Prj Prj. Prj. Prj. P2 Prj. P2 P2 Prj. Prj. Prj. Prj. Prj. Prj. Prj. CCPM: eindeutige Reihenfolge der Projekte neue Projekte werden immer als letztes in die Reihe gestellt es werden die Projekte anhand der Reihenfolge verplant bei Ressourcenkonflikten werden diese transparent am Engpass aufgelöst s Methode [M1]

26 26 Ausrichtung der Projekte am Engpass = strategische Priorisierung Engpasssicht P1 P2 P3 P1 Ressourcenpuffer im Engpass P2 Projektsicht P3

27 27 Störungen im Projekt alles läuft wie geplant und das ist die Realität

28 28 Handling von Unsicherheiten jede Schätzung ist falsch! je mehr Druck desto mehr Puffer wird eingerechnet Parkinson-Gesetz es wird immer die geschätzte Zeit ausgenutzt Studentensyndrom wenn man einen Puffer hat, verschiebt man den Arbeitsbeginn bis zum letzten Zeitpunkt relative Wahrscheinlichkeit max. sinnvolle Schätzung 50% abs. Wahrscheinlichkeit typ. Schätzung Murphy schlägt zu. Es kommt zu Verspätungen 0% opt. real. pes. Puffer werden immer aufgebraucht, Verfrühungen treten nicht auf, Verspätungen werden weitergegeben!

29 29 Projektplan gem. CCPM #1 in typ. Schätzungen sind 50% Puffer Arbeitspakete um 50% kürzen Puffer Puffer Projektpläne verkürzen sich um 25% #2 Verfrühungen und Verspätungen gleichen sich aus Projektpuffer um 50% kürzen

30 30 operative Prioritäten = Arbeitspaketebene 8 von 10 = 80% 1 von 4 = 25% 8 von 12 = 66% 3 von 4 = 75%

31 31 Projektcontrolling Projektgesundheit rot heißt - es stimmt was nicht bei den Supportprozessen Erledigungsgrad auf der kritischen Kette (in %) Erledigungsgrad auf der kritischen Kette (in %) % % % % % % % % % 0-10 % % % % % % % % % % 0-10 % % % % % Projektpufferverbrauch (in %) % % % % % % % Projektpufferverbrauch (in %) % % % % % % % Projekt A Projekt D Projekt C Projekt B 0 10 % 0 10 % Einzelprojekt: ein Projekt in Grün fertig machen ist gar nicht sinnvoll Portfolio: übergreifender Blick stärkt gegenseitige Hilfe zwischen den Projekten

32 32 Scrum und CCPM Scrum ungleiche Brüder Critical Chain-Projektmanagement (CCPM) P1 P2 P3 P1 Puffer P2 P3 aber gleiche Wurzeln? Puffer

33 33 viele Projekte ein Engpass das Beispielprojekt als Flussbild Engpass die Wertschöpfung erfolgt in Form von vernetzten Systemen Leistungsfähigkeit hängt von schwächsten Glied ab es gibt nur ein schwächstes Glied (Constraint) Management am Constraint ausrichten TOC [M4] oder Trichtermodell [M5]

34 34 Little s Law DLZ Bestand Wenn mehr Arbeit im System als Kapazität dann läuft die Durchlaufzeit weg Kapazität mittl. Durchlaufzeit [h] 100% Auslastung [%] min. DLZ Bestand [h/woche]

35 35 TOC - fünf Schritte der Fokussierung #1 Engpass identifizieren #2 Engpass optimal ausnutzen #3 das Management am Engpass ausrichten #4 den Engpass erweitern #5 wieder bei #1 beginnen

36 36 aber es sind zwei Engpässe! #1 Ressourcen und Skills P1 Prj. Prj Prj. Prj. Prj. Prj. P2 Prj. P2 P2 Prj. Prj. Prj. vor allem ein Engpassteam strat. Ressourcenmanagement [M3] Prj. #2 Kommunikationsund Denkbandbreite vor allem beim Projektmanagement

37 37 Baukasten für Hochleistungssysteme P1 Prj. Prj Prj. Prj. Prj. Prj. P2 Prj. P2 P2 Prj. Prj. Prj. Prj. #1 Ressourcen und Skills 7 Funktionen, die so gebaut sein müssen, dass sie den Ressourcenengpass optimal nutzen P1 Prj. Prj Prj. Prj. Prj. Prj. P2 Prj. P2 P2 Prj. Prj. Prj. Prj. #2 Kommunikationsund Denkbandbreite 6 best Practices mit Kommunikation optimal umzugehen

38 38 Die 7 Funktionen #1 WIP begrenzen nur soviel Arbeit im System wie leistbar #2 Engpass identifizieren objektiv den echten Engpass finden #3 Endtermin ermitteln nur ehrliche Termine planen #4 strategische Prioritäten festlegen Verfahren, um die richtige Reihenfolge festzulegen #5 Streuungen verarbeiten Streuungen gegen Termin puffern #6 operative Prioritäten festlegen Verfahren um die Arbeit den Ressourcen zu teilen #7 Fortschritt darstellen den Fokus auf die wirklichen Probleme lenken

39 39 Engpass Kommunikation die 6 Best Practices (das +) #1 Verhalten verbessern 3+1 Verhaltensprinzipien vereinbaren #2 Vertrauen schaffen positives Verhalten positiv rückkoppeln #3 Taktungen auflösen Arbeitsvorräte mit vielen Prozessinstanzen #4 Kapselung Arbeitspakete möglichst groß mit min. Kopplung strukturieren #5 schnelle Eskalation offene Punkte schnell weglösen #6 no Plan so wenig wie möglich planen nur das notwendigste s. High-Speed Projektmanagement [M2]

40 40 Vergleich CCPM/Scrum 7 Funktionen WIP begrenzen Engpass identfizieren Endtermin ermitteln strategische Priorität Umgang mit Streuungen operative Priorität Fortschritt darstellen eindeutige Priorität und Projektfreigabe am EP Ressourcenkonflikte systematisch auswerten klassisch mit Hilfe kritischer Kette unter Berücksichtigung der echten Kapazität und Einlastung FiFo und transparente objektive Reihenfolgenvertauschung am EP Puffer aus Arbeitspaketen in Projektpuffer, Zulieferpuffer und/oder Ressourcenpuffer Projektfortschritt auf krit. Kette gegenüber dem Pufferverbrauch Einzelprojekt: nach Business Value priorisiertes Product Backlog Multiprojekt: analog priorisiertes Project Backlog Scrum Master als Problem-/ Konfliktbeauftragter Blocks List wird systematisch abgearbeitet Retrospektiven als KVP-Instanz Iteration: Endtermin ist fix; tagaktuelles Sprint Burndown Chart zeigt Abweichungen sofort Gesamtprojekt: Messung der Velocity erlaubt realistische Endterminermittlung Schätzungen kommen immer vom Projektteam, sind daher realistisch, nicht von oben vorgegeben Product Owner darf Prioritäten im Product Backlog ändern,... ABER nur zu definierten Zeitpunkten (1x pro Sprint/Iteration) feingliedrige Anforderungen + Arbeitspakete Vielzahl sorgt für gegenseitigen Ausgleich von Über- und Unterschätzungen Velocity ist ein Durchschnittswert selbstorganisierendes Team kurze Feedback-Schleifen (Daily Scrum) Makro-Ebene (strategisch): Product Burndown Chart Mikro-Ebene (operativ): Sprint Burndown Chart, Task Board

41 41 Vergleich CCPM+/Scrum 6 Best Practices Verhalten verbessern Vertrauen schaffen Taktungen auflösen Kapselung stärken schnell eskalieren wenig planen 3 Verhaltensprinzipien sofort, direkt und Vertrag +1 keine Überraschungen schnelle Kritik und Lob, dem Vertrauenslevel angepasste Arbeitspakete jedes Teilprojekt hat sein eigenen Fluß, Synchronisation nur an Übergabepunkten nicht nach Organigramm sondern nach min. Kommunikation strukturieren offen Punkte schnell vom Projektmanager lösen nur das absolut notwendige, sauberer Auftrag, klare Verantwortlichkeiten und harte Vorgaben Commitment des Teams pro Iteration/Sprint kurze Feedbackschleifen (Daily Scrum) tägliche, direkte Zusammenarbeit mit dem Kunden Retrospektiven Scrum Master wehrt "dysfunctional behaviour" ab Das Team (kein Vorgesetzter) zeigt in kurzen, regelmäßigen Abständen das Produkt und bekommt direktes Feedback Prinzip "no surprises" für Reviews, denn der Product Owner weiß auch während des Sprints, woran das Team arbeitet sinnvolle Taktung auf Sprint-Ebene (Time-Box) alles andere ist Selbstorganisation des Teams Wo gar keine Taktung mehr möglich ist, Scrum um Kanban- Elemente erweitern Scrum-Teams sind interdisziplinär Team soll Funktionalität "end to end" als Zelle komplett selbst entwickeln können (weniger externe Abhängigkeiten) Aufgaben-, nicht Organigramm-Orientierung Scrum Master kümmert sich um jegliches Hindernis Product Owner bekommt Probleme zeitnah mit, spätestens täglich im Daily Scrum zeitlich weit Entferntes wird grob geschätzt und geplant aktueller Sprint wird feingranularer geschätzt Tagesplanung obliegt dem selbstorganisierenden Team

42 42 Vergleich CCPM/Scrum die Stärken Anwendungsgebiete Staffelung - in jeder Multiprojektumgebung = mehr Projekte als verfügbare Ressourcen Terminabsicherung in jedem Projekt mit hohem Fokus auf Termintreue vor allem in Multiprojektumgebungen unabhängig von Branchen komplexe Projekte mit unklaren oder zu Beginn noch unvollständigen Anforderungen (nahezu) dedizierte Projektteams sich ändernde Prioritäten während der Projektlaufzeit Einzel- oder Multi-Projekt-Umgebung skalierbar auf Projekte mit mehreren Teams auch außerhalb IT anwendbar anwendbar als Management Framework auf Bereichs- oder C*O-Ebene Nutzen >95% Termintreue (ehrliche Termin und sichere Einhaltung 25%-50% schnellere Durchlaufzeit (durch Reduktion WIP) mehr freie Kapazitäten (in Folge meist Verbesserung der Innovationsfähigkeit und Qualität) mehr Transparenz durch simples, aber glasklares Reporting weniger "work in progress" = weniger Investition in unfertige Produkte = geringeres Risiko = schnellere Durchlaufzeit = schnellere Amortisation, RoI > 1 früher erreicht weniger Overhead (Scrum ist "lean"!) Wichtiges wird früher fertig Investitionsschutz Projekte oft früher als geplant fertig (Kunde braucht nicht alle "goldenen Wasserhähne")

43 43 Zusammenfassung Um Höchstleistungen zu erreichen, ist das Management konsequent an Begrenzungen auszurichten. Begrenzungen im Projektgeschäft sind die Ressourcen und die Kommunikationsbandbreiten. Eine gute Projektsteuerung erfüllt idealerweise die zuvor genannten 7 Funktionen und 6 Best Practices. Scrum und CCPM+ decken die Funktionen und Best Practices in hervorragender Weise ab. Scrum spielt sein Trümpfe bei Innovationsprojekten aus, in denen dedizierte Ressourcen zum Einsatz kommen können. CCPM+ spielt seine Trümpfe in Standard-Projektumgebungen aus, wo es trotz vieler Projekte und geteilter Ressourcen auf absolute Termintreue und Durchsatz ankommt. Aber Achtung: Weder Scrum noch CCPM+ sind Entschuldigungen für schädliches Multitasking im Gegenteil! Der Wille zur Veränderung und eine gewisse Disziplin sind Voraussetzungen für beide Methoden, wenn man Ordnung ins Projekt-Chaos bringen möchte.

44 44 Mehr? Literatur [M1] Erfahrungsbericht der 1&1 Internet AG Projekt-Priorisierung in einem dynamischen und inhomogenen Projektumfeld, Projektmagazin 20/06 [M2] High-Speed-Projektmanagement bei 1&1 Teil 1: Vertrauen übertrumpft Methodik, Projektmagazin 05/08 und Teil 2: So funktioniert es in der Praxis, Projektmagazin 07/08 [M3] W.Müller Ressourcenmanagement im strategischen und operativen Multipro-jektmanagement, in Handbuch Multiprojektmanagement und -controlling, Steinle/Eßeling/Eichenberg (Herausge-ber), Schmidt Verlag 07/2008 [M4] E.Goldratt das Ziel (1990) und Critical Chain Project Management (2002) [M5] P.Nyhuis u. H.-P. Wiendahl logistische Kennlinien (2003) Literatur [1] "Agile Project Management with Scrum" von Ken Schwaber, 2004 (ISBN X) [2] "The Enterprise and Scrum" von Ken Schwaber, 2007 (ISBN ) [3] Scrum-Einführung: [4] Scrum-Glossar: [5] "Scrum and XP from the Trenches", Henrik Kniberg [6] "Scrum vs. Kanban", Henrik Kniberg oder direkt