Scrum-Teams vs. selbstorganisierte agile Beta-Teams

Vor Kurzem ist der Scrum Scale Guide 1.0 erschienen und im November 2018 gab es kleine Aktualisierungen am Scrum Guide. Beispielsweise wurde dabei der Eingangstext erweitert:

Scrum wurde ursprünglich dazu entwickelt, um Produkte zu managen und zu entwickeln. Seit den frühen 1990er Jahren wird Scrum weltweit ausgiebig genutzt zur:
  1. Erforschung und Identifizierung rentabler Märkte, Technologien und Produktfähigkeiten;
  2. Entwicklung von Produkten und Verbesserungen;
  3. Auslieferung von Produkten und Verbesserungen, auch vielfach pro Tag;
  4. Entwicklung und Aufrechterhaltung von Cloud-Umgebungen (online, secure, on-demand) und anderer Produktivumgebungen; sowie,
  5. Erhaltung und Erneuerung von Produkten.
(…)
Scrum bewährt sich täglich im Umgang mit Komplexität, da Technologie-, Markt-und Umweltkomplexität en und deren Interaktionen rapide zugenommen haben.

Die Aktualisierung und die Erscheinung des Scrum Scale Guide sind ein guter Anlass einmal genauer hinzuschauen worin eigentlich der Unterschied zwischen einem Scrum-Team und einem agilen Team besteht. Wie kann das voneinander abgegrenzt werden?

Was ist Scrum?

Während Scrum ein leichtgewichtiger Organisationsrahmen für Teams in der Produktentwicklung ist, der das Versprechen macht, das fortlaufend der größtmögliche Geschäftswert geliefert wird, ist der Begriff der „Agilität“ relativ unspezifisch wenn nicht sogar undefiniert.

Scrum kann als Teilmenge der agilen Ansätze, Werkzeuge und des Mindset gesehen werden. Die Besonderheit dabei ist das der Scrum Guide, das Framework und dazugehörige Zertifizierungen inzwischen sehr detailliert definieren was Scrum ist und was nicht.

Scrum – ein formales Regelwerk?

Die Fragebögen der typischen Scrum-Zertifizierungen und Scrum-Checklisten zeigen das es sich um ein formales Framework handelt. „Richtiges“ Scrum als solches ist validier- und überprüfbar.

Beispiele:

  • Ein Scrum-Team besitzt mehr als drei und weniger als neun Mitglieder, mit Scrum Master und Product Owner weniger als elf
  • Pro Team gibt es einen Scrum Master und einen Product Owner
  • Ein Sprint ist kürzer als 30 Tage
  • Am Beginn eines Sprints gibt es ein Sprint Planning Meeting mit fester Timebox, täglich ein Daily Meeting mit maximal 15 Minuten und zum Sprintabschluss ein Sprint Review Meeting mit einer angeschlossenen Retrospektive
  • Im Daily Scrum werden drei feste Fragen beantwortet
  • Mit dem Burndownchart kann die Velocity sichtbar gemacht werden, das Entwicklungsteam aktualisiert das Chart
  • Alle Backlog-Items sind geschätzt
  • Nur der Product Owner darf die Prioritäten im Backlog ändern
  • Die Verfeinerung des Backlogs sollte nur 10 % der Kapazität des Entwicklungsteams beanspruchen
  • Der Sprint Backlog wird täglich aktualisiert
  • Scrum besitzt fünf feste Werte und basiert auf drei wesentlichen Säulen
  • Es gibt keinen Teamleiter der das Team managt
  • Das Team besitzt ein Impediment Backlog und kennt die obersten drei Hindernisse
  • Alle Meetings sind timeboxed und besitzen neben einer definierte Maximallänge einen festen Teilnehmerkreis
  • Nach jedem Sprint wird eine Demo durchgeführt
  • Es gibt eine Definition of done
  • usw. usf.

Diese Regeln und Spezifikationen bilden dabei sicherlich den elementaren Unterschied zwischen einem Scrum- oder einem selbstorganisierten agilen Beta-Team.

Der Unterschied zu einem agilen Beta-Team

Eine formale Definition eines agilen Beta-Teams gibt es natürlich nicht. An dieser Stelle kann jedoch eine nützliche Annäherung gefunden werden.

Das agile Team als solches agiert, von außen betrachtet, als „Blackbox“. Es bekommt ein hohes Ziel und entscheidet dabei selbst „Wie?“ es arbeitet. Ohne Zwang oder sonstige Vorgaben. Darauf nimmt von außen keiner Einfluss. Natürlich gelten die üblichen Gesetze, allerdings wird auf sonstigen bürokratischen Überhang verzichtet.

Neben einer anspruchsvollen Vision bekommt das Team praktisch die Ressourcen die es zur Umsetzung braucht und einen Auftraggeber der als Abnehmer fungiert.

Gleichzeitig agiert dieser als Kontrollinstanz für soziale Konflikte und die Zielerreichung im Rahmen der Vision. Diese Instanz muss in der Regel nicht aktiv eingreifen, es reicht üblicherweise die Bewusstheit darüber, das es sie gibt.

Darüber hinaus besitzt das Team alle Freiheitsgrade damit ein hohes Maß an Selbstorganisation und Motiviation möglich wird.

Beispiele für charakteristische Eigenschaften und Prinzipien:

  • Kein Chef, anderweitige Hierarchien oder Managementinstrumente, sondern selbstorganisiertes Arbeiten auf Augenhöhe
  • Ein Auftraggeber der das Meta-Ziel definiert, es ist anspruchsvoll genug für das Team
  • Es gibt natürliche Fluktuation: nach einer begrenzten Zeit ist ein Projekt zu Ende oder wird mit neuem Projektteam weitergeführt das sich neu findet
  • Projektmitglieder können freiwillig gehen oder demokratisch ausgeschlossen werden – sie werden bei diesem Prozess unterstützt
  • Teammitglieder können parallel in 3-6 Projekten und Teams beteiligt sein
  • Damit die Teammitglieder gemäß ihren Kompetenzen, Fähigkeiten und Interessen optimal eingesetzt werden, wählen sie regelmäßig (alle 6 Monate) selbst bei welchen Projekten sie teilnehmen möchten, Projektmärkte sind ein Umsetzungsbeispiel dafür
  • Es gibt eine feste Zeitstruktur wie gearbeitet wird – ähnlich einem Stundenplanprinzip – womit sichergestellt wird, dass übergreifend in einer Art „Takt“ gearbeitet werden kann und mehrere Projekte parallel laufen können.

Im Gegensatz zum Scrum-Framework wird auf Regeln, Rollen und Vorgaben verzichtet. Die Teams werden sich selbst überlassen. Sie agieren praktisch als „Blackbox“ ohne Bewertung und Hierarchie von außen. Einzig alleine die Ergebnisse zählen. Dabei wird angenommen, dass sich die Teammitglieder eigenständig neue Ziele stecken um besser zu werden. Die Praxis zeigt, dass dies tatsächlich und ganz natürlich funktioniert. Menschen wollen Lernen.

Ganz bewusst werden für die Umsetzung sehr kurze Zeiteinheiten definiert, damit eine gesunde Fluktuation möglich wird. Diese sind notwendig falls sich Menschen nicht verstehen, ausreichend voneinander gelernt haben, das Interesse an einem Projekt sinkt und frühe Erfolge zu liefern.

Mit diesem „Blackbox“-Ansatz wird deutlich, das es nicht unbedingt weitere Formalismen, Definitionen oder Skalierungsansätze benötigt. Die Teams müssen bei diesem Ansatz „lediglich“ gut geschnitten werden, damit die richtigen Personen dabei sind.

Im Grunde bildet das den wesentlichen Unterschied zwischen einem agilen Beta- und einem Scrum-Team.

Vor- und Nachteile

Ein agiles Beta-Team besitzt natürlich höherer Freiheitsgrade und somit möglicherweise kann mehr Erfahrung in kontinuierlichen Verbesserungsprozessen und adaptivem Vorgehen erforderlich sein. Das ist möglich. Allerdings ist es gleichzeitig die natürlichste Sache der Welt, wie Menschen zusammenfinden und arbeiten können.

Ein „Projektmarkt“ wie in „Beyond Management“ beschrieben kann diesen sozialen Prozess unterstützen.

Scrum hingegen kann praktisch nach Leitfaden umgesetzt werden. Allerdings benötigt es die erforderlichen Rollen wie Scrum Master und Product Owner. Ein agiles Beta-Team kommt praktisch ohne aus.

Meine persönliche Erfahrung zeigt, das die beiden Rollen nicht unbedingt ein Erfolgsgarant sind, sondern das es tatsächlich auch ohne diese schnell und qualtiativ geliefert werden kann.

Macht das nachdenklich?