Die Macht der 48-Stunden-Regel

Als ich neulich etwas zu spät zum Scrum-Stammtisch dazustieß, war die Diskussion um Schätzungen nach halben Tagen, Stunden, schon in vollem Gange. Ich musste mit einem Schmunzeln an meinen Blog zum Schätzen nach Funktionalitäten denken. Ich bereitete mich innerlich also auf eine spannende Diskussion über das Dauerbrenner-Thema vor, musste aber schon bei meiner Frage nach dem Grund für die Schätz-Problematik feststellen, dass es eigentlich um etwas ganz anderes ging.Alle Anwesenden beteiligten sich an der Diskussion und fragten eifrig, wie denn die Rahmenbedingungen in der Firma und die Einstellungen der Mitarbeiter seien. Die Details würden für das, was ich sagen will, zu weit führen. Wir hatten es allerdings mit einem ScrumMaster zu tun, der nur noch den letzten Anstoß brauchte, um damit anzufangen, das ganze Potenzial aus seinem Team, dem PO, der Firma und schließlich sich selbst rauszuholen. Und wieder einmal hatte mich Scrum als Problemanalyse-Prozess nicht im Stich gelassen.Im Laufe der Diskussion erwähnte er fast beiläufig und mit einer gewissen Leichtigkeit, was man alles tun könnte, um die aktuelle Situation zu verbessern. Der Haken war nur: Er sah sich noch nicht offiziell als ScrumMaster - und das primär, vor allen anderen Verpflichtungen. Als der erste Scrum-Stammtischler fragte, ob dem ScrumMaster die Diskussion, die wir geführt hatten, weitergeholfen hätte, witterte ich meine Chance, Nägel mit Köpfen zu machen. Mit einem geliehenen Stift und auf der Rückseite einer Visitenkarte (die Nutzung des Bierdeckels wurde als Beschädigung fremden Eigentums angesehen) bat ich den ScrumMaster aufzuschreiben, was er in den nächsten 48 Stunden konkret von dem umsetzen werde, was er im Gespräch sowieso als sinnvoll erachtet hatte.

  • Eigene Entwicklungstätigkeit planen
  • Konzept für Retro und Sprint Plannings für das Team vorbereiten

Ich bat um eine Nachricht nach 48 Stunden, denn ich war gespannt darauf, was der ScrumMaster über seine Erfolge mit der Umsetzung zu berichten haben würde. Die E-Mail kam tatsächlich und versüßte meinen Start ins Wochenende ungemein. Dem ScrumMaster war es über die geplanten Tätigkeiten hinaus gelungen, mit dem Geschäftsführer zu reden. Offenbar rannte er bei ihm offene Türen ein mit seinem Vorhaben, sich voll und ganz auf die Tätigkeit als ScrumMaster zu konzentrieren. In dieser Rolle sah der Geschäftsführer die Fähigkeiten seines Mitarbeiters am besten für die Firma eingesetzt. Außerdem hatte er bereits ein Gespräch mit dem Team geführt, um den Mitgliedern übers Wochenende eine Hausaufgabe zu geben: Eine Rückmeldung dazu, was passieren müsste, damit sie motiviert sind und sich gut fühlen. „Damit wir gemeinsam das Unmögliche möglich machen!!!“

Agile Toolbox
Scrum
Rollen
ScrumMaster-Praxistipps
bgloger-redakteur
June 27, 2012

Table of content

Diesen Beitrag teilen

Das könnte auch interessant sein:

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst
BG

Scrum ist wie Klavierspielen – Warum du es nur durchs Tun wirklich lernst

Wer die Zukunft voraussagen will, muss sie gestalten
BG

Wer die Zukunft voraussagen will, muss sie gestalten

Die etwas andere agile Bücherliste.
BG

Die etwas andere agile Bücherliste.

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!
BG

Agile Transformation: Schluss mit dem Theoriedschungel – Fang endlich an!

Scrum organisiert am Produkt entlang
BG

Scrum organisiert am Produkt entlang

Trainings verändern - oder sie sind wertlos!
BG

Trainings verändern - oder sie sind wertlos!

Zertifizierung – Das ist hier die Frage
BG

Zertifizierung – Das ist hier die Frage

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind
BG

Die größten Missverständnisse über Scrum – und warum sie gefährlich sind

Organisationsentwicklung am Produkt entlang
BG

Organisationsentwicklung am Produkt entlang

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung
BG

Scrum im Krankenhaus: Eine Revolution in der Gesundheitsversorgung

Speed kills – oder rettet?
BG

Speed kills – oder rettet?

Weniger ist mehr – der Upstream ist zu managen
BG

Weniger ist mehr – der Upstream ist zu managen