Quo Vadis Scrum? Um zu verstehen wohin sich Scrum entwickeln wird ist es hilfreich sich mit der Historie des Scrum Guides zu beschäftigen. Genau das hab ich in diesem Blogpost vor.
Die erste Implementierung von Scrum ist 30 Jahre her als 1993 Jeff Sutherland, John Scumniotales und Jeff McKenna bei der Easel Corporation gearbeitet haben. Inspiriert von dem HBR Artikel "The New New Product Development Game” (1) nennen sie ihren neuen, innovativen Ansatz zur Produktentwicklung Scrum - und nutzen damit die Sport Metapher einer Mannschaft, die sich als Einheit übers Feld bewegt.
Erstmals öffentlich vorgestellt wurde Scrum von Jeff Sutherland zusammen mit Ken Schwaber in ihrem Paper zur OOPSLA Konferenz 1995 in Austin, Texas (2). 2001 kommen die beiden mit 15 weiteren Kollegen in Snowbird Utah zusammen um das Agile Manifest (3) zu verfassen: Ein Aufruf Software radikal anders zu entwickeln.
Seitdem verbreitet sich dieser ganzheitliche, teamzentrische und kundenorientierte Ansatz in (und bald auch ausserhalb) der IT Produktentwicklung. Mehrere Bücher (4,5,6,7) beschreiben den Ansatz, der sich selbst weiterentwickelt und neben anderen vor allem Ideen aus dem Extreme Programming absorbiert.
2010 veröffentlichen Jeff Sutherland und Ken Schwaber den ersten Scrum Guide (8). Nicht nur um Exaktheit und detaillierte Hilfestellung sicherzustellen, sondern auch um die Einfachheit dieses Rahmenwerkes zu unterstreichen (und wiederherzustellen).
Nach 2010 veröffentlichen die beiden sechs weitere Versionen (8).
Dieser Blogpost gibt eine Übersicht über die Veränderungen die ihren Weg in den Scrum Guide gefunden haben und stellt alle Scrum Guides zur eigenen Recherche zur Verfügung.
Februar 2010: der erste Scrum Guide
 |
| Scrum Guide 2010 |
13 Seiten lang, noch unter dem Branding der Scrum Alliance nennt der Scrum Guide bereits Rollen (Scrum Master, Product Owner, Team) und Events (damals noch Time-boxes), Crossfunktionalität, Selbstorganisation und empirische Prozesskontrolle, macht aber noch nicht die Artefakte explizit.
Der erste Scrum Guide enthält dafür noch Release Planning Burndown-Charts, Buchreferenzen, Hinweise zum skalierten Scrum sowie eine Vielzahl von separat ausgewiesenen Tipps.
Insgesamt wird noch eine stärker vorschreibende Sprache verwendet. So sind z.B. die 3 Fragen im Daily Scrum vorgeschrieben.
Juli/Oktober 2011: Konsolidierung
In den Versionen von 2011 finden die Artefakte einen Platz im Guide, das Team wird zum Development Team mit einer empfohlenen Größe zwischen drei und neun Personen, das Product Backlog Grooming wird hinzugefügt, die Timeboxes werden zu Events. Der Guide definiert nun auch erstmals Scrum:
Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value.
Vieles findet keinen Platz mehr: Sprint Backlog items, die separaten Tipps, Buchreferenzen, die "Chicken and Piggs" Geschichte und viele Praktiken verschwinden. Burndown-Charts und Release Planning werden optional. Das Entwicklungsteam commitet sich im Sprint Planning nicht mehr auf die geplante Arbeit sondern erzeugt eine Vorhersage ("forecast") was sie schaffen.
Insgesamt verwendet der Scrum Guide eine weniger vorschreibende Sprache und schafft damit mehr Raum für Flexibilität in der Anwendung. So ist z.B. auch das Product Backlog nicht mehr priorisiert ("sorted in order of priority") sondern geordnet ("ordered") und gibt damit dem Product Owner mehr Raum für andere Ordnungstechniken.
Der Scrum Guide enthält jetzt Acknowledgements und einen Verweis, das Scrum das Werk vieler und nicht nur zweier Personen ist. Er wächst auf 16 Seiten an.
Juli 2013: Sprint Planning: ein Event!
Sprint Planning ist jetzt ein Event, das sich auf das Was und dann auf das Wie fokussiert. Das Sprint Goal erhält mehr Bedeutung und Fokus. Und das Product Backlog Grooming wird zum Refinement. Die drei Fragen im Daily werden geschärft und zielen jetzt auf Fortschritt des Development Teams im Bezug auf das Sprint Goal ab, um eben kein Reporting Meeting des Einzelnen abzubilden (Gestern?, Heute?, Blocker?; Nächster!)
Juli 2016: Die Scrum Werte kommen!
Ein Abschnitt über die Scrum Werte wird hinzugefügt. Obwohl Scrum Werte bereits im ersten Scrum Guide erwähnt werden, werden sie nun ausformalisiert. So wird erstmalig neben der reinen Mechanik auch die Eigenschaften beschrieben, die erfolgreiche Scrum Teams ausprägen und zeigen: Fokus, Respekt, Offenheit, Courage und Commitment. Mit den Werten wird Vertrauen möglich. Mit Vertrauen Transparenz. Transparenz ermöglicht Inspektion. Und Inspektion Anpassung. Die Säulen der empirischen Prozesskontrolle.
When the values of commitment, courage, focus, openness and respect are embodied and lived
by the Scrum Team, the Scrum pillars of transparency, inspection, and adaptation come to life
and build trust for everyone.
Der Scrum Guide ist jetzt 17 Seiten lang.
November 2017: Breiter und auch enger
Der Scrum Guide wächst auf 19 Seiten. Er beschreibt nun auch Einsatzgebiete von Scrum und unterstreicht, das Scrum generell geeignet ist Problemstellungen in der komplexen Wissensarbeit (und nicht nur in der IT) zu lösen.
Die Rolle des Scrum Masters und seiner Unterstützung gegenüber dem Product Owner, dem Scrum Team und der umgebenden Organisation werden geschärft.
Die drei Fragen im Daily Scrum werden optional und geben damit dem Development Team mehr Freiheiten in der Gestaltung des Daily Scrums. Timeboxen werden als Maximallängen definiert, Events sind ansonsten frei in der zeitlichen Gestaltung und können bis zu der Maximallänge dauern ("at most").
Spannend: Obwohl der Scrum Guide über die Jahre immer breiter, immer weniger vorschreibend wurde, wird er nun erstmals wieder verpflichtender: Das Sprint Backlog enthält nun zwingend mindestens eine Verbesserung aus der vorangegangenen Sprint Retrospektive. Hierdurch soll sichergestellt werden, das Verbesserungsmassnahmen aus der Sprint Retrospektive auch Raum in der nächsten Sprint Planung bekommen, damit angegangen und umgesetzt werden können.
November 2020: Ein Team, ein Ziel!
Der aktuelle Scrum Guide. Nun wieder schlanker. Gleichzeitig wird die Sprache generischer und noch inklusiver.
Es werden viele Dinge entfernt, die Scrum mit IT in Verbindung bringen. IT Terminologie wie Architektur, Anforderung, Design oder Testing wird entfernt. Der Scrum Guide spricht nun von benutzbaren ("usable") und nicht mehr von verwendbaren ("releasable") Inkrementen. Auch die verpflichtende Verbesserung aus der letzten Sprint Retrospective verschwindet wieder. Genauso wie das Konzept des Servant Leadership - laut Ken die am meisten missverstandenste Formulierung im Scrum Guide (*). Der Scrum Master ist jetzt "a true leader who serves".
Die Rollen werden mit Verantwortlichkeiten ersetzt um klar zwischen Zuständigkeit ("responsibility") und Verantwortlichkeit ("Accountability") zu unterscheiden.
Und: es gibt nur noch ein Team, das Scrum Team. Kein Team im Team mehr sondern ein Scrum Team das gemeinsam verantwortlich für den Erfolg ist. Insgesamt ist das Scrum Team jetzt bis zu 10 Personen gross (als Empfehlung). Selbstorganisation wird zu Selbstmanagement.
Die Definition of Done und das Sprint Goal bekommen ein Zuhause im Scrum Guide. Zusammen mit dem neu hinzugefügten Product Goal werden sie zu Commitments auf die Artefakte, die Fokus, Alignment, Transparenz und klare Verantwortlichkeit ermöglichen. Das neu hinzugefügte Commitment auf das Product Backlog, das Product Goal, schliesst als strategisches Ziel die Lücke zwischen taktischem, kurzfristigen Ziel und langfristiger Vision. Dem Scrum Team ist es nun möglich die täglich im Daily Scrum geplante Arbeit zu mittelfristigen, zu strategischen Zielen zu verknüpfen, den Sinn dahinter zu erfahren - oder zu erfragen.
Aus dem gleichen Grund wird im Sprint Planning neben dem Was und dem Wie nun auch das Wozu des Sprints diskutiert.
Der Scrum Guide ist vorerst nur noch 13 Seiten lang.
Wie geht es weiter?
Der Scrum Guide wird sich weiterentwickeln. Die Veränderungen 2017 und 2020 deuten die Richtung an. Aus meiner Sicht wird die Entwicklung weiter dahin gehen, noch breiter und noch integrativer zu werden um komplexe Probleme adaptiv zu lösen.
Sehr hilfreich fand ich den Shift 2016, als die Scrum Werte ihren Weg in den Scrum Guide gefunden haben und damit die Interaktion miteinander noch stärker in der Vordergrund gewandert ist.
In diese Richtung darf es aus meiner Sicht ruhig weitergehen. Letztendlich zählen die Interaktionen der Menschen mehr als strukturgebende Prozesse. Eben:
Individuals and Interactions over processes and tools
Agile Manifesto
Welche Veränderung wünscht Du Dir in der nächsten Version? Sprich doch drüber in den Kommentaren!
Quellen
Mehr
Kommentare
Kommentar veröffentlichen