Einfaches Scrum

August 18, 2011 at 3:14 pm 2 comments


Dies ist die Übersetzung des Blog-Artikels „Simple Scrum“ von Tobias Mayer in der Version vom 01.01.2010 (http://agileanarchy.wordpress.com/2009/09/20/simple-scrum/).

Die Übersetzung habe ich (Stefan Roock, stefan.roock@it-agile.de) vorgenommen. Ich habe mich entschieden. an einigen Stellen leicht vom Original abzuweichen mit der Absicht, einen Sachverhalt einfacher zu erklären.

Ich denke an Scrum als etwas fast unfassbar Einfaches, das häufig unnötig verkompliziert wird. Es ist diese Verkomplizierung, die so viele Missverständnisse verursacht und zu schlechten Anwendungen von Scrum führt. Die folgende Beschreibung von Scrum hat das Ziel, Scrums Geist der Einfachheit einzufangen.

Scrum ist ein Framework, um die Art und Weise zu verbessern, in der Menschen arbeiten, oder wie auf der Scrum Alliance-Website definiert „ein team-basiertes Framework zur Entwicklung komplexer Systeme und Produkte“. Scrum benutzt einen iterativen Prozess in dem die Iterationen (aka Sprints) so kurz wie sinnvoll möglich gehalten werden. Die Sprints erzeugen einen gleichmäßigen Rhythmus der durch Planung, Durchführung und Reflektion pulsiert. Diese strikten, rhythmischen Time-Boxen von Scrum fördern auf frappierende Weise organisatorische Dysfunktionen zu Tage.

Scrum definiert drei Rollen (Scrum Master, Product Owner und Team), erfordert eine priorisierte Menge von Zielen, ein Commitment für jeden Sprint und eine einfache Art, Fortschritt zu messen. Scrum benutzt Zeremonien mit Timeboxen, um zu planen und auf täglicher sowie Sprint-Basis zu inspizieren und zu adaptieren.

Das „Was“ (das Ziel) und das „Wie“ (der Weg) werden klar unterschieden. Scrum erfordert klaren Fokus, Commitment und vollständige Transparenz auf allen Ebenen; es hebt auf bestimmte menschenzentrierte Werte ab, einschließlich (aber nicht eingeschränkt auf) Vertrauen, Integrität, Mut und Respekt.

Rollen
Der ScrumMaster ist eine dienende Führungskraft (Servant Leader) für das Team und ein Change Agent in der Organisation. Der Product Owner ist die Hauptstimme des Kunden, etabliert eine fesselnde Vision und benutzt einen Prozess kontinuierlicher Priorisierung, um die Vision umzusetzen. Das Team ist eine selbstorganisierte, cross-funktionale, bevollmächtigte Gruppe, die die Vision in das Produkt oder den Service umsetzt.

Artefakte
Ein Backlog (Auftragsbestand) aus Anforderungen oder Zielen ist immer vorhanden. Es enthält zu jeder Zeit all die Dinge, von denen wir möchten, das das Produkt oder der Service sie enthalten. Es ist eine lebendige Liste, kontinuierlich im Fluss und trotzdem jederzeit nach Priorität geordnet, die sich über die Zeit ändern wird. Die Einträge des Backlogs fokussieren auf das „Was“. Das Sprint-Commitment ist eine Untermenge des Backlogs, manchmal herunter gebrochen auf Arbeitsaufgaben (Tasks), die das „Wie“ beschreiben. Scrum fordert einfache Metriken, z.B. die verbleibende Restarbeit oder gelieferter Geschäftswert. Diese Metriken sollten verwendet werden, um die Wirklichkeit zu erfassen – nicht, um Erfolg oder Misserfolg zu festzustellen. Nur Metriken der Wirklichkeit können wir vertrauen, dass sie dem Team keinen Anreiz für Quick-Fix-Verhalten geben.

Zeremonien
Das Team und der Product Owner treffen sich vor dem Start jeden Sprints, um die Arbeit zu planen. Das Team committet sich auf priorisierte Arbeitspakete, die „wohldefinierte Ergebnisse“ (das Ziel) haben und es wird von ihm erwartet, dass es das fertige Produkt gemäß diesen Kriterien am Sprintende liefert. Wie das Team seine Arbeit erledigt (der Weg) ist allein ihm überlassen. Jeden Arbeitstag treffen sich die Teammitglieder an einem visuellen Board (z.B. Taskboard), um sich abzustimmen und Hilfe einzufordern und anzubieten. Am Ende jedes Sprints begutachten Stakeholder und Konsumenten die abgeschlossene Arbeit und machen Vorschläge für Anpassungen. Nach dem Review reflektieren die Teammitglieder über ihren Prozess, suchen nach Verbesserungsmöglichkeiten und committen sich auf Veränderungen ihrer Arbeitsweise. Jeder Sprint produziert ein verbessertes Produkt oder einen verbesserten Service und – sogar noch besser – ein glücklicheres Team.

Das ist mehr oder weniger die Beschreibung von Scrum, die seit der Veröffentlichung des ersten Scrum-Buchs 2003 existiert. Ich habe sie aus dem Software-Kontext herausgelöst, einige Begriffe fallen gelassen, um auf die grundlegenden Prinzipien zu fokussieren und versucht, sie auf ihre Essenz zu kondensieren. Ich habe nichts hinzugefügt oder weggelassen.

Entry filed under: #, it-agile-blog-planet. Tags: .

Artikel: “Die Architekturvision in Scrum: Vorausplanung und emergentes Design balancieren” Teamwork during the Daily Scrum

2 Comments Add your own

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: