Scrum – und wir machen doch was wir wollen

Wer gegenwärtig die Postings der deutschen Scrum Community ließt muss erschrecken. Das stehen Sachen wie:

[… ] wenn eine User Story zu umfangreich für einen Sprint ist, dann muss man eben die timebox für den Sprint verlängern. Denn:

Rasch BENUTZBARE Produkte / Services sind wichtiger als umfangreiche Planungsdokumentationen. […]

Diese beiden Argumente sind vollkommen voneinander getrennt, werden hier habe so miteinander vermengt, als wären sie kausal. Es wird noch wilder:

Also: Scrum Prozesse und Methoden sind Leitlinien, die situativ zu modifizieren sind, damit der eigentliche Kundennutzen schrittweise erzielt werden kann. Die Prinzipien der Agilität helfen dabei – auch sie sind aber keine “Gebote”.

Scrum Prozesse und Methoden sind Leitlinien, die situativ zu modifizieren sind — 1) Es gibt keine Scrum Prozesse. Wo kommt denn die Mehrzahl her. Es gibt nicht einmal einen Scrum Prozess.  Habt ihr Kens neuestes Buch gelesen, oder meines? Da steht aus guten Grund drin, dass Scrum keine Methodologie ist, dass man aber die Prinzipien genaus so wie sie aufgeschrieben worden sind einhalten muss.

[…]Wenn neue Aspekte zu einer Story auftauchen, geht das als neue Story ins
Product Backlog und nach Priorisierung des Product Owners in den Sprint ein.[…]

Richtig – aber weiter schreib der Autor:

Wenn es sich um Bugs handelt, ist das erstmal genauso.

FALSCH! Ein Bug wird zu einer Task, des gerade bearbeiteten Backlog Items!

Dann findet man ein Statemen wie:

Die Prioritäten User Stories geben die Vorgabe für die Prios der Tasks,

Absolut richtig! Aber dann geht es so weiter ….

die Tasks dienen zur wöchentlichen Feinplanung. Das ist nicht
unbedingt Scrum-by-the-book, hat sich aber bei meinen Kunden ganz gut
bewährt.

Natürlich ist das Scrum-by-the-book!

Sagt mal, was ist den ein Detail-Backlog:

[…]Ein Detailbacklog mit technischen Tasks auf Wochenbasis
und ein geschäftlicher Backlog mit User Stories auf Sprint-Ebene und
das Problem stellt sich so nicht mehr.

Es gibt ein Product Backlog, ein Selected Product Backlog und ein Sprint Backlog! Wozu fangen wir denn jetzt mit noch mehr Begriffen an.

Mir ist klar, dass ich jetzt wieder einigen auf den Schlips getreten habe und dass Ihr wieder alle schreiben werdet, der “Boris mit seinen Theorien, die Realität sieht anders aus.” Aber bitte – die obigen Zitate belegen, dass schwerwiegende Missverständnisse in der deutschen Scrum Community gelebt und gelehrt werden.

Wann immer ich mit einem Team gearbeitet habe, dass Probleme hatte, dann lag es nie daran, dass die Prinzipien eingehalten worden wären. Es lag immer daran, dass die Prinzipien, die Diziplin oder die klaren Hauptregeln von Scrum zugunsten der “Situation” verändert worden sind.

8 responses to “Scrum – und wir machen doch was wir wollen

  1. Hallo Boris

    >>Wenn es sich um Bugs handelt, ist das erstmal genauso.
    >FALSCH! Ein Bug wird zu einer Task, des gerade bearbeiteten Backlog Items!

    Aber nicht, wenn der Bug erst nach Sprint-Review gefunden wird, oder?

    Viele Grüße,
    Stefan

  2. Wolfgang Wiedenroth

    Hi Boris und Stefan,

    Bugs die nach dem Review auftreten sollten bestenfalls gar nicht erst auftreten. Sollte das dennoch der Fall sein ist bei der Story etwas falsch gelaufen denn “Done” kann sie ja nicht gewesen sein(weil nicht fehlerfrei).

    Wir haben es so gelöst, dass ein Bug direkt an das Team weitergeleitet wird. Dieser wird sofort gelöst(showstopper) oder mit ans Taskboard gehangen und jemand nimmt sich der Sache an sobald er Zeit hat(Unschönheit, etc.)
    Im Fall eines showstoppers wird die Iteration pausiert und das gesamte Team arbeitet am Bug.

    Wir hatten bis jetzt von jeder Art einen Fall und es hat wunderbar geklappt. Das Beste an dieser Art und Weise, war für das Team das direkte Feedback der User und für die User das Gefühl, dass etwas getan wird.

  3. Hi – der “Bug” aus Sprint A wird als Task in das gegenwärtig bearbeitete Backlog Item des Sprints B aufgenommen. Warum: a) Damit wird klar, dass das ganze Team jetzt dafür sorgen muss, dass der “Bug” gelöst wird. b) die Velocity im Sprint B geht zwangläufig runter.
    Dieses Prinzip kommt aus dem Toyota Production System – Bugs werden dort nicht gemanagt, sondern sofort gefixt.

  4. Wolfgang – deine Vorgehensweise klingt super. Du solltest darüber einen kurzen Artikel für die Scrum Alliance schreiben.


  5. Wann immer ich mit einem Team gearbeitet habe, dass Probleme hatte, dann lag es nie daran, dass die Prinzipien eingehalten worden wären. Es lag immer daran, dass die Prinzipien, die Diziplin oder die klaren Hauptregeln von Scrum zugunsten der “Situation” verändert worden sind.

    Naja, da muss ich widersprechen. Das gilt nur, wenn die Organisation weit genug ist – sonst muss man ab und an auch Kompromisse eingehen bzw. die Prinzipien interpretieren (was ist in der gegebenen Situation möglich). Natürlich muss man die Konsequenzen kennen – aber teilweise ist die Alternative (Einhaltung der Regeln) noch teurer.

    Naja, letztendlich gilt aber diese Ausrede auch nicht – denn eine plakative Regel von vielen Agilisten sagt ja, dass man die Organisation verlassen sollte, wenn diese “(noch) nicht passt” bzw. “passen will”.
    Ich hatte hierzu auch ein “Küchengespräch”, in dem wir die unangenehmen Aspekte von agilen Methoden herausgearbeitet haben. Im Kern sind diese nicht mit dem Sicherheitsdenken in der deutschen Angestelltenkultur kompatibel. Man muss sich irgendwann entscheiden: Freiheit oder (trügerische) Sicherheit. Solang man zu den “Guten oder Starken” gehört ist “Freiheit!” die richtige Antwort – für die anderen wird die Antwort schwieriger und deshalb gibt es oft (gefährliche) Kompromisse.

  6. Wolfgang Wiedenroth

    Danke

    werd ich in Angriff nehmen sobald meine Erkältung los bin und wieder einen klaren Gedanken fassen kann

  7. Hi Boris,

    ich mag Deine klaren Ansagen. Nur, wenn Scrum Mainstream wird, wird es degenerieren. Die Konzepte weichen auf, verändern sich.
    Das ist aus meiner Sicht normal, in Idealfall Evolution. Wenn es klappt, wird es weiter verfolgt, wenn nicht geht es schief.

    Einen anderen Aspekt finde ich ebenso spannend: Was ist für Dich ein Bug? Ist die fehlende Validierung eines Eingabefeldes, die zu Fehleingaben führen kann, ein Bug oder ein Feature? Bei Showstoppern vertrete ich klar Deine Sichtweise, und das nicht nur, weil dann ohnehin mein Chef hinter mir steht und mich auf den rechten Weg leitet. Der Übergang zum Feature ist aber fließend, so daß ich mir eine Aufnahme von gewissen Fehlern in das Backlog schon vorstellen kann.

    Eine Argumentation Bugs in Sprints zu integrieren, findet sich aber in einem Artikel, den Ken über das Zusammenspiel von Scrum und CMMI geschrieben hat: Das dort betrachtete Unternehmen hat festgestellt, daß es im Schnitt 1.6h dauert, einen Bug zu fixen, der in der Coding-Phase festgestellt wird, 12h, wenn er in der Testphase gefunden wird, und 23.7h, wenn er in der Maintenance-Phase gefunden wird.

    Selbst, wenn einem Zero Defects zu aufwändig sind, zeigt das das Potential, das Scrum bietet, wenn man Fehler zeitnah sucht und findet.

    Viele Grüße,
    Christian

  8. Was ist eigentlich mit reiner “Maintenance-Arbeit”, d.h. ein abgeschlossenes Projekt, in dem sporadisch Bugs gefixt und ggf. neue Features implementiert werden sollen. Das ist ja eigentlich kein Projekt und Scrum funktioniert so nicht – z.B. gibt’s keine Iterationen.

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s