Scrum Ursprung des Begriffs - Lothar Schulz...Scrum Ursprung des Begriffs Scrum contested between...

24
Scrum Ursprung des Begriffs Scrum contested between Newport and London Welsh in 1904, showing the more upright stance of the scrum used at the time. * * Rugby scrum 1904 Foto: Scanned by FruitMonkey, original author unknown Wikimedia Commons lpublic domian ( http://en.wikipedia.org/wiki/File:Rugby_scrum_1904.jpg#filelinks) Die Originaldatei ist hier (http://en.wikipedia.org/wiki/File:Rugby_scrum_1904.jpg) zu finden. Scrum - Gedränge [Rugby] Scum (NO ‚r‘ !) - Abschaum, Krätze, Schlacke

Transcript of Scrum Ursprung des Begriffs - Lothar Schulz...Scrum Ursprung des Begriffs Scrum contested between...

Scrum Ursprung des Begriffs

Scrum contested between Newport and London Welsh in 1904, showing the more upright stance of the scrum used at the time. *

* Rugby scrum 1904 Foto: Scanned by FruitMonkey, original author unknown•Wikimedia Commons lpublic domian (

http://en.wikipedia.org/wiki/File:Rugby_scrum_1904.jpg#filelinks) Die Originaldatei ist hier (http://en.wikipedia.org/wiki/File:Rugby_scrum_1904.jpg) zu finden.

Scrum - Gedränge [Rugby]Scum (NO ‚r‘ !) - Abschaum, Krätze, Schlacke

Scrum Übersicht

* Scrum Flow Foto: BkrehoffCreative Commons, lizenziert unter

GNU-Lizenz für freie Dokumentation ( http://creativecommons.org/licenses/by-sa/3.0/deed.de) Die Originaldatei ist hier (http://de.wikipedia.org/w/index.php?title=Datei:ScrumFlow.png) zu finden.

*

Scrum Motivation

TransparenzSelbstorganisationPull-Prinzip – Kontrolliere den Input

Entwicklungsteam organisiert selbständig wer welche Tasks bearbeitet

Timebox – GrenzenZeitliche Vorgaben durch Sprints / Zeitintervalle

Nutzbare Business FunktionalitätAm Ende der Timebox steht Lieferung eines potentiell auslieferungsfähigen Produkt(teil)es durch Team unter Beachtung der Standards, Richtlinien , den Vorgaben des Projektes

Scrum Motivation - Agile

AgileAgile software development is a group of software development methodologies based on iterative and incremental development, where requirements and solutions evolve through collaboration between self-organizing, cross-functional teams. *agilemanifesto.org:

Individuals and interactions over processes and toolsWorking software over comprehensive documentationCustomer collaboration over contract negotiationResponding to change over following a plan

* http://en.wikipedia.org/wiki/Agile_software_development

Scrum Motivation - Lean

Lean *:Unnötiges weglassenEingebaute QualitätWissenaufbau und ErweiterungSchnelle ProduktzyklenArbeiten mit Menschen (nicht Maschinen die verfügbar sind)

Kontinuirliches Anpassen und Verbessern

* inspiriert von http://www.agilecollab.com/a-lean-view-of-scrum

Scrum Prinzipien

Scrum nutzt Deming Cycle *

PLAN Establish the objectives and processes necessary to deliver results in accordance with the expected output (the target or goals). By making the expected output the focus, it differs from other techniques in that the completeness and accuracy of the specification is also part of the improvement.

DO Implement the new processes, often on a small scale if possible, to test possible effects. It is important to collect data for charting and analysis for the following "CHECK" step.

CHECKMeasure the new processes and compare the results (collected in "DO" above) against the expected results (targets or goals from the "PLAN") to ascertain any differences. Charting data can make this much easier to see trends in order to convert the collected data into information. Information is what you need for the next step "ACT".

ACTAnalyze the differences to determine their cause. Each will be part of either one or more of the P-D-C-A steps. Determine where to apply changes that will include improvement. When a pass through these four steps does not result in the need to improve, refine the scope to which PDCA is applied until there is a plan that involves improvement.

* http://en.wikipedia.org/wiki/PDCA

**

** The PDCA cycle Foto: Karn-b - Karn G. Bulsuk (http://blog.bulsuk.com). Originally published at http://blog.bulsuk.com/2009/02/taking-first-step-with-pdca.html

Wikimedia Commons, lizenziert unter Creative Commons Attribution 3.0 Unported Die Originaldatei ist hier (http://commons.wikimedia.org/wiki/File:PDCA_Cycle.svg) zu finden.

Scrum Motivation

* adapted by Boris Kneisel (www.boris-kneisel.de) based on http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf page 4** http://www.scrum.org/storage/scrumguides/Scrum%20Guide%20-%202011.pdf page 4

CREATE TRANSPARENCY ---> INSPECT CAREFULLY ---> ADAPT CONTINUOUSLY *

Transparency **Significant aspects of the process must be visible to those responsible for the outcome. Transparency requires those aspects be defined by a common standard so observers share a common understanding of what is being seen.For example:

A common language referring to the process must be shared by all participants; and,A common definition of “Done”1 must be shared by those performing the work and those accepting the work product.

Inspection **Scrum users must frequently inspect Scrum artifacts and progress toward a goal to detect undesirable variances. Their inspection should not be so frequent that inspection gets in the way of the work. Inspections are most beneficial when diligently performed by skilled inspectors at the point of work.

Adaptation **If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation.

Scrum Team

Scrum Rollen – Das Scrum Team

Interessante Links: http://media.agile42.com/content/Scrum_Cheat_Sheet.pdf & http://scrum-master.de/Scrum-Rollen/Scrum-Rollen_Pigs_Chickens

Kunde

Scrum Master

Entwicklungs-team

ProductOwner

Manager Anwender

Scrum Rollen

Der Product OwnerDer VisionärEr plant und lenkt ProduktentwicklungGewünschte Funktionen in der richtigen Reihenfolge beim Team adressierenArbeit auf täglicher Basis mit TeamOrdnet* den Product und Sprint Backlog :

Team SchätzungenBusiness PrioritätTeam Velocity & Burn Down Chart

„Sprint Planning 1 ist die Product Owner Show“

* ordered vs. prioritized Backlog: http://www.scrum.org/storage/Scrum%20Update%202011.pdf -> letzter Punkt

Scrum TeamKunde

Scrum Master

Entwicklungs-team

ProductOwner

Manager Anwender

Scrum Rollen

Der Scrum Master

Organisiert, überwacht und sorgt für Einhaltung des Scrum ProzessSchult alle am Projekt beteiligten Personen so, dass Ihre Rolle verstanden werden und ausüben könnenSchafft TransparenzOrganisiert Scrum Meetings„Scrum Review & Scrum Retrospective sind die Scrum Master Shows“Hält Impedimentliste und löst möglichst alle Schwierigkeiten, Blockaden und Probleme Hilft dem Team , die Ziele zu erreichenSchützt das Team wenn nötig *

* Interessant dazu: http://blog.mountaingoatsoftware.com/protecting-the-team-cuts-both-ways

Scrum TeamKunde

Scrum Master

Entwicklungs-team

ProductOwner

Manager Anwender

Scrum Rollen

Das Entwicklungs Team – Die Lieferanten

Das Team liefert das ProduktinkrementeIdealfall: Team enthält alle Personen, die für die Lieferungen erforderlich sind Scrum Team managt seine Angelegenheiten selbst (ggf. Hilfe vom Scrum Master)Alles Zielführende für das Projekt im Rahmen des Scrumprozesses ist erlaubt!Steuert selbst die ArbeitsmengeStandards der Organisation einzuhaltenVerantwortung für Qualität der Lieferung (Definition of Done)

Scrum TeamKunde

Scrum Master

Entwicklungs-team

ProductOwner

Manager Anwender

Scrum Rollen

Der Kunde – Der FinanziererAnforderer des Projektes Er kauft das Produkt oder hat Auftrag gegebenIn einem internen Projektentwicklungsteam ist der Budgetverantwortliche in der Rolle des Kunden

Der Anwender – Der NutzerWesentliche Informationsquelle für Scrum TeamEr benutzt später die SoftwareScrum Team bezieht Anwender in Produkt-Entwicklung mit einIdealfall: bei der Sprint Planung definiert er gemeinsam mit dem PO die AnforderungenArbeitet mit Team mit

Scrum TeamKunde

Scrum Master

Entwicklungs-team

ProductOwner

Manager Anwender

Scrum Rollen

Der Manager – Der Bereitsteller

Stellt Ressourcen und Richtlinien innerhalb der Organisation bereitSchafft Rahmen für Begegnung für Team, PO, Scrum MasterSollte vom Scrum Master nicht zu lösende Probleme lösenTrägt wirtschaftliche Verantwortung

Scrum TeamKunde

Scrum Master

Entwicklungs-team

ProductOwner

Manager Anwender

Scrum Meetings

Sprint Planning Meeting 1 – Was PO, Entwicklungsteam, (Management, Anwender) und ScrumMaster anwesend *PO stellt Backlog Items in geordneter Reihenfolge vordefiniert gemeinsam mit Team Ziel für anstehenden SprintEntwicklungsteam commited zu Backlog Items die es schaffen kann (nach Priorität sortiert)

Entwicklungsteam commitment zu story ist vorhanden, wenn alle Entwicklungsteammitglieder einzeln zu einem Backlog Item commiten können; kann ein Entwicklungsteammitglied nicht commiten gilt das Backlog Item als nicht commited und zu keinem niedriger priorisiertes Backlog Item kann commited werdenCommitment jedes einzelnen Entwicklungsteammitgliedes sollte sich an der Frage orientieren: Glaube ich[Entwicklungsteammitglied], dass das Entwicklungsteam dieses

Backlog Item im nächsten Sprint schaffen kann (definition of done)?Ergebnis: Commited Backlog Items stellen den Sprint Backlog dar

* Wenn Managment und Anwender nicht anwesend sind (was häufig vorkommt), obliegt es dem PO diese Rollen einzunehmen

Scrum Meetings

Sprint Planning Meeting 2 - WieEntwicklungsteammitglieder planen, wie sie die Sprint Backlog Items zu denen in Sprint Planning 1 commited wurde erreichen wollenBeratung untereinander, über Aufbau der Applikation, Architektur, Interfaces, Test Cases, DokumentationSie besprechen detailliert, wie welche Schritte zu tun sind und teilen Sprint Backlog Items in Tasks *Ergebnis: Sprint Backlog liegt als geordnete Liste der Items vor, die jeweils in Tasks unterteilt sind

* Tasks sollte in etwa ein Arbeitspaket mit der Dimension 1 Manntag sein

Scrum Meetings

Daily Scrum Update Meeting des Entwicklungsteams für das EntwicklungsteamJeden Tag alle zur gleichen Zeit am selben Ort für 15 MinutenScrum Master moderiertDrei Einfache Fragen sollte sich jedes Entwicklungsteammitglied stellen

Was habe ich seit dem letzten Daily Scrum für das Projekt erreicht?Was plane ich bis zum nächsten Daily Scrum für das Projekt zu erreichenGibt es Hindernisse hindern mich meine Projektziel bis zum nächsten Daily Scrum zu erreichen

Daily Scrum ist kein Reporting an PO oder SM!

Scrum Meetings - Daily Scrum Boards

Scrum Meetings

Estimation Meeting – Vorausplanen / SchätzungPO und Team aktualisieren mindestens einmal im Sprint das Product BacklogBacklog Items werden mit neuen Schätzungen versehen ( und ggf. neue Items aufgenommen )Entwicklungsteam stellt Verständnissfragen und konkretisiert damit die Acceptance Criteria der User StoriesReihenfolge der der Backlog Items wird unter den neuen Infos angepaßt Releaseplan wird hier aktualisiert und vervollständigt

Scrum Meetings

Sprint Review – Resultate präsentierenAm Ende des Sprints präsentiert Team die FunktionalitätenNur die Funktionalitäten, die produktiv eingesetzt werden können (Definition of Done)Nicht getestete oder instabile Funktionen werden nicht gezeigt und gelten als nicht geliefertShow Case Session (Manager und Kunde können anwesend sein)

Sprint- Retrospektive – sich ständig verbessernSystematische Lerne des Teams bezüglich des Scrum ProzessesAnalyse von Arbeitsprozessen zur Optimierung für das TeamErgebnisse werden in Impediment Backlog festgehalten und lassen sich so wieder in Sprint Planning einbringenScrum Master Show: er sorgt dafür das der Scrum Prozess ständig weiter verbessert wird

Shuhari

http://en.wikipedia.org/wiki/Shuhari:Aikido master Endō Seishirō shihan stated:

"It is known that, when we learn or train in something, we pass through the stages of shu, ha, and ri. These stages are explained as follows. In shu, we repeat the forms and discipline ourselves so that our bodies absorb the forms that our forebearers created. We remain faithful to the forms with no deviation. Next, in the stage of ha, once we have disciplined ourselves to acquire the forms and movements, we make innovations. In this process the forms may be broken and discarded. Finally, in ri, we completely depart from the forms, open the door to creative technique, and arrive in a place where we act in accordance with what our heart/mind desires, unhindered while not overstepping laws."

Japanisches Kampfkunstkonzept welches drei Bestandteile enthält:shu – „befolgen, behüten, bewahren“ ( „Honor the master, copy the master“ )ha – „bekanntes anpassen & weiter entwickeln“ri – „freie & kreative Weiterentwicklung“

Scrum & Bugs

Best practise:Bugs to be triaged (critical, important, nice to have)Bugs werden wie user stories im Backlog geordnet

Scrum - Slang Auszug

Produkt VisionKlares, deutliches, attraktives, emotionales Bild des angestrebten Produktes, z.B.:“We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard, because that goal will serve to organize and measure the best of our energies and skills, because that challenge is one that we are willing to accept, one we are unwilling to postpone, and one which we intend to win, and the others, too.” *

Product Backlog Items/User StoryDie zu lieferenden Funktionalitäten/Features, die in einem Product Backlog aufgelistet sindHaben immer Nutzwert für den Kunden

•* John F. Kennedy, 35th President of the United States, September 12, 1962, Rice Stadium speech see http://en.wikipedia.org/wiki/Rice_Stadium & http://en.wikipedia.org/wiki/John_F._Kennedy

Scrum - Slang Auszug

Product BacklogListe von Product Backlog Items, die vom PO nach Bedeutung für Projekziel geordnet wird

Sprint BacklogListe von Product Backlog Items für die das Entwicklungsteam pro Sprint commited hat

Sprint GoalPO legt mit Team das Sprint Goal festHat immer im Bezug zu Product Vision

Acceptance Criteria (AC)Liste von Kriterien (SMART) die eingehalten werden müssen, damit der PO die User Story im Review Meeting akzeptiert

Definition of DoneScrum erwartet vom gesamten Scrum Team, dass ein gemeinsames Verständnis einer Definition of Done vorherrscht. Dieses sollte fundamentale Bestandteile von professioneller Softwareentwicklung wie z.B. Dokumentation nicht enthalten, weil diese als Voraussetzung angenommen werden. Teamspezifische Besonderheiten und Unklarheiten (die sich z.B. in Reviews und Retrospektiven zeigen) sollen in der Definition of Done definiert / klargestellt werden.

Copyright notice

You are free:to Share―to copy, distribute and and transmit the workto Remix―to adapt the work

Under the following conditionsAttribution. You must attribute the work in the manner specified by the author or licensor (but not in any way that suggests that they endorse you or your use of the work).

Nothing in this license impairs or restricts the author’s moral rights.

For more information see http://creativecommons.org/licenses/by/3.0/