"Besser haben als brauchen"?

Photo by Elisa Ventur / Unsplash

Hast du schon mal probiert ein eigenes Produkt zu entwickeln? War es ein einfacher Weg, der immer nach Plan verlief? Hat dich dein Leben bisher gut darauf vorbereitet?

In den letzten Jahren habe ich mich privat immer mehr mit dem Thema Minimalismus beschäftigt. Wirklich spannend ist aber aktuell, dass die Erkenntnisse ohne erkennbaren Zusammenhang wieder in meinen Gedanken auftauchen. Und plötzlich bringt Minimalismus auch in der Softwareentwicklung einen Vorteil.

Immer wieder höre ich in Gesprächen mit Kollegen und Freunden zufällig das Sprichwort "Besser haben als brauchen". Bei mir zieht sich da erstmal alles zusammen. Das ist zwar statistisch betrachtet wenig überraschend, aber dennoch denke ich mir jedes Mal: "ich sehe das ganz anders, aber viel Glück mit deinem Weg." Meine Reaktion wurde durch die Lehre des Minimalismus ausgelöst. Diese hat mir beigebracht, dass man durch weniger Ablenkung auch automatisch seine eigene "Lenkung" - (Vorsicht Wortspiel!) verbessern kann. Durch das Beschränken auf weniger angesammelte Dinge, ist es einfacher zu sehen, was jetzt gerade wichtig für einen ist. Außerdem übt man das Loslassen von Dingen, die oft auch mit lieb gewonnenen Erinnerungen zu tun haben. Für mich hat es oft damit zu tun, sich auf die wesentliche Dinge zu fokussieren, die man in der Gegenwart benötigt - ohne zu starke Fixierung auf die Hobbies, die seit 5 Jahren nicht mehr ausgeübt werden und einen immer wieder daran erinnern, das man etwas früher besser konnte. Aber auch ohne, dass man bei allen Gegenständen denkt: "Das kann ich bestimmt irgendwann mal gebrauchen". Fakt ist häufig, irgendjemand kann genau diesen Gegenstand jetzt gerade nutzen. Und dann ist für mich klar, bei anderen ist der Gegenstand besser aufgehoben. Somit spiegelt die eigene Außenwelt auch im Grunde immer die aktuelle Person, die wir sind. Und da hilft es immer wieder, diese auch in der Außenwelt zu sehen, zu fördern - man fördert damit implizit eine ideale Umgebung für gute Gewohnheiten, aber zu dem Thema kann euch James Clear mit seinem Buch Atomic Habits sicher mehr erzählen.

Aber genug der menschlichen Aspekte, es gibt noch einen fachlichen Punkt, auf den ich hinaus will. In der letzten Woche habe ich viel über eine Variante des Projektmanagements gelernt. Durch Tiago Forte bin ich auf das Thema "Just-In-Time" Projektmanagment gestoßen. Die Methoden, die wir heute verwenden sollten - unterscheiden sich stark von denen vor 50 Jahren. Während wir uns heute im Alltag immer VUCA (Volatility, Uncertainty, Complexity, Ambiguity) stellen müssen, so waren Projekte früher sehr viel linearer, also vorhersehbar. Damals hat General Motors den RoI - Return On Invest genutzt, um Projekte untereinander zu vergleichen. Die ersten Softwareprodukte mussten sich fast nie damit beschäftigen, ob es eine Nachfrage im Markt geben würde oder die Nutzer überhaupt das Problem erkennen. Ein Erfolg war vorprogrammiert, fast alleine dadurch dass die Lösung neu ist. Viele Systeme wurden entwickelt "nur für den Fall, dass .." (Just-In-Case).

Wenn man an der Stelle eins und eins zusammenzählt, dann wird klar: im Just-In-Time Projektmanagement geht es darum, Dinge nicht nur für den Fall, dass XY passiert zu entwickeln, sondern dann - wenn man sie benötigt. Genauer gesagt ist es erforderlich die Entwicklung davon so spät wie möglich zu machen. Denn heute ist es um so wichtiger, dass man die gewonnenen Erkenntnisse oder das neue Wissen direkt in seine Entscheidung einbezieht. Deshalb ist es auch so wichtig, dass wir im Alltag der Unsicherheit mit einer ständigen Lernbereitschaft entgegentreten. Wir sollten heute viele Projekte direkt beginnen, da ein vorgelagertes Verstehen der Thematik und das Raten was als nächstes passieren wird mindestens genauso viel Zeit beansprucht, wie es direkt umzusetzen.

Das Prinzip klingt erstmal nach Prokastinieren in der reinsten Form, aber es macht total Sinn, wenn man das Thema mit der Theorie des kritischen Pfads ergänzt. Denn beim Prinzip Just-in-Time geht es nicht darum, die Aufgaben so lange vor sich herzuschieben wie nur irgendwie möglich. Sondern den sogenanten "späten Start" aus dem Critical-Chain Project Management zu nutzen. Diese Methode basiert auf der Theorie der Einschränkungen von Eliyahu Goldratt. Dabei geht es darum, den kritischen Pfad zu erkennen und die Reihenfolge dementsprechend so anzupassen, das Zeit und Ressourcen gespart werden können.

Das Ganze lässt sich mit einem Beispiel aus einem meiner Lieblings Hobbies gut erklären: Dem Kaffee kochen. Denkt euch dafür einen klassischen Pour-Over Kaffee, bei dem man zunächst das Wasser kochen muss, damit man die gemahlenen Bohnen in einem Filterpapier damit übergießen kann. Bei diesem einfachen Vorgang kann man 66% der Zeit einsparen, wenn man mit dem kritischen Pfad beginnt. Der kritische Pfad bildet sich dabei aus der längsten Kette von abhängigen Aufgaben. Somit lässt sich der baldmöglichste Genuss vom Kaffee vorhersagen. Folgt man dem kritischen Pfad, so bekommt man den Kaffee in etwa 4:30min, statt fast 7min - wenn man so blöd ist und das Wasser erst am Ende aufkochen lässt.

Und das schöne an diesem Beispiel ist, hier würde niemand anders vorgehen. Spätestens nach einem Mal falsch machen, hat es jeder verstanden. :) Die meisten Projekte aber starten leider ganz anders und nutzen den "late start" nicht wirklich. Das Standard Prozedere ist es direkt ein großes Team an eine große Aufgabe zu setzen - es gibt ja schließlich so viel zu tun. Das fühlt sich für alle auch erstmal gut an, es wird viel erledigt. Aber leider verliert man hier auch leicht den Fokus auf die Aufgaben, die den höchsten Impact auf den Erfolg des Projekts haben. Viele beachten den kritischen Pfad nicht und arbeiten munter vor sich hin. Das Prinzip des späten Starts würde hier eher empfehlen mit einem kleinen Kernteam zu beginnen, die sich mit Research, Discovery oder Nutzerbefragungen beschäftigen. Also auf die Tätigkeiten, die am meisten Erkenntnisse und neues Wissen generieren. Und wie Ash Maurya, Autor von Running Lean immer wieder predigt: "Die Geschwindigkeit in der wir neue Erkenntnisse sammeln und verarbeiten ist der neue unfaire Vorteil". Und geht es nicht im gesamten Bereich "Lean Startup", etc. darum Ressourcen oder Zeit zu sparen?

Denn natürlich fühlt sich das große Team irgendwann schlecht, wenn es heraus findet, dass die gemachte Arbeit vor einigen Wochen verworfen werden muss, da man inzwischen mehr weiß als zu Projekt Beginn?

In der Welt der Softwareentwicklung erkennt man einige Parallelen zum agilen Vorgehen. Auch hier geht es im Kern darum, mit den Änderungen am besten umzugehen. Egal ob neue Erkenntnisse oder neue Technologien, die einen höheren Nutzen haben. Aber agil sind ja heute angeblich alle irgendwie, jeder schreibt sich das auf die Fahne - deshalb wird es zu leicht durch die eigene Brille ignoriert und rausgefiltert.

Wenn man diese Ideen nun kombiniert, so komme ich zu einer bessern Version des Grundgedankens. Aus "Besser haben als brauchen" wird somit "Erst etwas haben, wenn man es wirklich braucht - und man auch genau weiß, warum / wofür man es braucht." So fühlt sich der Satz für mich auch wieder direkt besser an und lässt sich mit dem Prinzip Minimalismus super vereinen.

Jetzt komme ich endlich zu dem Hauptproblem, warum uns das alles so schwer fällt.

Wir sind es nicht gewohnt!

Schon in frühen Zeiten in der Schule haben wir für Prüfungen das komplette Spektrum an Wissen eingeübt, nur für den Fall das etwas davon dran kommt. Allgemein haben wir während unserer Schulzeit gelernt gute Noten zu schreiben für den Fall, dass wir mal einen Job haben wollen, bei dem das relevant ist. Oder wir lernen so viel, nur für den Fall das wir ein Studium angehen wollen, welches nur mit einem gewissen NC zulässt.

Außerdem haben wir gelernt, dass Volumen häufig auch Leistung entspricht. Viele sind stolz auf ihre 60 oder 70 Stunden Wochen. Viele werden gleich gut bezahlt, weil sie eine ähnliche Jobbeschreibung erfüllen, unabhängig davon wie viel wirklich in der Woche erreicht wird. In den Prüfungen früher haben wir uns antrainiert direkt zur Lösungsfindung überzugehen, bevor wir das Problem richtig verstanden haben - oder die Frage komplett gelesen haben. Sobald wir das kleinste Gefühl davon haben, wir wissen in welche Richtung es geht, wollen wir effizient direkt zur Antwort überspringen. Deshalb ist es heute so wichtig, das Problem besser zu verstehen - als der Kunde selbst. Denn Kunden sind auch immer nur Menschen. Die interessiert es nicht, was deine Lösung alles kann, sie wollen ihr Problem gelöst haben.

Deshalb ist es meiner Meinung nach so wichtig die junge Generation mit in die Entscheidungen einzubeziehen. Sie sind nicht so stark trainiert im Just-in-Case Denken oder spüren einen inneren Widerstand dabei. Und ein einmal gelerntes Verhalten abzutrainieren dauert etwa 30% der Zeit, die man es eingeübt hat.

Abschließen möchte ich meinen Text mit einem Tipp von Simon Sinek: Always start with WHY! Also fragt euch bitte:

• "Welches Problem möchte ich lösen"
• "Warum sollte sich jemand dafür interessieren?"
• "Warum mache ich das"?

Und der große Vorteil von der Entwicklung von Software ist ja, dass wir zu jeder Zeit eine Änderung vornehmen können. Also könnt ihr jederzeit damit anfangen, anders zu arbeiten, anders zu denken.

Danke fürs Lesen!

Quellen & Referenzen:

• Atomic Habits by James Clear 
• Just in Time Project Management - Tiago Forte, Online Blog Series ︎
• Theory of Constraints & Critical Chain Project Management (CCPM) by Eliyahu Goldratt 
• Running Lean III. Edition - Ash Maurya 
• sagt zumindest Jorge Bucay zur Verhaltenstherapie - basierend auf der Vergangenheit. Vergeiche: Komm ich erzähl dir eine Geschichte - Jorge Bucay 
• Start With Why - Simon Sinek