Scrum Guide 2011 – kritisch hinterfragt
19. September 2011
Die Scrum Gründer Ken Schwaber und Jeff Sutherland, nach wie vor zwei der federführenden Persönlichkeiten und Meinungsmacher in der Scrum Community, fokussieren sich in ihrem vor Kurzem veröffentlichten Scrum Guide 2011 auf das Wesentliche. Dem Titel „The Definitive Guide to Scrum: The Rules of the Game“ entsprechend, werden auf knapp 17 Seiten die Definitionen der Scrum-Regeln, -Rollen und -Artefakte beschrieben. ‚Keep it Short and Simple‘, sich auf das Wesentliche konzentrieren, das entspricht auch meiner persönlichen Einstellung. Aber 17 Seiten für ein so anspruchsvolles Thema finde ich dann doch sehr knapp. So einige Fragen bleiben unbeantwortet, andererseits wird dem Anwender aber auch viel Spielraum bei der Umsetzung gegeben. Ken Schwaber und Jeff Sutherland fokussieren sich stark darauf, für das Scrum Team optimale Arbeitsbedingungen zu schaffen und das Team zu schützen. Und das ist auch richtig so. Denn gerade auf die Entwicklungsteams wird in vielen Unternehmen oftmals ein nicht unerheblicher Druck ausgeübt, das Unmögliche möglich zu machen. Soweit gehe ich auch voll mit.
Aber warum musste der Scrum Guide 2011 denn unbedingt noch durch den Weichspülgang?
Es gibt kein Team Commitment mehr, sondern nur noch einen Sprint Forecast. D.h. die Entwickler begeben sich auf den Level der Sales Kollegen oder der Wettervorhersage, denen es verständlicherweise schwer fällt, genauere Daten vorauszusagen und die nur einen Forecast abgeben. Gerade das Commitment war aber ein Pfund, mit Scrum Teams wuchern konnten. „Ja, wir schaffen das! Ja, wir sind ein Team und können gemeinsam etwas reißen.“ Diese Haltung wird jetzt zu „Schaun mer mal, dann sehn mer scho“, wie einst schon Franz Beckenbauer sagte.
Sprint Burndown, Release Burndown und Release Planung wurden aus dem Guide verbannt – mit der Begründung, dass sie für Scrum als solches nicht notwendig sind. Richtig, da gehe ich noch mit! Aber Scrum oder das Scrum Team ist nun einmal Bestandteil einer Organisation bzw. eines Unternehmens und da ist Transparenz bezogen auf das, was gerade im Sprint läuft und vor allem auch eine Release Planung und ein Release Burndown essentiell für den Vertrieb, für Marketing, Operations und strategische Planung. Das wird wieder Energie und Zeit kosten, den PO und das Team zu überzeugen, diese Diagramme und Release Planung zu erstellen:-(
Das Product Backlog wird jetzt sortiert statt priorisiert. Ich weiß nicht, warum der Product Owner mehr Freiheiten haben soll, wenn das Backlog nicht priorisiert, sondern lediglich sortiert wird. Aber ich hoffe sehr, dass auch in Zukunft die wichtigen Dinge implementiert werden und nicht durch einen Sortieralgorithmus im Nirwana verschwinden.
So genug gemeckert für heute:-) Mal schauen, was die Scrum Comunity auf dem nächsten Scrum Tisch zu dem Thema sagt.
Quelle Foto: © rolffimages – Fotolia.com
| Keine Kommentare