Wozu Agilität? Continous Feedback

Wozu Agilität? Continous Feedback

Never say ‚I know‘.
Eliyahu Goldratt

 


 
Podcast bei iTunes
Folien bei Slideshare
 

Die Schwerfälligkeit des V-Modells

Und dann kommen wir im V-Modell jetzt quasi im „V“ Stück für Stück weiter nach oben und kommen jetzt zu den Anforderungen. Da war es vorher ja so, dass am Anfang ein Lastenheft geschrieben wurde, daraus wurde ein Pflichtenheft abgeleitet, dann Design, Architektur, Entwicklung, 3 Jahre Laufzeit und irgendwann wird es dann gegeneinander getestet und dann wird es schwer. Dazu habe ich ein Bild mitgebracht, das möchte ich einfach mal auf Sie wirken lassen. … Es braucht ein paar Sekunden. Das Schönste dabei finde ich ja noch, dass dann irgendjemand mal gesagt hat „Naja, das war zwar alles verkehrt, aber wir kleben einfach mal das C noch hier oben um die Ecke“ Wer kennt solche Projekte? Das machen wir doch alle so, oder? Schnell noch mal ein Balkon dran gebaut.

Never say ‚I know‘

„Never say ‚I know'“ ist ein Zitat von Eli Goldratt, dem Begründer der Theory of Constraints. Letztendlich: Nicht mehr davon ausgehen, dass das was ich einmal geschrieben habe – auch wenn so ein Lasten- oder Pflichtenheft viel Mühe macht -Sie müssen davon ausgehen, dass ein Großteil davon falsch ist. Und deswegen wäre es doch eigentlich besser gar nicht erst so viel davon zu schreiben. Wenn ich eine Idee für ein Produkt habe, eine initiale Produktidee, dann ist das ja erst mal eine Wolke. Ich weiß doch noch gar nicht genau, was ich eigentlich will. Ich weiß noch nicht, was der Kunde genau will. Und dann kommt dieses V-Modell oder andere klassische Ansätze und die sagen: Du musst Dich jetzt festlegen.

Starre Anforderungen in hochdynamischen Umgebungen

Und dann mache ich innerhalb der Wolke einen fixen weißen Punkt hin und sage: Genau das ist jetzt meine Produktidee. Aber das ist ja schon ein Fehler in sich. Weil die Produktidee ja noch sehr schwammig ist, eben eine Wolke. Der nächste Fehler ist dann, den Entwicklungsteams zu sagen, dass dies die Produktidee ist und sie genau dorthin müssen. Denn dann laufen die los. Und wenn das noch solche Unternehmen sind wo man sagt: Die Abteilungen sind schön voneinander getrennt, und wenn eine Abteilung fertig ist wirft sie das Ergebnis zurück über den Zaun zur Nachbarabteilung.

Projekterfolg oder Produkterfolg?

Dann heißt das letztendlich, dass sich das Entwicklungsteam zu der ursprünglichen Produktidee ankommt, dass Projekt wurde also erfolgreich abgeschlossen. Aber die Anforderungen haben sich im gleichen Zeitraum dramatisch verändert und liegen jetzt sogar außerhalb der ursprünglichen Wolke. Das eigentliche Produkt ist somit gescheitert. Projekt erfolgreich, Produkt gescheitert. Verdienen kann man damit nichts. Wie wäre es denn, wenn man auch hier schrittweise vorgeht?

Der Vorteil von Sprints

Im agilen Bereich gibt es die sogenannten Sprints. Sprints sind Einheiten von typischerweise 1-3 Wochen, in denen am Ende etwas geliefert wird – sozusagen ein Mini-Projekt. Und jeder kleine Pfeil in diesem Schaubild ist ein solches Mini-Projekt. Das Entwicklungsteam geht nach dem Start erst mal auf den weißen Punkt der initialen Produktidee los, in der Zwischenzeit arbeitet aber die Product-Development-Abteilung weiter an den Ideen. Dadurch bewegen sich die beiden Bereiche aufeinander zu, sie konvergieren. Und dann wird aus einem Projekterfolg automatisch auch ein Produkterfolg.

Weiter >>>

Navigation

Teil 1: Wozu Agilität? Klassisches Projektmanagement funktioniert doch auch sehr gut!
Teil 2: Wozu Agilität? Change
Teil 3: Wozu Agilität? Freeze
Teil 4: Wozu Agilität? Zero Bug Tolerance
Teil 5: Wozu Agilität? Continous Feedback
Teil 6: Wozu Agilität? Cross Functional Teams
Teil 7: Wozu Agilität? Unternehmenskultur

Vielleicht auch interessant für Sie...