Fertig werden ist eine Entscheidung!

Jahrelang haben wir gelernt, dass wir dann gute Entwickler und Entwicklerinnen sind, wenn wir alle Neben- und Anwendungsfälle  sauber durchdacht und abgesichert haben.

 

Genauso wurde uns in hierarchischen Unternehmen vermittelt, dass wir dann perfekt als Managerinnen oder Manager seien, wenn wir den allumfassenden Plan aufstellten. 

 

Agil arbeiten beziehungsweise "lean arbeiten" fordert etwas anderes. Postuliert wird, dass eine frühzeitige Überprüfung der Ideen im Markt (beziehungsweise bei den Auftraggebern) wichtiger und zielführender ist als das vollständige Ausarbeiten einer Idee.

 

In der Praxis sehen wir daher häufig UserStorys, die nicht enden wollen, und "Minimum Viable Products", die alles andere, aber nicht minimal sind. Hier verkettet sich eine schlanke, schnelle Idee mit alten Idealen des Perfektionismus.

 

Die entsprechenden Mitarbeiter und Mitarbeiterinnen trauen sich schlichterdings nicht, den Ansatz "als bis hierher fertig" zu deklarieren. Die Sorge ist zu groß, dass sie doch etwas Wesentliches übersehen haben.

1. Und ihnen daher auf Grund der vorherrschenden Fehlerkultur eine unfaire Beurteilung durch Vorgesetzte droht,
2. sie von den anderen Team-Mitgliedern für eine schlechte Leistung verantwortlich gemacht werden oder
3. sie insgesamt die Auswirkungen einer Fehlentscheidung nicht absehen können. 

Da die Auswirkungen einer Entscheidung unklar sind -- oder Unannehmlichkeiten drohen -- wird die Entscheidung verschoben, dass die entsprechende UserStory beendet ist beziehungsweise das Featureset für das Minimum Viable Product ausreicht.

 

Damit die Teammitglieder den Grundsatz

Fertig ist eine Entscheidung!

leben können, ist es also notwendig, dass etwaige Auswirkungen einer Entscheidung bekannt und klar sind. Sich für "fertig werden" zu entscheiden, heißt die offenen Restpunkte klar zu benennen und diese konzentriert anzugehen. Ein unklares "da fehlt noch etwas" ist eine (implizite) Entscheidung für das (Ab-)Warten und den Ist-Zustand. 

 

Im Falle der erfolgreichen Entscheidung ist der Leistungsumfang und die erreichte Qualität für das gesetzte Ziel ausreichend. Diesen Fall gilt es zu feiern -- dabei ist genau zu explizieren, was die Beteiligten zum Entscheidungszeitpunkt wussten. Es ist aus dem positiven Fall zu lernen.

 

Wenn die UserStory ist während der Demo durchgefallen ist beziehungsweise das MVP gravierende Mängel aufweist, die eine Überprüfung am Markt unmöglich machen, kommt das Team zu einer "blameless post mortem"-Sitzung zusammen. Es gilt zu lernen, was das Team übersehen hat, aus welchen Signalen eine andere Entscheidung ablesbar gewesen wäre.

 

Beide Wege sind in einer Organisation, die nicht vollständig agil arbeiten, der entsprechenden Hierarchie bekannt zu geben. Dabei wird nur das Verfahren begründet, nicht aber der Raum für Schuldzuweisungen geöffnet.

 

Verfährt das Team so, ist es einfacher, für den Einzelnen oder die Einzelne sich zum "Status: Fertig" zu bekennen. Es droht kein Ärger mehr, sondern es lockt die Möglichkeit der frühen Überprüfung von Arbeitshypothesen.