Was macht Scrum Teams eigentlich hyperproduktiv?

Es gibt sicher eine Reihe von Faktoren. Hier sind meine 10 Ideen dazu:

  1. Der ScrumMaster hilft dem Team, ungestört arbeiten zu können.
  2. Der ScrumMaster macht jedes Meeting zu einer produktiven Arbeitssitzung.
  3. Nach einiger Zeit entsteht im Team ein hohes Maß an Vertrauen: Das erzeugt nach Tom deMarco eine hohe kommunikative Bandbreite.
  4. Ständiges Feedback lässt Fehler sofort aufscheinen und hilft sie zu korrigieren.
  5. Das ständige Priorisieren des Backlogs fördert die Reduktion auf das Wesentliche.
  6. Der Fokus des Teams auf die gerade jetzt für den Sprint nötigen Aufgaben schafft Konzentration und dadurch steigt wiederum die Produktivität.
  7. Gelungene Retrospektiven erzeugen Verbesserungen im Arbeitsablauf.
  8. Die Teammitglieder fühlen sich im Team sicher. Menschen, die sich sicher fühlen, können Neues ausprobieren und so über sich hinauswachsen.
  9. Die Kommunikation im Team ist zielgerichtet und damit strukturiert, es wird weniger dokumentiert, aber dafür mehr kommuniziert.
  10. Teammitglieder haben in Scrum-Teams das Gefühl, etwas beitragen zu können. Das motiviert und fördert die Leistungsfähigkeit.

Es gibt bestimmt noch mehr Gründe, warum Scrum-Teams produktiver sind. Welche Erfahrungen habt ihr gemacht?

Geschrieben von

bgloger-redakteur bgloger-redakteur

TEILE DIESEN BEITRAG

Eine Antwort zu “Was macht Scrum Teams eigentlich hyperproduktiv?”

  1. Collin Rogowski sagt:

    Für mich ist der wesentliche Faktor die Identifikation von unnötiger Arbeit durch Kollaboration. Zwei Beispiele:
    1. Ein Entwickler bereitet eine Brownbag zu einem JavaScript-Framework vor. Im Zuge dieser Vorbereitung stellt er fest, dass alles was er in den letzten zwei Monaten programmiert hat, bereits Bestandteil dieses Frameworks ist. Diese Erkenntnis im Vorfeld hätte also dem Projekt zwei Personenmonate Aufwand erspart. Die Investition in Kollaboration, um systematisch Möglichkeiten für solche Erkenntnisgewinne zu ermöglichen (z.B. durch das Aufsetzen von Communities of Practice, etc.) ist im Vergleich eher gering.
    2. Durch die Diskussion mit dem Team erfährt der Product Owner, dass eine leichte Änderung eines Features den Aufwand für die Entwicklung dieses Features halbiert (“dieses Feature ist nicht im IE6 verfügbar”). Auch hier wird mittels einer Investition von ein paar Minuten (etwa im Planning Meeting) ein immens viel größerer Aufwand gespart.

Schreibe einen Kommentar

Deine E-Mail-Adresse wird nicht veröffentlicht.