In kurzer Abfolge sind zwei Scrum-Beschreibungen veröffentlich worden von Leuten, die Scrum ganz sicher verstanden haben:
- Scrum Guide Expansion Pack von Jeff Sutherland, John Coleman und Ralph Jocham: https://scrumexpansion.org/ (ca. 50 Seiten)
- Simple Guide to Scrum von Tobias Mayer: https://scrum.academy/guide/ (ca. 2 Seiten)
Der offizielle Scrum Guide hat 14 Seiten: https://scrumguides.org/
Ich habe inhaltlich nichts auszusetzen, weder am offiziellen Scrum Guide noch am Expansion Pack oder dem Simple Guide to Scrum. Alles, was drin steht, ist richtig und sinnvoll.
Aber ist es auch nützlich? Hängt davon ab, was man will.
Wie lernt man Scrum?
Ich habe immer noch den Leiters einer großen agilen Transformation im Ohr, als er mir nach 2 Jahren arbeiten mit Scrum eröffnete: „Ich habe jetzt kapiert, dass man Scrum nur verstehen kann, wenn man es praktiziert hat.“
Das stimmt auch mit meiner Erfahrung überein. Solange man Scrum nicht verwendet hat (und zwar so wie es gedacht ist und nicht irgendeine kastrierte Enterprise-Version), halte ich den Scrum Guide nicht für besonders nützlich. Die Beschreibung ist zu abstrakt und zu weit Weg von einer nicht-agilen Arbeitsweg. Da gibt es keine Anschlussfähigkeit.
Das ging mir übrigens nicht anders, als ich Mitte der 1990er Jahre das erste Mal über Scrum stolperte (damals noch als Pattern Language beschrieben): Jede Menge Begriffe und Konzepte, die ich überhaupt nicht einordnen und verstehen konnte.
Das ist mir erst viel später gelungen, als ich mehrere Jahre als Entwickler in XP-Teams (XP = Extreme Programming) gearbeitet hatte. Die XP-Erfahrung hat mir geholfen, Scrum einzuordnen; und das Buch „Agile Software Development With Scrum“ von Ken Schwaber und Mike Beedle. Das Buch ist sicher kein literarisches Highlight, aber durch die oft beispielhaft-anekdotische Beschreibung wird viel klarer, wie Scrum gemeint ist als durch die formelle Beschreibung des Frameworks durch den Scrum Guide.
Das Scrum Guide hat natürlich auch seinen Nutzen, weil er definiert, was Scrum ist und was nicht. Dadurch liefert er einen Standard für Schulungen, Tests und Zertifizierungen (unabhängig davon, was man davon halten mag). Dieser Standard ist auch nützlich für Diskussionen zwischen Scrum-Praktikern, um Scrum besser zu verstehen und weiterzuentwickeln. Verständnis bei Neulingen erzeugt er aus meiner Sicht eher nicht.
Scrum verstehen
Wie oben zitiert, braucht es Praxis, um Scrum zu verstehen. Und damit wird es eklig. Ich brauche die Praxis, um Scrum zu verstehen. Ohne Scrum verstanden zu haben, weiß ich nicht, ob wir es richtig praktizieren. Ich habe vor 25 Jahren mal über sowas wie einen agile Akzeptanztests nachgedacht – eine einfache Möglichkeit, festzustellen, ob man wirklich agil arbeitet. Ich bin daran gescheitert.
Idealerweise hat man jemanden dabei, der schon mit echtem Scrum gearbeitet hat. Aber die sind auch schwer von denen zu unterscheiden, die nur glauben, nach Scrum gearbeitet zu haben. Es ist wie verhext.
Aus meiner Sicht könnte der Weg so aussehen, dass man eine sehr schlanke Beschreibung der Kernideen hat (Tobias‘ Simple Guide to Scrum ist eine solche Möglichkeit) und über Fallbeispiele plastisch macht, wie diese Kernideen in der Praxis gelebt werden können. Und dann experimentiert man in seinem Kontext und findet die dort passenden Lösungen selbst.
Und das lässt sich gut kombinieren mit Jason Yips Agile Doctrine: https://jchyip.medium.com/what-is-agile-doctrine-45dd0c165f7a (er ist damit einem agilen Akzeptanztest viel näher gekommen als ich):
- Reduziere den Abstand zwischen Problemen und Problem-Lösern
- Validiere jeden Schritt
- Mache kleinere Schritte
- Räume kontinuierlich auf
So angewendet halte ich den Simple Guide to Scrum für nützlicher als das Scrum Guide Expansion Pack. (Ich schätze die Autoren des Expansion Packs sehr und glaube, dass er auch seinen Nutzen haben kann. Er räsoniert aber nicht so richtig mit mir.)
Über den Autoren
„Wir müssen immer wieder das Unmögliche versuchen, um das Mögliche zu erreichen.“ H. Hesse
E-Mail: stefan.roock@it-agile.de
LinkedIn: https://www.linkedin.com/in/StefanRoock/
Mein Name ist Stefan Roock und ich will eine bessere Arbeitswelt schaffen; eine in der Kunden von den Produkten und Services begeistert sind, Mitarbeitende ihre Arbeitsbedingungen lieben, Unternehmen erfolgreich sind und sich verantwortlich in der Gesellschaft verhalten. Ich helfe Menschen und Unternehmen dabei, ihre Potenziale für dieses Ideal zu entfesseln.
Ich verbreite und entwickle seit 1999 neue Arbeits- und Organisationsansätze in Deutschland. Das habe ich zunächst als Entwickler in agilen Teams, später als Scrum Master/Agile Coach und Product Owner getan. Ich habe seitdem mein Verständnis dessen, was für begeisternde Produkte und Arbeitsbedingungen notwendig ist, kontinuierlich weiterentwickelt. Besondere Produkte entstehen nicht dadurch, dass Teams „agil“ Anforderungen umsetzen. Stattdessen müssen Teams gemeinsam im direkten Kundenkontakt Produkte und Services gestalten.
Auf diesem Weg habe ich unter anderem die it-agile GmbH mitgegründet.