Empirie – Die Kunst durch Weniger mehr zu erreichen

There is an English version of this article available on Medium.

„Wofür hab ich bloß so viel gearbeitet?“, fragte er sich verzweifelt.

Die letzten Monate hatte er den Großteil seiner Arbeit darauf verwendet, an dieser einen Sache zu arbeiten. Die Arbeit daran war für einige Monate das Zentrum seines Lebens. Mit einer Vision hatte alles angefangen. Seine Idee hätte das Leben einiger Menschen leichter machen können. Und so verwendete er Stunde um Stunde, sein Projekt zu planen, entwickeln und den Launch vorzubereiten. Fast sechs Monate waren seitdem vergangen. „Verschwendet“, dachte er.

Nun betrachtete er die Seite mit den Page Views und Registrierungen. Er kam sich wie ein Trottel vor. Die ganze Arbeit für nichts. Nachdem er die Seite mehrmals neu geladen hatte, überzeugte er sich loszulassen. Er entschied, loszulassen und zu warten.

Verrat mir, wie oft musstest du im Leben die Richtung wechseln?

Als du beispielsweise vor hattest, nach Italien zu reisen, und eine Pandemie ausbrach. Im Geschäftsleben passiert es noch öfter. Das Meeting, auf das du dich vorbereitet hast? Abgesagt. Die Initiative, die du voran bringen wolltest? Geänderte Prioritäten. Die Deadline auf dem kritischen Pfad? Verfehlt. Leben läuft nicht immer wie geplant. Meinung geändert, Gelegenheit verpasst, Zeit versenkt. Sogar Fehlschläge sind im Leben unvermeidlich. Frag doch mal Edison, wie oft er es versucht hat, bevor er Licht in unsere Abende und Nächte gebracht hat.

Fehlschläge fühlen sich entsetzlich an. Niemand scheitert gerne. Noch schlimmer ist es, wenn wir den Fehlschlag hätten verhindern können. Aber wenn wir schon scheitern müssen – wäre es nicht gut wenn es wenigstens schnell ginge und wir daraus noch etwas lernen könnten?

Das ist die Idee empirischer Prozesssteuerung.

“I am the wisest man alive, for I know one thing, and that is that I know nothing.”

Socrates

Empirie ist eine Theorie mit einer einfachen Prämisse. Die Prämisse ist: Wissen wächst primär oder ausschließlich aus Erfahrung. Die Idee ist fast so alt wie die Menschheit, ist die Grundlage der modernen Wissenschaft und hilft uns die Welt zu verstehen. Sie hilft zu verstehen, wie die Welt tickt.

In der Wissenschaft führen wir Experimente durch, um eine Hypothese zu bestätigen oder zu widerlegen. In Scrum und anderen Ansätzen machen wir etwas ganz Ähnliches. Wir treffen eine Annahme, was für unsere Kunden von Wert ist, und dann schaffen wir etwas, um unsere Annahme zu überprüfen. Nicht hin und wieder, sondern am Ende eines jeden Sprints.

Dieser Ansatz zwingt uns, den Arbeitsumfang klein zu halten. Indem wir das machen, reduzieren wir gleichzeitig ein Risiko, das den meisten unserer Vorhaben inhärent ist: Der Ansatz hilft verschwendete Aufwände zu reduzieren.

Wenn du an die Idee der Empirie glaubst, würdest du Monate in die Planung versenken bevor du dich dran machst, deine Pläne umzusetzen?

Ich wette, das würdest du nicht. Du würdest die Annahme hinterfragen, dass du im Vorfeld wissen kannst, was deine Kunden brauchen. Du würdest dich weigern, jedes Detail im Vorfeld auszuarbeiten, bevor du das verdammte Ding baust. Bevor du weißt, ob irgendwer es haben will. Stattdessen würdest du eine minimale Version deines Produkts bauen und diese in der Praxis testen. Idealerweise würdest du das Ergebnis echten Kunden zeigen und rausfinden, ob es ihnen gefällt.

Gefällt es ihnen? Cool. Wenn nicht, hast du wenigstens nicht so viel Aufwand versenkt.

In manchen Fällen möchtest du Kunden keine frühe Versionen deines Produkts zeigen. Vielleicht baust du gerade das erste iPhone, während die restliche Welt noch stumpfe Mobiltelefone nutzt. Eine wahrlich neuartige Idee. Etwas, das du lieber geheim halten möchtest, bevor du es verkaufen kannst. Immerhin soll die Konkurrenz nicht deine Idee stehlen. In solchen Fällen würdest du die frühen Stadien deines Produkts ausgewählten Leuten in deiner Firma zeigen. Zumindest ist das der Ansatz von Apple.

Empirie bedeutet nicht, dass wir mit dem aufhören, worin wir gut sind. Es bedeutet anzuerkennen, dass mit allem, was wir tun, eine gewisse Ungewissheit verbunden ist. Und damit umzugehen.

Wenn wir uns auf die Idee einlassen, tun wir immer noch das Beste, was wir können. In kleinerem Umfang. Wir investieren immer noch ins Anforderungsmanagement. Wir sprechen immer noch mit Kunden und führen Marktstudien durch. Auch bauen wir weiter Prototypen, um technische Machbarkeit zu bestätigen. Dann machen wir uns daran, etwas von Wert zu produzieren. Natürlich wenden wir dabei den Qualitätsmaßstab unseres Berufsstandes an. So wie ein Entwickler weiter Tests für neue Funktionen schreibt. Oder wie ein Zimmermann weiterhin die Sägekanten eines Stück Holz glatt schleift.

Letztlich wollen wir doch weiter Produkte bauen, die Leute wirklich haben wollen.

Wir hören auch nicht auf zu planen. Tatsächlich planen wir sogar öfter. Unsere Planungszeiträume sind kürzer verglichen mit anderen Ansätzen. Eher im Bereich von Wochen bis zu wenigen Monaten – mit einer Präferenz für kürzere Zeiträume.

Erinnerst du dich an den Typ in der Einführung?

Dieser Typ hielt sich für schlau. Um einen Fehlschlag zu vermeiden sah er sich nach Produkten, die mit dem vergleichbar waren, was er im Sinn hatte. Er sprach mit Freunden. Dann verbrachte er Monat über Monat in seinem Zimmer. Baute das verdammte Ding. Aber, als er endlich fertig war, wollte es niemand haben. Zuerst dachte er, er müsste sich nur in Geduld üben und der Sache Zeit geben. Schließlich kommt Erfolg nicht über Nacht. Also wartete er. Er wartete und rührte die Werbetrommel. Social Media, bezahlte Anzeigen. Was immer dir einfällt. Er zog alle Register. Aber nach einigen Wochen fand er raus, dass seine potenziellem Kunden weiter gezogen waren. Sie hatten eine andere Lösung für das Problem gefunden, das er lösen wollte.

Jemand anders war schneller.

Nicht jeder Fehlschlag muss so groß ausfallen.

Nehmen wir an, du hast ein Produkt gebaut, das die Leute tatsächlich gut finden. Richtig gut. Aber du hast auch viel Zeit in dieses eine Feature gesteckt, von dem du glaubtest, dass deine Kunden es brauchen würden. Doch es entpuppt sich als Flop. Deine Kunden benutzen es nicht. Man kann nicht alle Aufwände vermeiden. Oft ist es allerdings möglich mehr zu erreichen, indem man den Arbeitsumfang reduziert und rausfindet, ob man damit durch kommt. Indem man früh Feedback einholt. Wenn du jemals den Titel eines Buches namens „Scrum — The art of doing twice the work in half the time“ (Affiliate-Link) — das ist die Idee dahinter.

Ich sagte, dass Fehlgeschläge unvermeidlich sind. Das ist die Wahrheit. Allerdings können wir aus Fehlern lernen. Das ist das Gute daran.

Die Sache ist auch nicht, dass wir nie im Vorfeld wissen was Leute wollen. Manchmal sagen sie es uns. Manchmal wissen sie es selbst nicht, bis wir es ihnen zeigen. Wenn wir in einer empirischen Weise arbeiten, können wir aus unseren fehlgeschlagenen Ideen lernen. Mit der Zeit können wir besser einschätzen, was Kunden wollen. Trotzdem werden wir noch manchmal scheitern. Unser empirischer Arbeitsmodus bewahrt uns davor, zu viel Aufwand zu versenken, bevor wir das rausfinden. Wenn wir einen kurzen Planungszyklus bemühen, müssen wir den Arbeitsumfang reduzieren, und das reduziert das Risiko.

Wie könnte ein empirischer Ansatz aussehen?

Wenn du dir selbst einen empirischen Arbeitsansatz ausdenken wollen würdest, könnte er ungefähr so ausfallen:

1. Planen der Arbeiten
2. Durchführung der Arbeit
3. Begutachten der Arbeit und wenn möglich Feedback einholen
4. Die Schritte wiederholen bis alle glücklich sind

Bei diesem Ansatz würdest du in kurzen Zeiträumen von wenigen Wochen bis zu einem Monat planen. Nach jedem dieser Zyklen würdest du deine Ergebnisse begutachten und den Prozess, wie du dahin gelangt bist. Du würdest schauen, ob es etwas zu lernen gibt. Wenn du vollständig von der Empirie überzeugt bist, würdest du jeden Tag als eine Iteration in der Iteration betrachten. In Konsequenz würdest du in jedem Tag eine Chance sehen, deinen Fortschritt in Richtung deines Ziels zu begutachten. Eine Chance, deine nächsten Schritte festzulegen.

Klingt das für dich nicht ein bisschen nach Scrum?

Dieser Artikel ist ursprünglich auf Medium erschienen als überarbeitete Form eines früheren Artikels.