Eine Applikation rausbringen ist der Zweck der Softwareentwicklung. Je höher der Wert und je schneller sie rausgebracht wird, desto grösser ist der Erfolg. Oft sind die Hürden in den Köpfen und hindern am raschen Erfolg. Prüfen Sie Ihr Mindset auf althergebrachte Irrtümer.

Digital Dummy denkt: Die Applikation ist fertig

Realität: Eine Applikation wird nie fertig.

Warum:
1. In der Zeit wo die Anwendung entwickelt wird, dreht sich die Welt weiter. Neue Technologien, Gesetze, Geräte, Erkenntnisse und Märkte entstehen ständig und warten nicht darauf, dass die App fertig wird.
2. Niemand weiss alles im Voraus vollständig. Jede Dokumentation ist veraltet, in dem Moment, wo Sie sie ausdrucken. Jede Anwendung ist veraltet sobald sie produktiv geht.

Learning:
Gewöhnen Sie sich an das Konzept des Lifecycle. Dann werden Ihre Entscheidungen kontinuierlich besser und die Planung wird solider und verlässlicher. Verstehen Sie, was Software Lifecycle bedeutet und die Applikation wird früher rauskommen und kontinuierlich wertvoller.

 

Digital Dummy denkt: Die Applikation ist fehlerfrei

Realität: Eine Anwendung ist niemals fehlerfrei.

Warum:
1. Es ist praktisch unmöglich fehlerfreie Apps zu bauen. Sogar Raumfahrtsoftware hat Fehler.
2. Es ist nicht wirtschaftlich Fehlerfreiheit anzustreben. Der Testaufwand steigt exponenziell, mit jedem if-Statement im Code vervielfacht sich die Anzahl der Fälle. Kennen Sie die Anzahl dieser Statements im Code? Also!

Learning:
1. Glauben Sie niemandem, der behauptet, die Software wäre fehlerfrei.
2. Halten Sie niemals einen Anwendungs-Entwickler für einen Idioten. Nicht er/sie ist der Idiot sondern der, der auf Irrtümer baut und die Zusammenhänge nicht erkennt.
3. Es gibt ein Optimum zwischen Aufwand und Funktion. Je früher Sie nach dieser Maxime entscheiden, desto besser wird das Ergebnis.
4. Es gibt viel mehr als “es muss funktionieren”. Gute Qualität braucht Kriterien. Stellen Sie die wichtigsten Qualitätskriterien auf und richten Sie die gesamte Arbeit danach aus.

 

Digital Dummy denkt: Ein wenig Druck beschleunigt die Fertigstellung der Applikation

Realität: Druck erzeugt Gegendruck genau wie in der Physik. Dadurch entsteht Reibung und Gegenwehr.

Warum:
Für Druck erlangt man allenfalls Aufmerksamkeit als harter Hund. Aber auch harte Köpfe können innen hohl sein. Druck ist das Eingeständnis von Unverständnis. Es offenbart die Frage: «Warum dauert das so lange?»

Ursache ist eine falsch verstandene Management Regel. Das Vermeiden von Mikro Management führt oft dazu die Flughöhe zu steigern bis zum Nichtverstehen der Zusammenhänge. Die Akzeptanz erlischt dadurch und statt Ursachen geklärt werden Rechtfertigungen konstruiert. Das senkt wiederum die Nachvollziehbarkeit. Ein Teufelskreis entsteht.

Learning:
Fragen Sie nach. Wenn Sie Druck machen ohne zu verstehen, woran es liegt, entstehen Festungen weil sich die Leute wehren. Im Ergebnis werden Sie langsamer statt schneller. Es bleibt Ihnen gar nichts anderes übrig, als die Zusammenhänge zu verstehen. Dann sehen Sie woran es liegt und können richtige Entscheidungen treffen und besser planen.

 

Digital Dummy denkt: Start-Up Feeling kann man erzeugen

Realität: Garagenatmosfäre ist nett aber die Abläufe sind schliesslich die gleichen wie in den grauen Bürohäusern. Die Killer-Applikation will einfach nicht gelingen.

Warum:
Gründer träumen vom Reichtum aber Angestellte mögen einen sicheren Job. Mit angesagter Garagenatmosfäre lässt sich eine Fassade aufbauen. Seien Sie sicher, dass die Mirabeiter es mögen. Aussergewöhnliche Leistungen beruhen aber auf Motivationen, nicht auf Fassade.

Learning:
Schaffen Sie ein Umfeld das die Leute mögen. Entspannt, vertrauensvoll und kravattenlos arbeitet es sich leichter. Glauben Sie aber nicht, dass sich Mitarbeiter veräppeln lassen. Garagenatmosfäre garantiert weder Knowhow noch Erfolg. Es schadet sogar, wenn bestimmte Goodies wieder zurückgenommen werden oder sich andere Mitarbeiter ausgeschlossen fühlen.

 

Digital Dummy denkt: Mehr Leute beschleunigen das Projekt

Realität: IT Projekte werden immer teurer und langwieriger.

"If you put additional people to a late software project, you make it even slower."

Warum:

Jeder freut sich über mehr Mitarbeiter, das bedeutet mehr Status aber auch mehr Führungsaufwand. Aber neun Frauen können nicht in einem Monat ein Baby zur Welt bringen.

Learning:
Wenn sich ihr Team vergrössert, haben Sie erstmal nichts falsch gemacht, es sei denn, Ihnen gehört der Laden. In traditionellen Unternehmen nennt man das Aufstieg. Die Anwendung wird dadurch weder schneller fertig noch wird sie besser. Mehr Kosten führt nicht automatisch zu Mehrwert. Fokussieren Sie auf den Wert der Applikation. Nehmen Sie sich die Zeit, den Wert zu bemessen. Benennen Sie jemand, der genau diesen Wert maximieren soll. Jede Wertsteigerung wird dann in kurzen schnellen Iterationen verbessert.

 

Digital Dummy denkt: Aufwand lässt sich berechnen

Realität: In jedem Betrieb gibt es Excel-Sheets mit dem Dateinamen planung.xls. Und schon haben wir eine Planung.

Papier ist geduldig, Excel auch! Jede Aufwandsschätzung ist entweder Hoffnung, Sales oder Märchenstunde. Fixpreisprojekte gab es früher mal. Diese Firmen sind allesamt pleite oder vom Kunden teurer aufgekauft.

Warum:

Natürlich gibt es theoretische Modelle zur Aufwandsschätzung für bestimmte genau definierte Funktionen. In der Wissenschaft, wo die Axiome vorher definiert werden und man darauf aufbauend eine Theorie entwickelt, funktioniert das auch.

Die Anwendbarkeit in der unternehmerischen Praxis geht gegen null. Denn solche Schätzungen wären nicht wirtschaftlich und würden zu lange dauern. Damit wäre die Schätzung unbrauchbar, siehe Irrtum Nr. 1 (Die Welt dreht sich ja weiter). Schliesslich hat es Interessenskonflikte zwischen Anbieter und Kunde, die in der Wissenschaft nicht existieren.

Learning:
Wenn Ihr Software-Team auf halber Strecke aufgibt oder pleite geht, haben Sie nichts gewonnen. Wenn Sie als Team- oder Projektleiter ein Enddatum verlangen weil das Management ihnen das abverlangt, dann wird Ihnen nichts anderes übrig bleiben als die Märchenstunde mitzuspielen. Immerhin können Sie auf dieses Learning verweisen. Es könnte etwas bewirken. Besser als eine pseudo-exakte Planung, die sowieso nicht realisiert wird, sind kontinuierliche Erfolge. Kleine testbare Fortschritte einer Applikation, die sichtbar eine Wertschöpfung erzeugen, können schliesslich besser überzeugen. Das ist dann Realität.

 

Digital Dummy denkt: Die Projektleitung ist agil

Realität: Agile Software-Entwicklung kennt keine klassische Projektleitung.

Warum:
Ein Projekt hat ein natürliches Ende. Es ist irgendwann fertig.

Wenn Sie einen Staudamm bauen wollen, macht Projektleitung Sinn. Der Staudamm ist irgendwann fertig und wird nicht tausende Male neu aufgebaut. Die Gesetze der Physik die es zu beherrschen gilt sind bekannt und stabil. Klassische Projektplanungstools und eine entspechende Projektorganisation machen das Vorhaben weitgehend planbar und beherrschbar.

Die Gesetze der Anwendungsentwicklung sind das nicht. Anwendungsentwicklung ist eher ein Prozess als ein Projekt. Genau aus dieser Erkenntnis heraus entstanden die agilen Ideen.

Software wird ständig neu gebaut: kompiliert, integriert, versionert, refraktioniert, redesigned, lokalisiert und released.

Selbst die Parametrierung über die GUI ist der Agilität eher abträglich, da sie manuell geschieht. Sie erfordert viel Zeit und Testaufwand und bremst jede Iteration aus. Manuelle Parametrierung ist nach agilen Kriterien ein Anti-Pattern. Ein klassischer Software-Irrtum.

Die Entwicklungs-Umgebung (environment) ist nie endgültig, nicht stabil und nicht kalkulierbar. Denn Prozessoren, Protokolle, Tools und Betriebssysteme ändern sich laufend.

Learning:

Wenn Sie noch klassische Projektleitung gelernt haben ist das nachvollziehbar. Die Informatik ist eine junge Disziplin, die versuchte, von anderen zu lernen. Man wusste es schlicht nicht besser. Die Anwendbarkeit klassischer oder auf der Kriegskunst basierender Führungslehren auf Softwareentwicklung ist sehr begrenzt und eher anti-agil.

Wenn Sie die Learnings aus den obigen Irrtümern verstanden haben, werden Sie sehen, dass Sie entweder agil arbeiten oder einen Staudamm bauen wollen.