itedas Scrum Practitioner Open Base

itedas Scrum Practitioner Open Base
Hinweis: Der Foliensatz dient lediglich zur Anregung für die Erstellung eines eigenen Foliensatzes. Alle Bilder und Icons können urheberrechtlich geschützt sein. Daher ist die Verwendung vor der Nutzung zu prüfen. itedas Scrum Practitioner Open Base Syl. 2.1

Zielsetzung Nach dem Seminar verfügen Sie über die notwendigen Kenntnisse und Fertigkeiten für das Agil Framework und das Scrum-Framework, um … die agilen Werte und Prinzipien in Ihrem Unternehmen zu vertreten und mit einzuführen. erfolgreich in Scrum-Projekten mitzuarbeiten, um im Team ein gemeinsames Ziel zu erreichen. bei persönlicher Eignung die Rollen des Scrum Master übernehmen zu können. die itedas certified Scrum Practitioner Scrum Master Zertifizierungsprüfungen bestehen zu können. itedas Scrum Practitioner Open Base Syl. 2.1

Literaturempfehlung zur Wissensvertiefung
[Schwaber, Sutherland 01] Ken Schwaber, Jeff Sutherland: Der Scrum Guide April 2017 [Pichler 01] Roman Pichler: Scrum. dpunkt.verlag 2008 [Rubin 01] Kenneth S. Rubin: Essential Scrum. mitp 2004 [Cohn 01] Mike Cohn: Succeeding with Agile. Addision-Wesley 2010 [Cohn 02] Mike Cohn: Agile Estimating and Planning. Pearson Education 2006 [Schwaber 01] Ken Schwaber: Agile Project Management with Scrum. Microsoft Press 2004, 23te Auflage 2016 [Lacey] Mitch Lacey: The Scrum Field Guide. Addision-Wesley 2012 [Pichler 02] Roman Pichler: Agile Product Management with Scrum. Addision-Wesley 2010 [Cohn 03] Mike Cohn: User Stories. mitp 2010 [Patton 01] Jeff Patton: User Story Mapping. O'Reilly 2014 [Dräther 01] Rolf Dräther: Retrospektive kurz & gut. O'Reilly 2014 [Löffler 01] Marc Löffler: Retrospektiven in der Praxis. dpunkt.verlag 2014 [Derby, Larsen 01] Esther Derby, Diana Larsen: Agile Retrospectives. The Pragamatic Programmers 2012 [Davies, Sedley 01] Rachel Davies, Liz Sedley: Agiles Coaching. mitp 2010 [Ries 01] Eric Ries: The Lean Startup. Portfolio Penguin 2011 [Schwaber, Beedle 01] Ken Schwaber, Mike Beedle: Agile Software Development with Scrum. Prentice Hall 2002 [Schwaber, Sutherland 02] Ken Schwaber, Jeff Sutherland: Software in 30 Days. John Wiley & Sons 2012 [Cohn 04] Mike Cohn: User Stories Applied. Addision-Wesley 2004 [Schwaber 02] Ken Schwaber: The Enterprise and Scrum. Microsoft Press 2014 [Adkins 01] Lyssa Adkins: Coaching Agile Teams. Addision-Wesley 2010 [Watts 01] Geoff Watts: Scrum Mastery. Inspect & Adapt 2013 [DeMarco, Lister 01] Tom DeMarco, Timothy Lister: Peopleware: Productive Projects and Teams. Addision-Wesley 2013 [Schwaber 03] Ken Schwaber: Nexus Guide August 2015 [SAFe 01] SAFe® 4.0 Introduction, A Scaled Agile, Inc. White Paper July 2016 itedas Scrum Practitioner Open Base Syl. 2.1

Zertifizierungsprüfung
Prüfungszeit: 90 Minuten (115 Minuten bei Kandidaten, deren Muttersprache nicht der Prüfungssprache entspricht) Prüfungsart: Closed-Book-&-Clean-Desk-Prüfung (Literatur und Notizen dürfen während der Prüfung nicht verwendet) werden 60 Multiple-Choice-Fragen mit bestimmten Antwortmöglichkeiten, von denen immer nur eine richtig ist Zertifikate: Scrum Foundation: 55%–74% (33–44 Punkte) Scrum Master : 75%–100% (45–60 Punkte) itedas Scrum Practitioner Open Base Syl. 2.1

Organisatorisches Tagesablauf (Tag 1+2) Vorstellung Beginn: 9:00 Uhr
Mittagspause: ca. 12:15–13:00 Uhr Erfrischungspausen: nach Bedarf Ende: 17:00 Uhr Vorstellung Name, Rolle (Scrum-)Projekterfahrungen Erwartungshaltung an das Seminar Sonstiges itedas Scrum Practitioner Open Base Syl. 2.1

Agenda Scrum: Grundlagen Scrum-Projekt: Set-up
Hintergrund und Ursprung Empirische Prozesssteuerung Agilität Scrum, das Framework Scrum-Projekt: Set-up Die Situation bei Flitz!Auto Die Wahl des Vorgehens Die Besetzung der Rollen Scrum-Projekt: Produktplanung Scrum-Planungsprinzipien Die Releaseplanung Der Product Backlog Scrum-Projekt: Sprint Die Sprint-Planung Das Daily Scrum Der Sprint-Review Die Sprint-Retrospektive Schätzung und Velocity Schätzkonzepte Schätzen des relativen Arbeitsaufwands Velocity Schätzverfahren Steuerungsaspekte Die Kommunikation Das Monitoring Die Nachfolgeplanung Scrum skalieren Vertikale/horizontale Skalierung Arbeiten in komplexen/großen Projekten Release Train Scrum einführen Grundlegendes Vorgehen Enterprise Transition Community (ETC) Reaktion auf Änderungen Agile Praktiken einführen Coaching itedas Scrum Practitioner Open Base Syl. 2.1

Scrum: Grundlagen Hintergrund und Ursprung Empirische Prozesssteuerung
Agilität Scrum, das Framework itedas Scrum Practitioner Open Base Syl. 2.1

Magisches Dreieck im Projektmanagement
Qualität Erfüllungsgrad (Anzahl und Tiefe) der Anforderungen an eine Lösung Güte der umgesetzten Anforderungen Kundenzufriedenheit Qualität Kosten Zeit Kundenzufriedenheit Grad des vom Kunden wahrgenommenen Nutzens im Vergleich zum erwarteten Nutzen der gelieferten Lösung Um den Kunden zufriedenstellen zu können, sind seiner Anforderungen hinsichtlich Qualität, Kosten und Zeit zu erfüllen. Da jedes Projekt Risiken ausgesetzt ist, muss man Fragen, wie die Risiken am besten gemangt werden können. Hierzu bedarf es in allen Projekten immer die Vereinbarung von gewissen Toleranzen bzw. Puffern. Die Buffer sind entweder offen sichtbar für den Kunden (agiler Ansatz) oder aber verdeckt, wie in allen sogenannten Festpreisprojekten. Bei letzteren kalkuliert der Anbieter einen entsprechenden Puffer ein. Toleranzen / Puffer sind notwendig, um die Projektrisiken in den Griff zu bekommen. Maximal 2 Ecken des magischen Dreiecks können fest vereinbart werden, um die Projektrisiken managen zu können. itedas Scrum Practitioner Open Base Syl. 2.1

One method fits all? Geschäftsprozesse Spezialmaschinenbau Tunnel
Autobahnen Smartphones Operationen Fahrzeuge Speisen U-Bahnen Häuser Maschinenbau Flugzeuge Software Anforderungen formuliert Projekt Nutzung Projektrisiko: Wie hoch ist die Sicherheit, dass die einmal formulierten Anforderungen am Ende des Projekts noch unverändert gültig sind? Kann ein und dasselbe Vorgehen (Projektmethode) für alle Projekte immer richtig sein? – Nein, da sich die Anforderungen während des Zeitraums der Entwicklung mehr oder weniger (im Extrem: gar nicht) stark ändern werden. Beispiel für eine langsame Änderung der Anforderungen (und daher für Wasserfall geeignet): S-Bahn-Haltestelle München Olympiastadion. Auch wenn das Olympiastadion auch heute noch in Betrieb ist, ist die zu den Olympischen Spielen 1972 gebaute Haltestelle heute eine nicht mehr genutzte Bauruine. Moderne innovative Produkte müssen zwingend agil (=adaptiv) entwickelt werden, da hier von einer starken Lernkurve (=> potentielle Anforderungsänderungen) ausgegangen werden kann. itedas Scrum Practitioner Open Base Syl. 2.1

Volatilität* der Anforderungen
* Schwankung Anforderungen ändern sich mehr oder weniger stark über die Zeit: aufgrund von Änderungen im Nutzungsumfeld aufgrund eines besseren Verständnisses der zu lösenden Aufgabe Zeit Änderung der Anforderungen adaptives (agiles) Vorgehen plangesteuertes Vorgehen (Wasserfallmodell) Entwicklungs- und Produktionszeit itedas Scrum Practitioner Open Base Syl. 2.1

Plangesteuertes Vorgehen (Wasserfall)/agiles Vorgehen
Analyse Design Programmierung früherer Teilnutzen Test Betrieb Analyse Design Programmierung Integration Test Betrieb Syl_ID_1.3 itedas Scrum Practitioner Open Base Syl. 2.1

Die richtige Methode für jede Aufgabenstellung
Mehr Informationen im Web unter dem Stichwort „Cynefin“ (sprich: ku-nev-in) Klassifizierung von Aufgaben-/Problemstellungen Komplex Hinterher weiß man alles besser Muster (Ursache-Wirkungs-Verhältnis) lassen sich durch Experimente finden Vorgehen (adaptives Vorgehen): prüfen erspüren Reagieren Beispiele Marsmission Entwicklung von Produkten in (bzw. für) sich „schnell“ ändernde(n) Umgebungen Einfach Faktenbasiertes Management klares Ursache-Wirkungs-Verhältnis Vorgehen (Anwenden von anerkannten „Best Practices“): erspüren kategorisieren reagieren Beispiele Fertighausbau Fließbandproduktion Kompliziert Experten gewähren Einblick Ursache-Wirkungs-Verhältnis lässt sich entdecken, ist aber nicht unmittelbar offensichtlich Vorgehen (Anwenden von bewährten Praktiken): erspüren analysieren (Expertendiagnose) reagieren Beispiel Suche von Fehlerursachen Chaotisch Krisenbewältigung keine Kenntnis des Ursache-/Wirkungs-Verhältnises Vorgehen handeln Erspüren, wo und inwieweit Ordnung eingetreten ist reagieren Beispiel Bankenkrise empirische Prozesssteuerung Scrum Syl_ID_1.2 itedas Scrum Practitioner Open Base Syl. 2.1

Empirische Prozesssteuerung
Adaptives Vorgehen: prüfen – erspüren – reagieren 1 2 Genauigkeit im Bereich von Zentimetern (cm) Genauigkeit im Bereich von zehntel Millimetern (mm) 3 1971 (Intel 4004): Genauigkeit im Bereich von wenigen Mikrometern (µm) 1 m 1 cm 1 Quelle: 10.September :20 Der Intel 4004 ist ein 4-Bit-Mikroprozessor des Mikrochipherstellers Intel, der am 15. November 1971 auf den Markt kam. Er gilt als der erste Ein-Chip-Mikroprozessor, der in Serie produziert und am freien Markt vertrieben wurde. Meist wird er auch als erster Mikroprozessor überhaupt bezeichnet, was aber nicht richtig ist, da bei Texas Instruments bereits 1968 ein Mikroprozessor als Auftragsarbeit entwickelt wurde, der aber nie in Serie ging. 0,1 mm 2 1 µm 3 itedas Scrum Practitioner Open Base Syl. 2.1

Wurzeln: Erste Erkenntnisse
„The New New Product Development Game“ Harvard Business Review Januar 1986 „Der … (sequentielle) ‚Staffellauf‘-Ansatz bei der Produktentwicklung … kann zu den Zielen der Maximierung von Geschwindigkeit und Flexibilität in Konflikt stehen. Im Gegensatz dazu kann ein ganzheitlicher oder ‚Rugby‘-Ansatz – mit dem ein Team als Einheit versucht, Boden gutzumachen – besser heutige Wettbewerbsanforderungen erfüllen.“ 6 Charakteristiken für einen ganzheitlichen Ansatz zur Produktentwicklung: eingebaute Instabilität => Kreativität freisetzen selbstorganisierende Teams => Arbeiten wie ein Start-up-Unternehmen, Freiheit, Dynamik, Eingehen von Risiken überlappende Entwicklungsphasen => kürzere Entwicklungszeit „multilearning” => team- und funktionsübergreifend subtile Steuerung (Steuerung ohne Druck, „jeder steuert jeden“) Transfer des Gelernten in die Organisation In dem 1986 im Harvard Business Review Magazin erschienen Beitrag beschrieben Takeuchi und Nonaka das Ergebnis einer Studie zur Erforschung von modernen Produktentwicklungsstrategien bei namhaften Unternehmen in Japan und den USA. Sie kamen zu dem Schluss, dass eine moderne Produktentwicklung einen holistischen Ansatz mit sechs Charakteristiken (siehe Folie) folgt. Zitat: “In this article, we highlight companies both in Japan and in the United States that have taken a new approach to managing the product development process. Our research examined such multinational companies as Fuji-Xerox, Canon, Honda, NEC, Epson, Brother, 3M, Xerox, and Hewlett-Packard. We then analyzed the development process of six specific products: • FX-3500 medium-sized copier (introduced by Fuji-Xerox in 1978) • PC-10 personal-use copier (Canon, 1982) • City car with 1200 cc engine (Honda, 1981) • PC 8000 personal computer (NEC, 1979 • AE-1 single-lens reflex camera (Canon, 1976) • Auto Boy, known as the Sure Shot in the United States, lens shutter camera, (Canon, 1979) We selected each product on the basis of its impact, its visibility within the company as part of a “breakthrough” development process, the novelty of the product features at the time, the market success of the product, and the access to and availability of data on each product.” Die 6 Charakteristiken finden sich heute in Scrum wieder: Eingebaute Instabilität => Kreativität freisetzen = User Story, die dem Dev-Team Raum gibt Selbstorganisierende Teams => Arbeiten wie ein Start-up Unternehmen, Freiheit, Dynamik, eingehen von Risiken Überlappende Entwicklungsphasen => Kürzere Entwicklungszeit “Multilearning” => Team- und Funktionsübergreifend Subtile Steuerung (Steuerung ohne Druck, „jeder steuert jeden“) Transfer des Gelernten in die Organisation Vieles davon findet sich heute in Scrum wieder. Syl_ID_1.1 itedas Scrum Practitioner Open Base Syl. 2.1

Der Markt fordert Agilität ein
Time2Market: Die Welt dreht sich immer schneller, und um Lösungen für Kunden oder interne Fachbereiche noch schneller bereitstellen zu können, eignen sich agile Vorgehensmodelle ausgezeichnet. MVP – Minimum Viable Product: Anforderungen ändern sich so schnell, dass ein Ausprobieren von Lösungen und Lösungsansätzen unumgänglich scheint. Anforderungen, die heute plausibel erscheinen, können einerseits morgen schon nicht mehr gefragt sein, und andererseits können Auffassungsunterschiede zwischen den handelnden Personen niemals ausgeschlossen werden. Apple iPhone 2007 iPhone 1 2008 iPhone 3G 2009 iPhone 3GS 2010 iPhone 4 2011 iPhone 4s 2012 iPhone 5 2013 iPhone 5s 2013 iPhone 5c itedas Scrum Practitioner Open Base Syl. 2.1

Empirische Prozesssteuerung
Scrum basiert auf der empirischen Prozesssteuerung. Dabei wird das Wissen aus Erfahrung gewonnen und werden Entscheidungen auf Basis des Bekannten getroffen. Scrum nutzt einen iterativen, inkrementellen Ansatz, um Prognosesicherheit zu optimieren und Risiken zu kontrollieren. Empirische Prozesssteuerung Transparenz (Transparency) Überprüfung (Inspection) Anpassung (Adaptation) Zur klassischen Prozesssteuerung ist es notwendig, dass der Input im Prozess so gezielt verarbeitet werden kann, dass ein gewünschtes Ergebnis wiederholbar (= eindeutiges Ursache-/Wirkungsverhältnis) erzeugt werden kann. In sich schnell ändernden oder komplexen Umgebungen kann es unmöglich oder zumindest sehr aufwendig sein ein eindeutiges Ursache-/Wirkungsverhältnis zu ermitteln, oder aber den Prozess immer wieder neu abzustimmen, um eine eindeutige Prozesssteuerung er etablieren zu können. In diesen Fällen hat die empirische Prozesssteuerung ihre Vorteil. Die empirischen Prozesssteuerung setzt auf Überprüfung und Anpassung (wozu eine ausreichende Transparenz notwendig ist) damit der Prozess nicht nur die Verarbeitung des Inputs sondern auch sich selber steuern kann. Syl_ID_1.2 itedas Scrum Practitioner Open Base Syl. 2.1

Empirische Prozesssteuerung und Scrum
Transparenz Diese sorgt dafür, dass die wesentlichen Aspekte des Arbeitsprozesses nach einem gemeinsamen Standard definiert werden, damit die Stakeholder ein gemeinsames Verständnis des Gesehenen teilen. Überprüfung Die Scrum-Artefakte und der Fortschritt müssen regelmäßig auf die Erreichung des Sprint-Ziels überprüft werden. Anpassung Anpassungen (Arbeitsablauf, Entscheidungen etc.) sind so schnell wie möglich vorzunehmen, damit weitere Abweichungen minimiert werden können. Für Überprüfung und Anpassung schreibt Scrum vier formale Ereignisse vor: Sprint-Planung Daily Scrum Sprint-Review Sprint-Retrospektive Syl_ID_1.2 itedas Scrum Practitioner Open Base Syl. 2.1

Scrum: Werte – Basis für Vertrauen
Empirische Prozesssteuerung Scrum-Werte Mut, das Richtige zu tun Fokussierung auf die Arbeit im Sprint Offenheit im Umgang mit allen Belangen der Arbeit Respekt im Umgang miteinander Selbstverpflichtung, die Ziele des Scrum-Teams zu erreichen V E R T A U N Transparenz (Transparency) Überprüfung (Inspection) Anpassung (Adaptation) Wenn die Werte Selbstverpflichtung, Mut, Fokus, Offenheit und Respekt durch das Scrum-Team verkörpert und gelebt werden, werden die Scrum‐Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen bei allen Beteiligten Vertrauen zueinander auf. Die Mitglieder des Scrum-Teams lernen und erforschen diese Werte, indem sie mit den Scrum Ereignissen, Rollen und Artefakten arbeiten. Der erfolgreiche Einsatz von Scrum beruht darauf, dass alle Beteiligten kompetenter bei der Erfüllung dieser fünf Werte werden. Sie verpflichten sich persönlich dazu, die Ziele des Scrum-Teams zu erreichen. Die Mitglieder des Scrum-Teams haben den Mut, das Richtige zu tun und an schwierigen Problemen zu arbeiten. Jeder fokussiert sich auf die Arbeit im Sprint und die Ziele des Scrum-Teams. Das Scrum-Team und seine Stakeholder sind sich einig, offen mit allen Belangen ihrer Arbeit und den damit verbundenen Herausforderungen umzugehen. Mitglieder von Scrum-Teams respektieren sich gegenseitig als fähige, eigenverantwortliche Individuen. Syl_ID_1.6 itedas Scrum Practitioner Open Base Syl. 2.1

Manifest für agile Softwareentwicklung
Wir erschließen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch unsere Tätigkeit haben wir diese Werte schätzen gelernt: Individuen und Interaktionen sind wichtiger als Prozesse und Tools. Funktionierende Software ist wichtiger als umfangreiche Dokumentation. Kooperation mit Projektbetroffenen ist wichtiger als Vertragsverhandlungen. Reaktion auf Änderungen ist wichtiger als Verfolgung eines festgelegten Plans. Das heißt, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein. Syl_ID_1.4 itedas Scrum Practitioner Open Base Syl. 2.1

12 Prinzipien hinter dem agilen Manifest (1/2)
Unsere höchste Priorität ist es, Kunden durch die frühzeitige und kontinuierliche Bereitstellung von nutzenbringender Software zufriedenzustellen. Wichtige Anforderungsänderungen sind, auch bei fortgeschrittener Entwicklung, willkommen. Agile Prozesse nutzen Änderungen zum Wettbewerbsvorteil des Kunden. Wir liefern funktionierende Software bevorzugt in kürzeren Zeitspannen, regelmäßig innerhalb weniger Wochen oder Monate. Während des Projekts müssen Fachexperten und Entwickler täglich zusammenarbeiten. Errichte Projekte rund um motivierte Individuen. Gib ihnen das Umfeld und die Unterstützung, die sie benötigen, und vertraue darauf, dass sie die Aufgabe erledigen. Die effizienteste und effektivste Methode, Informationen an ein und innerhalb eines Entwicklungsteams zu übermitteln, ist das Gespräch von Angesicht zu Angesicht. Quelle: übersetzt durch iXventiv Syl_ID_1.4 itedas Scrum Practitioner Open Base Syl. 2.1

12 Prinzipien hinter dem agilen Manifest (2/2)
Das wichtigste Fortschrittmaß ist Funktionierende Software. Auftraggeber, Entwickler und Benutzer sollten durchgehend ein gleichmäßiges Tempo halten. Agile Prozesse fördern nachhaltige Entwicklung. Ständiges Augenmerk auf hervorragende technische Fähigkeiten und gutes Design fördert Agilität. Einfachheit & Schlichtheit – die Kunst, das maximal Mögliche NICHT zu tun – ist unabdingbar. Die besten Architekturen, Anforderungen und Designs entstehen durch selbstorganisierte Teams. In regelmäßigen Abständen reflektiert das Team, wie es effektiver werden kann, und passt sein Verhalten entsprechend an. Quelle: übersetzt durch iXventiv Syl_ID_1.4 itedas Scrum Practitioner Open Base Syl. 2.1

Was eine Entwicklung agil macht
Jede Iteration liefert funktionstüchtige Software (siebtes Prinzip des agilen Manifests). Schneller Businessnutzen. In jeder Iteration findet jede Phase nahezu gleichzeitig statt. Fehlentwicklungen lassen sich schnell feststellen und korrigieren. Das Team nutzt spezifische Entwicklungsmethoden, die es erlauben, die Codebasis aktuell und flexibel zu halten. Auch kurzfristige Änderungen können noch berücksichtigt werden. Teams agieren selbstorganisiert. Weniger Overhead und Bürokratie; schnelle Entscheidungen. Anwendung von Lean-Prinzipien und -Techniken. Eliminierung von Verschwendung und Konzentration der Ressourcen auf das eigentliche Ziel  Effizienzsteigerung. itedas Scrum Practitioner Open Base Syl. 2.1

„Agile“ geht nur auf der Basis von „Lean“
Empower your Team! Sieh das Ganze! Entscheide verantwortungsvoll! Eliminiere Verschwendung! Liefere schnell! Baue Integrität ein! Stärke das Lernen! Quelle: M & T Poppendieck, Lean Software Development : Eleminiere Verschwenung (Eliminate Waste): Eliminate… …Anything that doesn’t add value (as perceived by the customer) to the product …Unnecessary code or functionality …Unclear requirements …Slow internal communications or processes …Bureaucracy Stärke das Lernen (Amplify Learning): Realization of purpose of use rather than conforming to requirements Not intended to produce repeatable results, but to create solutions to unique customer problems Design is done best using discovery solutions: short, repeated cycles of investigation, experimentation and checking results We like to Try it, Test it, and Fix it! Knowledge generation (or feedback) loops are critical Verantwortungsvolle Entscheidungen (Responsible Decisions): Decide as late as possible to be open to latest requirements. Schnelle Lieferung (Fast Delivery): Customers like rapid delivery. Look at how UPS and FedEx … Rapid delivery means less time for customers to change their minds Empower Team A mature organization looks at the whole system; it doesn’t only focus on optimizing disparate or separate parts. A mature organization focuses on learning effectively and empowers the people who do the work to make decisions. Bauer Integrität ein (Build Integrity in): Perceived Integrity: is affected by the customer’s whole experience of a system Conceptual Integrity: means that system’s central concepts work together as a smooth cohesive whole Sehe das Ganze (See the Whole): Systems Thinking & System Dynamics Grundpfeiler für eine schlanke Organisation Quelle: Jeff Sutherland, The Roots of Scrum 2010 (Übersetzung iXventiv) itedas Scrum Practitioner Open Base Syl. 2.1

ist eine geistige Haltung (Mindset) beschrieben durch 12 Prinzipien
„Agile“ ist eine geistige Haltung (Mindset) basiert auf 4 Werten beschrieben durch 12 Prinzipien itedas Scrum Practitioner Open Base Syl. 2.1

Definition: Scrum Ein Rahmenwerk (Framework), innerhalb dessen …
… Menschen komplexe adaptive Aufgabenstellungen angehen können … … und durch das sie in die Lage versetzt werden, … … produktiv und kreativ Produkte mit dem höchstmöglichen Wert ausliefern zu können. Syl_ID_1.5 itedas Scrum Practitioner Open Base Syl. 2.1

Scrum, das Framework (Rahmenwerk)
ist ein Rahmenwerk zur Entwicklung und Erhaltung komplexer Produkte, innerhalb dessen verschiedene Prozesse und Techniken genutzt werden können. ist leichtgewichtig, einfach zu verstehen, schwierig zu meistern. besteht aus Rollen, Ereignissen, Artefakten und Regeln, die die einzelnen Elemente miteinander verbinden. Rollen: Das Scrum-Team Ereignisse (Time Box) Sprint (max. 4 Wochen) Sprint-Planung (max. 1* Tag = max. 8* Stunden), Daily Scrum (max. 15 Minuten) Sprint-Review (max. 4* Stunden) Sprint-Retrospektive (max. 3* Stunden) Artefakte Product Backlog Sprint Backlog Inkrement Definition of Done Product Owner Entwicklungsteam Scrum Master * Die Zeitangaben reduzieren sich bei kürzeren Sprints. Auf die Regeln wird im Rahmen der Rollen, Ereignisse und Artefakte eingegangen. Syl_ID_1.5 / Syl_ID_3.4 itedas Scrum Practitioner Open Base Syl. 2.1

Scrum: Ereignisse im Sprint-Ablauf
Daily Scrum Planung Review Sprint Backlog Inkrement Retrospektive Product Backlog Ein Inkrement ist erst dann fertig und potenziell auslieferungsfähig, wenn es der Definition of Done entspricht! Planung Entwicklung Review Retrospektive maximal 4 Wochen Syl_ID_1.5 / Syl_ID_3.4 itedas Scrum Practitioner Open Base Syl. 2.1

Vorteile von Scrum Organisationen, die sich auf Scrum einlassen, …
profitieren von der Lernkurve aller Stakeholder und … begeistern ihre Kunden regelmäßig, indem sie ihnen das liefern, was sie wollen, und nicht „nur“ das, was einmal am ersten Tag festgelegt wurde. Weitere Vorteile: verbesserte Rendite durch häufigere kleinere Releases reduzierte Kosten durch Verbesserung schlechter organisatorischer Abläufe schneller Nutzen durch einsatzfähige Inkremente Vertrauen, in einer komplexen Welt erfolgreich zu sein Freude bei der Arbeit durch enge Zusammenarbeit, was zu verbesserten zwischenmenschlichen Beziehungen und größerem gegenseitigen Vertrauen führt Syl_ID_1.1 itedas Scrum Practitioner Open Base Syl. 2.1

6 agile Prinzipien (Überzeugungen), auf denen Scrum basiert
Die Zukunft bringt neue Erkenntnisse 1 Vorhersage und Anpassung 2 Validierendes Lernen 3 Work in Progress (WIP) 4 Fortschritt 5 Leistung 6 Syl_ID_1.3 itedas Scrum Practitioner Open Base Syl. 2.1

1. Die Zukunft bringt neue Erkenntnisse
Scrum nutzt die Veränderlichkeit (Lernkurve) und Unsicherheit (Neuland) in der Produktentwicklung aus, um innovative Lösungen zu schaffen, indem … man sich der Lösung in kleinen Einheiten (Inkrementen) nähert (Iteration). durch die empirische Prozesssteuerung (Überprüfung, Anpassung und Transparenz) auf Veränderlichkeiten reagiert werden kann. hilfreiche Änderungen bereitwillig angenommen werden. alle Formen der Unsicherheit bei der Produktentwicklung gleichzeitig reduziert werden. Unsicherheiten in der Produktentwicklung: End-Unsicherheit (Was-Unsicherheit) Methoden-Unsicherheit (Wie-Unsicherheit) Kunden-Unsicherheit (Wer-Unsicherheit) End-Unsicherheit (Was-Unsicherheit): Was soll genau entwickelt werden? Methoden-Unsicherheit (Wie-Unsicherheit): Wie (mit welcher Methode/nach welchem Konzept) soll entwickelt werden? „One-size-fits-all“-Problem; bei Wasserfall zu wenig Flexibilität durch zu frühe Festlegung. Kunden-Unsicherheit (Wer-Unsicherheit): Für welche Zielgruppe/Anwendungsfälle soll entwickelt werden? Syl_ID_1.3 itedas Scrum Practitioner Open Base Syl. 2.1

2. Vorhersage und Anpassung
Insbesondere schwerwiegende Entscheidungen sollten erst dann getroffen werden, wenn eine ausreichende Wissensbasis vorhanden ist. Oder wenn sie nicht mehr länger hinausgezögert werden können. Bei Scrum wird ständig der Wunsch nach Vorhersage gegen die Notwendigkeit der Anpassung abgewogen, indem … sich Optionen offengehalten werden. ein adaptiver, untersuchender Ansatz bevorzugt wird und abgewogen wird, wann und wo ein adaptives bzw. ein prädiktives Vorgehen besser geeignet ist. Dazu ist es notwendig, dass … alle wissen, dass wir über das gesamte Projekt hinzulernen werden und daher wissen, dass nicht alles gleich beim ersten Mal richtig gemacht werden kann. Änderungen auf eine ökonomisch sinnvolle Weise angenommen werden. Während der Entwicklung innovativer Produkte ist es notwendig, über Prototypen (o. Ä.) Ideen zu verifizieren oder zu falsifizieren, um zu neuem (validen) Wissen zu gelangen. Raten Chaos prädiktiv Festlegungen adaptiv Zu frühes Festlegen (= Festlegen ohne alle Fakten zu kennen) führt zu raten und zu Festlegungen, die mit den „wirklichen“ Anforderungen (die erst zu einem späteren Zeitpunkt über einen beschrittenen Lernweg erkannt werden) nicht zwingend übereinstimmen. Zu spätes Festlegen von bekannten Anforderungen führt zu dem nachträglichen Anpassen von Lösungen an „längst“ schon bekannte Anforderungen. Dies treibt die Kosten in die Höhe, verursacht Missstimmung bei allen Stakeholdern und führt zu einer negativen Wahrnehmung des Entwicklungsteams und des Produktes. Weitere Informationen zum Thema „Vorhersage und Anpassung“ findet sich auch unter dem, von Poppendieck 2003 geprägten, Begriff „Last Responsible Moment“. Änderungen sind normal. Mit Scrum wird versucht, die Kostenkurve für Änderungen so lange wie möglich flach zu halten, damit Änderungen möglichst lange kostengünstig implementiert werden können. Syl_ID_1.3 itedas Scrum Practitioner Open Base Syl. 2.1

3. Validierendes Lernen Validierendes Lernen bedeutet das Erwerben von Wissen, welches eine von uns getroffene Annahme (Hypothese) bestätigt (verifiziert) oder widerlegt (falsifiziert). Hierzu ist folgendes Vorgehen notwendig: insbesondere wichtige Annahmen schnell validieren Nutzung von Lernschleifen zur Unterstützung eines ständigen Lernprozesses Organisation des Arbeitsablaufs für schnelle Feedbacks Hypothese Wissensstand Test Syl_ID_1.3 itedas Scrum Practitioner Open Base Syl. 2.1

Lernkurve Risiko Wissen Iterationsschritte Samuel Beckett (1906–1989)
itedas Scrum Practitioner Open Base Syl. 2.1

4. WIP: Work in Progress (Arbeitspakete in Bearbeitung)
Um u. a. einen schnellen Nutzen liefern (und damit auch ein schnelles Feedback erhalten) zu können, ist es sinnvoll, die Anzahl (Batchgröße) der in Bearbeitung befindlichen Arbeitspakete zu limitieren. Wahl einer vernünftigen Batchgröße Lagerbestände (= nicht ausgelieferte Inkremente) erkennen und sinnvoll verwalten Konzentration auf unerledigte Arbeit und nicht auf „untätige“ Personen Kosten und Nachteile betrachten, die durch zu spät ausgelieferte Arbeitspakete entstehen (können) Vorteile von richtig gewählten Batchgrößen: reduzierte Zykluszeit: wir werden schneller konstantere Arbeitsgeschwindigkeit schnelleres Feedback reduziertes Risiko reduzierter Overhead, da weniger Aktivitäten gemanagt werden müssen erhöhte Motivation und Verantwortung des Einzelnen Syl_ID_1.3 itedas Scrum Practitioner Open Base Syl. 2.1

Viel Arbeit anfangen oder viel Arbeit fertig bekommen?
Die Situation: 40 Arbeitspakete à 8 h Arbeit stehen zur Bearbeitung an. Alle Arbeitspakete haben die gleiche Dringlichkeit (= gleicher Fertigstellungstermin). 10 Arbeitspakete haben eine hohe Priorität (= 1). Alles anderen Arbeitspakete besitzen eine Priorität von 2 oder 3. Zur Umsetzung der Arbeitspakete stehen pro Tag durchschnittlich 4 Nettoarbeitsstunden zur Verfügung. Alle Arbeitspakete der Priorität 1 werden begonnen und bearbeitet. Lösungsansatz 1: Nach 10 Tagen sind alle 10 Arbeitspakte zur Hälfte fertig. Der Kunde hat keinen Nutzen. Lösungsansatz 2: Es werden nur 5 Arbeitspakete der Priorität 1 begonnen und bearbeitet. Nach 10 Tagen sind 5 Arbeitspakete fertig. Der Kunde hat einen Nutzen. Mit der richtigen Wahl eines Bearbeitungslimits (Work-in-Progress-Limit) erhält der Kunde das mögliche Maximum an Nutzen. itedas Scrum Practitioner Open Base Syl. 2.1

5. Fortschritt Fortschritt wird gemessen an dem, was wirklich fertig und validiert (DoD) ist. Nicht an dem, was in einem vordefinierten (Phasen-)Plan steht. Um auf aktuelle Situationen angemessen reagieren zu können, erfolgt die Planung kontinuierlich auf Basis von Echtzeitinformationen über den gesamten Entwicklungszeitraum. Fortschrittsmessung auf Basis validierter Inkremente Konzentration auf eine wertzentrierte Auslieferung der Inkremente Zeit gelieferter Wert/Nutzen Scrum-Projekt Wasserfall-Projekt Syl_ID_1.3 itedas Scrum Practitioner Open Base Syl. 2.1

„Nicht ausbrennen du sollst!“
6. Leistung Gehe schnell, aber hetze nicht. Baue Qualität ein. Mach alles ohne großes Zeremoniell. Quelle: licensed under the Creative Commons Attribution-Share Alike License 3.0 (Unported) (CC-BY-SA) „Nicht ausbrennen du sollst!“ Auf Meister Yoda Du hören solltest. Baue Qualität ein: Qualität beginnt mit dem ersten Schritt und nicht erst beim Test. Also versuch es gleich richtig zu machen. Mach alles ohne großen Zeremoniell: Sprich lieber mit Deinem Nachbar, als das Du Aktennotizen o.ä. anlegst. Agilität und Scrum basieren u.a. auf einer effizienten Kommunikation von Mensch zu Mensch! „Qualität, die gute Seite der Macht.“ „Formalitäten Dich bremsen oft.“ Syl_ID_1.3 / Syl_ID_9.1 itedas Scrum Practitioner Open Base Syl. 2.1

Zusammenfassung: Scrum-Grundlagen
Hintergrund plangesteuertes Vorgehen (Wasserfall)/agiles Vorgehen Wurzeln: erste Erkenntnisse der Markt fordert Agilität ein empirische Prozesssteuerung Manifest für agile Softwareentwicklung Scrum-Überblick: Framework, Rollen, Ereignisse und Artefakte 6 agile Prinzipien (Überzeugungen), auf denen Scrum basiert: Veränderlichkeit und Unsicherheit Vorhersage und Anpassung validiertes Wissen (Lernen) WIP: Work in Progress Fortschritt Leistung itedas Scrum Practitioner Open Base Syl. 2.1

Scrum-Projekt: Set-up
Die Situation bei Flitz!Auto Die Wahl des Vorgehens Die Besetzung der Rollen itedas Scrum Practitioner Open Base Syl. 2.1

Scrum: Die Stakeholder-Familie
Manager weitere Stakeholder Scrum Master Entwicklungsteam Business Product Owner Die Rolle „Manager“ übernimmt die Funktion des Ressourcenmanagers und dient zur Bereitstellung aller notwendiger Ressourcen (Personal, Räume, Infrastruktur etc.) Die Rolle „weitere Stakeholder“ dient als Hinweis, dass es neben dem Business auch Kunden (=> €) und Anwender (= Nutzer der Lösung) o.ä. sein können. itedas Scrum Practitioner Open Base Syl. 2.1

Das Scrum-Team: verschiedene Rollen, ein Ziel!
Product Owner Entwicklungsteam Scrum Master Scrum-Teams sind … selbstorganisierend und interdisziplinär. entscheiden selbst, wie sie ihre Arbeit am besten erledigen. verfügen über alle Kompetenzen, die erforderlich sind, um die Arbeit zu erledigen. sind in der Lage, Flexibilität, Kreativität und Produktivität zu optimieren. liefern Produkte iterativ und inkrementell und maximieren somit die Gelegenheit für Feedback. Syl_ID_4 itedas Scrum Practitioner Open Base Syl. 2.1

Scrum-Teams liefern Qualität
Scrum-Teams stellen die gewünschte Qualität von Anfang an sicher. Für Scrum-Teams ist Testen eine zentrale Komponente innerhalb des Entwicklungsprozesses (und nicht etwas, was nach der Entwicklung („done“) mal passiert). Merkmale für „eingebaute“ Qualität (Qualität von Anfang an): Einsatz von qualitätsfördernden Entwicklungstechniken wie Pair Programming oder eingehendem Code Review/eingehender Inspection nahtlose Zusammenarbeit zwischen den Personen, die programmieren, und denen, die testen am ersten Tag eines Sprints finden „gleich viele“ Tests statt wie am letzten Tag Syl_ID_9.1 itedas Scrum Practitioner Open Base Syl. 2.1

Der Product Owner Ist verantwortlich für …
den wirtschaftlichen Erfolg und Wertmaximierung des Produktes. die wertschöpfende Arbeit ( Product Backlog) des Entwicklungsteams. ist ergebnisverantwortlich (accountable) für den Product Backlog. ist eine einzelne Person, kein Komitee. kann nur erfolgreich sein, wenn seine Entscheidungen in der Organisation respektiert werden. Die Entscheidungen des Product Owner sind in Inhalt und Reihenfolge des Product Backlog sichtbar. Syl_ID_4.2 itedas Scrum Practitioner Open Base Syl. 2.1

Universum des Product Owner
Stakeholder Businesskompetenz: repräsentiert alle Stakeholder vermittelt die Produktvision strategisches Alignment (Business/Entwicklung) Priorisierung der Investitionen verantwortlich für ROI Business Technik Soziales Entwicklungsteam Scrum Master Technische Kompetenz: Requirements Management Management des priorisierten Product Backlog Planung und Releasemanagement Akzeptieren oder Zurückweisen von Arbeitsergebnissen (Sprint Results) Überwachen des Fortschritts Durchführen von Reviews Universum des Product Owner Der PO muss sich stets in zwei Richtungen (Business&Stakeholder sowie Entwicklungsteam&ScrumMaster) orientieren. Sozialkompetenz: Motivierung des Teams Ansprechbarkeit trägt Sorge dafür, dass Entscheidungen auf einer möglichst geringen Hierarchieebene getroffen werden können Auflösung von Zweifeln im Team bezüglich des Projekts Syl_ID_4.2 itedas Scrum Practitioner Open Base Syl. 2.1

Hauptaufgaben des Product Owner
Organisation der wirtschaftlichen Belange Teilnahme an der Planung Pflege des Product Backlog Definition von Akzeptanzkriterien und Verifikation von deren Einhaltung Zusammenarbeit mit … dem Entwicklungsteam den Stakeholdern Syl_ID_4.2 itedas Scrum Practitioner Open Base Syl. 2.1

Architekturen designen Dokumentation erstellen User Interface designen
Das Entwicklungsteam … ist in der Lage, alle Tätigkeitsarten umzusetzen, die zur Erstellung eines Inkrements notwendig sind. Code programmieren Datenbanken designen Code testen Architekturen designen Dokumentation erstellen User Interface designen Server managen Syl_ID_4.1 itedas Scrum Practitioner Open Base Syl. 2.1

Das Entwicklungsteam Entwicklungsteam besteht aus Profis, die am Ende eines jeden Sprints … ein fertiges Inkrement übergeben, welches … potenziell auslieferbar ist. ist so strukturiert und befähigt, dass es seine eigene Arbeit selbst organisieren und managen kann. Die daraus resultierende Synergie optimiert die Gesamteffizienz und -effektivität des Entwicklungsteams. ist immer als Ganzes rechenschaftspflichtig. kennt keine dedizierten Titel wie Architekt, Tester etc.: „No ranks, no titles“. ist klein genug, um flink zu bleiben, und groß genug, um die Arbeit innerhalb eines Sprints erledigen zu können. besteht aus 3–9 Mitgliedern. Sollten Product Owner und Scrum Master auch Arbeiten aus dem Sprint Backlog erledigen, zählen sie zum Entwicklungsteam. Große Entwicklungsteams erzeugen eine zu hohe Komplexität, um durch einen empirischen Prozess gemanagt werden zu können. ! Syl_ID_4.1 itedas Scrum Practitioner Open Base Syl. 2.1

Die wichtigsten Aufgaben des Entwicklungsteams
Sprint durchführen Teilnahme am Daily Scrum (tägliches Untersuchen und Anpassen) Pflege des Product Backlog (verfeinern, schätzen, ggf. anlegen und priorisieren) Sprint planen Produkt (Sprint-Review) und Prozess (Retrospektive) untersuchen und anpassen Syl_ID_4.1 itedas Scrum Practitioner Open Base Syl. 2.1

Die wichtigsten Eigenschaften des Entwicklungsteams
selbstorganisierend funktionsübergreifend vielseitig T-förmige Fertigkeiten richtige Größe fokussiert und verpflichtet Musketier-Einstellung transparente Kommunikation breitbandige Kommunikation nachhaltiges Arbeitstempo langlebig, sodass aus einer Gruppe ein echtes Team entstehen kann -shaped Skills B R E I T T I E F „Einer für alle, alle für einen.“ im Team fachübergreifend mit Scrum Master mit Product Owner Häufigkeit „osmotische“ Kommunikation nutzen schnell und effizient Offenheit Syl_ID_4.1 itedas Scrum Practitioner Open Base Syl. 2.1

Entwicklungsteam: Mission
Organisiere dich selbst! Estimate, estimate, estimate! (Schätze!) Gewährleiste Qualität! Liefere, liefere, liefere! Setz dich ein! Commit! (Fühle dich verpflichtet!) Syl_ID_9.1 itedas Scrum Practitioner Open Base Syl. 2.1

Der Scrum Master Scrum Master ist für das Verständnis und die Durchführung von Scrum verantwortlich. tut dies, indem er dafür sorgt, dass das Scrum-Team die … Theorie, Praktiken und Regeln von Scrum einhält. hilft dabei, die Zusammenarbeit so zu optimieren, dass der durch das Scrum-Team generierte Wert maximal wird. ist ein Servant Leader (dienende Führungskraft) für das Scrum-Team. Syl_ID_4.3 itedas Scrum Practitioner Open Base Syl. 2.1

Scrum Master: Servant Leader für
… das Entwicklungsteam Coaching und Unterstützung … bei der täglichen Arbeit. bei der Einführung von Scrum Beseitigen von Hindernissen Unterstützen bei der Durchführung von Scrum- Ereignissen … den Product Owner Vermitteln von Techniken für eine effektive Verwaltung des Product Backlog Schaffen eines Verständnisses für Produktplanung in einem empirischen Arbeitsumfeld Vermitteln des richtigen Verständnisses von Agilität und ihrer Anwendung Unterstützen bei der Durchführung von Scrum- Ereignissen … die Organisation Leiten und Coachen bei der Einführung von Scrum Planen von Scrum-Implementierungen Unterstützen der Stakeholder beim Verstehen von Scrum Syl_ID_4.3 itedas Scrum Practitioner Open Base Syl. 2.1

Die wichtigsten Aufgaben des Scrum Master
Coach für Entwicklungsteam und Product Owner Servant Leader (dienende Führungskraft) Prozessautorität (Scrum-Werte, -Prinzipien und -Praktiken) schützt das Entwicklungsteam vor störenden Einflüssen Beseitigung von Hindernissen, sofern das Entwicklungsteam nicht selbst dazu in der Lage ist Berater in der Organisationsentwicklung für das Scrum-Team und Stakeholder (sorgt für den Erfolg von Scrum in der Organisation) Syl_ID_4.3 itedas Scrum Practitioner Open Base Syl. 2.1

Die wichtigsten Eigenschaften des Scrum Master
sachkundig neugierig geduldig teamfähig Sachkundig Expertenwissen: Scrum Gutes Grundverständnis: Technik: Technologien, Problemlösung etc. Business: Produktplanung, Wirtschaftlichkeit etc. Neugierig Interessiert an dem was Vorgeht Gespräche initiieren, um die Gesprächspartner zum Denken anzuregen Fragen erörtern, aber versuchen, dass die Experten selbst zu einer Lösung kommen Schützend Steht schützend vor dem Scrum-Team („Hütehund“, „Bodyguard“) Transparent Er gestaltet seine Kommunikation transparent und wirkt auf das Team ein, es ihm gleich zu tun. Geduldig Das Team (die Experten) muss selbst zu einer Lösung kommen; der Scrum Master sollte keine Lösung vorgeben. schützend transparent Syl_ID_4.3 itedas Scrum Practitioner Open Base Syl. 2.1

Wo ist der Projektmanager?
Das Scrum-Team: verschiedene Rollen, ein Ziel! Product Owner Entwicklungsteam Scrum Master Die Rolle des klassischen Projektmanagers teilen sich die einzelnen Rollen des Scrum-Teams itedas Scrum Practitioner Open Base Syl. 2.1

Zusammenfassung: Set-up
Flitz!Auto: Das Unternehmen Scrum: Die Stakeholder-Familie Das Scrum-Team Product Owner Entwicklungsteam Scrum Master Rollenverteilung in der Fallstudie itedas Scrum Practitioner Open Base Syl. 2.1

Scrum-Projekt: Produktplanung
Scrum-Planungsprinzipien Der Product Backlog Die Priorisierung Die Releaseplanung itedas Scrum Practitioner Open Base Syl. 2.1

Scrum-Planungsprinzipien
Pläne können nicht im Voraus richtig sein. Vorabplanung sollte hilfreich, aber nicht exzessiv sein. Planungsbestand richtig organisieren Planungsoptionen so lange wie möglich/nötig offenhalten schnelles Lernen und Abweichen vom Plan, wenn nötig Pläne können nicht im Voraus richtig sein: Statt alles am Anfang zu planen (-> Unsicherheiten, die Zukunft kann andere Fakten/Anforderungen/Erkenntnisse bringen), folgt Scrum seinen empirischen Wurzeln, die in den Prinzipien von Untersuchung (Inspection) und Anpassung (Adaptation) liegen. Vorabplanung sollte hilfreich, aber nicht exzessiv sein: Es reicht, wenn die wesentlichen Eckpunkte zu Beginn feststehen (=>Inspect&Adapt). Die Kunst liegt darin, die richtige Balance zwischen den im Vorfeld getroffenen Vorhersagen (Entscheidungen) und den Just-in-Time-Anpassungen zu finden. Planungsbestand richtig organisieren: Zuviel Planung im Voraus birgt in adaptiven Projekten die große Gefahr von Fehlentscheidungen, die später wieder korrigiert werden müssen. Planungsoptionen so lange wie möglich/nötig offen halten: Entscheidungen sollten am besten dann getroffen werden, wenn alle Informationen bekannt sind und damit das Risiko für eine Fehlentscheidung am geringsten ist. Schnelles Lernen und Abweichen vom Plan, wenn nötig: Vorab geplantes muss an neue Erkenntnisse angepasst werden. Konzentration auf Anpassen statt auf Befolgen eines (festen) Plans: „Planung ersetzt Zufall durch Irrtum“ – Irrtümer sollten so schnelle und so nachhaltig wie möglich korrigiert werden. Häufigere kleinere Releases reduzieren das Risiko: Kleine Releases benötigen weniger Entwicklungszeit und –ressourcen und tragen schneller zu einem positiven Cashflow bei. Außerdem ermöglichen sie ein schnelleres Feedback vom Kunden und erlauben ein schnelles Reagieren, auf Fehlentwicklungen und/oder Anforderungsänderungen. Konzentration auf Anpassen statt auf Befolgen eines Plans Häufigere kleinere Releases reduzieren das Risiko. Syl_ID_5.1 itedas Scrum Practitioner Open Base Syl. 2.1

Vorteil von kleineren und häufigeren Releases
Zeit Erlöse Investitionen geringere Investitionen + früherer ROI + schnelleres Feedback = geringeres Risiko Gewinnphase Legende Investitionen Erlöse Syl_ID_5.1 itedas Scrum Practitioner Open Base Syl. 2.1

Planung auf mehreren Ebenen (Planning Onion)
Strategie Unternehmen Portfolio Stakeholder und Product Owner Produkt Product Owner, Stakeholder Release Scrum-Team (Product Owner, Scrum Master, Entwicklungsteam), Stakeholder Sprint Scrum-Team (Product Owner, Scrum Master, Entwicklungsteam) Beispiel: Flitz!Auto Strategie: Anbieter von Mobilitätslösungen basieren auf KFZs. Autoverleih Neu: Carsharing Portfolio: Verschiedenen Wagenklassen Produkte Tagessätze / Wochensätze / One-Way … Die Themen Strategie und Portfolio sind nicht Gegenstand dieses Seminars Tag Scrum Master, Entwicklungsteam Syl_ID_5.2 itedas Scrum Practitioner Open Base Syl. 2.1

Portfolioplanung Die Portfolioplanung ist eine Aktivität, in deren Verlauf festgelegt wird, an welchen Produkten, in welcher Reihenfolge und über welchen Zeitraum hinweg gearbeitet wird. Produktportfolio itedas Scrum Practitioner Open Base Syl. 2.1

Planung auf Produktebene
Produktvision N strategischer Filter Idee Visionsfindung Release … Sprints Business weitere Stakeholder Product Owner Entwicklungsteam Scrum Master In der Regel sind viele Spezialisten (Produktverantwortliche, Marketing, Vertrieb, technische Spezialisten usw.) an der Visionsfindung beteiligt. Syl_ID_5.3 itedas Scrum Practitioner Open Base Syl. 2.1

Produktvision: Wesentliche Merkmale
„Eine Vision ist die Kunst, unsichtbare Dinge sichtbar zu machen.“* Eine Produktvision fängt die wesentlichen Grundzüge des Produkts ein. Sie liefert die Informationen, die gewusst und – mehr noch – gefühlt werden müssen, um ein erfolgreiches Produkt entwickeln und vermarkten zu können. Eine Produktvision zeichnet ein Bild von der Zukunft, von dem die Menschen angezogen werden. Sie beschreibt, … wer die Kunden sind, … welche Bedürfnisse sie haben und … wie diese Bedürfnisse befriedigt werden. Eine effektive Produktvision … leitet das Scrum-Team und … verbindet Stakeholder und Kunden. * Jonathan Swift (1667–1745), anglo-irischer Erzähler, Moralkritiker und Theologe itedas Scrum Practitioner Open Base Syl. 2.1

Produktvision: 5 Fragen, die es zu beantworten gilt
Wer wird dieses Produkt kaufen? – Wer ist die Zielgruppe? Welche Kundenbedürfnisse werden mit diesem Produkt adressiert? Welches sind die wesentlichen Attribute und Merkmale und damit die wesentlichen Erfolgsfaktoren des Produkts, um diese Kundenbedürfnisse zu befriedigen? Wie hebt sich das Produkt von den Produkten der Mitbewerber ab? – Was sind die Alleinstellungsmerkmale (Unique Selling Propositions – USPs) dieses Produkts? Was sind die Ziele bezüglich Zeitrahmen und Budget für Entwicklung und Markteinführung des Produkts? itedas Scrum Practitioner Open Base Syl. 2.1

Produktvision: Elevator Pitch
Der Elevator Pitch soll in einer möglichst knappen Zeit das Produkt so darstellen, dass die Zuhörer an dem Produkt interessiert sind und sich auf ein längeres Gespräch einlassen. Aufbau des Elevator Pitch: Für <Zielgruppe>, die <Bedürfnisse der Zielgruppe>, ist <Produktname> ein/eine <Produktkategorie>, der/die/das <Kernnutzen/zwingender Kaufgrund/USP>. Anders als <bekanntes Alternativprodukt> unser Produkt <Aussage über die wesentlichen Unterscheidungsmerkmale>. Beispiel: Für Jugendliche zwischen 14 und 25, die nach einer durchzechten Nacht schnell wieder fit werden wollen, ist ThirstQuencher TQ ein BIO-Energizer, der Körper und Geist unmittelbar wieder die volle Leistungsfähigkeit zurückgibt. Anders als Red Bull zeichnet sich unser Produkt durch seinen 0-Kalorien- Gehalt sowie einen 100%-igen Anteil an naturbelassenem Quellwasser aus. itedas Scrum Practitioner Open Base Syl. 2.1

Produktvision: Car2Ride
Für junge Leute und Unternehmen, die eine umwelt- und kostenbewusste Mobilität wollen, bietet Car2Ride einen Car-Sharing-Service, der individuellen und einfachen Art. Anders als SIXTY zeichnet sich unser Produkt durch einen kundenfreundlichen Service mit gutem Preis-Leistungs-Verhältnis bei hohem Qualitätsniveau aus. Auf Basis dieser Produktversion wurde im Car2Ride-Projekt eine erste allgemeine Übersicht mit Lösungskomponenten (Arbeitspaketen) erstellt. Ein notwendiges Arbeitspaket ist die Erstellung einer neuen Website. Nachdem erwartet wird, dass das neue „Tor zur Welt“ von Flitz!Auto kontinuierlich an die Anforderungen und den technischen Fortschritt angepasst werden muss, hat man sich zur Realisierung für ein adaptives Vorgehen nach Scrum entschieden. Themensammlung (Brainstorming) für die neu zu gestaltende Website zur Erstellung des Product Backlog. itedas Scrum Practitioner Open Base Syl. 2.1

Themensammlung für neue Website
Profile: Hier sollen Mitglieder der Car2Ride-Community eigene Profile anlegen und verwalten können. Internationalisierung: Die Website soll in allen Landessprachen verfügbar sein. Auftragsmanager zum Managen von Mietverträgen von Leih- und Share-Wagen Service-Chat-Bot: Besucher werden über einen Chat-Bot angesprochen und können im Chat Hilfe erhalten. Car2Ride-Community Downloads: Downloadangebot zu bestimmen Service-Themen Barrierefreiheit: Die Oberfläche muss barrierefrei gestaltet sein. Was ist wichtig? Partnerangebote: Im Rahmen des geplanten Partnerprogramms sollen Partner spezielle Angebote präsentieren können. Homepage (Look & Feel) Was soll zuerst umgesetzt werden? Bewertungen: Hier können Fahrzeugnutzer Wagen und Service bewerten. Events: Liste der angebotenen Veranstaltungen Mit den Re-Design der Website kann schon zu einem frühen Zeitpunkt begonnen werden. Lediglich die rot gekennzeichneten Themen können erst in Abstimmung mit dem Fortschritt des Car2Ride-Projektes umgesetzt werden. Daher werden diese Themen im weiteren Verlauf des Fallbeispiels nicht weiter beachtet. Mit dem Thema „Barrierefreiheit“ lässt sich sicherlich auch ein Gag einfügen bzgl. der Buchung eines Wagen von einem blinden Fahrer … Bereich für Premiumkunden mit speziellen Informationen und Angeboten Artikel: Veröffentlichung von redaktionell aufbereiteten Pressemitteilungen News: Bekanntgabe von Neuigkeiten Webbrowser-Unterstützung: die letzten 2 Versionen von IE, Firefox, Safari und Chrome Newsletter-Management für Kunden FAQs itedas Scrum Practitioner Open Base Syl. 2.1

Entwickelt sich im Laufe des gesamten Projekts weiter
Der Product Backlog Sammlung aller Anforderungen an das zu erstellende Produkt detailliertere Funktionen Besteht aus unterschiedlich fein detaillierten Anforderungen Entwickelt sich im Laufe des gesamten Projekts weiter detailliertere Anforderungspakete („Funktionsgruppen“) Anforderungen, die in einem der nächsten Sprints umgesetzt werden sollen, sind detaillierter als die Anforderungen, die erst zu einem späteren Zeitpunkt umzusetzen sind. grobe Anforderungspakete („Module“) Die Anforderungen sind in Form von User Stories beschrieben. Als <Rolle> möchte ich <Ziel>, sodass ich <Vorteil>. itedas Scrum Practitioner Open Base Syl. 2.1

User Stories (Product Backlog) aus Brainstorming
Events: Als … möchte ich … damit … Service-Chat-Bot: Als … möchte ich … damit … News – Themengruppen abonnieren: Als Besucher der Website möchte ich über bestimmte aktuelle Themen per Mail immer auf dem Laufenden bleiben, damit ich informiert bin. Auftragsmanager: Als … möchte ich … damit … Newsletter-Management für Kunden: Als … möchte ich … damit … Homepage (Look & Feel): Als … möchte ich … damit … News – Themengruppen: Als Besucher der Website möchte ich, dass die Themen in übersichtliche Themengruppen zusammengefasst sind, damit ich schnell auf die Themen zugreifen kann, die mich interessieren. Bewertungen: Als … möchte ich … damit … Artikel: Als … möchte ich … damit … Bereich für Premiumkunden: Als … möchte ich … damit … News: Als Besucher der Website möchte ich schnell erkennen können, welche aktuellen Informationen bei Flitz!Auto für mich interessant sind. FAQs: Als … möchte ich … damit … News: Als … möchte ich … damit … itedas Scrum Practitioner Open Base Syl. 2.1

Conversation (Gespräch)
User Story = 3Cs Card (Karte) Titel Als <Rolle> möchte ich <Ziel>, sodass ich <Vorteil>. Conversation (Gespräch) Dialog => notwendige Details! Entwicklungsteam Product Owner Stakeholder Confirmation (Bestätigung) Zufriedenheitsbedingungen/Conditions of Satisfaction (COS) ? Umsetzung OK NOK Syl_ID_3.3 itedas Scrum Practitioner Open Base Syl. 2.1

Gute User Stories sind „INVEST“
Independent: Eine Story ist unabhängig von anderen Stories. Negotiable: User Stories sind kein geschriebenes Gesetz; wenn nötig, können diese im Konsens der Stakeholder geändert werden. Valuable: Stories sollten einen erkennbaren Mehrwert liefern. Estimable: Eine Story muss so überschaubar sein, dass die Entwickler den Aufwand der Umsetzung schätzen können. Small: Über den konkreten Umfang von Stories muss das Team entscheiden. Als Faustformel gilt: Die Umsetzung einer Story sollte zwischen 0,5 und 10 Personentagen liegen. Testable: Stories müssen testbar sein. + nicht technisch formuliert itedas Scrum Practitioner Open Base Syl. 2.1

Product Backlog-Elemente: User Stories
Der Product Backlog besteht aus User Stories … mit funktionalen Anforderungen mit Änderungen (Verbesserungen, Konkretisierungen etc.) an bereits umgesetzten funktionalen Anforderungen mit technischen Verbesserungen/Anpassungen (notwendigen Updates) zur Fehlerbehebung (Tickets) zum Wissenserwerb PW-Reset Als Anwender möchte ich m ein PW zurücksetzen lassen , wenn ich es vergessen habe, sodass ich weiterarbeiten kann. itedas Scrum Practitioner Open Base Syl. 2.1

Stories zum Wissenserwerb („Spikes“)
Was wir nicht wissen, müssen wir durch Prototypen, Konzepte, Experimente oder Studien o. Ä. in Erfahrung bringen. User Story Als Entwickler möchte ich alternative Lösungen für den Service-Chat-Bot kennen, um zu wissen, welche Lösung langfristig die bessere Wahl ist. Solche Stories werden auch Spikes genannt Confirmation (Bestätigung) Zufriedenheitsbedingungen Es soll Klarheit erreicht werden, welche Lösungen für unsere Anforderungen ein gutes Preis-Leistungs-Verhältnis aufweisen. itedas Scrum Practitioner Open Base Syl. 2.1

Nichtfunktionale Anforderungen und Randbedingungen
Nichtfunktionale Anforderungen repräsentieren qualitative Anforderungen auf Systemebene. Randbedingungen sind Anforderungen (z. B. gesetzliche), die die Lösung jenseits dessen einschränken, was notwendig ist, um die funktionalen und qualitativen Anforderungen zu erfüllen. Nichtfunktionale Anforderungen und Randbedingungen sind so früh wie möglich in Erfahrung zu bringen. Nichtfunktionale Anforderungen und Randbedingungen sind Bestandteil der Definition of Done (DoD). Qualitative Anforderungen (ISO/IEC 25000) Sicherheit, Genauigkeit Zuverlässigkeit (Robustheit) Benutzbarkeit (Erlernbarkeit) Performance (Effizienz) Änderbarkeit Übertragbarkeit Beispiel für Website: bis zu Pageviews pro Stunde bis zu gleichzeitig aktive Benutzer Unterstützung der aktuellen und der letzten Browser-Versionen itedas Scrum Practitioner Open Base Syl. 2.1

Definition of Done (DoD)/Definition von „fertig“
Die Definition of Done listet alle Arbeiten auf, die abgeschlossen sein müssen, bevor ein potenziell auslieferungsfähiges Produkt-Inkrement als fertig erklärt werden kann. Beispiel: Definition of Done  Design überprüft Code abgeschlossen Code restrukturiert Code in Standardformat Code kommentiert Code eingecheckt Code ist überprüft Endanwenderdokumentation aktualisiert … Tests durchgeführt Unit Test Integration keine Fehlfunktionen festgestellt Akzeptanz erfolgreich getestet Zufriedenheits-/Akzeptanzbedingungen (Conditions of Satisfaction) sind vom Product Owner festgelegte Bedingungen, denen ein Inkrement genügen muss, um für den Anwender funktionieren zu können. Syl_ID_3.6 itedas Scrum Practitioner Open Base Syl. 2.1

User Story und mögliche weitere Attribute
Name/Titel (ggf. zzgl. eindeutige ID) User Story Als <Rolle> benötige ich eine <Funktionalität>, damit ich den <Nutzen> bekomme. Akzeptanzkriterien Die Akzeptanzkriterien beantworten die Frage, was getestet werden soll, und stellen sicher, dass eine Story abgenommen werden kann. technische (nichtfunktionale) Anforderungen Zwingend einzuhaltende Vorgaben bzgl. Architektur, Umsetzung, Anforderungen an Monitoring (Heartbeat), Abhängigkeiten. Umgang mit Code-Refactoring. Testumfang (Umgebung (Test, Dev, Prod), Testdaten, Testszenarien …) ergänzende Informationen einzuhaltende Rahmenbedingungen, Annahmen und Ausschlüsse, Beschreibung der Ausgangssituation, Klickpfade, Prozess-/Flussdiagramm, URL … Risiken, die mit der (Nicht-)Umsetzung verbunden sind (=> Testkonzept) Abhängigkeiten zu anderen Stories/Anforderungen/Ideen weitere Informationen Screenshots, Mockups, Dokumentationen, Schnittstellen … sowie Arbeitsabläufe, wie beispielsweise folgende: „Jede neue Story muss mindestens eine Runde zwischen Autor und Entwicklern durchlaufen, um ein einheitliches Verständnis zu ermöglichen. Dabei wird die User Story erweitert, d. h. Details werden beschrieben, Akzeptanzkriterien erweitert, fehlende Daten (wie Screens, Testdaten etc.) hinzugefügt, Antworten auf Fragen (im Beschreibungsteil) dokumentiert etc.“ Bestandteile der Definition of Done itedas Scrum Practitioner Open Base Syl. 2.1

Product Backlog-Struktur
Priorität gering hoch Als Redakteur benötige ich einen Bereich auf der Homepage, um aktuelle Ankündigungen für den Besucher gut sichtbar platzieren zu können. … kleine User Stories n 1 Tage Als Redakteur benötige ich ein einfach zu bedienendes Redaktionssystem (Web-Content-Management-System), das mir das Maximum an Freiheit zur Platzierung von Inhalten gibt. … (große User Stories) Epen 1 n Wochen Als Unternehmen benötigen wir eine attraktive und moderne Homepage, die zu unserem neuen Image passt, damit wir nach außen glaubwürdig wirken. … (sehr große User Stories) Themenblöcke Epik ist deswegen gestrichelt, da diese nicht immer und zwingend sichtbar gemacht bzw. genutzt werden, wie in dem Beispiel der Website für Car2Ride. Mit „Zeitdauer“ ist die Umsetzungsdauer gemeint Monate Syl_ID_3.1 itedas Scrum Practitioner Open Base Syl. 2.1

Ein guter Product Backlog ist „DEEP“
Detailed appropriately (angemessen detailliert) Emergent (sich entwickelnd) Estimated (Aufwand geschätzt) Prioritized (priorisiert/sortiert) itedas Scrum Practitioner Open Base Syl. 2.1

Management des Product Backlog
Entwicklungsteam Product Owner Stakeholder Auch wenn die Pflege des Product Backlog Gemeinschaftsarbeit ist, ist der Product Owner die einzige Person, die für das Management des Product Backlog (ergebnis-)verantwortlich (accountable) ist. Pflege (Grooming) des Backlog-Management Product Backlog-Einträge (Product Backlog Items – PBI) klar formulieren Product Backlog verfeinern Einträge so sortieren (priorisieren), dass Ziele und Mission optimal erreicht werden den Wert der Arbeit optimieren, die das Entwicklungsteam erledigt sicherstellen, dass der Product Backlog sichtbar, transparent und für alle klar ist sowie zeigt, woran das Scrum-Team als nächstes arbeiten wird sicherstellen, dass das Entwicklungsteam die Product Backlog-Einträge im erforderlichen Maße versteht Das Backlog Grooming kann zu fast jedem Zeitpunkt stattfinden. Wichtig ist lediglich, dass es sich gut in den Arbeitsablauf aller Beteiligten einfügt. Syl_ID_3.1 itedas Scrum Practitioner Open Base Syl. 2.1

Product Backlog: Priorisierung/Sortierung
Kano-Modell Return on Invest (ROI) itedas Scrum Practitioner Open Base Syl. 2.1

Product Backlog-Priorisierung: Kano-Modell
Basismerkmale vorausgesetzt oder unbewusst erwartet Erfüllung unbemerkt/neutrale Haltung Nichterfüllung erzeugt Unzufriedenheit Beispiele: Hotel: Heizung auf Zimmer Auto: Türen öffnen/schließen angenehm Leistungsmerkmale bewusst nachgefragt/gefordert Grad der Erfüllung ≈ Grad der Zufriedenheit Beispiele: Hotel: Wartezeiten bei Empfang, Zimmergröße Auto: Kraftstoffverbrauch, Motorleistung Begeisterungsmerkmale unerwartet oder sogar unbekannt Fehlen schadet nicht Erfüllung begeistert Beispiele: Hotel: Whirlpool im Zimmer Auto: selbstreinigender Lack itedas Scrum Practitioner Open Base Syl. 2.1

Das Kano-Modell Leistungsmerkmale Begeisterungsmerkmale Basismerkmale
Zufriedenheit Begeisterungsmerkmale gewinnbringend wecken Begehrlichkeiten haben ggf. Erklärungsbedarf Akzeptanzrisiko (Beispiel: alkoholfreier Wein) Leistungsmerkmale werden diskutiert kostendeckend für Kaufentscheidung neutral sehr zufrieden abwesend/ ganz schlecht vollständig/ sehr gut Umsetzungsgrad eines Merkmals Basismerkmale erfüllen auch Wettbewerber ggf. nicht kostendeckend bilden K.o.-Kriterien zeitliche Entwicklung: Begeisterung  Leistung  Basis Hotel: Bad/WC im Zimmer Auto: Zentralverriegelung, ABS völlig unzufrieden Syl_ID_5.3.1 itedas Scrum Practitioner Open Base Syl. 2.1

Die Größe von Backlog-Einträgen bestimmen
In Scrum werden Größen geschätzt. Durch dauerndes Wiederholen der Schätzungen gelangt man zu immer besseren Schätzergebnissen. Geschätzt wird in relativen Größen, also in Bezug auf eine oder mehrere Referenzgrößen. In der Regel schätzen Teams dazu in Story Points oder Idealtagen bzw. Idealstunden. Geeignete Maßskalen: 1, 2, 4, 8, 16, 32, 64, 128 … 1, 2, 3, 5, 8, 13, 20, 40, 60, 100 … XXS, XS, S, M, L, XL, XXL Die Größe eines Eintrags ist auch ein Maß für den benötigten Arbeitsaufwand, um diese Funktion zu erstellen. Syl_ID_5.3.1 itedas Scrum Practitioner Open Base Syl. 2.1

Product Backlog-Priorisierung nach „relativem ROI“
Werte-Vorrat: 1, 2, 4, 8, 16, 32, 64, 128 Nichtfunktionale Anforderungen gelten (i. d. R.) für alle Themen, die umgesetzt werden sollen. Product Owner Entwicklungsteam Stakeholder Syl_ID_5.3.1 itedas Scrum Practitioner Open Base Syl. 2.1

Produkt-Roadmap (Releaseplanung) für neue Website
Bereich für Premiumkunden Newsletter-Management Homepage (Look & Feel) Service-Chat-Bot Auftragsmanager Partnerangebote Bewertungen Downloads Artikel Events Q2 Q3 Q4 Q1 Syl_ID_5.3 itedas Scrum Practitioner Open Base Syl. 2.1

Aufbereiteter Product Backlog
Product Owner Bisher geplante Themenblöcke (und/oder Epen) des Product Backlog Homepage (Look & Feel) User Stories (Homepage) Als Redakteur … benötige ich einen gut sichtbaren Bereich auf der Homepage, um aktuelle Ankündigungen platzieren zu können. hätte ich gerne gewisse Freiheiten, um Content an verschiedenen Stellen platzieren zu können. … Als Besucher der Site … möchte ich auf einen Blick Neuigkeiten erkennen können. würde ich gerne über aktuelle Aktionen und Angebote erfahren. will ich eine intuitive Navigation durch alle Bereiche haben. Artikel Newsletter-Management Downloads Service-Chat-Bot Bewertungen Events Auftragsmanager Bereich für Premiumkunden Partnerangebote itedas Scrum Practitioner Open Base Syl. 2.1

Zusammenfassung: Produktplanung
Scrum-Planungsprinzipien Der Product Backlog Die Priorisierung Die Releaseplanung itedas Scrum Practitioner Open Base Syl. 2.1

Scrum-Projekt: Sprint
Der Sprint Die Sprint-Planung Das Daily Scrum Der Sprint-Review Die Sprint-Retrospektive Syl_ID_2.1 itedas Scrum Practitioner Open Base Syl. 2.1

Der Sprint: Das Herz von Scrum
Der Sprint ist eine Time Box von maximal einem Monat, innerhalb derer ein fertiges („Definition of Done“), nutzbares und potenziell auslieferbares Produkt-Inkrement hergestellt wird. Alle Sprints innerhalb eines Entwicklungsvorhabens sollten die gleiche Länge haben. Der neue Sprint startet unmittelbar nach Abschluss des vorigen Sprints. Sprints werden auch manchmal als Iteration bezeichnet. Jeder Sprint umfasst folgende Ereignisse: Sprint-Planung Daily Scrums Sprint-Review Sprint-Retrospektive Während des Sprints … werden keine Änderungen vorgenommen, die das Sprint-Ziel gefährden. wird der Qualitätsanspruch nicht geschmälert. kann der Anforderungsumfang auf Basis neuer Erkenntnisse zwischen Product Owner und Entwicklungsteam neu ausgehandelt werden. Syl_ID_2.1 / Syl_ID_9.1 itedas Scrum Practitioner Open Base Syl. 2.1

Aspekte, die für alle Sprints zu beachten sind
Time Box kurze Zeitdauer konsistente Zeitdauer keine das Ziel beeinflussenden Änderungen Definition of Done (Definition von fertig) itedas Scrum Practitioner Open Base Syl. 2.1

Timeboxing Timeboxing macht Fortschritt deutlich
erzwingt Priorisierung macht Fortschritt deutlich Timeboxing erfordert WIP-Limits verhindert unnötigen Perfektionismus WIP-Limits begrenzen die anzufangende Arbeit Um bei einem begrenztem Arbeitsumfang das richtige zu machen, ist eine Priorisierung der Arbeitspakete notwendig Der Fortschritt wird nach jedem Sprint (=Umfang des abgearbeitetem Sprint Backlog ) sichtbar Verhinderung von Perfektionismus: Aufgrund der „Zeitknappheit“ konzentriert man sich auf das was wirklich gemacht werden muss (Definition of Done) und versucht nicht noch die „Platinausführung“ zu ermöglichen, wenn „Blech“ gefordert ist. Kurze Zeiträume mit klaren Deadline helfen, das Ziel nicht aus den Augen zu verlieren und spornen an, fertig zu werden. Was in 4 Wochen fertig werden kann ist leichter vorherzusagen, als für einen Zeitraum von einem Jahr. verbessert die Vorhersehbarkeit motiviert die Fertigstellung itedas Scrum Practitioner Open Base Syl. 2.1

Zeitdauer: kurz und konsistent über alle Sprints
Kurze Zeitdauer erleichtert die Planung schnelles Feedback begrenzte Fehler verbesserter Return of Investment Begeisterung häufige Checkpoints Konsistente Zeitdauer => Nutzung der Kadenz Unter Kadenz versteht man in der Harmonielehre landläufig auch eine ganze Abfolge von harmonischen Funktionen, die mit einem tonischen Schluss (der eigentlichen Kadenz) endet. Der Kadenz-Begriff fasst hier also einen funktionalen Spannungsbogen mit ein. Quelle: :12 Sprints mit derselben Dauer liefern eine Kadenz (einen regelmäßigen, vorhersehbaren Rhythmus) für das Arbeiten. itedas Scrum Practitioner Open Base Syl. 2.1

Die Erstellung einer neuen Website, das „Tor zur Welt“
Das Sprint-Ziel beschreibt das Ergebnis (Geschäftszweck, Nutzen etc.) eines Sprints. Die Erstellung einer neuen Website, das „Tor zur Welt“ soll möglichst kurz und klar formuliert sein, um den Fokus des Sprints klar auszudrücken. ist Grundlage der gegenseitigen Verpflichtung zwischen Product Owner und Entwicklungsteam. itedas Scrum Practitioner Open Base Syl. 2.1

Sprint-Planung Planung der Arbeit für diesen Sprint (= Sprint Backlog)
Teilnehmer: Entwicklungsteam Product Owner Scrum Master als Coach ggf. auch weitere, sofern vom Entwicklungsteam benötigt Scrum Master Product Owner Entwicklungsteam Planung Sprint Backlog Product Backlog Sprint (max. 4 Wochen) Planung (max. 1 Tag (8 h)) Daily Stand-up (15 Minuten) Review (max. 4 Stunden) Retrospektive (max. 3 Stunden) itedas Scrum Practitioner Open Base Syl. 2.1

Planungsmeeting DoR- Filter Product Backlog Product Backlog
Scrum Master Product Owner Sprint Backlog Sprint-Ziel Entwicklungsteam anfängliches Sprint-Ziel Einschränkungen bewerten/schätzen abwägen organisieren 8 Team- Velocity DoR: Definition of Ready Syl_ID_3.2, Syl_ID_2.1.1 itedas Scrum Practitioner Open Base Syl. 2.1

Definition of Ready (DoR)/Definition von „bereit“
Um sicherzustellen, dass die im Planungsmeeting ausgewählten User Stories sich auch umsetzen lassen, kann es sinnvoll sein, die notwendigen Voraussetzungen dazu zu definieren. Beispiel: Definition of Ready  Der Geschäftswert/Nutzen ist klar artikuliert. Die Akzeptanzkriterien sind eindeutig und testbar. Das Entwicklungsteam hat die Einzelheiten richtig verstanden, sodass es in der Lage ist, eine fundierte Entscheidung darüber zu treffen, ob die Story im Sprint umgesetzt werden kann. Es wurden keine blockierenden Abhängigkeiten erkannt. Die Story ist klein genug, um sie im Sprint abschließen zu können. Das Scrum-Team versteht, wie es das Produkt-Inkrement bei Sprint-Review demonstrieren soll. … Syl_ID_3.5 itedas Scrum Practitioner Open Base Syl. 2.1

Auswahl der Product Backlog-Elemente
Sollte der Product Owner ein … formelles Ziel (Sprint-Ziel) genannt haben, werden die dazu passenden Elemente aus dem Product Backlog gewählt …, andernfalls werden die Elemente ihrer Reihenfolge nach gewählt. Definition of Ready (DoR) Syl_ID_2.1.1 itedas Scrum Practitioner Open Base Syl. 2.1

Einteilige/zweiteilige Sprint-Planung
Lassen freie Kapazitäten noch weitere Arbeiten zu? Auswahl eines Backlog-Elements Kapazität für Sprint ermitteln Zerlegung in Teilaufgaben Sprint-Ziel anpassen finale Verpflichtung Einteilige Sprint-Planung Kapazität für Sprint ermitteln Auswahl aller Backlog-Elemente bis zur Kapazitätsgrenze Zerlegung in Teilaufgaben finale Verpflichtung Auswahl der Backlog-Elemente anpassen Sprint-Ziel anpassen Kapazitätsanpassungen nötig? Zweiteilige Sprint-Planung Formale Verpflichtung des Entwicklungsteam zur Umsetzung das ausgewählten Einträge. Syl_ID_2.1.1 itedas Scrum Practitioner Open Base Syl. 2.1

kontinuierliche Task-Planung
Sprint-Ausführung kontinuierliche Task-Planung Daily Scrum Flow-Management Flow: Es soll ein kontinuierlicher Arbeitsfluss erreicht werden. Was muss/kann parallelisiert bzw. sequentiell abgearbeitet werden? Was kann/muss im singletasking/multitasking abgearbeitet werden? Wichtig ist der kontinuierliche Arbeitsfluss und NICHT der Versuch alle Personen zu jeder Zeit zu 100% auszulasten Umsetzung der Tasks Kommunikation Syl_ID_2.1.2 itedas Scrum Practitioner Open Base Syl. 2.1

Dekomposition: User Story -> Tasks
Als <Rolle> möchte ich <Ziel>, sodass ich <Vorteil>. Task (technische) Beispiele für Tasks: Erstellen einer Datenbanktabelle Erstellen eines Layouts für den Login-Screen Erstellen einer HTML-Seite zum Anmelden Erstellen einer CSS-Datei für HTML-Seite Erstellen eines Java-Skripts für Login Testen der Tabelle und deren Verknüpfungen Testen des Layouts der HTML-Seite … itedas Scrum Practitioner Open Base Syl. 2.1

Flow-Management Single Tasking Multi Tasking oder oder Task Switching
Wohnung putzen Fernsehen Radio hören Wohnung putzen Wohnung putzen Radio hören Multi Tasking oder oder Fernsehen Radio hören Fernsehen Task Switching Wp F Rh Wp F Rh Selbsttest: Wie viel kostet Task-Switching Schrieben Sie folgende Zahlenreihen so schnell sie können. Gruppe A: Zeilenweise (1, A, I – 2, B, II – 3, C, III … 10,J,X) Gruppe B: Spaltenweise (1,2,3 … 10, A,B,C … J, I, II, III … X) 1 A I 2 B II 3 C III 4 D IV 5 E V 6 F VI 7 G VII 8 H VIII 9 I IX 10 J X Single Tasking: geht Multi-Tasking: Wohung putzen/Fernsehen und Radio hören/Fernsehn geht nicht Task Switching: geht (vielleicht nicht immer gut). Kostet aber auf jeden Fall Zeit und sollte auf ein Minimum reduziert werden Switching "between tasks can cost as much as 40 percent of someone's productive time." Quelle: itedas Scrum Practitioner Open Base Syl. 2.1

Flow-Management und WIP-Limit
Die Situation: 3 identische Projekte (P1, P2, P3); identische Priorität und Dringlichkeit 3 Ressourcen (A, B, C) A benötigt 2 Wochen B benötigt 3 Wochen C benötigt 2 Wochen die Bearbeitungsreihenfolge ist A, B, C Wochen P1 P2 P3 A A B B B C C WIP=3 Task-Switching-Mode A A B B B C C A A B B B C C P1 P2 P3 A B C Single-Task-Mode WIP=1 A B C A B C itedas Scrum Practitioner Open Base Syl. 2.1

Daliy Scrum (Daily Stand-up) – „Mini-Planungsmeeting“
tägliches Treffen des Entwicklungsteams 15 Minuten maximal Teilnehmer: Entwicklungsteam Scrum Master ggf. stumme (!) Gäste Dient … der Synchronisation der Aktivitäten des Entwicklungsteams der Überprüfung des Fortschritts in Richtung Sprint-Ziel hilft dem Team, das Sprint-Ziel zu erreichen Daily Scrum Planung Sprint Backlog Product Backlog Drei Fragen, die von jedem Mitglied des Entwicklungsteams zu beantworten sind: Was habe ich seit dem letzten Daily Scrum erreicht? Was werde ich bis zum nächsten Daily Scrum erreichen? Welche Hindernisse sehe ich, die mich/uns vom Erreichen des Sprint-Ziels abhalten könnten? Syl_ID_2.2 itedas Scrum Practitioner Open Base Syl. 2.1

Sprint-Review Ziel ist es, das, was im Sprint erstellt wurde (das Produkt-Inkrement), zu überprüfen und den Product Backlog bei Bedarf anzupassen. Teilnehmer: Product Owner (lädt auch Stakeholder ein) Entwicklungsteam Scrum Master wichtige Stakeholder Daily Scrum Planung Review Sprint Backlog Inkrement Product Backlog Das Sprint-Review ist ein informelles Meeting (kein Statusreport), in dem den Teilnehmern das Inkrement vorgeführt wird. Die Vorführung des Inkrements ist als Anregung für Feedback und als Basis für die Zusammenarbeit gedacht. Syl_ID_2.3 itedas Scrum Practitioner Open Base Syl. 2.1

Elemente des Sprint-Reviews
Product Owner lädt Stakeholder ein erklärt, welche Product Backlog-Einträge „done“ sind stellt den aktuellen Stand des Product Backlog dar Entwicklungsteam stellt dar, was während des Sprints gut lief, welche Probleme auftraten und wie sie gelöst wurden führt die „Done“-Arbeiten vor und beantwortet Fragen Scrum Master Stakeholder Begutachtung der aktuellen (Markt-)Situation bzgl. neuer Erkenntnisse alle Teilnehmer erarbeiten gemeinsam, was im nächsten Sprint zu tun ist (=> wertvoller Input für Sprint-Planung) Überprüfung von Zeitplan, Budget und potenziellen Eigenschaften des nächsten zu erwartenden Produkt-Releases itedas Scrum Practitioner Open Base Syl. 2.1

Sprint-Retrospektive
Ziel ist es, … zu überprüfen, wie der Sprint in Bezug auf Personen, Beziehungen, Prozesse, Arbeitsweisen und Werkzeuge verlief. die wichtigsten gut gelaufenen Elemente zu erkennen. mögliche Verbesserungen zu identifizieren und in eine Reihenfolge zu bringen. einen Plan für die Umsetzung der Verbesserungen zu erstellen. Daily Scrum Planung Review Sprint Backlog Inkrement Retrospektive Scrum Master Product Owner Entwicklungsteam Inspect & Adapt Inspect & Adapt Product Backlog Syl_ID_2.4 itedas Scrum Practitioner Open Base Syl. 2.1

Sprint-Retrospektive: Vorgehen
Vorgaben: Fokus Übungen objektive Daten subjektive Daten Einsichten-Backlog Ergebnisse: Verbesserungen Einsichten-Backlog bessere Zusammenarbeit bessere Abläufe Scrum Master Product Owner Entwicklungsteam Inspect & Adapt Inspect & Adapt Syl_ID_2.4 itedas Scrum Practitioner Open Base Syl. 2.1

Gruppenarbeit: Retrospektive – Inspect & Adapt
Aufgabe: Umfüllen der 100 Bälle aus dem vollen Behälter in den leeren Behälter Rahmenbedingungen: Die Bälle müssen über eine Kette aus allen Teammitgliedern geführt werden. Die Bälle dürfen nicht direkt in die Hand übergeben werden, sondern müssen durch die Luft fliegen. Pässe zum direkten Nachbarn sind nicht erlaubt. Bälle, die auf den Boden fallen, sind aus dem Spiel. Ablauf: 4 Runden („Sprints“) à 4 Minuten Start Quelle: Auswertung wie folgt: Sprint # umgefüllte Bälle Anmerkung Vorhergesagt Erreicht Chaos, Finger pointing, # auf den Boden gefallene Bälle viele Spaß, Organisation, # auf den Boden gefallene Bälle 22 Stille, Konzentration, # auf den Boden gefallene Bälle 11 80 79 Stille, Konzentration, # auf den Boden gefallene Bälle 8 Innerhalb von nur vier Sprints waren die Abschätzung und der wirklich durchlaufenden Bälle fast identisch. Die Agile Übung macht deutlich, was es bedeutet in Scrum die Iterationen durchzuführen und dann per Retrospektive zu prüfen, was war gut und was nicht. Die Änderungen fließen sofort wieder in die neue Iteration ein. Retrospektive (Inspect & Adapt) 2 Minuten Vorhersage  Umsetzung 2 Minuten itedas Scrum Practitioner Open Base Syl. 2.1

Abbruch eines Sprints:
Sprint beenden Normales Ende: Ein Sprint ist automatisch nach Ablauf der definierten Zeit (Time Box) zu Ende. Abbruch eines Sprints: Ein Sprint kann vor Ablauf seiner Time Box durch den Product Owner (letzte Entscheidungsinstanz) abgebrochen werden, wenn das Sprint-Ziel obsolet geworden ist. Aufräumarbeiten bei Abbruch: „Abbruch-Review“: Begutachtung aller „Done“-Inkremente und ggf. Abnahme durch den Product Owner Neu-Schätzung aller unvollständigen Inkremente Aufräumen (Grooming) des Product Backlog itedas Scrum Practitioner Open Base Syl. 2.1

Zusammenfassung: Sprint
Die Sprint-Planung Das Daily Scrum Der Sprint-Review Die Sprint-Retrospektive itedas Scrum Practitioner Open Base Syl. 2.1

Schätzung und Velocity
Schätzkonzepte Schätzen des relativen Arbeitsaufwands Elemente, die beschätzt werden Teamkapazität Velocity Schätzverfahren itedas Scrum Practitioner Open Base Syl. 2.1

relative Größen benutzen Schätzungen sind keine Verpflichtungen
Schätzkonzepte Entwicklungsteam als gesamtes Team schätzen Die Schätzungen sollen auf der Expertise aller Mitglieder des Entwicklungsteams beruhen. relative Größen benutzen In der Regel werden so bessere Schätzergebnisse erzielt. auf ausreichende Richtigkeit/Genauigkeit konzentrieren, nicht auf Präzision Relative Größen: Die Höhenverhältnis zwischen den einzelnen Gebäuden beträgt 1:1,5:2 Exaktheit (ausreichende Richtigkeit/Präzision: Wieviel km sind es von Hamburg nach München? 775 km laut Google Maps. Eine Angabe von Nachkommastellen ist unnötig, da es an der Abschätzung der Fahrzeit nichts ändern wird. Außerdem liegt es in der Natur der Sache, dass Schätzungen mehr oder weniger großen Schätzfehlern belegt sind. Ein Beispiel, was man im Seminar nutzen kann: Frage 1: Wieviel Meter steht der Beamer von der rechten und linken Zimmerwand entfernt? Frage 2: Wo befindet sich der Beamer relativ zu den beiden Wänden? (Antwort: Etwa in der Mitte.) Verpflichtung: Um das einrechnen von Puffer-Aufwänden zu vermeiden, dürfen die Schätzungen nicht als Basis irgendeiner Erfolgsmessung hergenommen werden. Der einzige Zweck, der erzielt werden soll, ist, dass die Schätzungen über die Zeit besser werden. Daraus lässt sich auch der Tatbestand ableiten, dass Schätzungen nach außen am Besten in Story Points gemacht werden, damit das Umfeld nicht direkt in einen Nachmess- und Bewertungsmodus kommt sowie Idealzeiten mit Kalenderzeiten verwechselt. Schätzungen sind keine Verpflichtungen Syl_ID_6.1 itedas Scrum Practitioner Open Base Syl. 2.1

Schätzen des relativen Arbeitsaufwands
Das Entwicklungsteam beschätzt den relativen Arbeitsaufwand für Backlog-Einträge. Beschätzt wird in Einheiten, in denen der relative Arbeitsaufwand (bzw. die Größe der Story) gemessen werden kann: Idealzeiten (= Nettoarbeitszeit, ohne Pausen und sonstige Unterbrechungen) ideale Stunden oder ideale Tage Story Points: reine Größenschätzung Syl_ID_6.1 itedas Scrum Practitioner Open Base Syl. 2.1

Zeit-/größenbasiertes Schätzen
Schätzwerte basieren auf Annahmen und beinhalten Unsicherheiten. Zeitbasierte Schätzwertangaben (basierend auf der verstrichenen Zeit) ... in Personentagen (oder Personenstunden o. Ä.) führen zu einer ungerechtfertigt hohen Erwartungshaltung bezüglich des Fertigstellungstermins. beinhalten daher oft Pufferzeiten. bedeuten wegen der in ihnen enthaltenen Unsicherheiten eine unnötige Verbindlichkeit. differieren zwischen erfahrenen und unerfahrenen Entwicklern erheblich. sind absolute Größen. Größenbasierte Schätzwertangaben (Story Points) … unterstützen ein funktionsübergreifendes Verhalten. sind sicherer in ihrer Vorhersagekraft. sind selbstkorrigierend. sind schneller erstellt und haben eine längere Lebensdauer als zeitbasierte. sind relative Größen. Syl_ID_6.1 itedas Scrum Practitioner Open Base Syl. 2.1

Idealzeiten: Ein problematisches Schätzmaß
Durch die Angabe eines Zeitmaßes (= reale Zeit) ergeben sich folgende Probleme: Der angegebene Schätzwert vermittelt eine nicht vorhandene Präzision. Die zur Bearbeitung benötigte Zeitdauer scheint exakt zu berechnen zu sein. Beides resultiert in einer nicht gerechtfertigten Erwartungshaltung und unnötigem Druck im Entwicklungsteam. Der Ausweg: schätzen in Story Points Story Points sind relative Größenangaben; zu ihrer Bestimmung werden benötigt: eine (oder mehrere) Referenz(en) als Fixpunkt(e) eine Einheit, die beschreibt, mit welcher Messgröße wir messen eine Skala zur Angabe einer quantitativen Abstufung periodische Neubestimmung der Referenz Syl_ID_6.1 itedas Scrum Practitioner Open Base Syl. 2.1

Schätzen: Was? Wann? A B C Übliche Maßeinheiten Element
Portfolio- Backlog Product Backlog Sprint Backlog Task Backlog Einheit T-Shirt-Größen Story Points oder Idealtage Idealstunden/Aufwandsstunden Wertebereich XXS … M … XXL 1, 2, 4, 8, 16 … oder 1, 2, 3, 5, 8, 13, 20, 40 … reelle Zahl > 0 Verwendung Portfolioplanung Product Backlog-Pflege Sprint-Planung A B C Syl_ID_6.1 itedas Scrum Practitioner Open Base Syl. 2.1

Maßskalen zum Schätzen
Schätzungen können immer nur eine Annäherung an die wahren Werte liefern! Schätzungen unterliegen immer einem Schätzfehler! Zahlenbasierte Skalen 2er-Potenzreihe: 1, 2, 4, 8, 16, 32, 64, 128 … 2k an Fibonacci-Zahlenreihe angelehnt: 0, 1, 2, 3, 5, 8, 13, 20, 40, 100 … (Nk-1 + Nk)/2 Sonstige Skalen Kleidungsgrößen: XXS – XS – S – M – L – XL – XXL Die Fibonacci-Folge beschreibt u. a. zahlreiche Wachstumsvorgänge von Pflanzen und Tieren. Es scheint, als sei sie eine Art Wachstumsmuster in der Natur. [Quelle: Der goldene Schnitt, golden-section.eu, Dr. Dr. Ruben Stelzner in Zusammenarbeit mit Prof. Dr. Wolfgang Schad, abgerufen am 26. Oktober 2015] Hinweis: Wenn in einem Sprint viele kleinere Stories bearbeitet werden, ist der gesamte Schätzfehler kleiner, als wenn wenige große Stories bearbeitet werden! Syl_ID_6.1 itedas Scrum Practitioner Open Base Syl. 2.1

Die Referenz-Story Wertebereich: 1, 2, 3, 5, 8, 13, 20, 40, 100
Story A xxxx Business Value Story Points 1 Story B xxxx Business Value Story Points 20 Welche Story eignet sich potenziell am besten als Referenzgröße und warum? Keine der hier dargestellten Stories stellt eine gute Referenz dar. Die eine ist zu klein, die anderen zu groß. Ideal wäre eine Story der Größe 2 oder 3 Story C xxxx Business Value Story Points 40 Syl_ID_6.1 itedas Scrum Practitioner Open Base Syl. 2.1

Affinity Estimation Triangulation Planning Poker
Schätzarten Affinity Estimation Triangulation Planning Poker itedas Scrum Practitioner Open Base Syl. 2.1

Affinity Estimation schnelle Schätzung einer großen Anzahl (> 20) von User Stories Releaseplanung oder Portfolioplanung Vorbereitung: Liste mit User Stories auf Post-its, ausreichende Fläche zur Gruppierung der Stories Teilnehmer: Scrum-Team und, wenn nötig, weitere Teilnehmer, die Fragen beantworten können kleiner größer 1 SP 3 SP 5 SP 8 SP 13 SP 20 SP Statt, dass jedes einzelne Teammitglied für sich einzeln Stories gruppiert, kann dies in einem skalierten Umfeld (Scum-of-Scrums) auch durch verschiedene Teams gemacht werden. Syl_ID_6.1.1 itedas Scrum Practitioner Open Base Syl. 2.1

Affinity Estimation: Ablauf
Silent Sizing: Stilles Sortieren nach relativer Größe: Jedes Mitglied des Entwicklungsteams bekommt dazu einen Satz an Stories. Stories, die auch durch Nachfragen nicht gruppiert werden können, werden zur Seite gelegt. (Zeit: ca. 5–20 Minuten) Wikipedia-like Editing: Diskussion von „fragwürdigen“ Platzierungen im Entwicklungsteam und mit dem Product Owner, um zu einer abgestimmten Platzierung der Stories im Entwicklungsteam zu kommen. (Zeit: ca. 20–60 Minuten) Place Stories into Sizing Buckets: Größenzuweisung (Kleidungsgrößen, 2er-Potenzreihe oder „Fibonacci-Zahlen“ etc.) zu den einzelnen Story-Gruppen. (Zeit: ca. 10–30 Minuten) Product Owner Review: Das Entwicklungsteam kann jetzt eine Pause einlegen, während der Product Owner sich das Ergebnis anschaut, um zu erkennen, ob er Fragen an das Team hat. (Zeit: 15 Minuten) Wrap-up: Das Team beantwortet die Fragen des Product Owner und begründet seine Sizing-Entscheidung und/oder revidiert sie. Documentation: Das Ergebnis wird vom Product Owner dokumentiert. Statt, dass jedes einzelne Teammitglied für sich einzeln Stories gruppiert, kann dies in einem skalierten Umfeld (Scum-of-Scrums) auch durch verschiedene Teams gemacht werden. Syl_ID_6.1.1 itedas Scrum Practitioner Open Base Syl. 2.1

Triangulation Damit Schätzungen in einzelnen Sprint möglichst vergleichbar bleiben, wird zumindest eine Referenz-Story benötigt. 2 oder mehrere Referenz-Stories erhöhen die Schätzgenauigkeit (= Triangulation) Beispiel für Referenz-Stories für zwei Größen, um Schätzungen zu verbessern Syl_ID_6.1.2 itedas Scrum Practitioner Open Base Syl. 2.1

Planning Poker Jeder Schätzer erhält ein Set Karten mit je einem Kartenwert. Nachdem eine User Story vom Kunden oder Product Owner vorgelesen wurde, wird diese im Team kurz diskutiert. Im Anschluss bewertet jeder Schätzer für sich (!) die Story (und wählt eine Karte). Hat jeder Schätzer seine Bewertung vorgenommen, werden die Karten aufgedeckt und die Abweichungen diskutiert. Die Schätzungsrunden werden so oft wiederholt, bis sich die geschätzten Werte ausreichend angenähert haben. Schätzer Runde 1 Runde 2 Runde 3 Anita 3 5 Günther 8 Petra 20 10 Hannelore Syl_ID_6.1.3 itedas Scrum Practitioner Open Base Syl. 2.1

Teamkapazität schätzen
Person Arbeitszeit / Tag (h) Nettoarbeitszeit 20 Tage-Sprint (h) brutto netto* Petra 8 4 80 Jutta 3 60 Hans Bertram 6 120 Gabi 5 100 Ursel Hans-Günther 2 40 total 580 * geschätzter Durchschnittswert Woher weiß ein Team, wie viele User Stories im nächsten Sprint abgearbeitet werden können? Die Team-Kapazität in einem Idealzeitmaß abzuschätzen ist kein größeres Problem. Aber wie kommt das Team auf einen sinnvollen Sprint Backlog, der auf im Sprint mit hoher Wahrscheinlichkeit erfolgreich abgearbeitet werden kann? Syl_ID_6.1 itedas Scrum Practitioner Open Base Syl. 2.1

Kapazität des Entwicklungsteams ermitteln
Der Sprint-Puffer … dient zum Auffangen von Unvorhergesehenem. kann in der Regel erst mit wachsender Erfahrung gut bestimmt werden. maximale Kapazität andere Nicht-Sprint-Verpflichtungen andere Sprint-Aktivitäten Planung, Review, Retrospektive, Product Backlog-Pflege Sprint-Puffer Bearbeiten der Backlog-Elemente im Sprint Syl_ID_2.1.1 itedas Scrum Practitioner Open Base Syl. 2.1

Die Velocity eines Scrum-Teams gibt die Menge der Arbeit an, die in einem Sprint abgeschlossen wurde. erfüllt zwei wichtige Zwecke: Sie ist das wesentliche Konzept für Scrum-Planung. Sie liefert einen Maßstab, anhand dessen das Scrum-Team seinen Einsatz zur Lieferung von Kundenwerten beurteilen und verbessern kann. Sprint Syl_ID_6.2 itedas Scrum Practitioner Open Base Syl. 2.1

Vorhersage dessen, was im Sprint geleistet werden kann
Situation 1: Das Team hat bereits einige Sprints abgeschlossen und kennt seine Velocity (Abarbeitungsgeschwindigkeit). Sprint 1 2 3 4 5 6 7 Story Points 20 70 80 100 120 110 mögliche Bandbreite für Schätzung 90%–110% Velocity-Annahme für Sprint 2 = ca. 20 Story Points Velocity-Annahme für Sprint 6 = ( ) / 4 = 93  83–102 Story Points Situation 2: Das Team startet gerade mit einer neuen Aufgabe. Suche nach einer ersten Referenz-Story mit etwa 1–10 einzelnen Tasks und einer Abarbeitungszeit von ca. 0,5–5 Tagen und Zuordnung einer Größe von 1–10 Story Points. User Stories sollten ca. 1 bis 20 Tasks umfassen. Jeder Task sollte in ca. 4 bis 16 Stunden abzuarbeiten sein. Eine User Story sollte in ca. 0,5 bis 10 Tagen abzuarbeiten sein. Syl_ID_6.2 itedas Scrum Practitioner Open Base Syl. 2.1

Zusammenfassung: Schätzen und Velocity
Schätzkonzepte Schätzen des relativen Arbeitsaufwands Elemente, die beschätzt werden Teamkapazität Velocity Schätzverfahren itedas Scrum Practitioner Open Base Syl. 2.1

Steuerungsaspekte Der Arbeitsplatz Die Kommunikation
Die Nachfolgeplanung Das Monitoring itedas Scrum Practitioner Open Base Syl. 2.1

konzentriertes Arbeiten
Der Arbeitsplatz Das Team soll möglichst in einem Raum sitzen, damit … die Kommunikation erleichtert wird (Face to Face). jeder mitbekommen kann, woran der andere arbeitet (osmotische Kommunikation). die Möglichkeit zu (Gruppen-)Diskussionen besteht. Wichtige Informationen (über das Projekt und die Leistungsfähigkeit) gut sichtbar darstellen. Der Arbeitsplatz sollte flexibel zu gestalten sein, um einen leichten Wechsel zwischen konzentriertem Arbeiten und offenen Diskussionen zu ermöglichen. diskutieren konzentriertes Arbeiten Agile flourishes when scrum team members work closely together in an environment that support the process. If at all possible the team should be collocated. Items listed in the slide are encouraged this way. Set up a dedicated area and remove distractions... Create an Agile Workspace Collocated, encourage Communicating face-to-face: Physically standing up Using simple communication tools Being aware of what others are working on: Getting clarifications from other team members Asking for help: Supporting others Big visible charts and Backlog Big white board entspannen informieren itedas Scrum Practitioner Open Base Syl. 2.1

Entwicklungsteam: Zusammenarbeit
Aufstellen von einzuhaltenden Teamregeln wie Pünktlichkeit etc. Der Product Owner ist kein Feind. Andere Teams sollen verstehen, was wir tun und dass wir sie benötigen. Wir alle arbeiten für das identische Ziel. Goldene Regel Wir wissen, dass jeder im Team jederzeit sein Bestes gibt, damit wir als Team erfolgreich sind. Kommunikationsregeln Wertschätzung des anderen Ich-Botschaften konkrete Situation ansprechen keine Schuldzuweisungen aktives Zuhören Lösungsorientierung Information Radiator Task Board itedas Scrum Practitioner Open Base Syl. 2.1

Nachfolgeplanung – Succession Planning
Zielsetzung – Beantwortung der Frage: Wie bleibt das Know-how im Team? Ergebnis: Absicherung des Projektverlaufs durch … Erhöhung des Bus-Faktors und damit … Verhinderung/Minimierung von Eng- pässen aufgrund von Urlaub, Krankheit etc. Maßnahmen: Paarprogrammierung maximale Transparenz bessere Kommunikation (Stand-up-Meetings etc.) echte Miteigentümerschaft (Co-ownership) am Code Bus-Faktor Kritische Größe, die aussagt, wie viele Teammitglieder ausfallen dürfen, ohne dass das Projekt dadurch zum Erliegen kommt. Syl_ID_7.5 itedas Scrum Practitioner Open Base Syl. 2.1

Monitoring: Mögliche Kennzahlen
Prognostizierbarkeit Burn Down Rate Velocity automatische Tests Qualität Sprint Goal Success Rate Fehler im Test gefundene Fehler durch Anwender gefundene Fehler (Escaped Defects) Technical Debt (technische Schulden) Information Radiator: KPIs (Key Performance Indicators) Wert/Nutzen Kundenzufriedenheit Business Value Delivered Lean Durchlaufzeit Work in Progress Task Board Niko-niko-Kalender Technical Debt = schlechte technische Umsetzung Arbeitsmoral (Niko-niko-Kalender) Scrum-Team Syl_ID_7 / Syl_ID_7.6 / Syl_ID_7.7 / Syl_ID_9.1 itedas Scrum Practitioner Open Base Syl. 2.1

Information Radiator: Wichtiges im Blick
Allgemeiner Ausdruck für eine Darstellung von Informationen, die das Scrum-Team zur Selbststeuerung benötigt. einfach/leicht verständlich aktuell nur so lange sichtbar, wie das Thema aktuell ist soll das Team beeinflussen, Ungewünschtes zu ändern und Gewünschtes beizubehalten gut sichtbar „weniger ist mehr“ Information Radiator: KPIs (Key Performance Indicators) Information Radiator: Simple: A chart or graph should not require minutes or hours of study. Ensure it is brief and concise. Anything dense or complicated will fail to communicate. Also, don't use highly derivative, biased, weighted information. Simple facts speak more profoundly than clever algorithms. Current: Any information that is not kept current is quickly ignored. Information more than a few days old is too stale to have evocative powers. Preferably: real time updates or end-of-day updates. Transient: Radiators that only expose problems shouldn't be up there long, otherwise it's clear that you aren't solving your problems. Once it's clear the team has gotten the message, and things are back on track, take down the info. Influential: A good information radiator influences the team's daily work. It may also influence managers, customers, developers, or other stakeholders. Highly visible: An effective information radiator needs to not only have information on it, but must transfer it to team members, stakeholders, and passers-by. Minimal in number: Having too many graphs or charts will cause all of the charts to lose evocative power. Also, exposing too many problems on the wall at one time can demoralize any team, so choose either the most important, timely, or fixable problem to highlight, and defer the rest. [based on Information Radiator at agileinaflash.blogspot.nl] ---- Quelle: :22: "Information radiator" is the generic term for any of a number of handwritten, drawn, printed or electronic displays which a team places in a highly visible location, so that all team members as well as passers-by can see the latest information at a glance: count of automated tests, velocity, incident reports, continuous integration status, and so on. Also Known As a related term, nearly synonymous, is "Big Visible Chart" more generally, one speaks of "informative workspaces" Expected Benefits Intensive use of information radiators conveys two messages in addition to the information itself: the team has nothing to hide from its visitors (customers, stakeholders...) the team has nothing to hide from itself: it acknowledges and confronts problems The main benefit of the practice is therefore to promote responsibility among the team members. A secondary benefit is that information radiators tend to provoke conversation when outsiders visit, which can yield useful ideas. Origins 1980s: the notion of "visual control" originating in the Toyota Production System is an anticipation of "information radiators" 1999: the term "Big Visible Chart" is coined by Kent Beck in "Extreme Programming Explained", though later attributed by Beck to Martin Fowler 2001: the term "information radiator" is coined by Alistair Cockburn ( , part of an extended metaphor which equates the movement of information with the dispersion of heat and gas Herkunft des Begriffs: 1980: Toyota Production System „Visual Control“ 1999: „Big Visible Chart“ im Buch „Extreme Programming“ von Kent Beck 2001: „Information Radiator“ geprägt von Alistair Cockburn (amerikanischer Informatiker) als Teil einer Metapher, die die Verbreitung von Informationen mit der Ausbreitung von Gas und Wärme gleichsetzt Syl_ID_7.7 itedas Scrum Practitioner Open Base Syl. 2.1

tägliche Aktualisierung
Das Task Board Sprint Goal Das Tor zur Welt Stories Sprint Backlog Items Tasks To Do Tasks In Progress Stories/Tasks Done 2 fest 1 fest 3 tägliche Aktualisierung Syl_ID_7.2 itedas Scrum Practitioner Open Base Syl. 2.1

Technische Praktiken zur Umsetzung des Tasks
gemeinsame Code-Eigentümerschaft Programmierstandard Pair Programming … kontinuierliche Code Integration kontinuierliches Refactoring itedas Scrum Practitioner Open Base Syl. 2.1

Sprint Goal Success Rate
Jeder Sprint sollte (mindestens) ein funktionierendes Produkt-Inkrement liefern, welches folgende Anforderungen erfüllt: erfüllt das Sprint Goal entspricht der Definition of Done (DoD), ist also entwickelt, getestet, integriert und dokumentiert © Kzenon - Fotolia.com Done Items Sprint Goal Success Rate = Sprint Backlog Items Syl_ID_7 itedas Scrum Practitioner Open Base Syl. 2.1

Kleine Bugs – große GAUs
Ein paar falsche Zahlen oder Zeilen, und schon passiert es: Intel-Pentium-Bug bei Gleitkommadivision: 400 Mio. US-Dollar Schaden Konvertierung von 64-Bit-Gleitkommazahlen in 16-Bit-Integerzahlen: Explosion Ariane 5 (1996) „Punkt“ statt „Komma“ programmiert: verloren gegangene Venussonde Mariner 1 (1962) Quelle: :42 Der Pentium-Bug Einer der bekanntesten Katastrophen in der Computerindustrie war wohl der Pentium Bug von Intel. Die Kosten dieses Hardwareproblems beliefen sich auf mehr als 400 Millionen U.S. Dollar. Aus dem White Paper des Konzerns zum Problem ist zu entnehmen, dass es bei bestimmten Eingaben zu kleinen Fehlern bei Gleitkommazahlendivision kommt. Intel hat lange Zeit behauptet, dass kein Fehler existiere und später zugegeben, dass der Fehler bei einer von 9 Milliarden Eingaben zustande käme, was den Halbleiterkonzern nicht davor bewahrt hatte Ersatz für den Fehlerhaften Chip zu liefern. Das Problem war, dass der von Intel benutzte Divisions-Algorithmus einen ,,look-up table`` mit 1066 Einträgen benutzt. Durch einen Fehler in einer For-Schleife, kam es bei der Übertragung der Koeffizienten in den PLA (Programmable Logic Array), nur zur Übertragung von 1061 Werten, was bei bestimmten Eingaben zu Rechenungenauigkeiten von vier Stellen hinter dem Komma führt. Solche oder ähnliche Fehler führten auch schon in der Vergangenheit zu Problemen. Die bislang schwerste Computerpanne in der Medizin, gab es in einem medizinischen Bestrahlungsgerät gegen Krebsleiden, genannt Therac-25. In Kanada kam es deshalb zu mehreren Todesfällen wegen zu hoher Strahlendosen. Der Grund hierfür war mangelnde Qualitätssicherung der Softwareentwickler für das Gerät. Ein umfangreicheres Simulationsprogramm hätte die Fehler vermutlich frühzeitig entdecken können. Bei der ersten Venus Mission der NASA in 1962 hat man fälschlicherweise einen Punkt statt einem Komma im FORTRAN-Code der Mariner 1 benutzt, was zum Absturz der Sonde führte. Auf dem Kriegsschiff USS Yorktown hat 1998 ein Eingabefehler eine Division durch Null hervorgerufen, was zur Folge hatte, dass das Schiff stundenlang manövrierunfähig im Meer herumtrieb. Die Ariane 5 Explosion Die Ariane 5 Explosion im Jahre 1996 bescherte der europäischen Raumfahrt einen herben Rückschlag. Die Weiterentwicklung der Ariane 4 sollte den Europäern die Führung im Weltraumfrachtgeschäft sichern. Der wirtschaftliche Schaden belief sich hier auf mehr als 500 Millionen U.S. Dollar, da die Neuentwicklung der Ariane zwei, drei Tonnen schwere, wissenschaftliche Satelliten an Bord hatte. Ein unscheinbarer Bug, mit dem sicher jeder Informatikstudent im ersten Semester fertig werden muss, führte hier etwa 30 Sekunden nach dem Abheben zur Katastrophe. Eine Untersuchungskommission fand nach kurzer Zeit heraus, dass ein Konvertierungsfehler zur Explosion führte. Die Steuerung der Rakete wurde von einem Bordcomputer übernommen. Einige Zeit nach dem Start begann das sog. Trägheitskontrollsystem wirre Daten an den Bordcomputer zu senden. Eigentlich lieferte das System 64-Bit Gleitkommazahlen zur horizontalen Beschleunigung der Rakete, in Relation zur Startplattform. Mittlerweile empfing der Bordcomputer aber nur noch Fehlermeldungen von der Trägheitskontrolle, mit denen er aber nichts anfangen konnte, und das System abschaltete. Der Grund dafür war, dass ein kleines Unterprogramm der Trägheitskontrolle versuchte 64-Bit Gleitkommazahlen in 16-Bit Integer Zahlen, welche bekanntermaßen Zahlen kleiner plus Vorzeichen speichern können, zu konvertieren. Dies geschah, da die Raketeningenieure dachten, dass die Integergrenze bei diesen Operationen nicht erreicht werden könnte. Dies war zu Zeiten von Ariane 4 wohl noch korrekt, die neuentwickelte Ariane 5 war allerdings schneller. Sekundenbruchteile nach der Abschaltung der Trägheitskontrolle nahm ein redundantes System seine Arbeit auf. Dieses versagte ebenfalls, da die aufgespielte Software identisch mit der des Hauptsystems war. Zu aller Letzt wurde die automatische Selbstzerstörung der Rakete eingeleitet, da der Druck auf die Booster wegen fehlender Kurskorrekturen so groß wurde, dass sie abzubrechen drohten. Numerische Rechenfehler sind oftmals Ursachen für verheerende Unfälle. Nicht nur die Arianemission fand deshalb ihr vorzeitiges aus. Während des ersten Golfkrieges 1991, kam eine amerikanische Flugabwehrrakete wegen Rechenungenauigkeiten vom Kurs ab und traf ein U.S. Camp. Bei dem Unglück kamen 28 Soldaten ums Leben. Eine peinliche Stunde für die amerikanische Weltraumorganisation NASA gab es, als bekannt wurde warum sie den Mars Climate Orbiter verlor: Ein beteiligtes Entwicklungsteam benutzte die in der Wissenschaft üblichen metrischen Einheiten, wobei ein anderes Team englische Einheiten (wie etwa Zoll) benutzte. Die Inkompatibilität führte letztlich zum Verlust der Sonde. Das Unterfangen kostete die NASA nach eigenen Angaben ca. 125 Millionen US Dollar. „cm“ statt „Zoll“: Rakete verfehlt Ziel (Golfkrieg 1991) Syl_ID_7 itedas Scrum Practitioner Open Base Syl. 2.1

Escaped Defects verursachen große Kosten: ca. 84,4 Mrd. Euro* betragen die jährlichen Verluste durch Softwarefehler in Mittelstands- und Großunternehmen. Nicht entdeckte Fehler werden durch den Anwender gefunden (=> Maßzahl für die gelieferte Qualität). Planung Analyse Entwurf Program- mierung Testen Betrieb Kosten * Quelle: Zahlen aus dem Jahr 2006 Syl_ID_7 / Syl_ID_9.1 itedas Scrum Practitioner Open Base Syl. 2.1

Escaped Defects Chart Sprint
Syl_ID_7 / Syl_ID_9.1 itedas Scrum Practitioner Open Base Syl. 2.1

Testen am Ende funktioniert nicht, weil
Feedback, auf das reagiert werden sollte, erst sehr spät kommt. die gleichen Fehler immer wieder gemacht werden, ohne dass sie erkannt werden. der Projektstatus (aufgrund der nicht erkannten Fehler) kaum festzustellen ist. die Zeit für ausreichendes Testen eher dem Go-Live-Termin geopfert wird. es schwer ist, die Qualität eines fertigen Produktes im Nachhinein zu verbessern. itedas Scrum Practitioner Open Base Syl. 2.1

Technical Debt (technische Schulden)
„Wenn man das erste Mal Code ausliefert, dann ist das, als würde man sich verschulden. Ein paar kleine Schulden beschleunigen die Entwicklung, solange sie pünktlich mit einer Überarbeitung zurückgezahlt werden … Gefährlich wird es, wenn die Schulden nicht zurückgezahlt werden …“ Ward Cunningham 1992 Technical Debt bezeichnet alle Abstriche, Defizite und Mängel der Software wie: unpassendes Design Defekte und bekannte Probleme übermäßiges manuelles Testen, wenn automatische Tests verfügbar sind unzureichende Testabdeckung schlechtes Integrations- und Release-Management („Jugend forscht“) mangelnde Plattformerfahrung (fehlende COBOL-Kenntnisse) … Syl_ID_9.2 itedas Scrum Practitioner Open Base Syl. 2.1

Die Folgen technischer Schulden (Technical Debt)
sinkende Kundenzufriedenheit große Zahl an Defekten steigende Entwicklungs- und Supportkosten Leistungseinbruch (sinkende Velocity) Ursache: Da die Schulden in Form von Bug Fixes abgebaut werden müssen, sind bei ansteigenden Schulden immer mehr Ressourcen dafür aufzuwenden. Syl_ID_9.2 itedas Scrum Practitioner Open Base Syl. 2.1

Technische Schulden: Ursachen
Druck, Deadlines zu erreichen erfolglose Versuche der Velocity-Beschleunigung Reduzierung des Testumfangs Anhäufung von Schulden Zur Grafik: Der Release-Backlog ist für Release 1 und 2 gleich groß. Bei der Abarbeitung des Backlog für Release 1 zweigt sich, dass es bei der möglichen Entwicklungsgeschwindigkeit nicht möglich ist, das Release zum Wunschtermin (Vorgabe durch das Business) nicht fertig wird. Daraus resultiert ein Termindruck, der zur Anhäufung von technischen Schulden (durch mangelndes Testen, schludrige Arbeit etc.) führt. Aufgrund der notwendigen Bug-Fixes für Release 1 sinkt die Abarbeitungsrate des Backlog für Release 2. Ein erneuter Termindruck resultiert in einem Anwachsen der technischen Schulden. Release-Backlog Sprint 1 … n Sprint n+1 … m Syl_ID_9.2 itedas Scrum Practitioner Open Base Syl. 2.1

Umgang mit technischen Schulden
Technische Schulden müssen organisiert werden! Verwalten und überwachen Einsatz von bewährten Techniken wie: einfaches Design Test-Driven Development kontinuierliche Integration automatisiertes Testen Refactoring … starke Definition of Done Verstehen der wirtschaftlichen Aspekte Sichtbar machen geschäftliche Ebene technische Ebene (Technical Debt Backlog) Abbauen nur die lohnenswerten die, die man bei der Arbeit an neuen Inkrementen gerade findet Ticketing-Tool (Incidents, Problems, Changes) Technical Debt Backlog Product Backlog Syl_ID_9.2 itedas Scrum Practitioner Open Base Syl. 2.1

Information Radiator: Delivered Story Points
Syl_ID_7.1 itedas Scrum Practitioner Open Base Syl. 2.1

Sprint Burn-down Chart
30 Story Points 25 20 15 10 5 1 2 3 4 5 6 7 8 9 10 Tage Syl_ID_7.1 / Syl_ID_7.3 itedas Scrum Practitioner Open Base Syl. 2.1

Release Burn-down Chart
300 Story Points 250 200 150 100 50 1 2 3 4 5 6 7 8 9 10 11 Sprints Syl_ID_7.1 itedas Scrum Practitioner Open Base Syl. 2.1

Burn-down Bar Chart Product Backlog - 50 Points 300 Story Points
Velocity = 300 Points/7 Sprints = 43 Points/Sprint Backlog = 50 Points 250 200 + 100 Points 150 100 300 Points 50 Burn-down bars can show the changes in the Product Backlog better than normal burn-down charts. Completion of the items will be applied to the top of the bars and adding or removing items in the Product Backlog will be reflected to the bottom of the bars. Product Backlog 1 2 3 4 5 6 7 8 9 10 11 Sprints -50 -100 Syl_ID_7.1 itedas Scrum Practitioner Open Base Syl. 2.1

Burn-up Chart Product Backlog 400 350 - 50 Points
Velocity = 300 Points/7 Sprints = 43 Points/Sprint Backlog = 50 Points 300 Story Points 250 200 + 100 Points 150 100 300 Points 50 Product Backlog 1 2 3 4 5 6 7 8 9 10 11 Sprints Syl_ID_7.1 / Syl_ID_7.4 itedas Scrum Practitioner Open Base Syl. 2.1

Business Value Chart It’s a good idea to monitor the amount of business value created in each Sprint. It usually goes down, and it’s a good idea to stop the project when the output is not valuable enough. Syl_ID_7.1 itedas Scrum Practitioner Open Base Syl. 2.1

Zusammenfassung: Scrum-Steuerungsaspekte
Der Arbeitsplatz Die Kommunikation Die Nachfolgeplanung Das Monitoring itedas Scrum Practitioner Open Base Syl. 2.1

Scrum skalieren Vertikale/horizontale Skalierung
Neue Entwicklungsteams bilden Arbeiten in komplexen/großen Projekten Release Train Verteilte Teams Frameworks zur Skalierung von Scrum itedas Scrum Practitioner Open Base Syl. 2.1

Vertikales/horizontales Skalieren von Scrum
Aufbau weiterer Scrum-Teams zur Entwicklung verschiedener Produkte vertikales Skalieren Vertikales Skalieren bedeutet der Aufbau weiterer Entwicklungsteams, um komplexere/umfangreichere Produkte entwickeln zu können. Horizontales Skalieren bedeutet den Aufbau von weiteren Scrum-Teams, um verschiedene Produkte entwickeln zu können. Bei der horizontalen Skalierung geht es insbesondere auch darum, das Verständnis und Vorgehen über alle Scrum-Teams hinweg ausreichend zu harmonisieren, um u.a. die Teammitglieder ohne große Reibungsverluste je nach Anforderung in einzelnen Projekten mitarbeiten lassen zu können. Vertikales Skalieren Aufbau weiterer Entwicklungsteams, um ein komplexes Produkt entwickeln zu können Syl_ID_8.3 itedas Scrum Practitioner Open Base Syl. 2.1

Vertikales Skalieren: Neue Entwicklungsteams bilden
Vollständig neues Team Grow-and-Split-Modell Split-and-Seed-Modell Vollständig neue Teams Voraussetzungen: Die Organisation verfügt über einen hohen Reifegrad („is mature“) in der Anwendung von agilen Konzepten. Problem: Die neuen Teams kennen sich im Thema nicht gut aus und sind daher zu Beginn ineffizienter. Grow-and-Split-Modell Auffüllen des Originalteams mit neuen Mitgliedern bis zum Maximum. Nach Know-how-Transfer Aufteilung in zwei Teams. Sinnvoll einzusetzen beim Übergang aus einem Pilotprojekt in ein Produktivprojekt Vorteile: Das Originalteam bleibt erhalten. Das vorhandene Wissen wird in alle neuen Teams eingebracht. Die Teamentwicklung läuft mit weniger Problemen. Nachteil: Zeitaufwendig (wenn mehr als 2 Teams gebildet werden sollen) Split-and-Seed-Modell Aufteilung des Erstteams in benötigte Anzahl von Teams und Auffüllen der neuen Teams mit Ressourcen Vorteil: Nachteile: Das Originalteam existiert nicht mehr. Aufwand für Teambildung Syl_ID_8.3 / Syl_ID_10.3 / Syl_ID_10.4 itedas Scrum Practitioner Open Base Syl. 2.1

Arbeiten in komplexen/großen Projekten
Produkt 1 Produkt 1 Product Owner (ggf. für einzelne Module) 1 Product Backlog M Scrum Master (einer pro Team oder einer für mehrere Teams) N Entwicklungsteams Ort A DoR DoD Ort B Definition of Ready (DoR) und Definition of Done (DoD) müssen für alle Teams soweit wie sinnvoll übereinstimmen, damit die Qualität des Produktes gewährleistet werden kann. Hinweis: die Farbkodierung (rot, gelb, grün) zieht sich über die nächsten Folien durch und erklärt bestimmte Themen des Zusammenarbeit/Team-Koordination. Syl_ID_8.1 / Syl_ID_8.2 itedas Scrum Practitioner Open Base Syl. 2.1

Scrum of Scrums: Teamübergreifende Koordination
Fragen, die von jedem Vertreter der Entwicklungsteams zu beantworten sind: Was hat mein Team seit dem letzten Treffen geleistet, das die anderen Teams beeinflussen könnte? Was wird mein Team vor dem nächsten Treffen tun, das die anderen Teams beeinflussen könnte? Bei welchen Problemen meines Teams könnten die anderen Teams helfen? Scrum of Scrums Hinweis: „Koordination“ meint im Ggs. Zur „Synchronisation“ eine häufigere Abstimmung der Teams (vergl. Thema Release Train). dient zur teamübergreifenden Koordination findet bei Bedarf einige Male in der Woche statt ist auf 15 Minuten begrenzt (=> Koordination) Problemlösungen können, wie beim Daily Scrum, im direkten Anschluss stattfinden Syl_ID_8.1 itedas Scrum Practitioner Open Base Syl. 2.1

Release Train: Teamübergreifende Synchronisation
Sprints Sprints Releaseplanung Inspect & Adapt Releaseplanung Inspect & Adapt Alle Sprints haben die gleiche Länge. Bei der Release Planung kommen alle(!!) Teammitglieder zusammen (=> u.U. wird ein sehr großer Raum benötigt) Syl_ID_8.2 itedas Scrum Practitioner Open Base Syl. 2.1

Release Train: Regeln Planungs- und Release-Termine finden häufig und regelmäßig statt. Termine und Qualität sind fest vorgegeben, der Umfang ist variabel. Es werden dazwischenliegende globale und objektive Meilensteine etabliert. Alle Teams arbeiten mit der gleichen Sprint-Dauer. Auf der obersten oder Systemebene sowie auf den Funktions- und Komponentenebenen wird eine kontinuierliche Integration implementiert. Die Release-Inkremente stehen in regelmäßigen Intervallen (z. B.: alle 3 oder 6 Sprints) zur Voransicht zur Verfügung („Review“). Spezielle Sprints können zur Reduzierung von technischen Schulden genutzt werden. Damit Teams auf ähnlichen Konstrukten aufbauen können, sind entsprechende Vorarbeiten notwendig. Syl_ID_8.2 itedas Scrum Practitioner Open Base Syl. 2.1

Verteilte Teams virtuelle Zusammenarbeit (Tools!)
abgestimmte Arbeitszeiten (insbesondere bei verschiedenen Zeitzonen) Face-to-Face-Kommunikation an wichtigen Punkten wie Kick-off-Meeting Planungsphase; insbesondere Releaseplanung Team HH Team M Core Hours are the hours when everyone can commit to being in the (virtual) team space. In this example there are only 1.5 ‘core hours’ in the afternoon (3 PM - 4:30). A core schedule helps to set a sense of balance and cohesiveness. One of the biggest challenges to overcome when implementing Scrum within a distributed team environment is that of communication. As you may be aware, within a formal Scrum environment, everyday person-to-person conversation is a valued part of the process. Consequently, it is important to have that face-to-face time during vital points in the project - such as the beginning, planning phase of the project. Release Planning should be collocated. At this time, all of the team members can get acquainted with one another. As a result of working directly with one another, a sense of cohesiveness can develop. itedas Scrum Practitioner Open Base Syl. 2.1

Frameworks zur Skalierung von Scrum
Wenn mehrere Scrum-Teams zusammen ein integriertes Inkrement erzeugen, so ist Nexus das Exoskelett, welches auf den Teams ruht. Nexus ist konsistent zu Scrum, und seine Teile werden denen bekannt vorkommen, die schon in Projekten mit Scrum gearbeitet haben. Download: Das Scaled Agile Framework kombiniert Ansätze aus den agilen Methoden Scrum, Kanban und Extreme Programming mit Lean Thinking sowie den von Donald Reinertsen formulierten Prinzipien zum Lean Product Development und ermöglicht es so, Agilität im Enterprise-Umfeld und im großen Maßstab anzuwenden. Download: Syl_ID_8.4 itedas Scrum Practitioner Open Base Syl. 2.1

Zusammenfassung: Scrum skalieren
Vertikale/horizontale Skalierung Neue Entwicklungsteams bilden Arbeiten in komplexen/großen Projekten Release Train Verteilte Teams Frameworks zur Skalierung von Scrum itedas Scrum Practitioner Open Base Syl. 2.1

Scrum einführen Grundlegendes Vorgehen Reaktion auf Änderungen
Coaching Teamdynamik itedas Scrum Practitioner Open Base Syl. 2.1

Nutzen durch Agilität und Scrum
Businessnutzen mehr Nutzen in weniger Zeit agiles Änderungsmanagement, getrieben durch Business und Markt zum Nutzen des Kunden schnellere Markteinführung (Time-to-Market-Reduzierung) Menschen Selbstorganisierende, funktionsübergreifende Teams mit Entscheidungsbefugnissen sind motivierter und bringen bessere Ergebnisse in kürzerer Zeit. Prozesse schlanke Prozesse ohne unnötigen Overhead Reduzierung von Verschwendung (Waste) im Sinne von Lean Management höhere Qualität itedas Scrum Practitioner Open Base Syl. 2.1

Auf dem Weg zum agilen Unternehmen
Experimentier- phase Akzeptanz- phase Kulturschock Anpassungen (Organisation, Methode) Leitlinien und Dokumentation Nutzung nichtagiles Unternehmen agiles Unternehmen Pilot Adaption Nutzung Scope und Zielsetzung: ausgesuchte Abteilungen Projekte mit geringem Risiko lernen, wie Agile in der Organisation funktionieren könnte Scope und Zielsetzung: ausgesuchter vollständiger Bereich alle Projekte vollständige gegenseitige Anpassung von Methode und Organisation Darstellen von unternehmensweit gültigen Leitlinien, Dokumenten und Tools Inspect & Adapt Inspect & Adapt Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Grundlegendes Vorgehen bei der Einführung
Die Einführung von Scrum sollte im Rahmen eines agilen Projektvorgehens erfolgen. Pilotierung Ausbildung des Teams Coaching durch einen erfahrenen Scrum Master Klärung und Verteilung der Rollen Start mit einem ersten Projekt mit ersten positiven Ergebnissen (Quick Wins, Low Hanging Fruits) Schritt für Schritt: Anpassung und Änderung der Organisations- und Projektkultur Vorsicht vor Waterfallacies („Wasserfällern“) oder Agile Phobias (Agilo-Phobikern)! Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Enterprise Transition Community (ETC)
Scrum-Team, das die Transition hin zu agilem Vorgehen in einem Unternehmen durchführt Dieses Team arbeitet nach Scrum, produziert aber keine Software. Es liefert Organisationsveränderung in kleinen Schritten je Sprint. Inspect & Adapt Inspect & Adapt Awareness Bewusstsein, dass die aktuelle Herangehensweise (die Prozesse) nicht akzeptable Ergebnisse liefert Desire Das Verlangen, mit Scrum die aktuellen Probleme zu lösen Ability Die Fähigkeit, mit Scrum erfolgreich zu sein Promotion Bewerben von Scrum durch die Weitergabe von Erfahrungen, damit alle unsere Erfolge erkennen Transfer Übertragung der Anwendungsmöglichkeiten von Scrum auf alle Bereiche des Unternehmens Syl_ID_10.1 / Syl_ID_10.2 itedas Scrum Practitioner Open Base Syl. 2.1

Reaktion auf Änderungen
7. Integration 3. rationale Einsicht 5. Lernen 2. Ablehnung 6. Erkenntnis Quelle :05: 1. Schock wahrgenommene eigene Kompetenz 4. emotionale Akzeptanz Zeit Syl_ID_10.5 itedas Scrum Practitioner Open Base Syl. 2.1

Agile Praktiken einführen
Collective Code Ownership (kollektives Eigentum am Code) Pair Programming Test-Driven Development agiles Software-Configuration-Management (SCM) kontinuierliche Code Integration (Continuous Integration) kontinuierliches Refactoring (Continuous Refactoring) nachhaltige Entwicklungsgeschwindigkeit (Sustainable Pace) Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Collective Code Ownership (kollektives Eigentum am Code)
Niemand ist „Eigentümer“ eines Stücks Codes. Die Verantwortung liegt beim gesamten Entwicklungsteam. Jeder kann jeden Code ändern. daraus folgt: Stärkung der Zusammenarbeit im Team Fokussierung auf das Produkt bessere Code-Qualität (Verständlichkeit, „aus einem Guss“) 'get all text from current slide allText = titleLine For Each textShape In s.Shapes If textShape.HasTextFrame Then allText = textShape.TextFrame.TextRange If InStr(1, textShape.TextFrame.TextRange, Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

„Watch-the-Master“-Phänomen
Pair Programming Zwei Entwickler arbeiten gemeinsam am Code (ein Bildschirm, eine Tastatur). Die Lösung wird diskutiert und gemeinsam entworfen. Variante: Wer eine Idee hat, gibt die Tastatur ab. führt zu weniger Fehlern und zu höherer Qualität (4-Augen-Prinzip) fördert die Teambildung (und durch wechselnde Paare die „Collective Code Ownership“) erhöht die Motivation unterstützt das Lernen wichtig für: Successor-Planung („Bus-Faktor“) Problem: „Watch-the-Master“-Phänomen Ein potenziell auftretender Effekt, dass nur einer arbeitet, der andere nur zuschaut und KEIN Wissenstransfer stattfindet. Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Test-Driven Development (TDD)
TDD-Vorgehensweise: Programmierung erfolgt in Mikroiterationen TDD ist KEIN Testprozess, sondern eine Entwicklungsmethode Verständnis des Tests fördert Verständnis der zu erstellenden Funktion kontinuierliches Testen und Verbessern hoher Grad der Automatisierung und der Testabdeckung Einbeziehung des Kunden Start Schreibe Test! Schreibe/ändere den Programmcode, bis der Test bestanden wird! Räume den Code auf (Refactoring)! Ende Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Software Configuration Management (SCM)
Zielsetzung Sicherstellen der Integrität eines Produktes Erkennen und Beherrschen von Änderungen Code Repository Entwickler 1 Entwickler 2 X Code zusammengeführt Code geändert Code gesperrt Code nicht gesperrt Check- out Check- in Check-in Software configuration management (SCM) is known as a method of bringing control to the software development process, and thus, proper application of SCM is a key component in the development of quality software. FDD and DSDM take software configuration management explicitly into account. In FDD, SCM is one of the method's "best practices" that among others needs to be included in order to obtain the greatest benefit from the method. XP's approach to SCM can be seen as implicit. The method does not require software configuration management to be conducted. However, there is a practice in XP depicted on the next slide that can be considered good practice. In Scrum it is not explicitly addressed. Empfehlung: Check-in am Ende jedes Tages! Nimm Probleme ernst und behandle sie im Team! Führe so oft wie möglich zusammen! Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Kontinuierliche Code Integration
Zielsetzung kontinuierliche Steigerung der Softwarequalität ständige Verfügbarkeit eines lauffähigen Standes für Demo-, Test- oder Vertriebszwecke Vorgehen Codeänderungen werden möglichst früh und einfach in Codebasis übernommen. Generierung, Test und Deployment werden weitgehend automatisiert. Schnelle und einfache Bereitstellung neuer Programmversionen z. B. durch „nightly builds“. Vorteile Integrationsprobleme werden laufend entdeckt und behoben – nicht erst kurz vor einem Meilenstein. Inkompatibilitäten werden früh erkannt und können zeitnah beseitigt werden. Die sofortige Reaktion des Systems auf das Einchecken eines fehlerhaften oder unvollständigen Codes „erzieht“ die Entwickler im positiven Sinne zu einem verantwortlicheren Umgang und kürzeren Check-in-Intervallen. Empfehlung: mindestens täglich. Geringer Merge-Aufwand, da der Merge-Aufwand größer wird, je länger man mit der Integration wartet. Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Kontinuierliches Refactoring
Beim Refactoring geht es um die Verbesserung der nichtfunktionalen Eigenschaften des Codes, also der internen Struktur und Eigenschaften ohne Änderung von Funktion oder Außenverhalten. Refactoring Erhöhung der Lesbarkeit Reduzierung von Komplexität Verbesserung der Wartbarkeit Verbesserung der Ausbaubarkeit Verbessere kontinuierlich! Je früher, desto besser! Code refactoring is the process of restructuring existing computer code – changing the factoring – without changing its external behavior. Refactoring improves nonfunctional attributes of the software. Advantages include improved code readability and reduced complexity to improve source code maintainability, and create a more expressive internal architecture or object model to improve extensibility. Typically, refactoring applies a series of standardized basic micro-refactorings, each of which is (usually) a tiny change in a computer program's source code that either preserves the behavior of the software, or at least does not modify its conformance to functional requirements. Many development environments provide automated support for performing the mechanical aspects of these basic refactorings. There are two general categories of benefits to the activity of refactoring. Maintainability. It is easier to fix bugs because the source code is easy to read and the intent of its author is easy to grasp Extensibility. It is easier to extend the capabilities of the application if it uses recognizable design patterns, and it provides some flexibility where none before may have existed. Extensibility is a software design principle defined as a system’s ability to have new functionality extended, in which the system’s internal structure and data flow are minimally or not affected, particularly that recompiling or changing the original source code is unnecessary when changing a system’s behavior, either by the creator or other programmers Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Nachhaltige Entwicklungsgeschwindigkeit
Die Entwicklungsgeschwindigkeit soll sich auf einem nachhaltigen Niveau einpendeln. Unter der Voraussetzung stabiler Teams und vergleichbarer Aufgaben … kann die Entwicklungsgeschwindigkeit vom Team über lange Zeit ohne Überforderung gehalten werden (Zielerreichung z. B. ohne Überstunden). ist die Entwicklungsgeschwindigkeit stabil  gute Planbarkeit. ist gewährleistet, dass alle Prozesse etabliert sind und reibungslos laufen. liegt die Produktivität auf einem hohen Niveau (besser als vor/während der Einführung der agilen Methoden). nachhaltige Entwicklungsgeschwindigkeit = keine Überlastung des Teams Syl_ID_10 itedas Scrum Practitioner Open Base Syl. 2.1

Klärung der Ziele der Organisation
Coaching Zielsetzung Abholung Training Coaching autarke Umsetzung Klärung der Ziele der Organisation Abholung und Motivation des Teams Feststellung des (ersten) Trainingsbedarfs Training des Teams (Grundlagen und rollenspezifisches Training) Teambildung Teamgeist, Kommunikation und Motivation die Fähigkeit zur konstruktiven Diskussion Arbeitsklima Produktivität (Effizienz und Effektivität) Teamrollen Begleitung bei Umsetzung und Einübung (Kommunikation, konstruktive Diskussion, Arbeitsklima, Teamrollen), Problem- und Konfliktlösungen Zu erwartender Widerstand gegen Änderungen Bewahrer (Conservers) 25% bevorzugen Änderungen ohne Strukturänderungen wollen Sicherheit/Vorhersagbarkeit honorieren Traditionen und eingeführte Praktiken Pragmatiker (Pragmatists) 50% bevorzugen praktische Änderungen sind offen für beide Seiten eines Arguments mehr fokussiert auf Ergebnisse als auf Strukturen Erschaffer/Macher (Originators) 25% bevorzugen Änderungen, die aktuelle Strukturen infrage stellen stellen akzeptierte Annahmen infrage nehmen wenig Rücksicht auf akzeptierte Vereinbarungen Syl_ID_10.5 itedas Scrum Practitioner Open Base Syl. 2.1

Teamdynamik Performing (Arbeitsphase) Norming (Regelphase)
Geprägt durch Arbeitsorientierung, Flexibilität, Offenheit der Teammitglieder, Solidarität, Leistungsausrichtung und zielgerichtetes Handeln des Teams. Die Führungskraft gibt lediglich Globalziele (Visionen) vor und benötigt wenig Energie, da das Team sich größtenteils selbst steuert. Der Scrum Master sorgt für die Aufrechterhaltung der Standards. Norming (Regelphase) Geprägt durch die Entwicklung neuer Gruppenstandards und neuer Umgangsformen, durch Feedback und Austausch zwischen den Teammitgliedern sowie eine „Wir“-Orientierung.  Der Scrum Master koordiniert die Entwicklung. Storming (Konfliktphase) Geprägt durch unterschwellige Konflikte, eine Selbstdarstellung der (neuen) Teammitglieder, Kampf um (informelle) Führung, „Ich“-Orientierung und Cliquenbildung.  Der Scrum Master lässt Raum und versachlicht Diskussionen. Forming (Formierungsphase) Geprägt durch Höflichkeit, ein vorsichtiges Abtasten, das Streben nach Sicherheit und das Kennenlernen.  Der Scrum Master führt und setzt Prioritäten. itedas Scrum Practitioner Open Base Syl. 2.1

Probleme im Team Anzeichen für Probleme Gerüchte tauchen auf
der Kommunikationsfluss nimmt ab Aufgaben bleiben liegen negative Emotionen nehmen zu mehr Krankmeldungen Unpünktlichkeit längere Entscheidungsprozesse Cliquenbildung Lösungsansatz Alle Parteien müssen an einer Konfliktlösung interessiert sein. Jeder stellt seinen Standpunkt dar. Gemeinsamkeiten werden ausgelotet. Alle bleiben fair. Alle sind bereit, Kompromisse einzugehen. Jeder unterbreitet Lösungsvorschläge. itedas Scrum Practitioner Open Base Syl. 2.1

Schwierigkeiten – Probleme – Konflikte
Lösung angemessene Herangehensweise unangemessene Herangehensweise Schwierigkeit Alltägliche Hindernisse Ressourcenprobleme Qualitätsprobleme … Beispiel: Wiederkehrender Ausfall eines Druckers. Die Anwender können zeitweise nicht drucken. Workaround: Nach einem Neustart des Druckers funktioniert er wieder für eine bestimmte Zeit. Aber eigentlich benötigt der Drucker die aktuelle Firmware für sein LAN-Interface, um den Fehler dauerhaft zu beseitigen. angemessene Herangehensweise unangemessene Herangehensweise Problem Hindernisse, die unlösbar scheinen fehlende Befugnisse fehlende Unterstützung … Beispiel: Niemand kümmert sich um die Beschaffung und Installation der aktuellen Firmware. Die Benutzer sind nachhaltig genervt. Konflikt Absichten, deren Verwirklichung nicht erfolgt (erfolgen kann) Beispiel: Das Update des Druckers wird aufgrund anderer Prioritäten immer wieder verschoben. Die Benutzer halten den Support für unfähig. itedas Scrum Practitioner Open Base Syl. 2.1

Ursachenanalyse Thema und Situation identifizieren und auf Ursache untersuchen Folgende Ursachen können unterschieden werden: Sachkonflikt: beruht auf einem Mangel an Information bzw. auf Fehlinformation Interessenkonflikt: beruht auf subjektiv oder objektiv verschiedenen Interessen zwischen Stakeholdern Wertekonflikt: beruht auf einer unterschiedlichen Wertschätzung eines Sachverhaltes Beziehungskonflikt: beruht auf (starken) negativen Emotionen zwischen Stakeholdern („Die können nicht miteinander.“) Strukturkonflikt: beruht auf ungleichen Macht- und Autoritätsverhältnissen vermischte Konfliktursachen: Bei vermischten Ursachen sollten alle Ursachen erkannt werden, um so eine geeignete Auflösungsstrategie wählen zu können. itedas Scrum Practitioner Open Base Syl. 2.1

Zusammenfassung: Scrum einführen
Nutzen durch Agilität und Scrum Grundlegendes Vorgehen Enterprise Transition Community (ETC) Reaktion auf Änderungen Agile Praktiken einführen Coaching Teamdynamik Probleme im Team itedas Scrum Practitioner Open Base Syl. 2.1

itedas Scrum Practitioner Open Base

Ähnliche Präsentationen

Präsentation zum Thema: "itedas Scrum Practitioner Open Base"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback

Anmelden

Anmeldung über soziales Netzwerk:

itedas Scrum Practitioner Open Base

Ähnliche Präsentationen

Präsentation zum Thema: "itedas Scrum Practitioner Open Base"— Präsentation transkript:

Ähnliche Präsentationen

Über Projekt

Feedback