Spätestens wenn wir im Rahmen einer Schulung bei Kunden das Agile Manifest vorstellen und den Punkt „Funktionierende Software mehr als umfassende Dokumentation“ vorstellen geht das Geraune durch die Schulungsteilnehmer. Sätze wie „Cool, wenn ich Scrum mache, muss ich ja nicht mehr dokumentieren“, bis hin zu „Ich habe doch gleich gesagt, dass dieses agil nicht funktionieren kann, wenn die nicht mal dokumentieren“ schallen einem da als Trainier entgegen.
Genau wegen diesen gefährlichen Aussagen, die ich als gefährliches Halbwissen bezeichne, nehme ich mir jetzt die Zeit ausführlich auf das Agile Manifest einzugehen. Denn ich möchte klarstellen, dass der Satzteil auf der rechten Seite wichtig ist, der Satzteil auf der linken Seite nur als wichtiger angesehen wird.
Definition of Done hilft weiter
Tatsache ist, dass auch im agilen Umfeld ausführlich dokumentiert wird.
Gerade beim Einsatz von Scrum kann man die notwendige Dokumentation sehr gut zum Beispiel über die Definition of Done (DoD) festlegen:
- Was brauchen wir an Dokumentation?
- Wo legen wir das ab?
Festgehalten in der DoD ist die Dokumentation nicht genau das Arbeitspaket, das am Ende noch zu tun ist oder offen bleibt, da man keine Zeit mehr hat oder sie schlicht weg im Eifer der Entwicklung vergessen hat. Sondern sie ist von Anfang an über die Definition of Done fest verankert und fließt dementsprechend auch schon vorab in die Schätzung der Arbeit mit ein. Dabei wird die DoD, genau wie das Produkt selbst, inkrementell weiterentwickelt und erarbeitet.
Hintergründe zu der Aussage im Agilen Manifest
Wieso wurde nun aber im Agilen Manifest so ein Satz festgehalten, der oft zu falschen Aussagen führt und den Gegnern von Agilität so gut in die Hände spielt, wenn man das Manifest nicht besser kennt?
Betrachten wir sequentielles Vorgehen, zeichnet sich dieses zum einen dadurch aus, dass man erst eine Phase abgeschlossen haben muss, um in die nächste Phase zu starten. Dies führt meistens dazu, dass erst mal viel Zeit und Aufwand in die Erstellung eines allumfassenden Lastenheftes gesteckt wird. Das Lastenheft soll „perfekt“ sein und alle Anforderungen abdecken die man später haben möchte – auch wenn man noch gar nicht so genau weiß, was man eigentlich haben möchte. Als Antwort auf dieses „Werk“ – viele Lastenhefte sind kiloschwer und oft kann man bezweifeln, dass diese „Wälzer“ noch von jemandem wirklich komplett gelesen werden – wird dann genauso aufwändig und intensiv ein Pflichtenheft als Antwort geschrieben. Wenn dann dieses neue „Meisterwerk“ fertiggestellt ist, geht es vielleicht (irgendwann) in die Realisierung. Am Ende der Realisierungsphase steht dann hoffentlich das Produkt das man vorher ausführlich im Lastenheft angefordert hat. Jedoch stellt dann der Kunde oft fest, dass er das gar nicht so wollte und es sich anders vorgestellt hat. Bis dahin wird aber eine Menge an Papier oder digitaler Daten erstellt, wovon vieles nie wieder angesehen wird und am Ende sind doch noch Nacharbeiten am Produkt notwendig.
Im Lean bezeichnen wir das als „Waste“. Gleichzeitig wird beim sequentiellen Vorgehen schnell aus den Augen verloren, dass der Kunde am Ende vor allem eine funktionierende Software möchte, jedoch zuerst mit einer Unmenge an Dokumentation erschlagen wird.
Wer sich noch zurück erinnern kann an die großen Zeiten der Referenzmodelle, wie z. B. CMMI (Capability Maturity Model Integration), kennt vielleicht auch noch das Problem, das auch da oft die Praktiken und Ziele falsch verstanden worden sind und viele Bereiche und Unternehmen vor allem durch ein Übermaß an Dokumentation versucht haben irgendwelchen Assessoren zu beweisen, wie weit fortgeschritten sie schon sind. Normalerweise führte das nicht zum gewünschten Erfolg, sondern die Assessoren erkannten schnell, dass hier nur eine Dokumentationsflut herrscht, aber niemand damit arbeitet. Jedoch hinterließ diese Dokumentationswelle auch einen schlechten Beigeschmack und führte oft dazu, dass Themen wie CMMI oder auch SPICE in einem Unternehmen stark verbrannt wurden, da die Mitarbeiter die Modelle mit unnötiger Dokumentation gleichgesetzt haben. Und genau in dem Wort „unnötig“ steckt die Kernessenz drinnen.
Fazit
Dokumentation ist notwendig und wird auch im agilen Umfeld als notwendig erachtet. Im agilen Umfeld wird die Dokumentation genauso wie das Produkt inkrementell erstellt und iterativ weitergeschrieben. Immer mit dem Fokus auf so viel Dokumentation wie nötig. Bei der Anwendung von Scrum wird unter anderem über die Definition of Done festgehalten, was dokumentiert sein muss, damit die User Story als „Done“ angesehen werden kann.
Und immer daran denken: Die rechte Seite des agilen Manifests ist auch wichtig! 🙂
