Drücken Sie Enter, um das Ergebnis zu sehen oder Esc um abzubrechen.

Von Scrum 1.0 zu Scrum 3.0

Ken Schwaber und Jeff Sutherland haben immer gesagt, es kann kein Scrum 2.0 geben, es gäbe nur Scrum. Und ich habe immer dazu tendiert, dieser Linie zu folgen. Doch so langsam bröckelt meine Haltung in dieser Hinsicht.

Warum? Weil ich mehr und mehr Vorträge, Artikel und Scrum-Implementierungen erlebe, in denen Scrum heute noch so erklärt und gelebt wird, wie ich es selbst 2004, also vor mehr als zehn Jahren, gelebt und vertreten habe. Das war Scrum 1.0, wir wussten es ja nicht besser. Wir probierten aus. Gleichzeitig höre ich auf Konferenzen, dass es mittlerweile in den ersten Scrum-Umfeldern offenbar auch gibt, was ich selbst mit unserem eigenen Entwicklungsteam praktiziere: Die Entwickler arbeiten mit dem PO als Team, das Management ist nicht mehr existent. So gehört auf der SEACON und auf der BWI Fachtagung in Zürich. Das ist Scrum 3.0.

Scrum hat sich weiterentwickelt. Zu einem Management-Framework, zu einer Haltung, zu einem Ansatz, mit dem sich ganze Firmen steuern lassen. Scrum ist der de facto Standard in der agilen Projektmanagement-Landschaft geworden und wir wissen heute, wie man crossfunktionale, multidisziplinäre Teams in der Soft- und Hardwareentwicklung über Kontinente hinweg arbeiten lassen kann. Jetzt gibt es die ersten Firmen, die sogar auf Managementebene leben, was wir vor 15 Jahren auf der Teamebene begonnen haben und die langsam aber sicher das mittlere Management ausdünnen. Steve Denning hat Scrum in den USA als neuen Standard für das Management publik gemacht und als Alternative aufgezeigt. Der Hype hat begonnen.

Doch wir müssen aufpassen: In Scrum 3.0 ist nicht mehr drin, was in Scrum 1.0 drin war. Wir dürfen heute nicht mehr die ollen Kamellen erzählen, denn die haben sich über die Jahre als nicht funktional erwiesen. Außerdem haben sich die Möglichkeiten verändert. Scrum 3.0 weiß heute,

  • dass es so etwas wie „Flow“ gibt.
  • dass es auch die Skills zum Arbeiten mit Scrum braucht.
  • dass Remote-Arbeiten nicht mehr böse ist.
  • dass wir keine Branches mehr dulden.
  • dass Releases böse sind und
  • dass wir natürlich Festpreise machen wollen.
  • Heute schätzen wir nicht mehr, sondern messen die Durchlaufzeit.
  • Wir führen Dailys nicht mehr klassisch durch, sondern schauen uns jeden Tag das Ergebnis an.
  • Wir reduzieren die Retrospektiven auf eine Frage und machen sie dadurch schneller.
  • Wir fokussieren uns darauf, eine Sache zu verbessern.
  • Wir lassen die Entwickler die Storys schreiben und
  • aus den Storys sind Hypothesen geworden,
  • die Anforderungen sind den Beobachtungen gewichen und
  • der agile Festpreis macht keinen Sinn mehr, weil wir die Features einzeln verkaufen.
  • Und wir wissen, dass agiles Skalieren sicher nicht durch die nächsten Modelle funktioniert (obwohl sich das gut verkaufen lässt), sondern nur gelingt, wenn die Architektur das auch hergibt und dass
  • die Entwickler die Skills haben müssen, all das umzusetzen.

Das ist Scrum 3.0!

Aber leider werden 2015 noch immer die Ideen von Scrum 1.0 weitererzählt. Ja, und jetzt betreibe ich Nestbeschmutzung: Das ist so, weil die meisten Trainer und Coaches gar nicht mitbekommen, was sich da gerade tut. Sie machen nämlich gutes Geld mit ihren Trainings, verdienen als Einäugige unter den Blinden gerade eine Menge Geld. Ich gönne es ihnen. Unsere Firma profitiert natürlich auch von dieser Entwicklung.
Aber bitte: Das was mir Ken und Jeff vor Jahren beigebracht haben, war der Anfang! Ein guter Anfang und ich bin wahnsinnig dankbar dafür, aber 3.0 ist anders. Es ist noch einfacher geworden, weil wir die echten Mechanismen kennen. Nein, es ist nicht einfacher beim Implementieren geworden, es ist sogar schwerer geworden, weil die großen Unternehmen Scrum 1.0 wollen und wir aber wissen, dass es 3.0 gibt. Wer heute noch von den drei Fragen des Dailys erzählt, wer heute noch sagt, Teams müssen zusammensitzen, wer heute noch sagt, der  PO schreibt die Storys, der sollte dringend, wirklich dringend, zur Agile 2015 fahren, sich mit LIIP unterhalten oder mal bei CosmosDirekt vorbeischauen. Es ist irre, was sich gerade tut.

digits-705666_1280
Pixabay CC0 Public Domain
  • ich bin für Scrum 3.0 und tendiere Estimation noch einfacher zu machen ;-)

    Am meisten Potential finde ich hat User Strories schreiben mit und durch die Teammitglieder. Nur so haben diejenigen, die Produkt entwickeln auch die Verantwortung und das Wissen darüber. Product Owner gibt nur mehr Richtung vor (aber auch hier kann das Team mit einbezogen werden) und zweitens greift ein, wenn Stories z.B. wieder zu technisch werden oder nicht vertikal geschnitten sind.

    Der zweite Punkt ist Estimation komplett rauszunehmen. Das hilft am meisten das alte Mindset „alles ist planbar“ loszuwerden. Komplexität lässt sich nicht verwalten und planen und vor allem Komplexität ist notwendig für Selbstorganistion und sollte geschätzt werden.
    Ich würde auch die Durchlaufzeitmessung noch rausnehmen. Das macht es noch viel einfacher und meiner Meinung auch hinreichend genau. Ansatz: Wie viele User Stories schafft ein Team pro Sprint. Durch das Gesetz der großen Zahlen kann mach sagen, dass „im Mittel alle auch funktional gleich groß sind“. Das motiviert das Team auch kleine User Stories zu schreiben. Damit weiss man ganz genau wie lange es dauert ein Epic mit z.B. 20 User Stories umzusetzen, wenn das Team 5 Stories pro Sprint schafft. Daraus gibt es nur mehr zwei Fragen: Wie schafft das Team mehr Stories pro Sprint zu schaffen und was ist passiert, wenn mal keine oder über mehrere Sprints weniger Stories geliefert werden.

    @Boris: Bei der Retro hätte mich noch interessiert wie die ein Frage nach der Verbesserung durch den Selbstreferenzialität-Aspekt am einfachsten lauten kann, damit auch die Frage noch dem „We celebrate ourself“ noch enthalten ist.