Qualitätsverlust und Funktionalitätenschwund

Wieso kann ein Scrum-Projekt jeden nahezu frei gesetzten Termin halten? Warum macht es einen ScrumMaster in der Regel nicht nervös, wenn das Marketing für irrwitzig frühe Zeitpunkte Produktkampagnen ankündigt?

Ein entscheidender Unterschied zwischen Scrum und der deutschen Herangehensweise "Konzeptions- vor Durchführungsphase", wie sie beispielsweise im Wasserfallmodell zum Einsatz kommt, ist die Variabilität der Funktionalität bzw. der Qualität, erklärt anhand des Teufelsquadrats frei nach Harry Sneed:Das Teufelsquadrat enthält vier Variablen: Funktionalität, Zeit, Qualität und Kosten. Jede Änderung einer dieser Variablen hat die Änderung einer anderen zur Folge: Erhöhe ich die Funktionalität, dann brauche ich dafür mehr Zeit, oder es kostet mich mehr, oder die Qualität wird leiden; habe ich weniger Zeit zur Verfügung, dann kann ich weniger Funktionalität liefern und dann habe ich höhere Kosten (indem ich mir z.B. extern etwas fertigen lasse), oder die Qualität sinkt; habe ich weniger Budget als angenommen zur Verfügung, dann brauche ich mehr Zeit (weil ich Leute entlassen muss), ich kann weniger Funktionalität erstellen oder die Qualität sinkt. Möchte ich eine höhere Qualität haben, dann kostet es mich mehr, ich brauche mehr Zeit oder ich fertige weniger Funktionalität.

Im Wasserfallmodell sind drei Variablen fix: Die Kosten stehen nach der Konzeptionsphase fest, ebenso die Zeit, in der die fest definierte Funktionalität fertig gestellt werden muss.
Bleibt die einzige freie Variable die Qualität. Egal, wo es Probleme gibt, die Qualität bleibt auf der Strecke. Kommen mehr Anforderungen hinzu, soll also mehr Funktionalität umgesetzt werden, so kann ich mir dafür nicht mehr Zeit nehmen, denn die ist ja fix. Auch darf ich mir nichts Hilfreiches dazukaufen oder mehr Leute einstellen, denn die Kosten sind auch fix. Also kann ich nur weniger Qualität abliefern. Ähnlich verhält es sich bei weniger Zeit oder mehr Kosten/weniger Budget: die Qualität hat das Nachsehen.

In Scrum sind ebenfalls drei Variablen fix: Zeit, Kosten und Qualität.
Hier wird an den Funktionalitäten gespart, wenn etwas anderes drückt: Steht weniger Zeit zur Verfügung als angenommen, dann kann nicht so viel Funktionalität umgesetzt werden. Steht doch nicht so viel Budget zur Verfügung wie angenommen, dann setze ich weniger Funktionalität um. Macht mir die Qualität zu schaffen, dann bleibt ein wenig Funktionalität auf der Strecke.

Wenn nun in einem Projekt Hindernisse auftreten, dann kosten diese meistens Zeit. An den Kosten ändert das nicht viel, denn die gleichen Entwickler müssen auf der gleichen Hardware arbeiten.

Im Wasserfall-Projekt hieße dies, die Funktionalität "quick and dirty", schnell und dreckig, runterzuprogrammieren, damit man noch zum Termin hin fertig wird. Damit sind dann meist die Entwickler nicht glücklich, weil sie nicht stolz sein können auf ihre Arbeit, weil sie - mit Ihren Augen gesehen - Schmutz abgeliefert haben. Das Marketing ist nicht glücklich, weil die Endbenutzer haufenweise Bugs melden oder sie das minderwertige Produkt nicht kaufen. Das Management ist nicht glücklich, weil das nächste Release des Produktes sehr viel teuerer wird, da die Entwickler auf minderwertigen Code aufbauen müssen und es entsprechend schwieriger, also zeitintensiver und damit teuer, wird. Niemand ist damit glücklich!

Im Scrum-Projekt sind die Entwickler glücklich, obwohl sie zwar weniger geschafft haben, aber was sie geschafft haben, dass hat Hand und Fuß und der Entwickler kann darauf stolz sein. Das Marketing ist glücklich, obwohl sie nicht alle Funktionalitäten verkaufen können, aber das, was sie verkaufen, ist qualitativ hochwertig, und das freut die Endbenutzer und es werden weniger Bugs gemeldet. Das Management ist glücklich, weil die nachfolgenden Releases echte Funktionalität liefern und keine reinen Sanierungsrunden darstellen. Alle sind damit glücklich!

Natürlich kann man jedes Projekt in den Abgrund reiten, und natürlich kann man nur bis zu einem gewissen Grade die Funktionalitäten beschneiden und trotzdem noch das Projektziel erreichen, analog zur Reduktion der Qualität. Die Beschneidung von Funktionalitäten läßt sich aber sehr transparent darstellen anhand der unterschiedlichen Funktionalitäten, die das Produkt schon hat, noch haben wird wird zum Release, und jene, die es nicht mehr haben wird. Im Gegensatz dazu kann man nur implizit an der Qualität Abstriche machen, und allerhöchstens im Nachhinein explizit feststellen, dass das Produkt nicht gekauft wird oder haufenweise Bugs gemeldet werden. Implizitem Qualitätsverlust ist immer schwerer beizukommen als explizitem Funktionalitätenschwund.