Naturally Grown Software

Management ist eine Meta-Disziplin. Diesen Satz höre ich immer wieder. Es herrscht in weiten Teilen der IT-Landschaft die Vorstellung, dass Management von IT-Projekten nicht viel anders entgegenzutreten ist als anderen Projekten.

Ob es um den Bau eines Schiffes, eines Hauses, einer Webanwendung oder der Diplomarbeit geht, scheint dabei nur zweitrangig eine Rolle spielen.

Aktionen sind zu planen, deren Ausführung zu kontrollieren und bei Planabweichung ist entsprechende Steuerung von Nöten.

Dass IT-Projekte doch anders sind, hat sich mittlerweile rumgesprochen. Sie scheinen stets sehr viel länger zu brauchen, als ursprünglich geplant war. Das legt den Verdacht nahe, lediglich die Schätzungen stimmen nicht.

Managen, bloß wie?

Die Realität in der IT-Projektplanung ist weitaus schlimmer. Bereits die Planung stellt sich problematisch dar. Eine grobe Planung ist meist nicht möglich, da solche Ergebnisse oft nicht einmal zu Orientierung taugen. Eine nützliche Planung hingegen müsste so fein sein, dass bereits die halbe Arbeit getan wäre, bis man eine erste Aussage hätte. Die Kontrolle gestaltet sich nicht minderkompliziert. Eine verlässliche Größe zum Fortschritt (90%-Syndrom) oder zur Qualität scheint es nicht zu geben. Was sich hingegen messen lässt (z.B. Stunden oder Programmzeilen), dient oft nur als schwacher Indikator. Von der Steuerung mal ganz zu schweigen. Da man eigentlich permanent im Verzug ist, wird gleich zu Anfang das Motto „so schnell wie möglich“ zum Dauerzustand.

Fehler im Ansatz

Der Schuh drückt überall und scheint nicht zu passen. Softwareprojekten ist mit einer industriell geprägten Meta-Disziplin-Sichtweise so nicht beizukommen. Es muss ein neuer Ansatz her.

Mein „radikaler“ Vorschlag: betrachten wir die Softwareentwicklung für einen Moment einfach mal nicht aus der Sicht der industriellen Fertigung, sondern aus der landwirtschaftlichen Sicht. Der Manager ist der Landwirt und leitet seinen Acker. In dieser Analogie sollen die Entwickler die Bäume, Sträucher und Bodenpflanzen sein und die Früchte stellen die Software dar.

Natürlicher Zugang

Wozu diese Sicht? Sie soll helfen bisherige Handlungen neu zu bewerten und über die Analogie einen natürlichen Zugang zu einer neuen Sichtweise verhelfen.

Planung und Steuerung

Betrachtet man die Planung aus Sicht eines Bauern, so ist sie durchaus sehr wichtig. Nur wer die Saat ausbringt kann später ernten. Und dies braucht eine gewisse Vorlaufzeit. Aber kein Bauer würde sich drei Monate im voraus einen Tag im Kalender aussuchen und an diesem Tag ernten wollen. Die Umstände ändern sich täglich. Was, wenn nun wochenlang Trockenheit herrscht? Soll man weiter Unmengen Wasser verschwenden oder die Ernte teil-reif einholen? Was wenn die Früchte am Stichtag nicht reif sind, aber das Wetter gut ist? Dann vielleicht doch länger Sonne tanken lassen?

Was macht der industriell geprägte Manager? Er belohnt die Pflanzen mit Wasser, wenn sie gut wachsen. Wenn sie nicht schnell genug wachsen rationiert er das Wasser (um Anreize zu schaffen) oder er setzt das Feld unter Wasser – nach dem Motto: viel hilft viel. Zu guter letzt wird man ihn auf dem Feld erwischen, wie er am Gemüse zerrt und hofft, dass es so schneller wächst. Er wird aufgebracht den ganzen Tag emsig auf dem Acker hin und herlaufen, dabei rufen „ich muss doch etwas tun“ und dabei so manche Frucht beschädigen.

Software reift in ihrer Qualität. Es kann nicht einfach Wochen vorab entschieden werden, ob zum Stichtag eine gute Qualität anzutreffen sein wird. Dies muss sich ergeben. Ist dem nicht so, können betreffende Features rausgenommen oder der Release-Termin verschoben werden, bis die Qualität insgesamt annehmbar ist.

Kontrolle

Kommt der industriell vorbelastete Manager auf das Feld um zu „kontrollieren“, so wird er die ausgebrachte Menge Wasser und Dünger notieren, die Höhe der Pflanzen und das Gewicht der Früchte messen. Er wird sich vielleicht wundern, wieso die Früchte Anfangs schnell wuchsen und seit 3 Wochen nicht mehr wachsen, sondern nur grün herumhängen. Er wird zwar nach dem Erfassen der Daten nicht viel wissen, aber er wird hoffen nächstes Jahr aus den Zahlen bessere Entscheidungen treffen zu können.

Der Bauer wird sich wohl eher die Pflanzen anschauen. Lassen sie die Blätter hängen, brauchen sie vielleicht Wasser. Sind die Früchte noch blass, brauchten sie etwas mehr Zeit in der Sonne. Gerade bei ertragreichen Pflanzen (z.B. Obstbäumen) wird eher auf die Gesundheit der Pflanzen achten, als auf die aktuelle Ernte. Denn geht die Pflanze zugrunde, verliert er viele gute Ernten. Vor allem aber achtet er auf den Geschmack der Früchte. Denn der Kunde will guten Geschmack.

Softwarequalität lässt sich kaum messen. Wenn überhaupt kann ihre Abwesenheit (z.B. sogenannte „Smells“) gemessen werden. Gute Qualität kommt von guten Entwicklern, die gut über das nachdenken können, was sie tun. Das braucht manchmal Zeit. Gute Ideen und darauf basierende gute Entscheidungen sollten insgesamt eher Zeit sparen als kosten. (Eine Software, die nach 10 Jahren noch annehmbar zu benutzen ist, darf gerne auch doppelt so viel kosten, wie eine Software, die nach einem Jahr bereits größerer Anpassungen bedarf.)

Steuerung - Teamgröße

Wenn die Pflanzen nicht schnell genug wachsen und auch „an der Früchten zerren“ nichts bringt, wird der Manager mit industrieller Sichtweise versuchen das Team vergrößern. Er wird weitere Bäume kaufen und sie zu den anderen Pflanzen. Ihm wird klar sein, dass die neuen Bäume noch jung sind und erst einmal nur Wasser brauchen und keine Früchte geben - „Einarbeitungsphase“ halt.

Dem Bauer hingegen ist klar, dass zu viele Bäume sich gegenseitig das Licht und die Nährstoffe weg nehmen. Es wird zwar mehr Bäume geben, aber jeder wird weniger Ertrag bringen. Insgesamt wird es am Ende vielleicht kaum mehr zu ernten geben als vorher.

Manche Softwareprojekte sind für eine Einzelperson zu groß. Jedoch ist eine Einzelperson das ideale Team. Es herrscht Einigkeit, Klarheit und eine absolut ideale interne Kommunikation. Jede weitere Person im Team erfordert Abstimmung und Klärung. Ein Team sollte nach Möglichkeit so klein wie möglich ausgelegt werden. (Meiner bisherigen Erfahrung nach wird ein Projekt ab dem vierten Entwickler nicht mehr schneller, wenn diese an den gleichen Modulen arbeiten.)

Weitere Ansätze

Verwendet man die Landwirtschafts-Analogie für die Softwareentwicklung, so erscheinen die klassischen industriellen Ansätze fehl am Platz. Die Analogie leistet jedoch mehr. Sie bietet aus sich heraus weitere Anwendungsanalogien über die Softwareentwicklung, die es in der industriellen Fertigung so nicht gibt.

Orientierung am Team – nicht am Produkt

Besichtigt ein Bauer sein Feld, so interessieren ihn die Früchte nur am Rande. Er prüft den Reifegrad, aber er weiß, dass sie irgendwann (bald) reif sein werden. Sein primäres Augenmerk dient nicht dem Wachstum der Früchte. Diesen kann er nur indirekt beeinflussen. Er weiß, dass er sich eher um den Zustand der Pflanzen kümmern muss, wenn er viele gute Früchte ernten will. Sind seine Pflanzen fit? Haben sie vielleicht einen Schädlingsbefall?

Bei Software kommt es nicht auf den Code an. Es kommt vor allem auf die Menschen an, die ihn machen. Wissen die Entwickler was sie tun? Haben sie selbst ein Interesse daran, dass die Qualität gut wird? Wenn sie genötigt werden über längere Zeit schlechte Qualität hervorzubringen, gehen sie irgendwann - wie eine Pflanze auf schlechtem Boden - ein.

Vitalität im Team

Wie bei Monokulturen in der Landwirtschaft gibt es auch Monokulturen in der Softwareentwicklung. Manche Unternehmen spezialisieren sich auf eine Programmiersprache, ein Produkt, eine Datenbank, … eine Denkweise. Alle denken gleich. Es fehlen alternative unkonventionelle Sichtweisen aus anderen Gebieten. Entwicklungen von Anwendungen werden weniger aus der Beobachtung des Marktes heraus, als vielmehr aus den eigenen Möglichkeiten getrieben. Dies lässt jedoch kaum Raum für Neues oder gar Bahnbrechendes.

Freiheit

Jede Pflanze wächst wie sie will. Zwingt man sie in eine Form, geht dies von ihrer Energie ab. Gerade Softwareentwickler sind sehr freiheitliebend. Jegliche Konformitätsbestrebungen mindern ihre Kooperationsbereitschaft. Vor allem Aufgaben, die in ihren Augen sinnlos erscheinen, werden boykottiert. Uniformität als Selbstzweck funktioniert nur schlecht. Am liebsten halten sie es wie die Pflanzen: man geht ihnen am besten aus der Sonne, wenn man ihnen helfen will.

Indirekte Unterstützung

Der Bauer hilft seinen Pflanzen z.B. in dem er Unkraut entfernt, welches Licht und Nährstoffe raubt, sobald er es sieht – noch bevor die Pflanzen durch klare Signale, dies einfordern.

Entwickler sind in mancherlei Hinsicht ähnlich. Sie machen ihre Arbeit selbst und brauchen auf „ihrem“ Gebiet selten Hilfe. Man kann ihnen aber anders helfen. Viele Probleme sind politischer oder organisatorischer Natur. Dies sind Probleme, denen Entwickler gerne aus dem Weg gehen. (Entweder weil es sie schlichtweg nicht interessiert oder weil sie das Gefühl haben, sich nach „oben“ nicht durchsetzen zu können.) Sie arrangieren sich und weichen aus. Dies gilt es zu erkennen und zu helfen.

Gerade als Vorgesetzter sitz man oft näher an den Entscheidern und kann dem Team den Kopf zum denken frei halten oder das Umfeld verbessern.

Druck hilft nicht

Dem Bauer ist klar, dass es nicht hilft die Nährstoffe per Injektion in die Pflanze zu spritzen. Sie wird deshalb nicht schneller wachsen. Sie ständig umzupflanzen, um die richtige Stelle zu finden, ist ebenso wenig hilfreich. Sie zu fluten, zu überdüngen oder gar mit Scheinwerfern zu verbrennen hilft nicht.

Zu viel Aufmerksamkeit lenkt Entwickler ab. Sie daran zu erinnern, dass sie im Verzug sind, erhöht zwar den Druck und den Stress, aber keines der beiden ist für eine konzentrationssteigernde Wirkung bekannt.

Fazit

Management mag eine Meta-Disziplin sein, aber es ist nicht egal für welche Branche. Die althergebrachte industrielle geprägte Sichtweise und die Begrifflichkeiten wie „Produkte“ oder „Softwarelinien“ helfen nicht gerade diese Sichtweise auszuräumen. Der bisherige Ansatz scheint nicht zu funktionieren. Also wieso daran festhalten?

Es lebe die „naturally grown software“!

(PS: Natürlich halte ich Entwickler nicht für Pflanzen – aber noch viel weniger für Fertigungsroboter.)