18. July 2008 | Matthias Marschall

Ich habe es schon oft erlebt, dass an die Produktentwicklung in Startups mit den klassischen Projektmanagementmethoden herangegangen wird. Dazu gehören für mich vor allem das Management nach dem Prinzip des Magischen Dreiecks: Kosten, Termine, Qualität. Wie selbstverständlich geht man oft auch heute noch davon aus, dass diese drei Punkte konträr zueinander sind und man dem angeblichen Widerspruch nur mit Kompromissen begegnen kann. Ich habe allerdings die Erfahrung gemacht, dass das nicht zwingend so ist.

Die Illusion von Fortschritt oder „Wir sind doch im Zeitplan“
Jedes Projekt beginnt mit einem Termin und man ist versucht, so viel Funktionalität wie möglich in die vorgegebene Zeit zu packen. Was folgt sind die üblichen Probleme: Bei einer geplanten Projektlaufzeit von sechs Monaten ist man die ersten fünf Monate perfekt im Plan. Erst gegen Ende merkt man, dass man unendlich viele lose Enden hat, da man, um ursprünglich im Plan zu bleiben, auf Testing oder die Behandlung von Spezialfällen im Code verzichtet hat.

Die Bugwelle
Je näher der Termin rückt, umso mehr unfertige Dinge häufen sich auf, die man gleichzeitig im Auge behalten muss.

„Ist das Administrationsmodul schon fertig?“
„Habt Ihr beim Login den Fall bedacht, dass der User sein Passwort vergessen haben könnte?“
„Kann ich eigentlich den Beitrag, den ich gerade veröffentlicht habe, editieren oder ganz zurück ziehen?“
Und so weiter…

Schier endlose Excellisten mit Aufgaben in einer Vielzahl von verschiedenen Versionen werden per E-Mail ausgetauscht und keiner weiß eigentlich so genau, was wirklich in freischaltbarer Qualität vorliegt. Das liegt vor allem auch daran, dass später hinzugefügte Features oft eigentlich schon fertige Bereiche betreffen und diese damit wieder in eine Baustelle verwandeln.

Die üblichen Verdächtigen
Das haben viele wahrscheinlich auch schon so oder so ähnlich erlebt. Die üblichen Reaktionen sind:

„Wir brauchen mehr Zeit!“
„Wir brauchen mehr Leute!“
oder sogar beides.

Und natürlich wird an der Qualität gespart, um schneller fertig zu sein. Ein Fehler, wie man später oft mit Grauen feststellt.

Das Magische Dreieck durch kürzere Releasezyklen aufbrechen
Ein Release X.Y oder eine Phase Z beinhalten oft Mannjahre an Entwicklungsaufwand, die sich über mehrere Kalendermonate hinziehen. Auch ich habe schon Releases verantwortet, die nach 6 Monaten Entwicklungszeit mit einem Team von 10 Entwicklern freigeschaltet werden sollten. Erst am Ende der 6 Monate hatten wir eine Testphase von 3 Wochen angesetzt. Doch weder waren die geplanten Features zum Anfang der Testphase fertig, noch war deren Qualität auch nur annähernd brauchbar.

Durch die Einführung sehr viel kürzerer Releasezyklen (von 6 Monaten über 2 Monate hin zu wöchentlichen Releases) und einer sehr strikten Definition davon, was “fertig” für ein Feature bedeutet, ist es uns gelungen Geschwindigkeit und Qualität zu steigern.

Dadurch, dass man sich nur ein bis zwei Wochen Zeit gibt, um etwas freischaltbares fertig zu stellen, kann man den Fokus der Produktentwicklung deutlich schärfen. Anstatt das komplette Release X.Y oder den Abschluss von Phase Z im Auge zu behalten, kann man sich erst mal nur darauf konzentrieren, ein oder zwei Features wirklich „fertig“ zu bekommen.

Was heißt eigentlich "Fertig"?
„Fertig“ bedeutet bei so verkürzten Releasezyklen: Freigeschaltet. Der verantwortliche Entwickler programmiert also nicht irgend etwas in der ersten Woche eines 6-Monatsreleases was erst Monate später erstmals getestet wird, sondern kann sich auf genau ein Feature vom Konzept bis zur Freischaltung konzentrieren. Der ganze Softwareentwicklungszyklus von Design, Implementierung, Test wird dabei für jedes Feature innerhalb kürzester Zeit und vor allem an einem Stück durchgeführt.

Dadurch erhöht sich der Fokus auf jedes einzelne Feature und auch die Identifikation der Entwickler mit ihrer Aufgabe steigt, da sie direkt für die freigeschaltete Qualität verantwortlich sind. Bei 6-Monatsreleases geht der Beitrag eines jeden Entwicklers leicht im See der sich gegenseitig beeinflussenden Änderungen unter und jeder Entwickler hat mindestens 1000 Gründe zu argumentieren, warum er nicht für die letztendliche Qualität verantwortlich ist.

Nicht intuitiv - aber wirksam
Eigentlich ist der Ansatz, die Releasezyklen zu verkürzen, nicht intuitiv. Denkt man doch gewöhnlich, dass mehr Qualität ja auch mehr Zeit und höhere Ausgaben benötigt. Doch genau das Gegenteil ist der Fall. Durch die dramatische Verkürzung der Releasezyklen auf eine oder zwei Wochen entstehen Effekte wie höhere Konzentration auf nur eine Aufgabe und höhere Visibilität der eigenen Qualitätsverantwortung durch schnelleres Feedback.

Diese Effekte führen letztendlich zu deutlich höherer Entwicklungsgeschwindigkeit bei viel höherer Qualität. Die Kompromisse des Magischen Dreiecks werden plötzlich durch sich selbst verstärkende Mikroeffekte ausgehebelt und man erreicht doch das Unmögliche: Höhere Qualität bei höherer Geschwindigkeit und niedrigeren Kosten.

Artikelinformation

Artikel-Feed, Kommentar-Feed,

18. July 2008 - 14:41, abgelegt in Kategorie: Autoplenum, Best Practices, Tech, eLAB Projekte

Trackback URL für diesen Artikel:

http://www.holtzbrinck-elab.de/blog/kosten-termine-qualitat-das-magische-dreieck
-hat-ausgedient/trackback/

3 Reaktionen zu “Kosten, Termine, Qualität - Das Magische Dreieck hat ausgedient”

Oliver's Stuff » Diese Effekte führen letztendlich zu deutlich höherer... Am 21. July 2008 um 14:19 Uhr
[...] das Unmögliche: Höhere Qualität bei höherer Geschwindigkeit und niedrigeren Kosten. — Kosten, Termin, Qualität July 21 @ 08:17 AM | Comments | Tags: agile, development, good, fast, [...]
Muck Am 2. August 2008 um 09:21 Uhr
Kurz gesagt: Agile Webentwicklung.
Glaubwürdigkeit von Corporate Blogs » eLAB-Blog Am 19. October 2008 um 12:44 Uhr
[...] die „Wahl des richtigen Domainnamens“ oder von Matthias Marschall über „Agile Development“ schon hatten, sehr gerne. Einfach E-Mail an mich (rene.seifert [at] gmail.com), erst stimmen [...]

Einen Kommentar schreiben