Wetter von gestern

Wie viel Stories schafft ein Team in einem Sprint? Da kann man viel Aufwand betreiben, um das zu planen, oder einfach das Wetter von gestern zu Rate ziehen. Dieses Prinzip stammt aus dem Extreme Programming. Es hilft mir in fast jedem SprintPlanning weiter.

"Stormy Weather!" von Khalid Almasoud

Der Legende nach (beschrieben in Kapitel 8 von "Planning Extreme Programming" von Kent Beck und Martin Fowler) gab es mal einen Wetterdienst, der einen Haufen Geld investierte, um das Wetter besser vorhersagen zu können. Das Ergebnis waren Vorhersagen mit einer 70 %igen Wahrscheinlichkeit. Irgendwann hat dann jemand herausgefunden, dass man diese Wahrscheinlichkeit auch dann erreicht, wenn man vorhersagt, dass das heutige Wetter genauso sein wird wie das von gestern. Praktische Simplizität.

Das Team schafft also vermutlich genau so viel im kommenden Sprint, wie das, was es im letzten Sprint geschafft hat. Und genau so viel plant das Team dann auch ein im SprintPlanning. Diese Prinzip finde ich erfrischend einfach und immer wieder erstaunlich zutreffend.

Anzumerken sei noch, dass dieses Prinzip immer nur ein Startwert sein kann. Wenn im letzten Sprint die Hälfte der Entwickler sich einen Magen-Darm-Virus eingefangen haben, die Geschwindigkeit der Entwicklung entsprechend niedrig war und nur 5 von 10 geplanten Stories fertig gestellt wurden, dann wäre es höchst unwahrscheinlich, dass im nächsten Sprint auch nur 5 Stories fertig gestellt werden. Analog würde man ja auch nicht annehmen, nur weil heute ein Jahrhundertsturm durchs Land wütet, dass der morgen noch einmal vorbeikommt. Hier bin ich bislang ganz gut gefahren, wenn ich das Wetter von Vorgestern zum Planen heranziehe.

XpDays 2008

Oha, da habe ich doch glatt verpennt, auf die XpDays 2008 aufmerksam zu machen. Shame on me! Und dabei sind die schon nächste Woche. Egal, dann bin ich halt einer der letzten, der erwähnt, dass die XpDays dieses Jahr wieder so richtig gut zu werden scheinen.

Das Programm hat's in sich: Donnerstags war sonst immer das Vorgeplänkel mit Workshops, doch dieses Jahr sind auch hier schon Sessions verfügbar. Parallel zu den Sessions läuft ein Agiler Schnupperkurs in Form eines Workshops, durch den Jens Coldewey und ich führen, und zwar ohne PowerPoint. Da freue ich mich schon drauf, finde es aber auch schade, dann keine Zeit für die Donnerstags-Sessions zu haben. Egal, das wird hoffentlich wieder ausgeglichen mit dem Extreme poetry & Buzzword Roulette von Martin Heider und Christine Neidhardt. Bin mal gespannt, was und wie das wird :-)

Tags darauf ist dann der Hauptteil der Konferenz: Begrüßung plus 19 Sessions plus Keynote werden angeboten. Johannes Link wird etwas über TDD, Ajax und Web 2.0 erzählen, Henning Wolf wird Agile Methoden einführen, Frank Westphal berichtet über Getting Real von den 37 Signals, dann komme ich mit einer Session über Werte, und Andreas Höfers Session "Vergleich erfahrener und unerfahrener Entwicklerpaare" ist ein Geheimtip: Wenn die annährend so interessant wird wie letztes Jahr, dann kann ich einen Besuch bei Andreas' Session nur emfehlen!

Na, noch nicht genug? Ein Novum in diesem Jahr ist der Community-Day am Samstag! Da freue ich mich schon ganz besonders drauf, denn das Format des Community-Day wird Open Space sein, und wer so etwas schon einmal mitgemacht hat, der weiß, dass es sehr kurzweilig, informativ und vor allem effizient ist.

Ich erwarte in diesem Jahr auch viele Scrummer auf den XpDays anzutreffen. Das Programm-Kommitee konnte sich noch nicht durchringen, die XpDays in so etwas wie AgileDays umzubenennen, aber immerhin haben die XpDays jetzt die Tagline All About Agile, und da dürfen dann auch endlich die Agilen jeder Methode ruhigen Gewissens teilnehmen ;-)

Laut Stefan Roock, dieses Jahr Vorsitzender des Programm-Kommitees, sind die XpDays fast ausgebucht. Ich persönlich mag die XpDays sehr gerne und sie sind jedes Jahr aufs Neue ein Highlight in meinem Kalender. Ich hoffe, wir sehen uns dort?

Zu guter Letzt: Es gibt einen XpDays-Blog unter http://xpdayblog.it-agile.de/blog

stilversprechend.de

Nach werkannwann.de (ich berichtete) gibt es ein weiteres hilfreiches Tool als Webapplikation aus dem Hause it-agiles: stilversprechend.de analysiert den Stil eines Textes und gibt hilfreiche, mindestens aber interessante Informationen über ihn aus.

Die User-Story ist ziemlich einfach: Schreiber schreibt Text. Schreiber möchte Feedback, ob der Text so okay ist oder er ihn noch verbessern kann. Schreiber hat niemanden, der ihm Feedback gibt. Schreiber ist frustriert, weil er kein Feedback bekommt. Schreiber surft zu stilversprechend.de und gibt den Text ein per Copy 'n Paste. Stilversprechend.de gibt Schreiber Informationen über den Stil des Textes. Schreiber passt Text an, damit dieser lesbarer und stilvoller wird. Schreiber ist glücklich, weil er Feeback bekam.

Surft man zu stilversprechend.de, so erscheint ein Formular mit zwei Eingabefeldern und drei Buttons. In das große Formular kann man Text eingeben, und wenn man dann auf "Text prüfen" klickt, wird der Text geprüft und das Ergebnis ausgegeben. Alternativ kann man auch eine URL angeben und dann wahlweise per Häkchenbox den Text einlesen oder gleich überprüfen lassen.

Das Ergebnis ist schon ziemlich umfangreich: Anzahl der Zeichen, Wörter, Silben und Sätze wird ausgegeben. Es wird der Flesch-Wert berechnet, mit dem man erkennen kann, ob man seine Artikel eher dem Axel-Springer-Verlag (Bildzeitung; Fleschwert 61-70) oder dem Julius-Springer-Verlag (wissenschaftliche Titel; Fleschwert 20-30) anbieten sollte. Werte für den Durschnitt von Wörtern pro Satz, Silben pro Wort, Kommas pro Satz und die Passivrate werden ermittelt. Das sind schon ganz nützliche Angaben, wie ich finde. Darüber hinaus wird der analysierte Text noch mit zusätzlichen Angaben versehen: Nominalstile, Füllwörter, lange Sätze und Wörter, Floskeln, Wortdoppelungen und Satzanfänge mit "Es", Passivsätze und Anglizismen werden hervorgehoben dargestellt.

Eine (sehr gut und lustig geschriebene) Kritik an dieser Art der Stilüberprüfung weist darauf hin, dass man in seiner künstlerischen Freiheit durch Metriken wie den Fleschwert zu stark eingeschränkt wird, wenn man dieser Metrik quasi blind Folge leistet. Die Hintergründe zu verstehen lohnt sich daher. Und wie bei jeder Metrik steckt auch hier eine Implikation dahinter, keine Äquivalenz: Gute Texte haben gute Kennzahlen, aber nur, weil die Kennzahl gut ist, muss der Text es noch lange nicht sein. Allerdings: Schlechte Kennzahlen deuten auch auf schlechte Texte hin. Aber wir kennen soetwas ja zur Genüge bei der Testabdeckung...

Guter Stil ist übrigens relativ: Ich habe mich mit Kollegen darüber unterhalten, und die Meinungen gehen weit auseinander. Während ich persönlich der Ansicht bin, dass selbst die Präsentation eines Produktes im Comicstil (Fleschwert über 70) überaus gut ankommen, wird auch gerne die Ansicht vertreten, dass der Stil gehoben sein müsse, damit der Text überhaupt vorzeigbar ist (Fleschwert 20-30; geht in Richtung der Soziolekte, Stichwort: restringierter und elaborierter Code). Ach ja, da waren doch damals diese stressigen Diskussionen mit meinem Prof, ich solle doch meine Sätze nicht so einfach halten, dass sei ja nicht wissenschaftlich... :-(

Natürlich bleibt es dem Schreiber vorbehalten, Änderungen aufgrund der Angaben von stilversprechend.de durchzuführen. stilversprechend.de bietet einen Spiegel für den Verfasser und trägt nicht selbst das Make-Up auf oder drückt einen Pickel aus. Wer auf z.B. Wolf Schneider und seine Stilkunde steht, der mag seine helle Freude an dem Tool haben. Ich selbst untersuche jeden meiner Blogeinträge vor dem Veröffentlichen mit stilversprechend.de. So siehen die Kennzahlen für diesen Post aus:

Screenshot der Kennzahlen von stilversprechend.de für diesen Post. Naja, ist nicht ganz ein Comic geworden :-)

Mein Featurewunsch an stilversprechend.de: Ein Widget für meinen Blog wäre toll, mit dem ich die Metriken direkt abfragen kann. Dann könnte ich in den Footer schreiben: Dieser Post besteht aus v Sätzen, w Wörtern, x Silben, y Zeichen und hat einen Fleschwert von z.


Glückwunsch an meine Kollegen von it-agile für dieses aus meiner Sicht feine und sehr nützliche Tool! Und hoffentlich lest ihr auch meinen Featurewunsch hier und priorisiert den hübsch weit oben in Eurem ProductBacklog, damit ich bald in Eurem Blog von stilversprechend.de nachlesen kann, wie ich das Widget einbauen kann.

Horizontaler und Vertikaler Schnitt von Stories

Jede agile Methode teilt ihre funktionalen Anforderungen: Extreme Programming hat seine Stories, Feature Driven Development - es steht schon im Namen - seine Features und Scrum hat, je nach Quelle, seine ProductBacklog Items aka Features aka Stories. Ich beobachte oft, wieviel vom guten Schnitt der Stories abhängt. Ein Aspekt des guten Schnitts ist das vertikale Schneiden, im Gegensatz zum ungünstigen horizontalen Schnitt.

"Stories schneiden" meint den Vorgang, aus einer Anforderung gut verdaubare Häppchen zu erstellen, die schätzbar und priorisierbar sind und dem ProductOwner einen echten Mehrwert liefern.

Man stelle sich ein Backend-System vor, dass Termine, Kontakte und Aufgaben von einer Quelle abgreift, etwas damit macht und in ein Ziel schreibt. Es gibt dieses Backend-System noch nicht, der ProductOwner will es erst haben, das Team hat es noch nicht gebaut. Der ProductOwner schreibt dafür eine Story: "Lese Termine, Kontakte und Aufgaben aus der Quelle ein und schreibe sie ins Ziel."

Der ProductOwner stellt die Story dem Team vor. Das Team sagt: "Uffz!" und gibt damit zum Ausdruck, dass es da einen ziemlichen Brocken vorgesetzt bekam. Das Team weiß nicht so recht, was mit den Daten geschehen soll zwischen Quelle und Ziel, und es verzettelt sich einige Male in Nebensächlichkeiten bei der Diskussion. Der ProductOwner bittet das Team, den Aufwand zu schätzen. Das Team schätzt die Story auf 23 StoryPoints (SP), wobei einige eher 10 SP schätzen würden, andere eher 50. Dem ScrumMaster fällt auf, dass das Team im ganzen letzten Sprint 23 SP geschafft hat. Die Story ist zu groß für den Sprint. Stories sollten nie größer sein, als dass man sie nicht während eines Sprints erledigen kann. Auch traut der ScrumMaster der Schätzung nicht, da die Spanne von 10 bis 50 SP darauf hindeutet, dass das Team keine einheitliche Vorstellung von der Story hat.

Alle Anforderungen in einer einzigen Story. Die Story ist 23 SP groß, wobei die Schätzungen der Teammitglieder zwischen 10 und 50 SP auseinandergegangen sind.

Der ScrumMaster rät dem ProductOwner, die Story zu teilen. Die einzelnen Teile wären überschaubarer, einfacher zu durchleuchten vom Team und auch einfacher zu schätzen. Der ProductOwner schreibt zwei Stories: "Lese Termine, Kontakte und Aufgaben aus Quelle" und "Schreibe Termine, Kontakte und Aufgaben ins Ziel". Das Team schätzt das Einlesen mit 12 SP und das Schreiben mit 14 SP, und die Schätzungen sind einheitlicher als bei der vorherigen großen Story.

Zwei Stories, horizontal geschnitten (12 SP + 14 SP = 26 SP)

Der ProductOwner bemerkt, dass das ja nun auch nicht besser sei, als bei der großen Story: Zusammen wär's nun noch teurer geworden (12 + 14 = 26). In einen Sprint passen die beiden Stories nun auch nicht, da 26 SP für beide Stories zusammen größer ist als das, was das Team im letzten Sprint geschafft hat und laut Wetter von Gestern im nächsten Sprint schaffen wird. Außerdem fängt das Team an, die Schnittstelle zwischen den Schichten des Systems (Lesen und Schreiben) abzusprechen, wobei die enormen Abhängigkeiten der beiden Stories zueinander deutlich werden: Das Team wird sich voraussichtlich in Diskussionen um Schnittstellen-Verträge verheddern. Der ScrumMaster erkennt, dass das System horizontal nach den Schichten (Frontend, Backend) geschnitten wurde, was die Probleme beim ProductOwner und beim Team verursacht.

Der ScrumMaster bittet den ProductOwner, das System vertikal in Stories zu schneiden. Der ProductOwner versucht es: "Lese Termine aus Quelle und schreibe sie ins Ziel." - "Lese Kontakte und schreibe sie ins Ziel." - "Lese Aufgaben und schreibe sie ins Ziel." Das Team stellt fest, dass die Aufgaben weitestgehend unabhängig voneinander sind, und freut sich, keine Schnittstellen-Verträge festklopfen zu müssen.

Drei Stories, vertikal geschnitten und (noch) nicht schätzbar, da nicht klar ist, in welcher Story welche storyübergreifende Anforderung "versteckt" ist

Das Team versucht zu schätzen - und scheitert. Es weiß jetzt nicht, wo es die zusätzlichen Aufgaben unterbringen soll, die in jeder Story enthalten sein werden: Beim Einlesen sollen die Daten auch validiert und beim Schreiben nach Angaben vom Ziel umgewandelt werden. Beim Lesen soll ein Puffer zum Einsatz kommen, beim Schreiben eine Warteschlange. Das Team sagt, das hätten sie implizit mitgeschätzt bei der ganz großen Story oder den beiden mittelgroßen, horizontal geschnittenen Stories.

Der ProductOwner wandelt die impliziten Anforderungen in explizite Stories um: "Validiere Termine beim Lesen." - "Validiere Kontakte beim Lesen." - "Validiere Aufgaben beim Lesen." - "Wandle Termine um vorm Schreiben gemäß Ziel." - "Wandle Kontakte um vorm Schreiben gemäß Ziel." - "Wandle Aufgaben um vorm Schreiben gemäß Ziel." - "Baue Puffer beim Lesen ein." - "Baue Warteschlange beim Schreiben ein." Das Team schätzt erneut: Termine und Kontakte zu lesen und zu schreiben kosten je 3 SP, Aufgaben zu lesen und zu schreiben kosten 4. Das Validieren schlägt mit je 2 SP zu Buche, das Umwandeln 1 bzw. 2 bzw. 3 SP. Der Puffer kostet 2 SP, die Warteschlange 4.

Elf Stories, vertikal geschnitten und geschätzt (3 SP + 3 SP + 4 SP + 2 SP + 2 SP + 2 SP + 1 SP + 2 SP + 3 SP + 2 SP + 4 SP = 28 SP)

Der ProductOwner wird ungehalten, denn er rechnet nach, dass ihn alles zusammen 28 SP teuer zu stehen kommen werden. Er wäre lieber bei der einen großen Story geblieben, denn die hätte ihn 7 SP weniger gekostet. Der ScrumMaster erklärt, dass die Schätzung nun wesentlich genauer sei und das Team vor allem jetzt das explizit schätzen konnte, was vorher nur implizit in die Schätzung eingegangen war. Von daher sei jetzt nur transparent gemacht worden, was schon die ganze Zeit dagewesen wäre, vorher allerdings verdeckt.

Der ProductOwner wirft ein, dass trotz aller Teilung die Summe nicht in den nächsten Sprint passe. Der ScrumMaster sieht das auch so, und teilt dem ProductOwner mit, dass sie jetzt einen kritischen Pfad hätten (nicht zu verwechseln mit der Methode des kritischen Pfades). Der ScrumMaster zeigt dem ProductOwner den kritischen Pfad:

Elf Stories, drei davon auf dem kritischen Pfad (kritischer Pfad = 3 SP + 3 SP + 4 SP = 10 SP)

Der ProductOwner versteht noch nicht ganz: Was bringt ihm der kritische Pfad? Der ScrumMaster erläutert, dass alles auf dem kritischen Pfad Liegende ausschlaggebend für das erreichen des SprintGoals ist. Das, was der ProductOwner haben wolle, sei das Lesen von Daten aus einer Quelle und das Schreiben der Daten in ein Ziel. Die entsprechenden Stories kosten den ProductOwner nur 10 SP, und sind mit ziemlicher Sicherheit am Ende des Sprints umgesetzt. Der ProductOwner könnte dann sein Kerngeschäft (Lesen und Schreiben von Daten) vorführen, testen, damit experimentieren, sogar damit in einer Beta-Phase online gehen.

Der ScrumMaster führt weiter aus, dass diese Stories für den vertikalen Schnitt durch das System - er nennt es auch "den Durchstich" - erst einen vollständigen Integrationstest durch alle kritischen Bereiche des Systems ermöglichen, ja sogar eine ideale Grundlage für Akzeptanztests bilden. Hierfür müssen alle wichtigen Bereiche des Systems kollaborativ miteinander arbeiten. Jedes Sandkorn im Getriebe würde sofort bemerkt werden. Sobald ein Durchstich durch das System erst einmal erreicht ist, dienen die Akzeptanztests als Regressionstests und halten das System dauerhaft am Leben.

Was mit den anderen Stories denn noch sei, die nicht auf dem kritischen Pfad liegen, möchte der ProductOwner wissen. Die seien, so der ScrumMaster, seitlich an den kritischen Pfad anzudocken. Der Durchstich würde quasi verbreitert. Bei der Umsetzung der nicht auf dem kritischen Pfad liegenden Stories könne der Durchstich als Unterstützung angesehen werden: Die Validierung erweitert das Lesen um einen Aspekt, wodurch das Lesen als solches aber nicht beeinträchtigt wird. Die vorhandene Infrastruktur, geschaffen per Durchstich, kann ausgebaut werden. Und falls es Komplikationen während des Sprints gibt, werden allenfalls die Stories im Sprint nicht erledigt, die nicht auf dem kritischen Pfad liegen.

Der ProductOwner fügt den Stories auf dem kritischen Pfad die aus seiner Sicht höchstpriorisiertesten Stories hinzu, so dass der Sprint "voll" wird. Er wählt das Validieren mit je 2 SP, den Puffer und die Warteschlange für 2 bzw. 4 SP, und das Umwandeln der Termine für 1 StoryPoint. Zusammen mit den 10 SP für die Stories des kritischen Pfades kommt er so auf 23 SP, was dem entspricht, was das Team im letzten Sprint geschafft hat.

Elf Stories, neun davon im jetzigen Sprint eingeplant (23 SP), zwei davon nicht im jetzigen Sprint eingeplant (5 SP)

Alles wird gut, meint der ScrumMaster.

Update: Dank an Jens Coldewey fürs Korrigieren einer Addition.

Bootcamps und CSM-Tests

Auf InfoQ erschien vor ein paar Tagen ein Artikel zum Thema Scrum Certification Test. Dort berichtet der Autor Mark Levinson, dass ab 2009 jeder Teilnehmer eines Certified-Scrum-Master-Kurses nur noch dann als Certified Scrum Master (CSM) von der Scrum Alliance zertifiziert werde, wenn er einen Abschlusstest erfolgreich absolviert habe. Eine erste Version des Tests sei auf dem Scrum Gathering diesen Herbst in Stockholm entworfen worden.

Sehr interessant finde ich die Ansichten zu dem Thema von Alistar Cockburn (ausschnittsweise beschrieben im Artikel, ausführlich im entsprechenden Post auf der englischsprachigen Scrum-Mailingliste zu finden):

1. "Well, tbe problem is that the course is to certify a person as having learned the ScrumMaster role, but people use the course as a Scrum Bootcamp course (and get a free certificate from it)."
   Er spricht im weiteren Verlauf von einem "Certified Bootcampee" - und trifft die momentane Situation aus meiner Sicht damit sehr gut. Mit einem Scrum Bootcamp würde das explizit gemacht, was bislang implizit sowieso der Fall war.
2. "What we have now is a really untenable situation where thousands of
   people have CSM certificates without possibly even knowing basic
   Scrum rules..."
   Bingo! Ich kennen keinen, der mal den CSM-Kurs nicht bestanden hat. CSM wird man durch die Kursteilnahme, quasi durch Handauflegen. Ich höre immer wieder die Meinung, dass man durch eine zweitägige Schulung nicht wirklich als Scrum Master agieren kann. Das meine ich auch. Da ist noch kein Master vom Himmel gefallen, auch nicht in zwei Tagen. Von daher würde ich ein Scrum Bootcamp begrüßen, als Vorstufe zum CSM mit Aufnahmeprüfung.

SprintGoals und Überstunden

Ist das SprintGoal ein Versprechen vom Team an den ProductOwner? Eines, dass um jeden Preis eingehalten werden muss, notfalls mit Überstunden und Urlaubsverzicht?

Ja, könnte man so sehen. Der ProductOwner bekommt immer genau das am Ende eines Sprints, was das Team zu Anfang im SprintPlanning ihm zugesagt hat. Hat das Team sich verschätzt, so muss es sehen, wie es den Karren wieder aus dem Dreck prügelt. Egal wie: Das BurnDownChart soll am letzten Tag des Sprints bei 0 landen. Punktlandung. Der ProductOwner ist zufrieden, denn er hat das Erwartete bekommen, oder nicht?

Nein, tatsächlich bekommt er nicht das Erwartete. Das SprintGoal ist kein Funktionalitätsversprechen, sondern eine Schätzung. Schätzungen können daneben gehen, das Team kann und darf sich verschätzen. Wenn das Team sich verschätzt hat und die Funktionalitäten mehr Zeit brauchen, als der Sprint es zulässt, dann spart das Team in der Regel an der Qualität: es werden weniger Tests geschrieben, es wird weniger refaktorisiert, es wird weniger über die eigene Arbeit reflektiert. Es wird gespart an Abstimmungen zwischen den Kollegen. Das Team vernachlässigt sich selbst, tut sich selbst nichts mehr Gutes. Wie könnte es da jemand anderem, dem ProductOwner, etwas Gutes tun? Der ProductOwner bekommt seine Funktionalitäten, aber in einem miserablen Zustand.

Eine schlechte Qualität bei einer Punktlandung abzuliefern hat Konsequenzen: Die geplanten Funktionalitäten des nächsten Sprints werden auf schlechter Qualität aufbauen müssen. Das kostet Zeit, Zeit vom nächsten Sprint, und im Endeffekt werden weniger Funktionalitäten gebaut als im Sprint zuvor. Die Punktlandung des vorherigen Sprints suggeriert, dass der Sprint erfolgreich war. War er aber gar nicht: Es gab keine ausreichende Qualität.

Punktlandungen bei BurnDownCharts misstraue ich. Natürlich sollten SprintGoals erreichbar sein, und in der Regel landet ein eingespieltes Team in der Nähe der Nulllinie, knapp drüber oder drunter. Ein genauer Treffer der Nulllinie würde bedeuten, dass das Team beim Planen exakt wusste, was passieren wird. Keine Schätzung, sondern eine Prophezeiung, eine Zukunftsvision. Daran glaube ich nicht.

SprintGoals als Versprechen zu sehen ist unfair aus Sicht des Teams. Falls das Team sich verschätzt hat zu seinen Ungunsten, dann soll es dafür büßen mit Überstunden und 120%igem Einsatz. "Durch Schmerz lernen die schon" habe ich einen ScrumMaster sagen hören über ein Team. Und was ist, wenn das Team sich zu seinen eigenen Gunsten verschätzt? Was ist, wenn sie schneller das SprintGoal erreicht haben, also noch vor Sprint-Ende? Darf es den 5. Tag bezahlt frei machen, wenn es seine auf fünf Tage geschätzte Arbeit in vieren erledigt? Darf oder muss es dass tun, was jede Festpreis-Verträge eingehende Firma tut, also die Differenz einheimsen bzw. bezahlen? Habe ich noch nicht erlebt, dass dies einem Team erlaubt wurde... Warum eigentlich nicht? Wäre doch fair?!

Punktlandungen und SprintGoal-Versprechen passen auch nicht zu Scrum, denn sie setzen die Funktionalität fest, was auf Kosten der Qualität geht. Scrum will Qualität haben vom Team. Sollte der ProductOwner an seinen Funktionalitäten festhalten, so hat er einen Ziel- oder Prioritätenkonflikt: Will er alle Funktionalitäten, dafür aber Qualitätsverluste, oder will er Qualität, dafür aber weniger Funktionalität? Scrum setzt auf Funktionalitätenschwund statt Qualitätsverlust während der Projektlaufzeit. Aus den gleichen Gründen sollte das der ProductOwner auch während eines Sprints tun. Hier ist Projektlaufzeit und Sprint selbstsymmetrisch.

Wie verhält sich ein Team, dem eine Schätzung abgerungen wird und das ganz genau weiß, dass es diese Schätzung einhalten muss, notfalls mit Überstunden? Wird es dadurch pessimistischer Schätzen? Lernt es durch den Schmerz (aka Überstunden)? Nein, es schätzt nicht pessimistischer, und es lernt auch nicht in dem Maße, wie es erforderlich wäre, um realistischer zu schätzen. Mal angenommen, dass Team verschätzt sich zu seinen eigenen Ungunsten. Die Zeit wird nicht reichen, um die Funktionalität ordentlich (also qualitativ zufriedenstellend) bereitzustellen. Das Team wird versuchen, mit Überstunden gegenzusteuern. Dadurch wird das Ergebnis an Qualität einbüßen, denn Überstunden sind außerhalb der produktiven Zone, weil außerhalb einer nachhaltigen Arbeitsgeschwindigkeit. Und vielleicht reichen die Überstunden auch nicht zur Kompensation des Verschätzens. Spätestens jetzt wird die Funktionalität mit den sehr heißen Nadeln gestrickt: Qualität ade!

Unvorteilhaft an Qualität ist ihre große Feedbackschleife: Erst relativ spät erkennt man den Mangel an Qualität. So meint nun der ProductOwner bei einem Sprint mit Überstunden - der ja sehr erfolgreich war, weil das BurnDownChart eine Punktlandung anzeigt -, dass alles in Ordnung sei. Der ProductOwner meint, er könne wieder ein SprintGoal-Versprechen dem Team abringen. Hier schließt sich der Kreis. Nach ein paar Sprints verlangt das Team nach Aufräum-Sprints, in denen keine Funktionalität mehr produziert werden kann. Das Team ist gestresst aufgrund der Überstunden und des hohen Drucks durch das SprintGoal-Versprechen. Die Moral ist am Ende. Das Projekt bald auch.

Die Alternative? Wenn das Team sich überschätzt hat und nicht alle Funktionalitäten in diesem Sprint bereitstellen kann, dann wirkt sich das auf die Entwicklungsgeschwindigkeit aus und damit auf die Teamgeschwindigkeit, also auf die Anzahl der Stories/Features/Tasks/Idealen Stunden/Gummibärchen/Tomaten, die das Team in einem Sprint schafft. Per Wetter von gestern geht die Überschätzung des Teams in den nächsten Sprint ein: Das Team wird sich weniger Stories/... vornehmen. Aber unabhängig davon: Was das Team auch immer produzieren wird, das soll es in Ruhe und ohne Druck machen, damit es qualitativ hochwertige Arbeit abliefern kann. Eine Arbeit, auf die das Team selbst stolz ist. Dies darf bedeuten, dass am Ende des Sprints weniger Funktionalitäten für den ProductOwner herausspringen.

Ist das nicht sehr unkomfortabel für den ProductOwner, wenn nun das Team nun quasi abliefern kann am Ende des Sprints, was es will? Wo bleibt die Planbarkeit? Das Ziel sollte weiterhin sein, möglichst gute Vorhersagen treffen zu können, wie viel das Team während eines Sprints schafft. Das schafft Transparenz, die nicht zuletzt dafür benutzt werden kann um nachzuschauen, in welcher Zeit wie viel vom ProductBacklog abgearbeitet sein wird. Genau das aber wird nicht erreicht durch SprintGoal-Versprechen. Bei diesen Versprechen machen alle beteiligten die Augen zu und hoffen, den Wagen schon irgendwie auf der Straße halten zu können, während er langsam in die Böschung schlingert, weil keiner gegenlenkt! Nur durch ein selbstregulierendes System bei aufrechterhaltener Qualität kann eine realistische Prognose und damit Transparenz erzielt werden: "Wetter von gestern" und das Team in Ruhe arbeiten lassen.

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.