Kontakt / Impressum

Impressum:

Emanuel Ludi
Landorfstrasse 56
CH-3098 Köniz

Email: ludiemanuel@gmail.com
Tel.: +41(0)76 570 15 68

MwSt.Nr.: Nicht MwSt.-Pflichtig
KURSE
DESIGN THINKING
Diese Seite verwendet keine Cookies. Es werden keine Daten erfasst*.

Heisst das, dass Sie uns nicht interessieren?

Im Gegenteil: Sie liegen uns so am Herzen, dass wir Ihre Privatspäre schützen wollen.


*Der Provider dieser Seite ist gesetzlich verpflichtet, Verbindungsdaten zu speichern.
Für Links zu externen Seiten übernehmen wir keine Haftung. Diese Seiten werden in einem separaten Fenster/Tab geöffnet.

Das Agile Manifest

Im Februar 2001 trafen sich Kent Beck, Mike, Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Gree^nning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland und Dave Thomas in Utah (USA).
Bei dieser Zusammenkunft wurde auf Vorschlag von Mike Beedle die bis anhin gebräuchliche Bezeichnung "leichtgewichtig (lightweight, engl.)" fü¨r die Softwareentwicklung durch "agil (agile, engl.)" ersetzt.
Gleichzeitig wurde das "Agile Manifest (Manifesto for Agile Software Development, engl.)" formuliert:

"Wir erschliessen bessere Wege, Software zu entwickeln, indem wir es selbst tun und anderen dabei helfen. Durch diese Tätigkeit haben wir folgende Werte zu schätzen gelernt:

  • Individuen und Interaktionen mehr als Prozesse und Werkzeuge
  • Funktionierende Software mehr als umfassende Dokumentation
  • Zusammenarbeit mit dem Kunden mehr als Vertragsverhandlung
  • Reagieren auf Veränderungen mehr als das Befolgen eines Plans

  • Das heisst, obwohl wir die Werte auf der rechten Seite wichtig finden, schätzen wir die Werte auf der linken Seite höher ein."

    Agile Prinzipien

    Die Agilen Prinzipien dienen als Leitsätze für die agile Arbeit.
    Die 12 Prinzipien des "Agilen Manifests":

    Agile Methoden und Frameworks

    Agilität ist eine Einstellung

    "Srum ist einfach zu verstehen, aber schwierig zu meistern." ist ein Satz aus dem Srum Guide von Jeff Sutherland und Ken Schwaber.

    Die Erklärung ist im Grunde ebenso einfach, aber schwierig zu verstehen:

    Agile Entwicklung ist nicht etwas, das man einfch so lernen kann, wie z.B. ein Fremdwort. Man muss lernen, agil zu denken, zu fühlen und zu handeln.

    Und genau da liegt vielfach der Knackpunkt. Agilität muss zur Firmenphilosophie werden, damit sie so gut funktioniert, wie überall herumposaunt wird.

    Sowohl die Chefetage, als auch die Mitarbeiter müssen sich ihrer neuen Rolle und Verantwortung bewusst sein. Wer sich damit nicht identifizieren kann, hat einen schweren Stand oder verursacht Probleme bei der Umsetzung der agilen Prinzipien.

    So muss man verstehen, dass der ehemalige Projektmanager plötzlich nicht mehr das alleinige Sagen hat. Seine Aufgaben werden teilweise delegiert. Andererseits muss er sich um neue Techniken und Methoden kümmern, welche für die Planung und Durchführung des Projektes entscheidend sind.

    Die Entwickler wiederum müssen plötzlich selbständig entscheiden, WIE sie eine Aufgabe lösen sollen. Ihre einzige Vorgabe ist das WAS. Sie geniessen eine grössere Entscheidungsfreiheit, bezahlen diese aber durch die höhere Verantwortung im Team.

    Das kann sehr schnell zu Missmut und Frustration führen. Man sollte die Implementierung agiler Methoden in der Firma sehr gut planen. Es lohnt sich besonders am Anfang, sich die Zeit für eine gute Einführung und Begleitung aller Beteiligten zu nehmen.

    Checkliste "Bin ich agil?"

    JaNein
    Ich überdenke regelmässig meine Überzeugungen und meine Weltanschauung.
    Ich übernehme gerne Verantwortung.
    Ich kann Verantwortung auch gut abgeben.
    Ich traue meinen TeamkollegInnen zu, selber Entscheidungen zu treffen.
    Ich kommuniziere offen und transparent.
    Der Kundenwunsch bestimmt meine Planung.
    Ich weiss, wie ich die wahren Bedürfnisse meiner Kunden erkennen kann.
    Ich begrüsse Fehler, denn sie zeigen mir das Veränderungspotenzial.
    Ich kann mich gut in andere Menschen hinein versetzen, ich habe die Fähigkeit zur Empathie.
    Ich finde die Arbeit in einem interdisziplinÄren Team angenehm und interessant.
    Ich habe eine gute Selbstführungskompetenz.
    Ich habe bereits Erfahrungen mit agilen Arbeitsmethoden.
    Es steht mir genügend Zeit zur Verfügung für die Reflektion und Weiterentwicklung meiner Arbeit.
    Ich beherrsche konstruktive Kommunikationstechniken.
    Ich kenne die Werte und Prinzipien des Agilen Manifests und handle danach.
    Ich habe Freude daran, Neues kennenzulernen und auszuprobieren.

    Was ist Lean?

    "Lean" bedeutet "dünn; mager; schlank" und heisst in Bezug auf die Produktion und das Management soviel wie: Diese Philosophie kann mittels verschiedenen, sich ergänzenden Methoden in die Tat umgesetzt werden.
    Im Vordergrund steht dabei immer die Kundenorientierung.
    Grundsätzlich werden alle MitarbeiterInnen dazu angehalten, ihre Arbeitsabläufe permanent zu hinterfragen und Vorschläge zur Optimierung einzubringen. Dazu muss zuerst das Mindset von sämtlichen Beteiligten auf "lean" eingefahren werden.

    Im Projekt Management kann man Leerläufe und Fehlproduktionen von Anfang an reduzieren, indem man z.B. genügend Zeit in die Abklärung des effektiven Kundenbedürfnisses investiert.

    In der Logistik können Transportwege und Auslastung optimiert werden.

    In der Produktion kann Kanban eine grosse Hilfe sein, um die Prozesse zu koordinieren und Überproduktion zu vermeiden.
    Werbung / Anzeige:


    Lean Management für Einsteiger: Grundlagen des Lean Managements für kleine und mittelständische Unternehmen - mit vielen Praxisbeispielen

    Lean Management: Einführung und Vertiefung in die japanische Management-Philosophie

    Six Sigma+Lean Toolset: Mindset zur erfolgreichen Umsetzung von Verbesserungsprojekten

    Was ist Kanban?

    1947 entwickelte Taiichi Ohno, der Erfinder des Toyota-Produktionssystems, Kanban ("Karte"; "Behälter"; "Beleg", Jap.) zur Umsetzung des "Pull-Prinzips".
    Die Idee dafür kam ihm im Supermarkt, wo sich die Kunden selber bedienen (pull) und die Mitarbeiter:innen die Regale nach Bedarf wieder auffüllen.
    Im Produktionsprozess funktioniert Kanban also folgendermassen: Dank diesem Prinzip wird nur soviel produziert, wie gerade benötigt wird. Dadurch wird eine Überproduktion vermieden und kostbarer Lagerplatz gespart.

    Genau so klappt Kanban auch im Projektmanagement: Jede:r Mitarbeiter:in darf dabei höchstens zwei Karten gleichzeitig bearbeiten. Die zweite Karte darf er:sie allerdings erst nehmen, falls die Arbeit an der ersten Karte aus irgend einem Grund ins Stocken geraten ist.

    Die sechs Prinzipien

    1. Klare Regeln: Alle Regeln müssen von allen Beteiligten transparent sein, verstanden und umgesetzt werden.
    2. Aufgabenlimit: Die zur Verfügung stehenden Aufgaben (Karten) sind zahlenmässig zu begrenzen.
    3. Workflow: Es müssen immer Aufgaben in Bearbeitung sein.
    4. Kaizen (fortlaufender Verbesserungsprozess): Prozesse müssen regelmässig analysiert und nach Möglichkeit verbessert werden.
    5. Leadership: Sämtliche Beteiligten tragen die Verantwortung, sich für Verbesserungen einzusetzen und den Workflow zu erhalten.
    6. Modelle: Modelle führen durch die Veranschaulichung zu einem besseren Verständnis der Prozesse und begünstigen dadurch effizientere Lösungen.

    Regeln

    Werbung / Anzeige:


    Kanban: Verstehen, einführen und anwenden

    Kanban für Anfänger: Grundlegendes über den Einsatz von Kanban in der Industrie und der Softwareentwicklung | Wie Kanban in der Praxis funktioniert

    Kanban – mehr als Zettel: Wie die Methode Ihnen zu echtem Mehrwert verhilft

    Was ist Design Thinking?

    Werbung / Anzeige:


    Design Thinking: Radikale Innovationen in einer digitalisierten Welt

    Das Design Thinking Playbook: Mit traditionellen, aktuellen und zukünftigen Erfolgsfaktoren

    Das Design Thinking Toolbook: Die besten Werkzeuge & Methoden
    Werbung / Anzeige:


    Scrum – verstehen und erfolgreich einsetzen

    Scrum in der Praxis: Erfahrungen, Problemfelder und Erfolgsfaktoren

    Scrum-Grundlagen - Wissenskarten - Steigern Sie das Wissen und die Produktivität Ihres Teams - DEUTSCHE Version
    Ken Schwaber & Jeff Sutherland

    Der Scrum Guide

    Der gültige Leitfaden für Scrum: Die Spielregeln

    November 2020

    Der Sinn des Scrum Guides

    Wir haben Scrum in den frühen 1990er-Jahren entwickelt. Wir haben die erste Version des Scrum Guides im Jahr 2010 geschrieben, um Menschen auf der ganzen Welt dabei zu helfen, Scrum zu verstehen. Wir haben den Guide seitdem durch kleine, funktionale Aktualisierungen weiterentwickelt. Wir stehen gemeinsam dahinter.

    Der Scrum Guide enthält die Definition von Scrum. Jedes Element von Scrum dient einem bestimmten Zweck, der für den Gesamtwert und die mit Scrum erzielten Ergebnisse wesentlich ist. Den Kern oder die Grundideen von Scrum zu verändern, Elemente wegzulassen oder den Regeln von Scrum nicht zu folgen, verdeckt Probleme, begrenzt den Nutzen und macht Scrum im Zweifel sogar nutzlos.

    Wir verfolgen den zunehmenden Einsatz von Scrum in einer stetig komplexer werdenden Welt. Wir sehen demütig, wie Scrum in zahlreichen Bereichen komplexer Arbeit über die Softwareentwicklung hinaus - wo Scrum seine Wurzeln hat - eingesetzt wird. Während sich die Verwendung von Scrum weiter verbreitet, wird diese Arbeit von Entwickler:innen, Forscher:innen, Analyst:innen, Wissenschaftler:innen und anderen Spezialist:innen getan. Wir verwenden das Wort 'Developer:innen' in Scrum nicht, um jemanden auszuschliessen, sondern um zu vereinfachen. Wer auch immer vom Einsatz von Scrum profitiert, soll sich angesprochen fühlen.

    Beim Einsatz von Scrum können Muster, Prozesse und Erkenntnisse angewendet und entwickelt werden, die zum Scrum-Rahmenwerk passen, wie es in diesem Dokument beschrieben ist. Ihre Beschreibung geht über den Zweck des Scrum Guides hinaus, da sie kontextabhängig sind und sich, je nachdem wie Scrum eingesetzt wird, stark unterscheiden. Solche Taktiken für die Anwendung innerhalb des Scrum- Rahmenwerks variieren stark und werden an anderer Stelle beschrieben.


    Ken Schwaber & Jeff Sutherland, November 2020



    © 2020 Ken Schwaber and Jeff Sutherland This publication is offered for license under the Attribution Share-Alike license of Creative Commons, accessible at http://creativecommons.org/licenses/by-sa/4.0/legalcode and also described in summary form at http://creativecommons.org/licenses/by-sa/4.0/. By utilizing this Scrum Guide, you acknowledge and agree that you have read and agree to be bound by the terms of the Attribution Share-Alike license of Creative Commons.







    Scrum-Definition

    Scrum ist ein leichtgewichtiges Rahmenwerk, welches Menschen, Teams und Organisationen hilft, Wert durch adaptive Lösungen für komplexe Probleme zu generieren.

    Kurz gesagt fordert Scrum, dass ein:e Scrum Master:in ein Umfeld fördert, in dem
    1. ein:e Product Owner:in die Arbeit für ein komplexes Problem in ein Product Backlog einsortiert;
    2. das Scrum Team aus einer Auswahl dieser Arbeit innerhalb eines Sprints ein wertvolles Increment erzeugt;
    3. das Scrum Team und dessen Stakeholder:innen die Ergebnisse überprüfen und für den nächsten Sprint anpassen;
    4. diese Schritte wiederholt werden.

    Scrum ist einfach. Probiere es so aus, wie es ist, und finde heraus, ob seine Philosophie, Theorie und Struktur dabei helfen, Ziele zu erreichen und Wert zu schaffen. Das Scrum-Rahmenwerk ist absichtlich unvollständig und definiert nur die Teile, die zur Umsetzung der Scrum-Theorie erforderlich sind. Scrum baut auf der kollektiven Intelligenz der Personen auf, die es anwenden. Anstatt den Menschen detaillierte Anweisungen zu geben, leiten die Regeln von Scrum ihre Beziehungen und Interaktionen.

    Innerhalb des Rahmenwerks können verschiedene Prozesse, Techniken und Methoden eingesetzt werden. Scrum umhüllt bestehende Praktiken oder macht sie überflüssig. Scrum macht die relative Wirksamkeit des aktuellen Managements, der Umgebung und der Arbeitstechniken sichtbar, so dass Verbesserungen vorgenommen werden können.

    Scrum-Theorie

    Scrum basiert auf Empirie und Lean Thinking. Empirie bedeutet, dass Wissen aus Erfahrung gewonnen wird und Entscheidungen auf der Grundlage von Beobachtungen getroffen werden. Lean Thinking reduziert Verschwendung und fokussiert auf das Wesentliche.

    Scrum verwendet einen iterativen, inkrementellen Ansatz zur Optimierung der Vorhersagbarkeit und zur Risikokontrolle. Scrum setzt auf Personengruppen, die gemeinsam über alle Fähigkeiten und Fachkenntnisse verfügen, um die Arbeit zu erledigen und solche Fähigkeiten im Bedarfsfall zu teilen oder zu erwerben.

    Scrum kombiniert vier formale Events zur überprüfung und Anpassung innerhalb eines umspannenden Events, des Sprints. Diese Events funktionieren, weil sie die empirischen Scrum-Säulen Transparenz, überprüfung und Anpassung implementieren.

    Transparenz

    Der sich entwickelnde Prozess und die entstehende Arbeit müssen sowohl für diejenigen sichtbar sein, die die Arbeit ausführen, als auch für diejenigen, die die Arbeit empfangen. Bei Scrum basieren wichtige Entscheidungen auf dem wahrgenommenen Zustand seiner drei formalen Artefakte. Artefakte, die wenig transparent sind, können zu Entscheidungen führen, die den Wert mindern und das Risiko erhöhen.

    Transparenz ermöglicht Überprüfung. Eine überprüfung ohne Transparenz ist irreführend und verschwenderisch.

    Überprüfung

    Die Scrum-Artefakte und der Fortschritt in Richtung der vereinbarten Ziele müssen häufig und sorgfältig überprüft werden, um potenziell unerwünschte Abweichungen oder Probleme aufzudecken. Um bei der Überprüfung zu helfen, bietet Scrum eine Kadenz in Form seiner fünf Events.

    Überprüfung ermöglicht Anpassung. Überprüfung ohne Anpassung wird als unsinnig betrachtet. Scrum Events sind darauf ausgerichtet, Veränderungen zu bewirken.

    Anpassung

    Wenn einzelne Aspekte eines Prozesses von akzeptablen Grenzen abweichen oder wenn das resultierende Produkt nicht akzeptabel ist, müssen der angewandte Prozess oder die produzierten Ergebnisse angepasst werden. Die Anpassung muss so schnell wie möglich erfolgen, um weitere Abweichungen zu minimieren.

    Die Anpassung wird schwieriger, wenn die beteiligten Personen nicht bevollmächtigt (empowered) sind oder sich nicht selbst managen können. Von einem Scrum Team wird erwartet, dass es sich in dem Moment anpasst, in dem es durch Überprüfung etwas Neues lernt.

    Scrum-Werte

    Die erfolgreiche Anwendung von Scrum hängt davon ab, dass die Menschen immer besser in der Lage sind, fünf Werte zu leben:
    Fokus, Offenheit, Respekt und Mut
    Das Scrum Team committet sich, seine Ziele zu erreichen und sich gegenseitig zu unterstützen. Sein primärer Fokus liegt auf der Arbeit des Sprints, um den bestmöglichen Fortschritt in Richtung dieser Ziele zu bewirken. Das Scrum Team und dessen Stakeholder:innen sind offen in Bezug auf die Arbeit und die Herausforderungen. Die Mitglieder des Scrum Teams respektieren sich gegenseitig als fähige, unabhängige Personen und werden als solche auch von den Menschen, mit denen sie zusammenarbeiten, respektiert. Die Mitglieder des Scrum Teams haben den Mut, das Richtige zu tun: an schwierigen Problemen zu arbeiten.

    Diese Werte geben dem Scrum Team die Richtung vor, was seine Arbeit, seine Handlungen und sein Verhalten betrifft. Die Entscheidungen, die getroffen werden, die Schritte, die unternommen werden, und die Art und Weise, wie Scrum angewendet wird, sollten diese Werte stärken und nicht schmälern oder untergraben. Die Mitglieder des Scrum Teams lernen und erforschen die Werte, wÄhrend sie in den Events und mit den Artefakten von Scrum arbeiten. Wenn diese Werte durch das Scrum Team und die Menschen, mit denen es arbeitet, verkörpert werden, werden die empirischen Scrum-Säulen Transparenz, Überprüfung und Anpassung lebendig und bauen Vertrauen auf.

    Scrum Team

    Der zentrale Bestandteil von Scrum ist ein kleines Team von Menschen, ein Scrum Team. Das Scrum Team besteht aus einem:einer Scrum Master:in, einem:einer Product Owner:in und Developer:innen. Innerhalb eines Scrum Teams gibt es keine Teilteams oder Hierarchien. Es handelt sich um eine geschlossene Einheit von Fachleuten, die sich auf ein Ziel konzentrieren, das Produkt-Ziel.

    Scrum Teams sind interdisziplinär, d.h. die Mitglieder verfügen über alle Fähigkeiten, die erforderlich sind, um in jedem Sprint Wert zu schaffen. Sie managen sich ausserdem selbst, d.h. sie entscheiden intern, wer was wann und wie macht.

    Das Scrum Team ist klein genug, um flink zu bleiben und gross genug, um innerhalb eines Sprints bedeutsame Arbeit fertigzustellen, üblicherweise 10 oder weniger Personen. Im Allgemeinen haben wir festgestellt, dass kleinere Teams besser kommunizieren und produktiver sind. Wenn Scrum-Teams zu gross werden, sollten sie in Erwägung ziehen, sich in mehrere zusammengehörende Scrum Teams zu reorganisieren, die sich alle auf dasselbe Produkt konzentrieren. Daher sollten sie Produkt-Ziel, Product Backlog und Product Owner:in teilen.

    Das Scrum Team ist umsetzungsverantwortlich (responsible) für alle produktbezogenen AktivitÄten: Zusammenarbeit mit den Stakeholder:innen, Verifikation, Wartung, Betrieb, Experimente, Forschung und Entwicklung und alles, was sonst noch erforderlich sein könnte. Es ist von der Organisation so aufgebaut und befähigt, dass es seine Arbeit selbst steuert. Das Arbeiten in Sprints mit einer nachhaltigen Geschwindigkeit verbessert den Fokus und die Kontinuität des Scrum Teams.

    Das gesamte Scrum Team ist ergebnisverantwortlich (accountable), in jedem Sprint ein wertvolles, nützliches Increment zu schaffen. Scrum definiert drei spezifische Ergebnisverantwortlichkeiten innerhalb des Scrum Teams: Developer:innen, Product Owner:in und Scrum Master:in

    Developer:innen

    Developer:innen sind jene Personen im Scrum Team, die sich der Aufgabe verschrieben haben, jeden Sprint jeden Aspekt eines nutzbaren Increments zu schaffen.

    Die spezifischen Fähigkeiten, die von den Developer:innen benötigt werden, sind oft breit gefächert und variieren je nach Arbeitskontext. Die Developer:innen sind jedoch immer ergebnisverantwortlich dafür,

    Product Owner:in

    Der:die Product Owner:in ist ergebnisverantwortlich für die Maximierung des Wertes des Produkts, der sich aus der Arbeit des Scrum Teams ergibt. Wie dies geschieht, kann je nach Organisation, Scrum Team und Individuum sehr unterschiedlich sein.

    Der:die Product Owner:in ist auch für ein effektives Product-Backlog-Management ergebnisverantwortlich, das Folgendes umfasst:
    Der:die Product Owner:in kann die oben genannten Arbeiten selbst durchführen oder die Umsetzungsverantwortung an andere delegieren. Unabhängig davon bleibt der:die Product Owner:in ergebnisverantwortlich. Damit der:die Product Owner:in Erfolg haben kann, muss die gesamte Organisation seine:ihre Entscheidungen respektieren. Diese Entscheidungen sind im Inhalt und in der Reihenfolge des Product Backlogs sowie durch das überprüfbare Increment beim Sprint Review, sichtbar. Der:die Product Owner:in ist eine Person, kein Gremium. Der:die Product Owner:in kann die Bedürfnisse vieler Stakeholder:innen im Product Backlog berücksichtigen. Diejenigen, die das Product Backlog ändern möchten, können dies tun, indem sie versuchen, den:die Product Owner:in zu überzeugen.

    Scrum Master:in

    Der:die Scrum Master:in ist ergebnisverantwortlich für die Einführung von Scrum, wie es im Scrum Guide definiert ist. Er:sie tut dies, indem er:sie allen dabei hilft, die Scrum-Theorie und -Praxis zu verstehen, sowohl innerhalb des Scrum Teams als auch in der Organisation.
    Der:die Scrum Master:in ist ergebnisverantwortlich für die Effektivität des Scrum Teams. Er:sie tut dies, indem er:sie das Scrum Team in die Lage versetzt, seine Praktiken innerhalb des Scrum-Rahmenwerks zu verbessern.
    Scrum Master:innen sind echte Führungskräfte, die dem Scrum Team und der Gesamtorganisation dienen.
    Der:die Scrum Master:in dient dem Scrum Team auf unterschiedliche Weise, unter anderem dadurch,
    Der:die Scrum Master:in dient dem:der Product Owner:in auf unterschiedliche Weise, unter anderem dadurch,
    Der:die Scrum Master:in dient der Organisation auf unterschiedliche Weise, unter anderem dadurch,

    Scrum Events

    Der Sprint ist ein Container für alle anderen Events. Jedes Event in Scrum ist eine formelle Gelegenheit, Scrum-Artefakte zu überprüfen und anzupassen.
    Diese Events sind speziell darauf ausgelegt, die erforderliche Transparenz zu ermöglichen. Wenn ein Event nicht wie vorgeschrieben durchgeführt wird, verpasst man die Gelegenheit, zu überprüfen und anzupassen. Events werden in Scrum verwendet, um Regelmässigkeit zu schaffen und die Notwendigkeit von Meetings, die in Scrum nicht definiert sind, zu minimieren. Optimalerweise werden alle Events zur selben Zeit und am selben Ort abgehalten, um die Komplexität zu reduzieren.

    Der Sprint

    Sprints sind der Herzschlag von Scrum, wo Ideen in Wert umgewandelt werden. Es sind Events mit fester Länge von einem Monat oder weniger, um Konsistenz zu schaffen.
    Ein neuer Sprint beginnt unmittelbar nach dem Abschluss des vorherigen Sprints.
    Alle Arbeiten, die notwendig sind, um das Produkt-Ziel zu erreichen, einschliesslich Sprint Planning, Daily Scrums, Sprint Review und Sprint Retrospective, finden innerhalb der Sprints statt.
    Während des Sprints Sprints ermöglichen Vorhersagbarkeit, indem sie mindestens jeden Kalendermonat eine Überprüfung und Anpassung der Fortschritte in Richtung eines Produkt-Ziels gewährleisten.
    Wenn der Horizont eines Sprints zu lang ist, kann das Sprint-Ziel hinfällig werden, die Komplexität kann steigen und das Risiko kann zunehmen.
    Kürzere Sprints können eingesetzt werden, um mehr Lernzyklen zu generieren und das Risiko von Kosten und Aufwand auf einen kleineren Zeitrahmen zu begrenzen. Jeder Sprint kann als ein kurzes Projekt betrachtet werden.
    Es gibt verschiedene Vorgehensweisen, um den Fortschritt vorherzusagen, wie Burn-Down-Charts, Burn- Up-Charts oder Cumulative-Flow-Diagramme. Diese haben sich zwar als nützlich erwiesen, ersetzen jedoch nicht die Bedeutung der Empirie. In komplexen Umgebungen ist unbekannt, was passieren wird. Nur was bereits geschehen ist, kann für eine vorausschauende Entscheidungsfindung genutzt werden. Ein Sprint könnte abgebrochen werden, wenn das Sprint-Ziel obsolet wird. Nur der:die Product Owner:in hat die Befugnis, den Sprint abzubrechen.

    Sprint Planning

    Das Sprint Planning initiiert den Sprint, indem es die für den Sprint auszuführenden Arbeiten darlegt. Dieser resultierende Plan wird durch die gemeinschaftliche Arbeit des gesamten Scrum Teams erstellt. Der:die Product Owner:in stellt sicher, dass die Teilnehmenden vorbereitet sind, die wichtigsten Product‐Backlog‐Einträge zu besprechen, und wie sie dem Produkt-Ziel zuzuordnen sind. Das Scrum Team kann zu Beratungszwecken auch andere Personen zur Teilnahme am Sprint Planning einladen. Das Sprint Planning behandelt die folgenden Themen:

    Thema Eins: Warum ist dieser Sprint wertvoll?

    Der:die Product Owner:in schlägt vor, wie das Produkt im aktuellen Sprint seinen Wert und Nutzen steigern könnte. Das gesamte Scrum Team arbeitet dann zusammen, um ein Sprint‐Ziel zu definieren, das verdeutlicht, warum der Sprint für die Stakeholder:innen wertvoll ist. Das Sprint‐Ziel muss vor dem Ende des Sprint Plannings finalisiert sein.

    Thema Zwei: Was kann in diesem Sprint abgeschlossen (Done) werden?

    Im Gespräch mit dem:der Product Owner:in wählen die Developer:innen Einträge aus dem Product Backlog aus, die in den aktuellen Sprint aufgenommen werden sollen. Das Scrum Team kann diese Einträge während dieses Prozesses verfeinern, was Verständnis und Vertrauen erhöht.
    Die Auswahl, wie viel innerhalb eines Sprints abgeschlossen werden kann, kann eine Herausforderung darstellen. Je mehr die Developer:innen jedoch über ihre bisherige Leistung, ihre zukünftige Kapazität und ihre Definition of Done wissen, desto sicherer werden sie in ihren Sprint-Vorhersagen sein.

    Thema Drei: Wie wird die ausgewählte Arbeit erledigt?

    Für jeden ausgewählten Product-Backlog-Eintrag planen die Developer:innen die notwendige Arbeit, um ein Increment zu erstellen, das der Definition of Done entspricht. Dies geschieht oft durch Zerlegung von Product-Backlog-Einträgen in kleinere Arbeitseinheiten von einem Tag oder weniger.
    Wie dies geschieht, liegt im alleinigen Ermessen der Developer:innen. Niemand sonst sagt ihnen, wie sie Product-Backlog- Einträge in Increments von Wert umwandeln sollen.
    Das Sprint-Ziel, die für den Sprint ausgewählten Product-Backlog-Einträge und der Plan für deren Lieferung werden zusammenfassend als Sprint Backlog bezeichnet.
    Das Sprint Planning ist zeitlich beschränkt auf maximal acht Stunden für einen einmonatigen Sprint. Bei kürzeren Sprints ist das Event in der Regel kürzer.

    Daily Scrum

    Der Zweck des Daily Scrums besteht darin, den Fortschritt in Richtung des Sprint-Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.
    Das Daily Scrum ist ein 15-minütiges Event für die Developer:innen des Scrum Teams. Um die Komplexität zu reduzieren, wird es an jedem Arbeitstag des Sprints zur gleichen Zeit und am gleichen Ort abgehalten. Falls der:die Product Owner:in oder der:die Scrum Master:in aktiv an Einträgen des Sprint Backlogs arbeitet, nimmt er:sie als Developer:in teil.
    Die Developer:innen können Struktur und Techniken beliebig wählen, solange ihr Daily Scrum sich auf den Fortschritt in Richtung des Sprint-Ziels fokussiert und einen umsetzbaren Plan für den nächsten Arbeitstag erstellt. Das schafft Fokus und fördert Selbstmanagement.
    Daily Scrums verbessern die Kommunikation, identifizieren Hindernisse, fördern die schnelle Entscheidungsfindung und eliminieren konsequent die Notwendigkeit für andere Meetings.
    Das Daily Scrum ist nicht die einzige Gelegenheit, bei der die Developer:innen ihren Plan anpassen dürfen. Sie treffen sich oftmals während des Tages für detailliertere Diskussionen zur Anpassung oder Neuplanung der restlichen Arbeit des Sprints.

    Sprint Review

    Zweck des Sprint Reviews ist es, das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen.
    Das Scrum Team stellt die Ergebnisse seiner Arbeit den wichtigsten Stakeholder:innen vor, und die Fortschritte in Richtung des Produkt-Ziels werden diskutiert.
    Während des Events überprüfen das Scrum Team und die Stakeholder:innen, was im Sprint erreicht wurde und was sich in ihrem Umfeld verändert hat.
    Auf der Grundlage dieser Informationen arbeiten die Teilnehmenden gemeinsam daran, was als Nächstes zu tun ist. Auch kann das Product Backlog angepasst werden, um neue Möglichkeiten wahrzunehmen. Das Sprint Review ist ein Arbeitstermin, und das Scrum Team sollte vermeiden, es auf eine Präsentation zu beschränken.
    Das Sprint Review ist das vorletzte Event des Sprints und ist für einen einmonatigen Sprint auf maximal vier Stunden zeitlich beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

    Sprint Retrospektive

    Der Zweck der Sprint Retrospective ist es, Wege zur Steigerung von Qualität und Effektivität zu planen.
    Das Scrum Team überprüft, wie der letzte Sprint in Bezug auf Individuen, Interaktionen, Prozesse, Werkzeuge und seine Definition of Done verlief. Die überprüften Elemente variieren oft je nach Arbeitsdomäne. Annahmen, die das Team in die Irre geführt haben, werden identifiziert und ihre Ursprünge erforscht. Das Scrum Team bespricht, was während des Sprints gut gelaufen ist, auf welche Probleme es gestossen ist und wie diese Probleme gelöst wurden (oder auch nicht).
    Das Scrum Team identifiziert die hilfreichsten änderungen, um seine Effektivität zu verbessern. Die wirkungsvollsten Verbesserungen werden so schnell wie möglich in Angriff genommen. Sie können sogar in das Sprint Backlog für den nÄchsten Sprint aufgenommen werden.
    Die Sprint Retrospective schliesst den Sprint ab. Sie ist für einen einmonatigen Sprint auf maximal drei Stunden beschränkt. Bei kürzeren Sprints ist das Event in der Regel kürzer.

    Scrum-Artefakte

    Die Artefakte von Scrum repräsentieren Arbeit oder Wert. Sie sind dafür ausgelegt, die Transparenz von Schlüsselinformationen zu maximieren. So haben alle, die sie überprüfen, die gleiche Grundlage für Anpassungen.
    Jedes Artefakt beinhaltet ein Commitment, um sicherzustellen, dass Informationen bereitgestellt werden, welche Transparenz und Fokus verbessern, um den Fortschritt messbar zu machen: Diese Commitments dienen dazu, Empirie und die Scrum-Werte für das Scrum Team und seine Stakeholder:innen zu verstärken.

    Product Backlog

    Das Product Backlog ist eine emergente, geordnete Liste der Dinge, die zur Produktverbesserung benötigt werden. Es ist die einzige Quelle von Arbeit, die durch das Scrum Team erledigt wird.
    Product-Backlog-Einträge, die durch das Scrum Team innerhalb eines Sprints abgeschlossen (Done) werden können, gelten als bereit für die Auswahl in einem Sprint-Planning-Event. Diesen Transparenzgrad erlangen sie in der Regel durch Refinement-Aktivitäten.
    Das Refinement des Product Backlogs ist der Vorgang, durch den Product-Backlog-EintrÄge in kleinere, präzisere Elemente zerlegt und weiter definiert werden. Dies ist eine kontinuierliche Aktivität, wodurch weitere Details wie Beschreibung, Reihenfolge und Grösse ergänzt werden. Die Attribute variieren oft je nach Arbeitsumfeld.
    Die Developer:innen, die die Arbeit erledigen werden, sind für die Grössenbestimmung umsetzungsverantwortlich. Der:die Product Owner:in kann die Developer:innen beeinflussen, indem er:sie dabei unterstützt, die Product-Backlog-Einträge zu verstehen und Kompromisse einzugehen.

    Commitment: Produkt-Ziel

    Das Produkt-Ziel beschreibt einen zukünftigen Zustand des Produkts, welches dem Scrum Team als Planungsziel dienen kann. Das Produkt-Ziel befindet sich im Product Backlog. Der Rest des Product Backlogs entsteht, um zu definieren, "was" das Produkt‐Ziel erfüllt.
    Ein Produkt ist ein Instrument, um Wert zu liefern. Es hat klare Grenzen, bekannte Stakeholder:innen, eindeutig definierte Benutzer:innen oder Kund:innen.
    Ein Produkt kann eine Dienstleistung, ein physisches Produkt oder etwas Abstrakteres sein.
    Das Produkt‐Ziel ist das langfristige Ziel für das Scrum Team. Das Scrum Team muss eine Zielvorgabe erfüllen (oder aufgeben), bevor es die nächste angeht.

    Sprint Backlog

    Das Sprint Backlog besteht aus dem Sprint-Ziel (Wofür), den für den Sprint ausgewählten Product- Backlog-Einträgen (Was) sowie einem umsetzbaren Plan für die Lieferung des Increments (Wie).
    Das Sprint Backlog ist ein Plan von und für die Developer:innen. Es ist ein deutlich sichtbares Echtzeitbild der Arbeit, welche die Developer:innen während des Sprints zur Erreichung des Sprint-Ziels ausführen wollen. Folglich wird das Sprint Backlog während des gesamten Sprints immer dann aktualisiert, wenn mehr gelernt wurde. Es sollte genügend Details beinhalten, damit sie ihren Fortschritt im Daily Scrum überprüfen können.

    Commitment: Sprint-Ziel

    Das Sprint-Ziel ist die einzige Zielsetzung für den Sprint.
    Obwohl das Sprint-Ziel ein Commitment der Developer:innen ist, bietet es Flexibilität in Bezug auf die genaue Arbeit, die erforderlich ist, um es zu erreichen. Das Sprint-Ziel schafft auch Kohärenz und Fokus und ermutigt somit das Scrum Team, zusammen statt in separaten Initiativen zu arbeiten.
    Das Sprint-Ziel wird während des Sprint-Planning-Events erstellt und dann zum Sprint Backlog hinzugefügt.
    Während die Developer:innen innerhalb des Sprints arbeiten, behalten sie das Sprint‐Ziel im Gedächtnis. Wenn sich herausstellt, dass die Arbeit von ihren Erwartungen abweicht, arbeiten sie mit dem:der Product Owner:in zusammen, um den Umfang des Sprint Backlogs innerhalb des Sprints zu verhandeln, ohne das Sprint-Ziel zu beeinflussen.

    Increment

    Ein Increment ist ein konkreter Schritt in Richtung des Produkt-Ziels. Jedes Increment ist additiv zu allen vorherigen Increments und gründlich geprüft, um sicherzustellen, dass sie alle zusammen funktionieren.
    Um einen Mehrwert zu erzielen, muss das Increment verwendbar sein.
    Innerhalb eines Sprints kann mehr als ein Increment erstellt werden. Deren Summe wird im Sprint Review vorgestellt, womit Empirie unterstützt wird.
    Ein Increment könnte jedoch auch schon vor Ende des Sprints an die Stakeholder:innen geliefert werden. Das Sprint Review sollte niemals als Barriere zur Lieferung von Wert angesehen werden.
    Arbeit kann nicht als Teil eines Increments betrachtet werden, solange sie nicht der Definition of Done entspricht.

    Commitment: Definition of Done

    Die Definition of Done ist eine formale Beschreibung des Zustands des Increments, wenn es die für das Produkt erforderlichen Qualitätsmassnahmen erfüllt.
    In dem Moment, in dem ein Product-Backlog-Eintrag die Definition of Done erfüllt, wird ein Increment geboren.
    Die Definition of Done schafft Transparenz, indem sie allen ein gemeinsames Verständnis darüber vermittelt, welche Arbeiten als Teil des Increments abgeschlossen wurden. Wenn ein Product-Backlog- Eintrag nicht der Definition of Done entspricht, kann es weder released noch beim Sprint Review präsentiert werden. Stattdessen wandert es zur zukünftigen Berücksichtigung in das Product Backlog zurück.
    Wenn die Definition of Done für ein Increment Teil der Standards der Organisation ist, müssen alle Scrum Teams diese als Mindestmass befolgen. Wenn sie kein Organisationsstandard ist, muss das Scrum Team eine für das Produkt geeignete Definition of Done erstellen.
    Die Developer:innen müssen sich an die Definition of Done halten. Wenn mehrere Scrum Teams an einem Produkt zusammenarbeiten, müssen sie eine gemeinsame Definition of Done definieren und sich alle daran halten.

    Schlussbemerkung

    Scrum ist kostenlos und wird in diesem Guide angeboten. Das Scrum-Rahmenwerk, wie es hier beschrieben wird, ist unveränderlich. Es ist zwar möglich, nur Teile von Scrum zu implementieren, aber das Ergebnis ist nicht Scrum.
    Scrum existiert nur in seiner Gesamtheit und funktioniert gut als Container für andere Techniken, Methodiken und Praktiken.

    Danksagungen

    Personen

    Von den tausenden Personen, die zu Scrum beigetragen haben, sollten wir diejenigen hervorheben, die zu Beginn von besonderer Bedeutung waren:
    Jeff Sutherland arbeitete mit Jeff McKenna und John Scumniotales, und Ken Schwaber arbeitete mit Mike Smith sowie Chris Martin - und sie alle arbeiteten zusammen. Viele weitere haben in den folgenden Jahren einen Beitrag geleistet. Ohne deren Hilfe wäre Scrum nicht so ausgefeilt, wie es heute ist.

    Scrum-Guide-Historie

    Ken Schwaber und Jeff Sutherland haben Scrum gemeinsam zum ersten Mal auf der OOPSLA Konferenz 1995 präsentiert.
    Diese Präsentation dokumentierte im Kern die Erkenntnisse, die Ken und Jeff in den vorherigen Jahren bei der Anwendung von Scrum gewonnen hatten, und stellte die erste formale Veröffentlichung der Definition von Scrum dar.
    Der Scrum Guide dokumentiert Scrum, wie es von Jeff Sutherland und Ken Schwaber über 30 Jahre lang weiterentwickelt wurde, gewachsen ist und aufrechterhalten wurde. Andere Quellen liefern Muster, Prozesse und Erkenntnisse, die das Scrum-Rahmenwerk ergänzen. Diese können zur Steigerung der Produktivität, des Werts, der Kreativität und der Zufriedenheit mit den Ergebnissen führen.
    Die vollständige Geschichte von Scrum wird an anderer Stelle beschrieben.
    Um die ersten Orte zu würdigen, an denen es erprobt wurde und sich bewährt hat, erkennen wir Individual Inc., Newspage, Fidelity Investments und IDX (jetzt GE Medical) als solche an.

    Änderungen des Scrum Guides von 2020 im Vergleich zu 2017

    Noch weniger vorschreibend
    Im Laufe der Jahre wurde der Scrum Guide ein wenig vorschreibender. Die Version von 2020 zielte darauf ab, Scrum wieder zu einem minimal ausreichenden Rahmenwerk zu machen, indem die vorschreibende Sprache entfernt oder abgeschwächt wurde.
    Zum Beispiel wurden die Daily-Scrum- Fragen entfernt, die Sprache um Product-Backlog-Eintrag-Attribute abgeschwächt, die Sprache um Retro-Items im Sprint Backlog aufgeweicht, der Abschnitt zum Sprint-Abbruch gekürzt und mehr.
    Ein Team, fokussiert auf ein Produkt.
    Ziel war es, das Konzept eines separaten Teams innerhalb eines Teams zu beseitigen, das zu einem "Stellvertreter"- oder "wir und sie"-Verhalten zwischen dem PO und dem Dev-Team geführt hat. Es gibt jetzt nur noch ein Scrum Team, das sich auf dasselbe Ziel fokussiert und drei verschiedene Ergebnisverantwortlichkeiten hat: PO, SM und Developer:innen.
    Einführung des Produkt-Ziels
    Der Scrum Guide von 2020 führt das Konzept eines Produkt-Ziels ein, um das Scrum Team auf ein grösseres, wertvolles Ziel auszurichten. Jeder Sprint sollte das Produkt näher an das übergeordnete Produkt-Ziel heranbringen. Eine Heimat für das Sprint-Ziel, die Definition of Done und das Produkt-Ziel
    Frühere Scrum Guides beschrieben das Sprint-Ziel und die Definition of Done, ohne ihnen wirklich eine Identität zu geben. Sie waren nicht ganz Artefakte aber waren diesen in gewisser Weise zugeordnet.
    Mit der Erweiterung um das Produkt-Ziel bietet die Version von 2020 mehr Klarheit darüber. Jedes der drei Artefakte enthält nun "Commitments" ihnen gegenüber.
    Für das Product Backlog ist dies das Produkt- Ziel, das Sprint Backlog hat das Sprint-Ziel und beim Increment handelt es sich um die Definition of Done (jetzt ohne Anführungszeichen). Sie existieren, um Transparenz und Fokus hinsichtlich des Fortschritts jedes Artefakts zu fördern.
    Selbstmanagement über Selbstorganisation
    Frühere Scrum Guides bezeichneten Development Teams als insofern selbstorganisierend, als dass sie wählen konnten, wer die Arbeit erledigt und wie gearbeitet wird.
    Mit einem stärkeren Fokus auf das Scrum Team betont die Version von 2020 ein selbstmanagendes Scrum Team. Dieses wählt, wer die Arbeit erledigt, wie und woran gearbeitet wird.
    Drei Sprint-Planning-Themen
    Zusätzlich zu den Sprint-Planning-Themen "Was" und "Wie" legt der Scrum Guide von 2020 den Schwerpunkt auf ein drittes Thema: "Wofür".
    Dieses bezieht sich auf das Sprint-Ziel.
    Allgemeine Vereinfachung der Sprache für ein breiteres Publikum
    Der Scrum Guide von 2020 hat einen Schwerpunkt auf die Eliminierung redundanter und komplexer Aussagen sowie die Beseitigung aller verbleibenden Rückschlüsse auf IT-Arbeit (z.B. Test, System, Design, Requirements, etc.) gelegt. Der Scrum Guide umfasst jetzt weniger als 13 Seiten [Anm. d. übersetzer: Im Deutschen sind es bis zur Danksagung 14 bis zur Danksagung geworden.].

    Übersetzung

    Dieser Guide wurde von der englischen Originalversion, bereitgestellt von Ken Schwaber und Jeff Sutherland, übersetzt. Hierzu beigetragen haben: Kontaktinformationen:
    Name der Übersetzungsgruppe: GermanScrumTranslators
    Bewerbungen werden angenommen unter: https://www.linkedin.com/groups/4071080/
    Primärer Ansprechpartner / Product Owner: Dominik Maximini
    Kontaktadresse: translation@valuerise-consulting.de

    Änderungshistorie der Übersetzung

    Übersetzungs-Glossar

    Version 3.2, Stand 03.12.2020
    Übersetzungs-Grundregeln, an die wir uns gehalten haben:
    Englischer Begriff Deutscher Begriff
    accountable ergebnisverantwortlich
    adaptation Anpassung
    Commitment Commitment
    Courage Mut
    cross-functional interdisziplinär
    Daily Scrum Daily Scrum
    Definition of Done Definition of Done
    the Developer, the Developers der:die Developer:in, die Developer:innen
    DoneDone
    empiricismEmpirie
    eventEvent
    feedbackFeedback
    focusFokus
    forecastVorhersage
    frameworkRahmenwerk
    incrementdas Increment
    inspect & adaptÜberprüfung und Anpassung
    inspectionÜberprüfung
    Lean ThinkingLean Thinking
    OpennessOffenheit
    process frameworkProzessrahmenwerk
    productProdukt
    Product Backlogdas Product Backlog
    Product Backlog iitemProduct-Backlog-Eintrag
    Product GoalProdukt-Ziel
    the Product Ownerder:die Product Owner:in
    refinementRefinement
    RespectRespekt
    responsibleumsetzungsverantwortlich
    Scrum ArtefactsScrum-Artefakte
    ScrumScrum
    Scrum EventsScrum Events
    Scrum GuideScrum Guide
    the Scrum Masterder:die Scrum Master:in
    Scrum TeamScrum Team
    self-managementSelbstmanagement
    Sprint Backlogdas Spriint Backlog
    Sprint Backlog itemSprint-Backlog-Eintrag
    Sprint GoalSprint-Ziel
    Sprint Planningdas Sprint Planning
    Sprint progressSprint-Fortschritt
    Sprint Retrospectivedie Sprint Retrospective
    Sprint Reviewdas Sprint Review
    timeboxdie Timebox
    timeboxedzeitlich beschränkt
    valueWert
    TransparencyTransparenz

    Erklärungsvideo

    Kurskalender

    Stolpersteine

    Das Persona-Modell

    Kommunikationstechniken

    Werbung / Anzeige:


    Erfolgreiche Gespräche durch aktives Zuhören (expert-taschenbücher)

    Aktives Zuhören nach Carl R. Rogers: Erfolgreiches Zuhören in der professionellen Gesprächsführung und in der Wissensgesellschaft

    Modern Leading - der neue Ratgeber für Führungskräfte: Wie Sie Mitarbeiter führen und motivieren. Effektive Führungsstile & -techniken zur authentischen Führung

    Das Kanban- / Scrum-Board

    Werbung / Anzeige:

    Burn-Down-Chart

    Werbung / Anzeige:



    Burn down chart: Beginner's Guide - Second Edition

    Bücher