en
de

Kein Bauer hat den Misthaufen in der Stube

19 März 2013
| |
Lesezeit: 3 Minutes
Der Frühling kommt und damit auch die Zeit, wo die Bauern den Mist aufs Feld austragen. Der Mist ist ein wichtiger Dünger für den Boden. Nur auf einem gut gedüngten Boden kann die Saat des Bauern gedeihen und damit sein Business wachsen. Der Misthaufen ist überlebenswichtig für den Bauern. Darum hat auch jeder Bauernhof seinen Misthaufen. Dieser ist, wenn man bei einem Bauernhof vorbeiläuft, immer sehr gut sicht- und riechbar. Aber kein Bauer hat den Misthaufen in seiner Wohnung; der Misthaufen lagert draussen, möglichst weit weg vom Wohnhaus.
Warum aber lagert die Entwicklung dann den Misthaufen in ihren Büros, auf den Tischen der Entwickler?
Was ist der Mist in der Entwicklung überhaupt? Mist ist nicht per se schlecht, sondern etwas sehr Nützliches, Lebensnotwendiges: Mist, das sind die neu geplanten Features und Funktionen, die Anforderungen. Kurz, die offene Arbeit. Nur durch diese neuen Features wächst das Produkt, wird es besser. Und ein Produkt mit immer neuen Features ist das A und O für ein wachsendes Business, eine wachsende Firma.
Viele Firmen schieben offene Features sofort in die Entwicklung und erwarten, dass dieses Feature entsprechend gleich umgesetzt wird. Dann wundert sich die Firma, dass die Entwicklung nichts mehr herausbringt. Das ist ja kein Wunder, all der Mist, die vielen Aufgaben, verstopfen die Entwicklung. Die Entwickler wissen vor lauter offenen Arbeiten gar nicht mehr, wo beginnen. Das ist so, wie wenn der Bauer abends müde vom Feld nach Hause kommt, um seinen Feierabend zu geniessen, aber vor lauter Mist in der Stube sich nicht erholen kann.
Offene Arbeiten gehören – mit Ausnahme der gerade aktuellen Arbeit – also nach draussen, gehören ausserhalb der Entwicklung gelagert.
In agilen Prozessen hat sich dafür der Backlog etabliert, eine priorisierte, geschätzte, gewartete und sichtbare Liste von allen offenen Arbeiten.
Priorisiert:
Es wird aus der Liste klar ersichtlich, welches die wichtigen und welches die unwichtigen Arbeiten sind. Die Wichtigkeit wird nicht durch die Entwicklung definiert, sie hat damit nichts zu tun. Die Wichtigkeit wird durch alle Stakeholders des Produkts definiert. Natürlich ist auch die Entwicklung ein Stakeholder des Produkts, aber nur einer unter vielen.
Scrum definiert dafür die Rolle des Product Owners, einer Person, welche das letzte Wort über die Wichtigkeit hat. Dies ist nützlich, wenn sich Stakeholders nicht einigen können.
In Scrum wird der Backlog nicht priorisiert, sondern rangiert. Dieser feine Unterschied ist wichtig, weil eine Priorisierung mit Stufen (1, 2, 3) zu grob ist. Bei einer reinen Priorisierung haben viele Arbeiten Priorität 1 und nur wenige zweite Priorität.
Kanban fügt noch eine weitere, interessante Technik hinzu: Stakeholder selektieren regelmässig die nächsten wichtigen Arbeiten. Dabei können sie zum Beispiel nur 10 Arbeiten selektieren, für mehr hat es nicht Platz. Das Team arbeitet danach die selektierten Arbeiten ab und generiert dadurch wieder freie Plätze. Beim nächsten Treffen können die Stakeholders diese offenen Plätze wieder mit neuen offenen Arbeiten füllen. Dadurch muss nicht die ganze Liste der offenen Arbeiten rangiert werden und die Stakeholders verhandeln zusammen, welches die nächsten wichtigen Arbeiten sind.
Geschätzt:
Jeder Eintrag im Backlog, häufig auch Product Backlog Item oder User Story genannt, hat eine Aufwandsschätzung. Diese Schätzung wird durch diejenigen abgegeben, welche die Arbeit danach auch ausführen, d.h. durch die Entwicklung. 
Parallel dazu schätzen die Endkunden oder die Stakeholders den Wert eines neuen Features. Für beide Schätzungen gibt es interessante Techniken, wie Story Points und Planning Poker, resp. Business Value Poker. Wenn nun der Wert durch den Aufwand dividiert wird, ergibt sich der Return on Investment pro Item. Wenn ein Item wenig Aufwand zur Realisierung braucht, aber einen hohen Wert hat, sollte dieses früher realisiert werden, als ein Item mit hohem Aufwand und nur wenig Wert.
Gewartet:
Die Einträge im Backlog werden regelmässig durch die Entwicklung diskutiert: Wo gibt es neue Items ohne Schätzung, wo muss die Schätzung wegen neuen Erkenntnissen überprüft werden. Welche Items steigen in der Rangliste und müssen entsprechend detailliert werden. Die Stakeholders diskutieren auch regelmässig die Wertschätzung und die Rangierung. Dieser Arbeiten werden vielfach zusammen in sogenannten Product Backlog Groomings gemacht.
Sichtbar:
Der Backlog ist für alle Stakeholders und die Entwicklung einsehbar. Viel besser ist es, wenn er gleich für die ganze Firma und die Kunden einsehbar ist (Der Misthaufen beim Bauernhof ist ja auch für alle Spaziergänger sichtbar). Dies ist für die offene Diskussion der nächsten Arbeiten notwendig und schafft Vertrauen. Microsoft zum Beispiel hat seinen Backlog für Visual Studio auch offen gelegt und lässt die Anwender an der Rangierung aktiv teilhaben (siehe http://bit.ly/pKnm5W).
Ein Backlog, offiziell anerkannt und gewartet durch Stakeholders, entlastet die Entwicklung. Sie kriegt Luft für die wichtigsten und wertbringendsten Arbeiten und muss sich nicht mit Prioritätsänderungen von Items mit tiefem Wert und mit neuen (Furz-)Ideen herumschlagen.
Also lieber Entwicklungsleiter: Misthaufen nach draussen, Stube reinigen, Fenster auf und frische Luft hereinlassen. Und den Misthaufen draussen gut durch die Stakeholders und Entwickler pflegen lassen. Und liebe Entwickler: Macht euren Entwicklungsleiter darauf aufmerksam, dass ihr gerne die Stube reinigen wollt.

Kommentare (0)

×

Updates

Schreiben Sie sich jetzt ein für unsere zwei-wöchentlichen Updates per E-Mail.

This field is required
This field is required
This field is required

Mich interessiert

Select at least one category
You were signed up successfully.

Erhalten Sie regelmäßige Updates zu neuen Blogartikeln

Jetzt anmelden

Oder möchten Sie eine Projektanfrage mit uns besprechen? Kontakt aufnehmen »