Change ist eine tolle Sache, aber kann echt entnervend sein. Ihr Wunsch nach Stabilität ist verständlich, aber hat bei Agile eine niedrigere Priorität. Warum ist Agil eigentlich so doof da?
Wann sind wir endlich da?
Kürzlich, in der Projektsitzung: die Dame vom der Fachabteilung fragt, wann die Anwendung denn endlich fertig ist? Denn sie möchten alle Fachkollegen aus 30 Ländern für eine Woche in die Firmenzentrale holen, um sie dort auf dem neuen System zu schulen. Dazu gehört auch eine umfangreiche Doku inklusive Screenshots, die quasi als Prozessdoku und Arbeitsanweisung dient. Dazu sollte das System aber bitte weitestgehend stabil sein. Weil, das artet ja sonst in Arbeit aus, die so gar nicht vorgesehen ist.
Ich geh dann schon mal vor
Die Vorstellung, dass das System irgendwann komplett fertig ist, erschreckt mich etwas. Das würde ja bedeuten, dass wir entgegen dem Pareto Prinzip (20% der Arbeit liefern bereits 80% des Ergebnisses) alles umgesetzt haben und nicht nur das wichtigste mit dem besten Kosten/Nutzen Verhältnis Genau, gut mitgedacht: ich meine die 80% von gerade eben. Diese Denke, dass das System vollumfänglich der Spezifikation entspricht und man zu 100 % das bekommt, was man bestellt hat, finde ich aus agilen Gesichtspunkten grenzwertig. Hier geht normalerweise ein Aufschrei durch die aufgeputschte Menge: aber wir haben doch dafür bezahlt, um genau das zu bekommen! Und zwar etwas ganz Bestimmtes!
Generation Flatrate
Da geht es Ihnen. wie es mir mit dem Begriff Flatrate inzwischen geht. Ich lese Flatrate und irgendwo steht dann „nach 3 GB passen wir Ihre Geschwindigkeit auf die eines Akustikkopplers anno 1980 an. Happy Surfing.“. Das ist jetzt eine Flatrate: weil sie kostet nur einen fixen Betrag, ganz egal was ich tue. Und wenn ich zu viel tue, dann kriege ich gar nichts mehr für mein Geld. So ähnlich funktioniert es auch in Fixpreisprojekten. Natürlich nicht in den 2% der super-gutlaufenden-wo-die-Abschätzung-stimmt-und-alles-sehr-effektiv-läuft-Referenzprojekten. Bei den anderen 98 % wird eben so lange gearbeitet, bis das Fixpreis Budget am Ende ist – bei erfahrenen Projektleitern nur bis kurz vorher – und dann wird – mit Verlaub – gepfuscht. Je nachdem wie gut der Teil ist der bis dahin abgeliefert worden ist, ist der Kunde zufrieden oder unzufrieden. Meistens muss man sich deshalb in den CR Bereich retten.
Die Igelleistung der Softwareindustrie
Grundsätzlich sind CRs eine gute Sache und insgesamt geeignet eine Lösung vor dem sicheren Tod durch Feature Creep und Gold Plating zu bewahren. Allerdings kann man CRs auch als Waffe einsetzen, gerade wenn die Prozesse für die Definition Request nicht sauber aufgesetzt sind. Spät im Projekt sind alle Änderungen CRs und mit üppigen, äh „rückwirkenden“ Kompensationsaufschlägen versehen. Sie dienen der Refinanzierung des Projektes. Glücklich sei der Kunde, der am Anfang einen gewissen Prozentsatz der Budgetsumme des Projektes zur freien CR-Verfügung eingeplant hat. Damit kann man im allgemeinen die Salamitaktik gegen Ende ganz gut kontern.
Vom Häuslebauer lernen
Allerdings weiß jeder, der ein gebrauchtes Haus gekauft hat, dass man besser ein paar 10.000 € für notwendige Reparaturen und Renovierungen beiseite legt. Erstaunlicherweise wird sich in den nächsten 2-3 Jahren herausstellen, dass dieses Geld nicht mal ansatzweise reicht um auch nur die Waschküche wieder auf Vordermann zu bringen. Das Gleiche kann man auch von Softwareprojekten sagen: der Betrag, den Sie einplanen für Unvorhergesehenes wird 1/4 bis 1/3 der tatsächlichen Kosten abdecken.
Darum prüfe wer sich ewig bindet…
Aus dieser Überlegung heraus ist es ziemlich sinnlos auf ein vollständiges System zu warten oder es sich zu erhoffen. Hier setzt eben der inkrementelle Prozess ein, der darauf abzielt den kontinuierlichen Verbesserungsprozess umzusetzen und anstelle eines Komplettsystems ein System zu liefern, dass ein optimales Kosten-Leistungsverhältnis bietet.
Bei agilen Projekten kann der Kunde zu jedem Zeitpunkt das Projekt abbrechen. Normalerweise wird er das tun, sobald er das Gefühl hat das auch weitere Investitionen für ihn keinen weiteren Nutzen mehr bringen. Vertriebler hassen das, und auch Ressourcenauslastungsplaner. Dieser Schwellenwert kann sehr früh oder sehr spät im Projekt erreicht sein.
Ausschlaggebend dafür ist das Mindset des Auftraggebers. Wenn wie im vorliegenden Fall noch alte Denkmuster vorherrschen, frei nach dem Motto „ich habe dafür bezahlt – ich will auch alles aufessen“ dann wird es schwierig.
Spatz in der Hand, Taube scheisst auf’s Dach
An der Stelle ist es wichtig vorher und auch laufend im Projekt allen Projektbeteiligten das agile Mindset näher zu bringen. Sobald Personen mit einem klassischen Vorstellungraum von Projekten versuchen mit ihrer Wahrnehmung das Projekt zu gestalten wird es schwierig. Oft kommen typische Vorwürfe wie: „das ist ja alles nur halb fertig“. Oder: „wo soll das denn alles hinführen“.
Legen Sie jetzt in der Kommunikation den Schwerpunkt auf die bereits gelieferten und die nächsten konkreten Features und argumentieren Sie, dass nicht das System, wie es in irgendwann einmal sein wird wichtig ist sondern das System wie es im Moment ist und was man damit machen kann. Weil: Tomorrow never happens.
Ganz oder gar nicht
Viele Anwender glauben, dass der aktuelle Wunschzustand das Minimal Set ist, dass Sie benötigen um erfolgreich mit einem System zu arbeiten. Was heißt arbeiten? Das bedeutet für uns, dass die Arbeit mit dem System für den Kunden einen Nutzen schafft. Der ganz-oder-gar-nicht Ansatz bedeutet im Grunde genommen, das die Anforderung des Kunden atomar sind und nicht geteilt werden können.
Es gibt sicher Bereiche wie eine Atomkrafwerktsteuerung bei denen ein halbgesteuertes Atomkraftwerk nicht nutzbringend ist. Außer man ist Jod Produzent. Hey, Geschäftsmodelle! Auf solche speziellen Projekte gehen wir später noch einmal gesondert ein.
Im Normalfall sind ganz-oder-gar-nicht Kandidaten selten in der Lage ihre Arbeitsprozesse und Abläufe in Teilschritte zu zerlegen. Anstelle von einer nutzenorientierten Vorgehensweise (aka Wertschöpfungskettenanalyse …), die den Wert maximiert die ein System für eine Firma heute hat, herrscht häufig ein funktionales Denken vor. Funktional bedeutet hier: das System wird als eine Menge an Einzelfunktionen gesehen. Alle werden benötigt werden, um daraus dann eine komplette Anwendung zu machen.
Ich weiss, was ich will. Schnellere Kutschen.
Dazu kommt das ein neues System gerne „alles“ können soll was ein altes konnte. Dazu gibt es zwei Grundgedanken: das alte System war wahrscheinlich auch schon murks aka hat Kompromisse gemacht, aber ist jetzt eben vertraut und deshalb gut.
Und: niemand kann sich vorstellen, wie man mit einem System arbeitet, bis … man damit tatsächlich arbeitet. Das ist in etwa so wie über Kinder zu reden, und dann welche zu bekommen. Komisch, in den Elternratgebern passt das immer …
Kleine Annekdote: was wollen die Anwender vor der Erfindung des Autos? Genau: schnellere Kutschen bei weniger Pferdeäpfeln auf der Strasse …
Start small vs. Status Quo
Die Abteilungsleiterin aus unserem Beispiel oben kann sich also nicht vorstellen, dass sie auch nur mit einem Teil des Systems arbeiten kann. Lieber harren & hoffen, als mit etwas kleinem zu beginnen. Meistens hat die eigene Komfortzone damit auch noch etwas zu tun. Insbesondere wenn Altsysteme abgelöst werden, die eine gewisse Behaglichkeit und Vertrautheit für den Anwender symbolisieren, das bekannte Übel.
Kommunikation bügelt Vertrauensdefizite aus
Außerdem bedeutet es einen Vertrauensvorschuss mit etwas „unfertigem“ zu arbeiten, und der Rest kommt dann schon irgendwann. Da hat die IT in den letzten Jahrzehnten ja auch eine guten Job gemacht, meistens. Wichtig: kleine Erfolge und Fortschritte aufzeigen, und den direkten Kontakt nie abreißen lassen.
Ja, alle 2 Wochen kann schon nervig sein „wie müssen ja auch noch richtig arbeiten“, aber: Sie tun ja etwas FÜR die Fachabteilung. Das ist Einstellungssache, und gerade alte Hasen sind das von „der IT“ so nicht gewohnt. Was da schon alles im Powerpoint versprochen wurde, früher …
Wer schreibt, der bleibt
Insbesondere der Ansatz, ein System dokumentieren zu wollen, führt oft bei iterativen Lieferungen zu einem starken Verdruss bei der Fachabteilung. Hier spielen insbesondere gute Stories eine entscheidende Rolle, damit eine entsprechend modular aufgebaute Dokumentation nicht jedes Mal von oben bis unten durchgekaut werden muss bei der Änderungssuche.
Insofern ist das Thema Dokumentation sehr ähnlich dem Thema Qualitätssicherung. Auch da sind manuelle Regressionstests vom Aufwand her nicht vertretbar in agilen Projekten. Für die Doku muss also eine neue, agilere Lösung her.
Weil einfach einfach einfach ist
Wenn jeder Teil einer Lösung einfach zu verstehen und einfach zu bedienen ist, dann kann die notwendige Dokumentation auf ein Minimum eingedämmt werden. Leider legen viele Entwickler und POs keinen Wert auf eine einfache Bedienung trotz aller UX Trends. UX ist ja keine „echte Softwarearbeit“, weil „nicht funktional“.
Sieht man sich in der Entwicklergemeinde um, wird man feststellen das UX meistens leider bei irgendeinem Design Fuzi angesiedelt ist. Echte Entwickler klatschen Felder auf Masken und das muss reichen. Das ändert sich erst, wenn man tatsächlich Customer Centric arbeitet, das ist aber Kultur.
Hier werden sie geholfen
Die Frage bleibt nun, wie wir unserer Abteilungsleiterin weiterhelfen können. Ihr Ziel ist es, dass ihre Mitarbeiter mit dem System sicher umgehen können und sie das auch sicherstellen kann. Anstelle einer großen zentralen Schulung mit einer ellenlangen Dokumentation die höchstwahrscheinlich eher als Nachschlagewerk oder Monitorstütze dient, haben wir regelmäßige kurze Schulungen mit einer viertel bis halbe Stunde nach wirklich jedem Release veranstaltet.
3-5 Tage später gab es jedesmal eine Q&A Runde, in der die Anwender Fragen stellen konnten zur Bedienung und zu den Abläufen.
Als zusätzlichen Service haben wir für die weitere Laufzeit bzw. Einsatzzeit des Systems mit dem Kunden eine niedrige Schulungspauschale vereinbart: Neue Mitarbeiter konnten so schnell von uns geschult werden ohne dass eine Dokumentation aufwendig gepflegt und aktuell gehalten werden musste.
Nebenbei stellt sich raus: mit dem neuen System gibt es auch neue Abläufe, manche sogar besser als die alten.
Moderne Zeiten
Sie sehen an diesem Beispiel, das die Auswirkungen einer agilen Transformation sehr weitreichend sein können. Natürlich kann man versuchen die Auswirkungen von Agilität zu beschränken. Man muss nicht jedes Potenzial heben, das man findet. Andererseits sind alte Zöpfe nicht unbedingt dadurch besser, dass sie alt sind. Schon früher waren Dinge – wie in unserem Beispiel die zentrale Schulung an einem Ort – eher unerwünscht und wurden oft als Gemengelage auch wegen den teambildenden oder sozialen Aspekten umgesetzt.
Tl;dr
Agil bedeutet ab dem ersten Release produktiv mit dem System zu arbeiten. Agil bedeutet, das alles im Projekt iterativ erfolgt. Agil bedeutet dann aufzuhören, wenn es gut ist, egal ob noch Budget da ist. Agile Doku und Schulung laufen anders. Fertig ist bei 80% Nutzen.
