Kennst du das?

Entwickler:innen hassen Scrum wegen der Meetings?

 

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings.

(Der Scrum Guide spricht übrigens von Events.)

Events in Scrum

Nimmt man die Event-Dauern aus dem Scrum Guide, kommt man für einen zweiwöchigen Sprint auf:

  • max. 4 Stunden Sprint Planning
  • max. 15 Minuten täglich für Daily Scrums, in Summe 2,5 Stunden
  • max. 2 Stunden Sprint Review
  • max. 1,5 Stunden Sprint Retrospektive

Das ergibt zusammen 10 Stunden, also 5 Stunden pro Woche. Das sind bei einer 40-Stunden-Woche 12,5% der Arbeitszeit.

Das ist eine Menge nicht-wertschöpfender Arbeit. (Ich benutze einen engen Wertschöpfungsbegriff: Wertschöpfend ist, was eine positive Veränderung des Produktes bewirkt. Meetings tun das nicht.)

Zur Verteidigung kann man anführen, dass die Zeiten Maximalzeiten sind und das für die Scrum-Events auf die anderen Meetings in Unternehmen verzichtet werden soll. Das passiert leider häufig nicht und dann sitzen Entwickler:innen in Summe auch mal 30-50% ihrer Arbeitszeit in Meetings. Nimmt man dann noch die Kontextwechselkosten dazu, kommen sie kaum noch zu arbeiten. Da wäre ich auch angepisst. Aber kann man das wirklich Scrum ankreiden?

Was ist der eigentliche Punkt?

Der eigentliche Punkt ist aber ein anderer.

In vielen Scrum-Implementierungen ist den Beteiligten der Zweck der Scrum Events unklar. Dabei definiert der Scrum Guide den Zweck der meisten Events explizit:

  • Daily Scrum:
    „... den Fortschritt in Richtung des Sprint-Ziels zu überprüfen und das Sprint Backlog bei Bedarf anzupassen, um die bevorstehende geplante Arbeit zu justieren.“
  • Sprint Review:
    „... das Ergebnis des Sprints zu überprüfen und künftige Anpassungen festzulegen.“
  • Sprint Retrospektive:
    „Wege zur Steigerung von Qualität und Effektivität zu planen.“

Leider bleibt der Scrum Guide ausgerechnet beim längsten Event, dem Sprint Planning, den Zweck schuldig.

Ich würde den Zweck wie folgt definieren:

  • Sprint Planning:
    Alignment zwischen Product Owner und Entwickler:innen darüber herstellen, was im Sprint wichtig ist und Alignment unter den Entwickler:innen herstellen, wie das geschafft werden kann.

Die Dauer der Events laut Scrum Guide sind für mich eine Empfehlung für den Start. Da weiß man ziemlich sicher, wie man den jeweiligen Zweck auch mit einem unerfahrenen Team erreichen kann. Aber danach geht es darum, die Events zu verschlanken.

Warum sollte ich 4 Stunden mit Sprint Planning verbringen, wenn es auch in 10 Minuten geht (das ist tatsächlich möglich!)? Warum sollten wir uns jeden Tag 15 Minuten zusammenstellen, wenn wir den ganzen Tag Mob Programming mit dem ganzen Team praktizieren und jede:r ständig über alles informiert ist?

Wenn man konsequent nach leichtgewichtigeren Ansätzen sucht, um den jeweiligen Zweck zu erreichen, kommt man mit viel weniger Zeit aus.

Eine gute Idee, um alle Beteiligten in diese Diskussion einzubinden, ist, am Ende eines jeden Events eine kleine Mini-Retrospektive zu machen. Das kann z. B.  mit einem ROTI oder einer schnellen Plus/Delta abfrage sein. Damit bleibt die Diskussion um die Dauer und Inhalte des Events am Leben. Ein „das haben wir immer schon so gemacht“ wird so deutlich seltener.

Aber wenn ich die Zwecke gar nicht brauche?

Dann brauche ich vermutlich Scrum auch nicht.

Scrum kann nützlich sein, wenn es darum geht, in einem komplexen Umfeld mit einem echten Team eine Lösung zu schaffen. Ein echtes Team zeichnet sich dadurch aus, dass die Mitglieder ein gemeinsames Ziel verfolgen und dabei gegenseitige Abhängigkeiten haben. Gegenseitige Abhängigkeit bedeutet, dass das Ziel nicht durch die Summe der Einzelbeiträge der Teammitglieder erreicht werden kann, sondern nur wenn durch enge Kooperation Synergien entstehen.

Wenn die gegenseitige Abhängigkeit nicht oder nur rudimentär vorhanden ist, braucht man tatsächlich Sprint Planning und Daily Scrum in der Scrum-Form nicht mehr und Retrospektiven vermutlich weniger häufig.

Hier ist unser Kollege Stefan zu sehen.

Über den Autor

Stefan Roock

Stefan Roock hilft Unternehmen, Führungskräften und Teams dabei, ihre Potenziale zu entfalten - hin zu erfolgreichen Unternehmen, die ihre Kunden und Mitarbeiter begeistern. Er ist davon überzeugt, dass dazu strukturelle, personelle und interpersonelle Themen im Zusammenspiel adressiert werden müssen. 

Veröffentlichungen (u. a.):

E-Mail:Twitter:LinkedIn:

Mehr von Stefan Roock

Unser it-agile Lagerraum

Möchten Sie mehr erfahren?

Tauschen Sie sich mit unseren Expert:innen aus und lassen sich zu Schulungen, Coaching oder Wissensthemen beraten.

 

+ 49 40 4135 848-0    info@it-agile.de    Online Termin buchen

Agile Coaching von it-agile

Kennen Sie eigentlich schon it-agile?

Die Expert:innen zu agiler Arbeit und agilen Methoden

Kund:innen wollen begeistert werden. Mit innovativen Produkten, durch Schnelligkeit, Transparenz und auch Verlässlichkeit. Unsere erfahrenen Agile Coaches sorgen gemeinsam mit Ihren Teams und Führungskräften dafür, auch in komplexer Umgebung Ihre Ziele nicht aus dem Auge zu verlieren und implementieren die richtigen agilen Methoden für nachhaltige Veränderung.

  • Wir integrieren Pragmatismus mit Idealismus
  • Wir befähigen Sie nachhaltig ohne Abhängigkeit von uns
  • Wir erzeugen Kundenfokus mit wirkungsvoller Agilität
agile review Magazin

agile review

Unser Kundenmagazin 

In unserem Magazin stellen wir Artikel rund um agiles Arbeiten für Sie zusammen. Das Spektrum reicht von methodischen Themen wie Scrum und Kanban über Agile Leadership bis hin zu technischen Aspekten wie agilem Testen und flexiblen Architekturen.

  • Als Abo oder Einzelausgabe erhältlich
  • Digital oder Print
  • Einzelne Artikel sofort digital verfügbar

Wissens- und Lesenswertes

Das könnte Sie zu Agiler Arbeit auch interessieren

Agile Teams

Ein Haufen abhängiger agiler Teams ergibt noch kein agiles Unternehmen. Die übergreifenden Themen führen zu extremen Overhead, schlechter Vorhersagbarkeit und langsamer Time-To-Market. Diese Probleme…

Agile Teams

Wir hören immer mal wieder, dass Entwickler:innen Scrum hassen - wegen der vielen Meetings. Was steckt dahinter?

Agile Entwicklung

DORA (DevOps Research and Assessment) ist ein wissenschaftliches Studienprogramm, das unser Kollege Andreas Havenstein zur Weiterentwicklung von Teams angewandt hat.

it-agile Newsletter

Sichern Sie sich regelmäßige Neuigkeiten, Inspiration und Tipps zu agiler Arbeit, Konferenzen, aktuelle und neue Termine für unsere Schulungen sowie vieles mehr.


* Benötigte Angaben