Scrum – eine kurze Einführung

Einleitung

Während man beim klassischen Entwicklungsansatz nach dem sog. (linearen) Wasserfall-Modell (Anforderungen → Entwurf → Implementierung → Überprüfung → Wartung) möglichst detaillierte Vorarbeiten leistet mit entsprechend genauen Arbeitsanweisungen, erhalten Scrum Teams entsprechend der agilen iterativen Scrum Vorgehensweise genaue Zielvorgaben, was die Zielerreichung anbelangt. Der Weg dorthin entwickelt sich jedoch innerhalb eines hochqualifizierten und interdisziplinären Scrum Teams während der Implementierung.

Geschichte

  • der Ursprung findet sich in den „Lean-Prinzipien“ der japanischen Automobilproduktion (best quality, lowest cost, shortest lead time, best safety,high morale)
  • Jeff Sutherland schuf die neue Rolle des PM als Moderator / Scrum Master
  •  1995: erster Vortrag von Ken Schwaber über Scrum auf einer Konferenz
  • 2001: erstes Buch über Scrum von Schwaber (zusammen mit Mike Beedle) „Agile Software Development with Scrum“

Agiles Manifest

Scrum verkörpert die Werte der agilen Software-Entwicklung, die 2001 im Agilen Manifest von Ken Schwaber, Jeff Sutherland und anderen formuliert wurden:

Zusammenfassung:

  • Menschen und Interaktionen sind wichtiger als Prozesse und Werkzeuge.
  • Funktionierende Software ist wichtiger als umfassende Dokumentation.
  • Zusammenarbeit mit dem Kunden ist wichtiger als die ursprünglich formulierten Leistungsbeschreibungen.
  • Eingehen auf Veränderungen ist wichtiger als Festhalten an einem Plan.

Oft wird fälschlicherweise angenommen, dass im Scrum Elemente wie Prozesse, Dokumentation und Leistungsbeschreibungen vernachlässigt oder gar ignoriert werden können. Das sagen die Richtlinien allerdings nicht aus. Sie stehen im Scrum nicht an erster Stelle, sind aber unabdingbar für einen planbaren und nachvollziehbaren Projektverlauf.

 Rollen

Product Owner

  •    stellt fachliche Anforderungen und priorisiert sie
  • ist für die Eigenschaften und den wirtschaftlichen Erfolg des Produkts verantwortlich
  • Zur Festlegung der Produkteigenschaften verwendet der Product Owner das Product Backlog. Darin trägt er in Zusammenarbeit mit dem Entwicklungsteam und den Stakeholdern die Anforderungen an das Produkt ein. Der Product Owner ordnet, detailliert und aktualisiert das Product Backlog regelmäßig im Product Backlog Refinement. Neben Werkzeugen wie Jira kann man als Dokumentationswerkzeug hier das Dokumentations-Pattern Requirement nutzen. Übergreifend kann auch das Dokumentations-Pattern Projekt oder Dokumentations-Pattern Produkt zur Dokumentation dienen.
  • er hält der Product Owner regelmäßig Rücksprache mit den Stakeholdern, um deren Bedürfnisse und Wünsche zu verstehen

Scrum Team

  • mindestens 3 bis max. 9 Mitglieder
  • ist für die Lieferung der Produktfunktionalitäten in der vom Product Owner gewünschten Reihenfolge verantwortlich
  • organisiert sich selbst!
  • es lässt sich von niemandem, schon gar nicht vom Scrum Master oder gar PO, vorschreiben, wie es Backlogeinträge umzusetzen hat
  • das Team sollte in der Lage sein, das Ziel eines jeweiligen Sprints ohne größere äußere Abhängigkeiten zu erreichen (deshalb ist eine interdisziplinäre Besetzung des Entwicklungsteams wichtig, z. B. mit Architekt, Entwickler, Tester, Dokumentationsexperte und Datenbankexperte)
  • für den Erfolg oder Misserfolg eines Sprints ist immer das gesamte Team verantwortlich, niemals eine Einzelperson
  • Aufgaben:
    • Entwicklung
    • die Schätzung des Umfangs der Einträge im Product Backlog (bzw.im Product Backlog Refinement)
    • das Team bricht in der Sprint Planung die für einen Sprint ausgewählten Einträge aus dem Product Backlog in Arbeitsschritte (Tasks) herunter, deren Bearbeitung in der Regel nicht länger als einen Tag dauert (Ergebnis = Sprint Backlog)

Scrum Master

  • ist dafür verantwortlich, dass Scrum gelingt.
  • managed den Prozess und beseitigt Hindernisse
  • arbeitet mit dem Entwicklungsteam zusammen, gehört aber selbst meist nicht dazu
  • führt die Scrum-Regeln ein und überprüft deren Einhaltung, er moderiert die Treffen
  • kümmert sich um die Behebung von Störungen und Hindernissen (z.B. Probleme in Kommunikation mit Team und PO oder innerhalb des Teams)
  • ist gegenüber dem Entwicklungsteam eine dienende Führungskraft. Er gibt einzelnen Team-Mitgliedern keine Arbeitsanweisungen. Weder beurteilt er sie, noch belangt er sie disziplinarisch

Scrum Artefakte

Product Backlog

  • Das Product Backlog ist eine geordnete Auflistung der Anforderungen an das Produkt
  • ist dynamisch und wird ständig weiterentwickelt. Alle Arbeit, die das Entwicklungsteam erledigt, muss seinen Ursprung im Product Backlog haben
  • Der Product Owner ist für die Pflege des Product Backlogs verantwortlich
  • Der Product Owner verantwortet die Reihenfolge bzw. Priorisierung der Einträge

Sprint Backlog

  • Das Sprint Backlog ist der aktuelle Plan der für einen Sprint zu erledigenden Aufgaben
  • Es umfasst die Product Backlog-Einträge, die für den Sprint ausgewählt wurden, und die dafür nötigen Aufgaben

Product Increment

  • Das Inkrement ist die Summe aller Product-Backlog-Einträge, die während des aktuellen und allen vorangegangenen Sprints fertiggestellt wurden
  • Am Ende eines Sprints muss das neue Inkrement in einem nutzbarem Zustand sein und der Definition of Done entsprechen.

Aktivitäten

Sprint Planning 1

  • WAS kann im Sprint entwickelt werden?
  • Der Product Owner stellt dem Entwicklungsteam die im Product Backlog festgehaltenen Produkteigenschaften in der zuvor priorisierten Reihenfolge vor
  • Das Product Backlog sollte im Sprint zuvor im Product Backlog Refinement (oder direkt Planning 1) so weit vorbereitet worden sein, dass es geordnet, gefüllt und die Einträge für den nächsten Sprint geschätzt (Planning Poker!) sind.
  • Das gesamte Scrum Team arbeitet im ersten Teil der Planung daran, ein gemeinsames Verständnis für die im Sprint zu erledigende Arbeit zu entwickeln.
  • Dabei werden die Eigenschaften und die Akzeptanzkriterien besprochen, beispielsweise die Gebrauchstauglichkeit.
  • Außerdem einigt sich der Product Owner mit dem Entwicklungsteam auf die Kriterien, die am Ende des Sprints darüber entscheiden, ob die neue Funktionalität fertig ist oder nicht (Definition of Done).
  • Ziel ist die Fertigstellung eines auslieferbaren Produkts: ein Produktinkrement, das hinreichend getestet und integriert ist, um für den Benutzer freigegeben werden zu können.
  • Anschließend prognostiziert das Entwicklungsteam die Anzahl der Product-Backlog-Einträge, die es im nächsten Sprint liefern kann.
  • Die Entscheidung, wie viele Einträge im nächsten Sprint umgesetzt werden, liegt alleine beim Team, während die Entscheidung über die Reihenfolge alleine beim Product Owner liegt.
  • Aus den ausgewählten Product-Backlog-Einträgen formuliert das Team ein Sprintziel
  • hier können Dokumentationspattern Requirement, Dokumentationspattern ChangeRequest oder Dokumentationspattern Feature als unterstützende Dokumentationsmittel dienen

Sprint Planning 2

  • WIE wird im Sprint entwickelt?
  • hier plant das Entwicklungsteam im Detail, welche Aufgaben (Tasks) zum Erreichen des Sprintziels und zur Lieferung der prognostizierten Product-Backlog-Einträge notwendig sind.
  • Diese Planung macht das Entwicklungsteam, wobei der Product Owner für Fragen in Reichweite sein sollte.
  • Oftmals bilden sich zur Beantwortung der Wie-Frage Kleingruppen, in denen verschiedene Aspekte wie z. B. Architektur, Datenelemente und Schnittstellen geklärt werden.
  • Ergebnis ist das Sprint Backlog: der detaillierte Plan für den nächsten Sprint. Er enthält die für den Sprint geplanten Product-Backlog-Einträge und die Aufgaben zu deren Umsetzung.: bewährte Vorgehensweise: erst alle Aufgaben auf Zettel schreiben, dann erst in Jira übertragen.
  • hier bietet sich als Übersicht eine Liste der auch in Planning 1 verwendeten Patterns an.

Daily Scrum

  • täglich
  • max. 15 Minuten (time boxed)
  • Scrum Master und Product Owner häufig anwesend, jedoch nicht aktiv beteiligt
  • Zweck des Daily Scrum ist der Informationsaustausch
  • Im Daily Scrum werden keine Probleme gelöst, es dient nur als Überblick über den aktuellen Stand
  • jeder sagt, was es seit dem letzten Daily Scrum erreicht hat, was es bis zum nächsten Daily Scrum erreichen möchte, und was dabei im Weg steht.
  • Beim Daily Scrum kann offensichtlich werden, dass die Erledigung einer Aufgabe länger als geplant dauert. Dann ist es sinnvoll, den Task in kleinere Aufgaben aufzuteilen, die dann auch von anderen Mitgliedern des Entwicklungsteams übernommen werden können.
  • Treten beim Daily Scrum Fragen auf, die sich nicht innerhalb der strikten 15-Minuten-Vorgabe beantworten lassen, so werden sie entweder notiert und dem Scrum Master übergeben, oder ihre Beantwortung wird auf ein späteres Meeting, häufig direkt im Anschluss, verlegt.
  • hier bietet sich das Dokumentationspattern Meeting an

Sprint Review

  • Time-boxed (4 h)
  • Maximal eine Stunde Vorbereitungszeit pro Person
  • Das Team selbst – nicht irgendein übergeordneter Manager – zeigt dem Product Owner und anderen interessierten Personen live am funktionierenden System, was es innerhalb des Sprints erreicht hat.
  • Wichtig: keine Dummies, kein Powerpoint! Nur fertige Produktfunktionalität (Increment of Potentially Shippable Functionality) darf vorgeführt werden.
  • Feedback seitens Product Owner, Stakeholders u.a. Anwesenden ist erwünscht und fließt in die weitere Arbeit ein.
  • Auf Basis des Gezeigten entscheidet später der Product Owner, ob das Inkrement produktiv gesetzt oder weiter entwickelt werden soll. Diese Möglichkeit hat er nach jedem Sprint. So ist gewährleistet, daß in sich abgeschlossene funktionale Bausteine eines Gesamtsystems möglichst früh einen Nutzen erzeugen.
  • ebenso kann man hier Dokumentationspattern Meeting nutzen

Sprint Retrospektive

  • dient zur Verbesserung des Teams und seine Zusammenarbeit während des Projekts
  • wird nach jedem Sprint gemacht
  • Meeting innerhalb einer 3-stündigen Time-Box im Anschluß an das Sprint Review Meeting, moderiert vom ScrumMaster.
  • Das Team diskutiert rückblickend den soeben zu Ende gegangenen Sprint und überlegt sich, was weshalb gut oder schlecht gelaufen ist und was man tun könnte, um den nächsten Sprint produktiver und/oder angenehmer (ja, Spaß bei der Arbeit ist wichtig!) zu machen.
  • Typische Fragen im Meeting können beispielsweise sein:
  • Wie zufrieden sind wir mit dem Ergebnis des letzten Sprints?
  • Haben wir unsere Sprint-Ziele erreicht und wenn nein: Warum nicht?
  • Wie können wir die Zusammenarbeit im Team und auch mit dem Product Owner verbessern?
  • Wie können wir die Produktqualität optimieren?
  • Phase 1:Set the Stage:
    • In dieser Phase der Retrospektive werden alle Beteiligten auf das Meeting eingestimmt und die Rahmenbedingungen erläutert. Wichtig ist hier, dass jeder Teilnehmer einen aktiven Beitrag leistet, um jeden einzelnen zu “aktivieren”.
  • Phase 2: Gather data
    • Diese Phase dient dazu, alle möglichen Informationen zum Betrachtungszeitraum (z.B. letzter Sprint) zu sammeln. Dabei können die Teilnehmer etwa danach gefragt werden, wie sie persönlich die
    • Stimmung im Team oder auch den Verlauf des letzten Sprints empfunden haben.
  • Phase 3: Derive insights
    • Mit dieser Phase geht die Retrospektive in die aktive Verbesserung der Zusammenarbeit über. Aus den zuvor gesammelten Informationen soll das Team Verbesserungsvorschläge erarbeiten und diskutieren. Im einfachsten Fall geht das mit der Aktion “+/Delta“.
    • Beispiel-Aktion: +/Delta und der Blick nach vorne: Das Plus-Delta-Vorgehen besticht durch zwei Aspekte: Zum einen durch das explizite Ansprechen positiver Gesichtspunkte, zum anderen durch den Ansatz, lösungsorientiert zu arbeiten statt zu kritisieren. Natürlich ist es auch wichtig, sich der Stärken bewusst zu sein – umso schlimmer, dass wir quasi nie über sie sprechen. Kritik dagegen fällt uns viel leichter, bringt uns jedoch nur indirekt weiter. Plus-Delta zielt deshalb darauf ab, eine Kritik direkt in einen Verbesserungsvorschlag umzuwandeln.
  • nutzen könnte man hier Dokumentationspattern Learning