Dokumentation hat keinen Wert

Ein Projekt hat immer ein Ziel: es soll ein Produkt erstellt oder Ergebnis erzielt werden, welches die Welt ein klein wenig besser macht – oder zumindest dem Auftraggeber ein Return on Invest verheißt. Das Ziel ist (zumindest meistens) nicht Papier zu erzeugen.

In der Softwareentwicklung, in der ich mich überwiegend bewege, ist die Erstellung einer Anwendung das Ziel. Kein Kunde oder Benutzer sieht jemals die Code-Dokumentation. Selbst das Handbuch oder die Online-Hilfe werden so gut wie nie genutzt. Und falls doch mal jemand zum Handbuch greift, ist das selbstverständlich ein klares Zeichen von schlechter Usability und eines miserablen Nutzererlebnisses. Hier scheinen sich auch alle einig.

Da wundert es nicht, dass die Dokumentation keinen Wert zu haben scheint. Aber ist das so? Wieso wird dann so oft doch dokumentiert? Wieso beschwert sich dann überhaupt jemand über „mangelnde Dokumentation“? Wer braucht Dokumentation überhaupt?

Dokumentation ist lästige Pflicht

Produkte (und dazu gehört auch Software) müssen mit einem Handbuch ausgeliefert werden. Andernfalls ist es ein Mangel. Je nach Branche und Produkt kann es hier noch zahlreiche weitere Auflagen geben.

Um diesen Pflichten nachzukommen, muss wohl oder übel dokumentiert werden. Die Zeit und Kosten dafür müssen im Projekt daher berücksichtigt werden.

Kein Wunder, wenn da Unmut im agilen Team entsteht. Hier wird leider oft versäumt zwischen „Pflicht“ und „Pflicht“ zu unterscheiden. Gerade in größeren Konzernen ist es üblich jede Menge „Pflichten“ zu haben, die vom Unternehmen selbst auferlegt werden. Stehen sie der eigentlichen Arbeit im Weg, so werden sie zurecht angeprangert und in Frage gestellt.

Meist wird jedoch nur schlichtweg versäumt zu kommunizieren, weshalb es diese oder jene Pflicht gibt. Rechtliche Pflichten werden schnell akzeptiert. Firmeninterne Regelungen hingegen bedürfen öfters mehr Erläuterungen, die man sich angesichts der aufkeimenden Diskussionen gerne erspart. Kein Wunder, wenn dann die Pflicht zur Dokumentation als lästig wahrgenommen wird. Wer hier noch mit optionaler Dokumentation (z.B. Code-Dokumentation, Architekturdokumentation, Konzepten, Anforderungslisten oder gar Personas und Nutzungskontexten) daherkommt wird argwöhnisch betrachtet.

Dokumentieren ist nicht agil

Agil ist es am Produkt zu arbeiten – und nicht an der Dokumentation. Da sind sich alle einig. Nicht umsonst hat man sich auf die Werte der agilen Softwareentwicklung per Manifests geeinigt: „[Wir schätzen] Funktionierende Software mehr als umfassende Dokumentation.“

Mit anderen Worten: Dokumentation kostet Zeit, die auf Kosten der eigentlichen Softwareentwicklung geht.

Was als Reaktion auf das frühere Wasserfallmodell entstand, in dem sehr viel Dokumentation im Vorfeld entstand, hat unlängst ins Gegenteil umgeschlagen. Das Feindbild „Dokumentation“ ist selbst in Führungsetagen vorgedrungen, in der man sich Jahrzehnte zuvor nur allzu gerne an Schriftstücke geklammert hat.

Zusätzlich rückt seit Jahren der Kunde bzw. der Nutzer immer weiter in den Mittelpunkt aller betrieblichen Aktivitäten. Themen wie Usability, User Experience (UX), User Centered Design (UCD) oder Design Thinking sind in den agilen Teams angekommen. Auch hier konzentriert man sich mehr auf was die Nutzer sagen und tun, als auf irgendwelche alten eigenen Vorhaben, Pläne oder Konzepte.

Da stellt sich schnell die Frage: wozu noch Konzepte oder Pläne erstellen, wenn man das alles flexibel halten will?

Fehlendes Dokumentieren kann teuer sein

Meetings

Schnell sind sie angesetzt. Denn etwas zu mal eben zu erklären geht meist fünf bis zehn Mal schneller, als es aufzuschreiben. Da erscheint es wenig sinnvoll zu dokumentieren. Es wird kurzerhand ein Meeting angesetzt und alles wird mündlich vermittelt. Dies scheint eine gute Lösung zu sein und wird auch oft so praktiziert.

Dabei wird nicht selten außer Acht gelassen, dass die Adressaten diese Information oft zu unterschiedlichen Zeitpunkten benötigen. Jene, die gerade diesen Bedarf für sich selbst noch nicht absehen können, hören weniger aufmerksam zu und vergessen das gesagte schnell wieder, da es wenig Relevanz für sie hat.

Wird das Thema dann später relevant, muss das gesagte meist nochmal wiederholt werden. Diese zeitliche Entkopplung sorgt für mehrfache Wiederholungen und kann den Aufwand einer einmaligen Dokumentation deutlich übersteigen.

Einarbeitung in Code

Auch schlecht dokumentierte Schnittstellen im Code kosten die Entwickler viel Einarbeitungszeit. Anstatt einen Code einfach und schnell verwenden zu können, müssen sich die Entwickler in die Funktionsweise im Detail einlesen, um zu verstehen, wie dieser Code zu verwenden ist. Auch hier würde eine einmalige Dokumentation wiederholte Zeit und damit Kosten sparen.

Nachschlagewerke

Niemand kann sich alles merken. Gerade bei Projekten mit mehr als 2000 Stunden Aufwand häufen sich Use Cases, Anforderungen, Bugs, Arbeitslisten, Pläne, etc. an, die sich niemand merken kann oder will. Wird hier zu sehr an Dokumentation gespart, verdammt man sich schnell zu einem Drehen im Kreis.

Fluktuation im Team

Bei langlaufenden Projekten kommen immer wieder neue Personen ins Team und müssen eingearbeitet werden. Auch hier ist ein vorhandener Grundstock an Dokumenten als Quelle hilfreich. Insbesondere dann, wenn Mitarbeiter mit wichtigem Wissen das Projekt verlassen, ist es unerlässlich dies an die Nachfolger zu übergeben. Kommt der Nachfolger erst Monate später, ist Dokumentation oft das einzige, was dieses Wissen transportiert.

Nicht zu dokumentieren ist auch keine Lösung. Das Minimum-Prinzip ist hier keine gute Option und eine schlechte Heuristik und kostet im Endeffekt viel Zeit und Geld.

Wann man dokumentieren sollte

Um zu bestimmen, wann eine Dokumentation zweckdienlich ist und wann nicht, muss man sich auf den eigentlichen Zweck von Dokumenten zurückbesinnen.

Das geschriebene Wort hatte schon seit jeher einen zentralen Zweck: die Zeit zu überdauern. Denn unser Gedächtnis ist flüchtig und ungenau. Dieser Zweck hat sich bis heute nicht geändert. Und es ist der wichtigste Grund, wieso man überhaupt dokumentieren sollte, auch wenn man nicht dazu verpflichtet ist. Geht Wissen verloren, ist es meist schwer wieder zu erlangen. Ist der Aufwand der Wiedererlangung größer als der Aufwand der Dokumentation, sollte man dokumentieren.

Regel 1: Man sollte das dokumentieren, was nicht vergessen werden darf.

Die Zeit zu überstehen ist jedoch nicht der einzige Zweck des geschriebenen Wortes. Die Weitergabe und Vermehrung des Wissens war auch schon lange ein wichtiges Ziel. (Dieser Artikel zum Beispiel dient primär der Weitergabe und Vermehrung von Wissen.) Zeichnet ein Text uns einen Gedankenpfad auf oder vermittelt eine Idee, so können wir dem folgen, ohne uns diese Einsicht mühsam selbst erarbeiten zu müssen. Das Schreiben und Lesen dient nicht nur der Bewahrung über die Zeit, sondern auch dem Wissenstransfer von Mensch zu Mensch. Dokumentation hilft, sich nicht zu wiederholen.

Regel 2: Man sollte das dokumentieren, was zum dritten Mal gesagt wurde.

Genauso flüchtig wie die Worte sind, so flüchtig ist auch der Kontext, für den sie relevant waren. Eine mündlich gegebene Hilfestellung hat vielleicht ihren Zweck bereits erfüllt und braucht nicht aufgeschrieben zu werden. Dies wäre Zeitverschwendung. Wird diese Hilfestellung jedoch bereits zum dritten Mal gebraucht, so lohnt es dies aufzuschreiben. (Die Zahl 3 ist hier lediglich ein guter Erfahrungswert. Wichtig ist nur, dass es ein klares Limit gibt.)

Diese Regeln sind Faustregeln, die helfen in agilen Teams schnell und leicht zu entscheiden, was man dokumentieren sollte und was nicht.

Auffindbarkeit der Dokumentation

Oft wird sogar dokumentiert (bzw. noch schlimmer: mehrfach dasselbe dokumentiert) und es entfaltet trotzdem nicht den gewünschten zeitsparenden Effekt. Dies liegt dann meist an der Unauffindbarkeit dieser Dokumente.

Dokumentation ist meist vielfältig: Während der Code seine Dokumentation im Quellcode trägt, sind Architekturentscheidungen oft separat dokumentiert. Ticketsysteme können mehr oder minder integriert sein. Deren Verwendung ist, sofern überhaupt dokumentiert, ebenfalls außerhalb des Ticketsystems zu suchen. Die Hausordnung hängt an der Wand und der Arbeitsvertrag in der Personalakte. Dokumente sind nie an einem Ort und ab einer gewissen Größe bzw. Komplexität stark verteilt. In so einem Umfeld sind Informationen oft kaum zu finden.

Zudem benötigt jede Rolle im Team unterschiedliche Dokumente. Nicht jedes Dokument ist für jede Rolle geeignet.

Regel 3: Dokumentation sollte Rollen-bezogen auffindbar gemacht werden.

Dokumentation ohne Auffindbarkeit ist in der Tat eine Produktion von „Waste“. Daher empfiehlt es sich, pro Rolle einen zentralen Einstiegpunkt zu hinterlegen, von dem aus alle anderen Dokumente zu finden sind. Idealerweise ist dieser Ort systematisch und hierarchisch organisiert. Nicht umsonst haben Bibliotheken einen Index. Niemand will alle Bücher lesen, wenn er eine konkrete Antwort auf eine konkrete Frage hat.

Angesichts der heterogenen Dokumentationslandschaft ist es i.d.R. kaum einem Team möglich diese Landschaft vollständig zentral durchsuchbar zu gestalten. Prozessänderungen erzeugen zudem Brüche in der Systematik dieser Landschaft. Dies erschwert die Suche. Es genügt meist jedoch ein zentraler Einstiegsort und kurze Erläuterungen was wo zu finden ist. Die einzelnen Systeme (DMS, Code Repository, Wiki oder Ticketsystem) bieten dann meist eine Suchfunktion. Aber auch hier ist eine Einstiegshilfe sinnvoll. Denn nicht jeder weiß gleich, wonach er suchen muss.

Dokumentation, die mit Respekt der eigenen Zeit und der Zeit des Lesenden gegenüber erzeugt wird, sollte immer mehr Zeit sparen, als es erzeugt.

Eine solche Behauptung von mir wird verständlicherweise reflexartig abgelehnt. Die eigene Idee ist natürlich völlig neuartig und niemand auf der Welt hat sie zuvor gedacht, sonst hätte man ja schon längst davon gehört, oder nicht?

Andere hatten die Idee schon vor dir

Dass dem nicht so ist, zeigt die Geschichte oft genug: John Boyd Dunlop z.B. erfand den luftgefüllten Gummireifen, für den er heute weltbekannt ist. Er hatte nicht von Robert William Thomson gehört, der diese Idee bereits 44 Jahre vor ihm hatte. Als er sich die Idee schützen lassen wollte, musste er erfahren, dass sie bereits patentiert war. Auch das Telefon wurde mehre Male unabhängig voneinander erfunden. Nur weil man noch nichts von einer solchen Idee gehört hat, bedeutet es im Umkehrschluss nicht, die Idee sei neu.

Die rosarote Brille für eigene Idee

Leider ist die eigene Einschätzung meist trügerisch. Ich arbeite viel mit kreativen Menschen in Gruppen zusammen, in denen Ideen entwickelt werden müssen. In solchen Gruppen entstehen mehrere Ideen und irgendwann muss man sich entscheiden. Hier kann man sehr gut beobachten, dass die eigene Idee immer klar den Vorzug bekommt. Ich nenne es „in die eigene Idee verliebt sein“. Es ist wie mit Eltern und ihren Kindern. Die eigenen Kinder werden einfach nicht objektiv bewertet. Was bei den eigenen Kindern evolutionsbedingt ein wichtiger Schutz der Nachkommenschaft ist, ist bei den eigenen Ideen zum Teil hinderlich.

Bei Geschäftsideen ist es besonders wichtig, möglichst frühzeitig eine realistische Einschätzung der eigenen Idee zu haben. Wer zu lange an einer vermeintlich tollen Idee arbeitet oder sogar Kapital in eine Idee investiert, die sich dann später als zu optimistisch bewertet herausstellt, der wird bald keine Zeit und kein Geld mehr haben, um in die guten Geschäftsideen zu investieren.

Ist man sich erst einmal bewusst, dass man bei eigenen Ideen einem Verzerrungseffekt unterliegt und daher der eigenen Einschätzung nicht trauen darf, ist man auf einem guten Weg Ideen besser zu bewerten.

Ich kann mit niemand über meine Idee reden

Da man selbst keinen klaren Blick auf die eigene Idee hat, muss man andere bitten die Idee zu bewerten. – Und genau da scheiden sich die Geister. Während es im amerikanischen Raum eher heißt „Du musst dich mit vielen Leuten austauschen“, heißt es hierzulande eher: „Ich kann meine Idee doch nicht anderen verraten!“

Die Angst davor, dass die eigene Idee gestohlen wird, ist meist größer, als die Angst davor, dass die Idee nicht reif genug ist. Vor allem durch den Mythos des „Pivot“ der Start-up Szene scheinen allerorts jegliche Bedenken über möglicherweise unausgegorene Ideen wie weggeblasen. Das teure Ausprobieren ersetzt Marktanalysen und eine Konzeption.

Wenn Sie Ihre Idee also für neu halten, dann könnte es auch einfach daran liegen, dass Sie nicht von so einer Idee hören würden, auch wenn andere die Idee vorher hatten.

Ideen haben keinen Wert!

Eine tolle neue Idee ist also vielleicht gar nicht neu - und wohlmöglich nicht einmal so toll, wie man sie selbst findet? Aber sie ist doch etwas wert? Immerhin gibt es auch immaterielle Werte, oder? Leider nein.

Das Bewertungsparadoxon

Ideen lassen sich schlecht handeln oder bewerten. Ein Beispiel: Mal angenommen Sie haben eine tolle Geschäftsidee. Sie sind von ihrer eigenen Idee begeistert und sie denken, diese Idee ist viel Geld wert. Nun wollen Sie diese Idee verkaufen. Ihr potentieller Käufer möchte die Idee vorher sehen bzw. hören, um zu beurteilen, ob sie ihren Preis wert ist. Aber sobald sie Ihre Idee zeigen oder erzählen, hat ihr Käufer die Idee bereits bekommen. Nun kann er jeglichen Preis ablehnen. Eine Idee lässt sich nur schlecht verkaufen.

Schutzrechte

Man könnte meinen, der Verkauf von immateriellen Gütern ist generell etwas anders als der Verkauf von realen Waren. Vielleicht sind Ideen ja immaterielle Güter? Nun das ist nicht prinzipiell falsch. Ideen können zu Patenten werden und Patente genießen Schutzrechte. Auf die Art können Patente beurteilt und gehandelt werden, ohne dem Bewertungsparadoxon zu unterliegen. Der wesentliche Punkt ist: der Staat garantiert hier einen Schutz. Haben sie z.B. eine Idee für eine Maschine, die Nüsse knackt, so können Sie sich das als Patent schützen lassen. Wenn sie eine Idee für ein Spielprinzip für ein Brettspiel haben, so lässt sich dies nicht patentieren.

Eine Idee an sich hat keinen Wert. Erst durch den staatlich zugesicherten Schutz kann ein Wert daraus erwachsen. – Aber auch Patente können wertlos sein.

Strategischer Vorteil durch Wissen

Auch wenn man Ideen schlecht handeln kann und sie meist keinen Schutz genießen, so können Ideen doch Kosten sparen oder Mehreinnahmen ermöglichen. Damit müssten Ideen einen Unterschied machen und einen Wert besitzen, oder nicht? Auch das stimmt nicht.

Dazu ein Beispiel: Stellen Sie sich vor, ein junger Mann ist Nachbar einer Fabrikbesitzerin. Dieser junge Mann hat eines Tages eine einfache Idee zur Kostensenkung in der Produktion der Fabrik seiner Nachbarin und erzählte ihr seine Idee. Sie setzt die Idee um und bald darauf macht sie eine Million mehr Gewinn. Diese Idee scheint klar einen Wert zu haben - und zwar eine Million. Immerhin kann sie dieses Geld ja auch ausgeben. Und nun stellen Sie sich vor, dieser junge Mann hätte die Idee für sich behalten. Hätte er dann auch eine Million ausgeben können? Natürlich nicht. Die Million war nicht der Wert der Idee, sondern das ungenutzte Potential in der Produktion.

Durch Anwendung, Ideen einen Wert geben

Wie aus dem Beispiel zuvor erkennbar wird, entsteht der Wert, den man gemeinhin der Idee zuschreibt, durch ihre Umsetzung. Die Idee selbst hat keinen Wert. Ihre Umsetzung kann jedoch einen Wert erzeugen. Diese scheinbar spitzfindige Unterscheidung zwischen der Idee und ihrer Umsetzung ist sehr wichtig. Eine Idee kann man nicht auf das Konto einzahlen, sie bringt keine Zinsen und verdient kein Geld. Erst durch die Umsetzung einer profitablen Geschäftsidee entsteht ein Geschäft, dass Geld verdient.

Wenn in einer Branche zwei Menschen dieselbe Idee haben. Der eine setzt seine Idee um und der andere belässt es bei der Idee. Dann wird der letztere nicht 50% des Marktanteils haben, sondern 0%.

Eine Idee an sich ist nichts wert. Erst durch ihre Umsetzung bekommt sie einen Wert.

Der Wert großer oder disruptiver Ideen

In den Medien wird öfters von „großen“ oder „disruptiven“ Ideen gesprochen. Damit gemeint sind Ideen, die Menschen zu Millionären oder sogar Milliardären gemacht haben. Es sind die Vorbilder, zu denen wir aufschauen und deren Ideen wir bewundern. Doch das sollten wir nicht. Die Ideen waren nicht die große Leistung. Es war die Umsetzung.

Erst durch die Marktteilnahme, die daraus resultierende Marktverschiebung und den Siegeszug der neuen und besseren Lösung, ändern sich Märkte. Das macht die zugrundeliegende Idee zu einer „disruptiven“ Idee. Aber ohne ihre Umsetzung – kann keine Idee disruptiv sein, da sie allein durch Ihre Existenz nichts ändert. Disruption ist das Resultat der Umsetzung, nicht eine Eigenschaft der Idee.

Umgang mit Ideen

Wer eine Idee (insbesondere eine Geschäftsidee) hat, sollte sich mit anderen austauschen. Erst durch den Austausch können Probleme oder Schwächen der Idee aufgedeckt werden. Es ist wichtig früh ein realistisches und unverfärbtes Bild auf die eigene Idee zu erhalten.

Manchmal kann es sinnvoll sein eine Idee erstmal umzusetzen, bevor man sie publik macht. Doch man muss sich bewusst sein, dass man damit ebenfalls ein Risiko eingeht.

Man sollte sich nicht der Illusion hingeben, die Idee allein hätte einen Wert. Ohne eine Anwendung oder Umsetzung ist und bleibt eine Idee ohne Wert. Also ran ans Machen!

Wer ein Team hat, hat einen Prozess

Sobald Menschen in einem Team zusammenkommen entstehen unvermeidlich Übergabepunkte. (Andernfalls arbeitet jeder für sich – und das ist keine Teamarbeit.) An diesen Übergabepunkten werden Ergebnisse ausgetauscht und die weitere Arbeit basiert auf darauf.

Der Wunsch einen Prozess definieren zu wollen, ist oft gering. Denn viele haben Prozesse bereits als Hürde und Beschränkung der persönlichen Freiheit und Effizienz erlebt und haben daher eine bisweilen ausgewachsene Aversion gegen Prozesse. Da ist es schwer einen Prozess zu etablieren. So manche Führungskraft, die zunächst als Fachkraft gearbeitet hat und selbst solche Prozesse kennengelernt hat, neigt anfangs noch stärker dazu, Prozesse nicht zu definieren, um einen natürlichen (von sich aus gewachsenen) Prozess zuzulassen.
Das so ein Vorgehen in den meisten Fällen nicht aufgeht ist dabei absehbar.

Scrum als Default

Gerade in der Softwareentwicklung genießt Scrum eine hohe Anerkennung. Dieser Prozess ist agil, schnell und leicht erklärt. Es scheint eine sichere Wahl zu sein. Selbstgebraute Prozesse könnten auf Widerstand und Skepsis stoßen. Der Gefahr will sich so manche Führungskraft nicht aussetzen. - Gegen Scrum wird ja wohl niemand was sagen.

Leider wird Scrum vielerorts immer noch falsch eingesetzt. Gerade als Scrum in Mode kam, war es an der Tagesordnung, dass Teams in größeren Unternehmen mit starren hierarchischen Strukturen Scrum einsetzen wollten. Da hat so mancher Vorgesetzte kurzerhand alte Gewohnheiten einfach nur auf Scrum-Begriffe um-etikettiert und meinte jetzt mit einem Pseudo-Scrum agil zu sein.
Schlimmer noch: Die Rolle des Scrum-Masters und Product Owners nahm zu oft der bisherige Vorgesetzte ein und vermischte so Scrum-Rollen mit unterschiedlichen Zielen. Dies kommt auch heutzutage noch öfters vor. Es führ dazu, dass die Rolle des Scrum Masters untergeht und der Vorgesetzte als Product Owner zu einem Antreiber wird, der die Prinzipien des Scrum früh verrät. Abgabetermine und Aufgaben werden weiterhin diktiert und das Team wird so nicht vor unrealistischen Erwartungen des Managements geschützt.

Andere wiederum mache es sich einfacher: Sie bedienen sich beim Scrum und anderen agilen Prozessen wie an einer Süßigkeiten-Theke und stellen sich so ihren eigenen agilen Prozess zusammen. Dem ist prinzipiell nichts einzuwenden, wenn der Prozess am Ende stimmig ist. Auch hier gibt es so manchen „Frankenstein“-Prozess der eher wie ein Monster daherkommt, als dem Team ein guter Freund zu sein.

Mit Kaizen und Retrospektiven zum besseren Prozess?

Die erfahrene Führungskraft aus den Bereichen Scrum oder Lean-Development wird Kaizen („Veränderung zum Besseren“) bzw. die Scrum-Retrospektive kennen. Diese sind prinzipiell gesehen sehr gute Mittel, um bestehende Prozesse zu verbessern und so stetig kleinere auftretende Hindernisse aus dem Weg zu räumen und den Prozess anzupassen.

Leider werden diese Ansätze zur adaptiven Veränderung als Ersatz für eine Modellierung von Prozessen gesehen. Zu oft wird auf Reibungspunkte und Defizite fokussiert und die eigentlichen Ziele des Teams aus den Augen verloren.

Wie alle agilen Methoden optimieren diese nur in kleinen Schritten vom aktuellen Stand der Dinge heraus. Dies sind Optimierungsmethoden, die das lokale Optimum suchen – und nicht das globale Optimum. Größere Umbrüche und Veränderungen geschehen nicht, wenn es keine größeren Probleme gibt. Zudem haben sie oft strukturelle Schwächen. Wie auch Software, die agil entwickelt wird, einen Hang zur Architekturschwäche hat, so hat ein iterativ verbesserter Prozess den Hang zur Strukturschwäche.

Wer keinen Plan davon hat, was er erschafft, und nur vor sich verbessert erhält einen gewachsenen Prozess, mit dem man leben kann, – aber sicher keinen schönen Prozess, mit dem man leben möchte. Aber Vorsicht! Iterative Verbesserungen sind wichtig. Wer sie nicht macht, riskiert Ineffizienz, Frust und im schlimmsten Fall den inneren Boykott des Prozesses durch die Teammitglieder.

Wie in der Software, braucht auch der Prozess eine Architektur – ein Grundgerüst, der dem Prozess eine Form gibt, die dann iterativ angepasst und optimiert werden kann.

Das Fundament im Prozess

Das wichtigste bei einem Prozess ist wie bei allem das Ziel bzw. das Endprodukt, dass erstellt werden soll. Im der Softwareentwicklung ist es in der Regel die Software. – Doch das ist nicht das Ende, sondern gerade erst einmal der Anfang.

Die wichtigste Aufgabe im Prozess ist es alle Pflicht-Artefakte zu erfassen. Oft werden (neben der Software als wichtigstes Artefakt) Nebenprodukte wie z.B. Handbücher oder ähnliches übersehen, die zwingend gesetzlich oder organisatorisch vorgeschrieben sind. Diese stellen das Fundament des Prozesses dar. Denn sie sind das Produkt – und können nicht eingespart oder wegoptimiert werden.
Wenn sie eingespart werden können, sind sie keine Pflicht-Artefakte.

So wird ein Prozess daraus

Artefakte erstellen sich nicht von selbst, das ist klar. Das Team hat die Aufgabe sie herzustellen. Im Rahmen von Tätigkeiten werden sie als Ergebnisse (Deliverables) erzeugt. (Zum Beispiel wird die Software von Entwicklern programmiert und das Handbuch von Redakteuren verfasst.) Die Tätigkeiten sollten dabei so ausgelegt und eng umfasst sein, dass sie zielgerichtet auf das Ergebnis ausgerichtet sind.

Fast jede Tätigkeit hat Voraussetzungen oder benötigt selbst Ergebnisse anderer, um darauf aufzubauen. So benötigt ein Entwickler z.B. für die Erstellung von Software (Code) eine Spezifikation oder ein detailliertes Konzept. Der Redakteur wiederum kann auf Basis der Konzepte das Handbuch vorbereiten. Die Konzepte ihrerseits müssen ebenfalls erzeugt werden. Sie entstehen in Rahmen eines Konzeptions- und Designprozesses auf Basis von Anforderungen und Szenarien. Und auch diese werden durch Tätigkeiten/Teilprozesse erstellt.

Arbeitet man sich systematisch von den Pflicht-Artefakten über Tätigkeiten zu benötigten Quell-Artefakten durch, sind auch hier schnell vorgelagerte Tätigkeiten identifizierbar. Dies endet dort, wo entweder keine Artefakte benötigt werden oder diese bereits fertig vorliegen.

Hilfsmittel, Systeme und Nachschlagewerke

Die meisten Tätigkeiten im Rahmen agiler Prozesse sind auf Wiederholungen ausgelegt. So wird z.B. eine User Story nach der anderen umgesetzt, eine Anforderung nach der anderen ins Konzept konsolidiert und ein Szenario nach dem nächsten in Testpläne überführt.
Dabei sind die einzelnen Arbeitspakete nicht unabhängig voneinander. Während das erste Feature einer Software noch unberührtes Terrain betritt, findet das zweite Feature bereits das erste vor. Mit der Zeit wird die Software komplexer, die Handbücher umfangreicher, die Konzepte voller und die Testpläne länger. Alles wird komplexer und vernetzter.

Eine Abhilfe schaffen da Repositories, Ticketsysteme, Requirements Management Systeme, Kanban-Boards, Dokumentenmanagement Systeme, Wikis, etc. Sie stehen dem Team bei den jeweiligen Tätigkeiten zur Hilfe und unterstützen sie dabei, die aktuellen Quell-Artefakte und das bisher bestehende komplexe System in Ergebnisse/Deliverables zu wandeln die stimmig sind. Auf diese Art können komplexe Systeme entstehen, die in sich schlüssig und konsistent sind.

Einfluss der Teamzusammensetzung auf den Prozess

Teams unterscheiden sich in vielerlei Hinsicht. Nicht jedes Team erzeugt dieselben Pflicht-Artefakte. Doch der größere Unterscheid ist in der Regel die Zusammensetzung des Teams. Die Unterschiede sind vielseitig:
Wie viele Personen sind im Team vorhanden? In welche Rollen sehen sich die Teammitglieder? Wo liegen ihre Stärken und wo ihre Schwächen? Wer ergänzt wen und welche Fähigkeiten sind im Team eher rar? Wer ist stark spezialisiert und wer kann seine Rolle flexibler wechseln? Wer ist „Forscher“ und wer „Polizist“?

Kein Team ist wie das andere. Und das ist der Hauptgrund, wieso kein Teamprozess sein sollte wie jeder andere. Die Positionierung der Teammitglieder innerhalb des Teams und deren Fähigkeiten und Stärken definieren nicht nur wo die Übergabepunkte* sind, sondern auch **welchen Detailgrad die Artefakte haben müssen, um verwertbar zu sein.

Es heißt, die Leute ergänzen sich. Diesen Vorteil will man nutzen. Meist macht man sich die Bedeutung dieser Aussage nicht wirklich vollends bewusst: Es bedeutet, dass die kleinen (oder großen) Schwächen und Unzulänglichkeiten des einen durch die anderen kompensiert werden. Dieser Ausgleich kostet das Team Abstimmung- und Kommunikationsaufwand und wird sich sehr bald im Prozess in Form von klaren Absprachen abzeichnen. Denn es ist die Aufgabe des Prozesses die Koordination und Kommunikation durch Konvention zu reduzieren. So passt sich der Prozess dem Fingerabdruck des Teams an.

Je qualifizierter eine Person für ihre Rolle im Team ist, umso weniger muss durch das Team kompensiert werden und umso einfacher fallen Übergabe-Artefakte aus. Ein guter Prozess berücksichtigt sie Stärken und Schwächen der Einzelnen und hat sinnvoll gewählte Übergabepunkte, die sich an den Fähigkeiten ausrichten.

Kein Team ist statisch. Menschen lernen dazu, entwickeln Verständnis für einander und kommunizieren effizienter und unterliegen wie überall auch einer natürlichen Fluktuation. Auch der Prozess sollte daher von Zeit zu Zeit in Frage gestellt werden und ggf. erneut modelliert werden, auch wenn er kontinuierlich in kleinen Schritten verbessert wird.

Einbettung in Scrum

Scrum ist ein recht schlichter Prozess, der als Rahmen für unterschiedliche Aufgaben dienen kann. Dabei ist er nicht auf Softwareentwicklung beschränkt. Im Grunde kann er für alles genutzt werden, was aus kleinen Teilaufgaben besteht und wenig gut planbar erscheint. So wurde Scrum auch schon bereits in Schulen als Lern-Prozess eingesetzt.

Scrum lässt sich leicht mit einem individuellen Team-Prozess vereinbaren, indem der Scrum-Prozess diesen umschließt und einbettet. Die einzelnen Tätigkeiten lassen sich im Backlog erfassen und priorisieren. Sprints geben dem Team kurzfristige erreichbare Ziele und helfen Kennzahlen (z.B. die Velocity) zu erfassen. Während Scrum den Rahmen und den Takt vorgibt und dem kontinuierlichen Betrieb und der Planung dient, hat der Team-Prozess die Aufgabe die Tätigkeiten, die Koordination und Übergaben im Team zu regeln und zu vereinfachen.

Es besteht kein Widerspruch zwischen einem individuellen Team-Prozess und Scrum, da sie auf unterschiedliche Aspekte des Prozesses abzielen und verbessen.

Akzeptanz des Prozesses

Wie jeder Prozess, ist auch ein maßgeschneiderter Prozess letztendlich nur ein Prozess und unterliegt der allgemeinen Prozess-Aversion. Zudem stehen etwa 30% aller Mitarbeiter Änderungen in ihrem gewohnten Arbeitsablauf mehr als nur skeptisch gegenüber. Kurzum: Prozesse sind der Feind.

Umso wichtiger ist es das Team in die Prozessmodellierung einzubeziehen. Es wird Bedenken geben und diese sollten früh geklärt werden. Auch eine kontinuierliche Prozessverbesserung (z.B. per Retrospektive im Scrum) durch das Team selbst hilft die Akzeptanz des Prozesses zu erhöhen.

Aber egal wie gut gemeint ein Teilprozess oder eine Vorgabe gemeint war, nach einer Weile erinnert sich so mancher nicht mehr daran, wozu es gut war und wird den Sinn in Frage stellen und den Mehraufwand nicht hinnehmen wollen. Es empfiehlt sich daher bei jeder Vorgabe zum Prozess auch ihren ursprünglichen Sinn mit zu dokumentieren. Wer sich Vorgaben durchliest, liest deren Sinn gleich mit. Dies hilft langfristig, den Prozess als Mehrwert zu sehen und weniger als Bürde.

Viele möchten auch mal eine große Idee und Erfolg haben – und dabei scheinen sie immerzu nur banale Schnapsideen zu haben. Wer will nicht auch einmal genial sein? Doch das scheint nur wenigen vergönnt.

Diese Denkweise ist falsch und hält uns davon ab erfolgreich zu sein.

Fixierung auf große Ideen

Wer sich auf große oder geniale Ideen versteift und nach der nächsten weltverändernden Idee sucht, der legt Schubladen in seinem Kopf an, die Ideen in Klassen einteilen: in gute und wertvolle Ideen – und in nutzlose und schlechte Ideen.

Alle Ideen erscheinen dann klein, unbedeutend und nicht gut genug. Wir messen uns an den Ideen der Großen. Erfolg hat man eben nur mit großen Ideen – so die gängige Sichtweise.

Geniale Ideen führen nicht zwingend zum Erfolg

Leonardo da Vinci gilt in unserer Welt als Universalgenie. Er hat bereits im 15. Jahrhundert im Alter von ca. 30 Jahren Entwürfe von Geräten gezeichnet, die wir als frühe Formen von Panzern, U-Booten, Flugzeugen und Fallschirmen wiedererkennen. Geräte, die heute überall auf der Welt zu finden sind. – Ein Visionär mit großen und genialen Ideen.

Doch wo waren diese Geräte im 16. Jahrhundert? Wieso ist die Republik Florenz damals nicht zur Weltmacht aufgestiegen? Wieso flogen keine Fluggeräte herum? Wieso hatten diese Ideen erst Jahrhunderte später ihre ersten Erfolge? Eine spannende Frage. Doch egal wie: selbst Ideen eines Genies sind kein Erfolgsgarant. Nicht jede gute oder große Idee wird auch zum Erfolg.

Es gibt keine genialen Ideen

Da Vinci schöpfte seien Ideen aus seiner besonders guten Beobachtungsgabe, die er als Maler und Bildhauer sich erarbeitet hat. Seine Ideen basieren auf der Beobachtung der Natur. Im Grunde lieferte die Natur fast fertige Ideen: Ahornsamen schrauben sich durch die Luft (Hubschrauber), Vögel nutzen Schwingen zum fliegen (Fluggerät), Wasser verwirbelt sich (Hydrodynamik) und Luft verhält sich dazu analog (Aerodynamik). Da Vinci erkannte bereits diese Zusammenhänge sehr früh. Das ist es auch, was uns heute so an Ihm fasziniert. Doch seine Ideen für Geräte bauten auf den genialen Ideen und Lösungen der Natur auf. Er bediente sich ihrer und entwickelte sie weiter.

Albert Einstein, ein genialer Geist – wie wir alle wissen, hat die spezielle und allgemeine Relativitätstheorie formuliert. Seither wissen wir, dass das Licht eine Geschwindigkeit hat und dass diese unveränderlich ist. Auch die Zeit verläuft nicht an jedem Ort gleich. An manchen Orten läuft sie schneller als an anderen. Wir haben das Bild eines Genies vor Augen, dass mit weltverändernden Erkenntnisse aufwartet, die uns noch Jahrzehnte später in Staunen versetzen.

Während die Erkenntnis der Konstanz der Lichtgeschwindigkeit und der Ortszeit scheinbar Einstein zugeschrieben wird, war sie hingegen die Arbeit von Henri Poincaré. War also Einstein kein Genie? Natürlich waren Einsteins Erkenntnisse bahnbrechend! Er hat Poincaré Arbeit und die vieler anderer vor ihm in seine Überlegungen einbezogen und in das weiterentwickelt, was wir kennen.

Wie jede gute oder vermeintlich geniale Idee, bauten auch Einsteins und Da Vincis Ideen auf Ideen anderer auf. Nicht von ungefähr stammt die Redensart „Wir sind Zwerge auf den Schultern von Riesen“. Keine Idee entsteht aus dem Nichts heraus. Jede Idee ist eine Weiterentwicklung bestehender Idee oder eine Kombination aus ihnen, die wieder neue Ideen entstehen lässt.

Ideen werden klein geboren

Wenn wir erst einmal akzeptiert haben, dass jede Idee eine kleine Verbesserung bestehender Ideen ist und damit selten einen großen Sprung darstellt, dann stellt sich die Frage:

Wie kann eine Idee dann überhaupt groß werden?

Groß macht eine Idee - ihre Anwendung. Wenn eine Idee, eine Erkenntnis oder eine Erfindung erst einmal in unserer aller Alltag angekommen ist, dann gilt die Erfindung als groß. Charles Goodyear zum Beispiel wird als Erfinder des Hartgummis (des Vulkanisationsverfahrens und einiger erster Gummiprodukte) als großer Erfinder geehrt. Dies jedoch nicht wegen seines Erfolgs. – Er starb, wie er lebte – mittellos. Vielmehr ist es das, was man als „Vermächtnis“ bezeichnen könnte: die zahlreichen Anwendungen und die Grundlage für viele darauf aufbauenden Erfindungen. So konnte John Boyd Dunlop 44 Jahre später auf diese Idee setzen und fand eine weitere tolle Anwendung für Gummi als luftgefüllten Reifen. (Robert William Thomson hingegen kam Dunlop sogar 43 Jahre zuvor. Er hatte dieselbe Idee bereits 1 Jahr nach Goodyears Patent schützen lassen – vier Jahrzehnte vor Dunlop. Aber leider fehlte ihm die Anwendung. Darum ist er heutzutage weitestgehend unbekannt. Trotz der deutlich früheren Idee.)

Ohne eine Anwendung bleibt eine Idee klein. Erst durch die Anwendung der Idee wird sie groß.

Der Wunsch nach großen Ideen schadet

Wer den Anspruch hat eine große Idee haben zu wollen, der denkt viel zu früh in Kategorien wie „groß“ und „klein“ und erwartet die Anwendungen und den Erfolg zu einem Zeitpunkt (also am Anfang der Entwicklungsgeschichte einer Idee), zu dem jede Idee nicht anders als nur klein sein kann.

Diese Denkweise aber - verleitet dazu, alle kleine Ideen zu Seite zu schieben, sie nicht zu beachten und nicht aktiv anzugehen, weil man auf die große Idee wartet. Doch erst durch die Umsetzung und die Verbreitung der Anwendung der Idee kann eine Idee überhaupt groß werden.

Wer kleine Ideen zu schätzen weiß, der geht sie an und setzt sie um, weil sie wert sind umgesetzt zu werden - eine nach der anderen. So stellt sich irgendwann Erfolg ein.

Wer hingegen unbedingt eine große Idee haben will, der verwirft die kleinen Ideen und ärgert sich nur darüber, dass die großen Ideen scheinbar nur die Anderen haben. Die eigene Erwartungshaltung verbaut den Weg zur großen Idee.

Es erscheint auf den ersten Blick nachvollziehbar und wird daher auch oft so verstanden oder sogar propagiert. Gerade in der Softwareentwicklung, in der sich Anforderungen schnell ändern, gehören agile Methoden seit Jahren zum Standard. Und genauso oft gehört es zum guten Ton, jegliche Form von Prozessen zu boykottieren oder zumindest zu missbilligen. Mit hochgehaltenem Manifest wird gefordert, man möge sich doch nach den Menschen richten und nicht nach Prozessen.

Nicht alle Prozess sind gleich

Wie kann es sein, dass Prozesse so ein Problem werden? Unagil sind Prozesse nicht per se. Scrum zum Beispiel wird in Softwareentwicklungsteams gerne als Prozess angenommen. Hier stößt man kaum auf Wiederstand. Scrum versteht sich als agiler Prozess und dieses Marketing kommt an. Es wird nicht als unagil verstanden und daher eher akzeptiert. Dabei ist es ganz offensichtlich ein Prozess.

Regeln engen ein

Prozesse passen nicht, sind aufwendig, kosten viel Zeit. – So das Mantra, dass so mancher Entwickler aufsagt. Nicht selten werden Prozesse mit nahezu religiöser Emotionalität diskutiert und hinterlassen nach einer klaren Ansage der Führung - Gesichter voller Resignation.

Prozesse kommen aber in der Regel in Form von Vorschriften und Regeln daher. Regeln sind Spielverderber. Sie verbieten kürzeste Wege und zwingen zu Umwegen. Sie schreiben Tätigkeiten vor, auf die man keine Lust hast oder beschneiden die persönlichen Freiheiten.

„Ich kann so nicht effizient arbeiten!“ ist ein häufiger Satz, in dem sich der Unmut über die einengende Natur der Prozesse entlädt.

Management gegen Mitarbeiter

So mache Führungskraft ist da auch mal gerne geneigt nachzugeben und weicht Prozesse auf oder sieht vertrauensvoll weg, um dem eigenen Team etwas mehr Spielraum zu geben. Das geht dann eine Weile gut. Bald darauf kommt es zum Vorfall, bei dem die Augen nicht mehr verschlossen werden können.

Nicht selten versagt die Abstimmung im Team und es kommt zum Terminverzug, Kostenanstieg und Qualitätsrückgang. Spätestens wenn klar wird, dass die Abweichung vom Prozess eine der Ursachen war, wird als direkte Gegenreaktion die strikte Einhaltung der Prozesse gefordert. Das Team schluckt die bittere Pille und es herrscht dicke Luft.

Unterschiedliche Sichtweisen auf Prozesse

Führungskräfte setzen Prozesse nicht ohne Grund ein. Meist sind sie das probate Mittel, um einmal aufgetretene Probleme oder Mehraufwände zu vermeiden und systematisch und nachhaltig zu umschiffen. Gegossen in Regeln werden sie kommuniziert und sind als Anweisungen klar verständlich. Es ist eine Kunst für sich, die richtigen Regeln zu finden, welche das gewünschte Ergebnis bringen sollen.

Die vom Prozess betroffenen ihrerseits verstehen solche Regeln eher als Einschränkung, Einengung, Entmachtung oder Strafe für einen früheren Vorfall. Zudem werden viele Regeln als veraltet, sinnlos oder sogar als widersprüchlich betrachtet und nur wiederwillig befolgt.

Nutzen von Prozessen

Prozesse sind Konventionen, die es erlauben ein ständiges (erneute) Abstimmen im Team zu vermeiden, in dem die Abstimmung einmalig geklärt und langfristig geregelt wird. Prozesse helfen Übergabepunkte zu definieren und grenzen Aufgabengebiete ein. - Nicht um einzuengen, sondern um Freiräumen zu definieren, die nicht durch Andere verletzt werden. Klare Übergabepunkte beschleunigen die Übergabe und erlauben ein asynchrones und dadurch voneinander freies Arbeiten.

Doch was als Abstimmung gemeint ist – kommt als Vorschrift an. Was als Freiraum gemeint ist – kommt als Begrenzung an. Und was als freies Arbeiten gemeint ist – kommt als Isolation an.

Die Kluft muss man aktiv schließen

Natürlich gibt es auch veraltete Prozesse, verkrustete Strukturen und Unsinn mit System. Daran zweifelt niemand. Doch nicht jeder Prozess ist „Waste“. Ob ein Prozess einen Nutzen hat oder nicht, ist leider für die meisten nicht erkennbar. Das liegt jedoch an der Form der Prozesse.

Prozesse und Regeln sollten immer zusammen mit ihrem Nutzen festgehalten und vermittelt werden.

Eine Regel mit Erklärung ist verständlich und nachvollziehbar. Vor allem aber ist ihr Nutzen klar erkennbar. Veraltete Regeln sind nicht an ihrem Alter erkennbar. Vielmehr ist ihr Bezug nicht mehr gegeben. Doch das ist selten erkennbar. Sind die Regeln jedoch mit ihrem Nutzen erläutert, ist schnell sichtbar, ob die Grundlage der Regel noch gegeben oder bereits überholt ist.

Fazit

Prozesse können Werte schaffen oder zerstören. Statt die Fronten zu verhärten sollten die Regeln diskutabel bleiben. Dies geht nur, wenn der Zweck klar und verständlich ist. – Nicht nur die Anweisung.

Gerade die Akzeptanz von Prozessen hängt primär davon ab, dass ihr Nutzen für jeden leicht nachvollziehbar ist.

Daher sollte es jeder Führungskraft am Herzen liegen, die geltenden Regeln und Prozesse klar mit Ihrem Nutzen zu kommunizieren. Solche Prozesse sind dann kein „Waste“.