Grenzen von Stop-the-Line?

February 17, 2009 at 10:21 pm 2 comments


Getreu dem Motto “Bugs werden gefixt und nicht gemanagt” finde ich es attraktiv, in Scrum-Projekten Bugs sofort zu beseitigen, wenn sie gefunden werden. Aber funktioniert das immer? Bei einem Kunden wurde es angezweifelt. Es gäbe immer wieder Differenzen zwischen Team und Fachabteilung, ob etwas ein Bug oder ein Feature ist. Und noch viel schlimmer: 75% der Rückmeldungen aus den Fachabteilungen seien gar keine Fehler, sondern gingen auf Fehlbedienung des Systems zurück.

Das spricht dann doch dafür, die Meldungen erstmal in einem Bugtracker aufzunehmen und dann regelmäßig über diese zu entscheiden. Das kann man so machen, aber letztlich laboriert man so nur an den Symptomen herum. Viel interessanter ist doch die Frage, warum Fachabteilungen und Team sich über die Bug-Feature-Frage nicht einigen können. Und noch interessanter ist natürlich die Frage, warum das Team ein System entwickelt, das die Fachabteilungen gar nicht richtig bedienen können. Wenn man die Rückmeldungen aus den Fachabteilungen also nicht in einen Bugtracker schreibt, sondern direkt auf das Team einprasseln lässt, zwingt man das Team, sich mit den zugrunde liegenden Problemen zu befassen.

Entry filed under: Uncategorized. Tags: .

Das Commitment des Product Owners Ich auf Twitter

2 Comments Add your own

  • 1. Felix  |  February 18, 2009 at 6:11 am

    Einerseits hast Du Recht – wenn das Feedback direkt zum Team kommt, dann erzeugt dies sehr viel mehr Aufmerksamkeit. Aber genau das kann auch ein Problem sein: Aufmerksamkeit für etwas nicht geplante verringert die Produktivität (lost focus) und erzeugt Chaos.
    Das ist bei wichtigen Rückmeldungen ein gangbarer Weg, meist aber dürften die Kosten höher sein als der Nutzen.

    Meiner Erfahrung nach bedient die Fachabteilung eine Lösung falsch, da sie sich nie zuvor damit beschäftigt hat. Ein PO gibt einen Workflow vor und ein Büro weiter wird dieser nicht verstanden. Ein Problem vom Team? Nein – das ist das Problem des POs. Anders sieht es natürlich aus wenn das Team Details so gewählt hat, dass dies zusätzlich Verwirrung stiftet.

    Deswegen: Einen Puffer für Fehler vorsehen, dort die “normalen” Fehler beheben. In der Retro genau erfragen was hinsichtlich Feedback aus der Fachabteilung passiert ist. Bei Bedarf dem Team ins Lehrbuch schreiben qualitätssichernde Maßnahmen zu verbessern. Dem Product Owner klar machen, welche Verantwortung er trägt – und dass es dazu gehören kann die Kollegen “aus dem Business” auch zu schulen bzw. sich mit denen abzustimmen.

  • 2. stefanroock  |  February 18, 2009 at 8:04 am

    Hallo Felix
    Schön, dass Du die Adresse des neuen Blogs erfolgreich gefunden hast🙂

    >Ein Problem vom Team? Nein – das ist das Problem des POs.
    Scrum unterscheidet zwischen dem Scrum-Team (inkl. PO) und dem Entwicklungsteam. Natürlich ist es nicht alleine das Problem des Entwicklungsteams. Aber es ist definitiv das Problem des Scrum-Teams. Das Scrum-Team baut gemeinsam das Produkt und ist gemeinschaftlich verantwortlich. Also dürfen sie auch gemeinschaftlich leiden, wenn es solche Probleme gibt.

    Und wenn das zu Ärger führt, weil die Entwickler beispielsweise meinen, sie müssten den Mist das POs ausbaden, dann funktioniert der Gedanke des Scrum-Teams an der Stelle nicht und man sollte man mal gucken, was da los ist.

    Deine Variante mit dem Puffer widerspricht “Stop the Line” ja nicht. Er sorgt ja lediglich dafür, dass das Team sein Commitment auch denn hält, wenn ein paar Fehler auftreten.

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

Trackback this post  |  Subscribe to the comments via RSS Feed



%d bloggers like this: