fast-fail

Fail fast – aufgeben oder angreifen?

Katharina Kreuzer
Expertin für Veränderung
Mehr erfahren

Fehler einzugestehen, ist für uns alle immer eine kritische und unangenehme Situation. Wir werden am Erfolg gemessen und nicht daran, wie wir scheitern. Aber wieso? Bedeuten Fehler automatisch Versagen, oder bringt ein Fehler auch das sprichwörtliche Lernen aus Fehlern mit sich? Bei metaGoals heißt es definitiv: „Fail fast, succeed sooner.“ Das wissen wir jetzt aus eigener Erfahrung.

Nach einem fulminanten Start (der Hackathon) und dem Weg zur App (metaGoals) war es zuletzt still geworden um das metaGoals-Projekt. Wir steckten fest. Nun aber sind wir zurück mit einem motivierten Team, einer neuen Strategie und einigen „Fail’ings“ (Fail-Learnings).

Nach acht Monaten haben wir feststellen müssen, dass unser Ziel einer vollumfänglichen App-Entwicklung viel zu hoch gesteckt war. Die Idee, dieses Projekt in kürzester Zeit neben der regulären Arbeit zu stemmen, war utopisch. Daher haben wir die Notbremse gezogen. Sind einen Schritt zurückgetreten und haben aus der Entfernung betrachtet, was wir eigentlich geplant und was wir getan hatten. Das Ziel: unser Vorgehen zu überarbeiten – und ehrlich auf einige kritische Fragen zu antworten.

fast-fail

Wir haben erkannt: Unser Ziel, in 8 Monaten neben der regulären Arbeit eine vollumfängliche App zu entwickeln, war zu hoch gesteckt (Quelle: Adobe Stock / Javier).

Was wollen wir eigentlich erreichen?

Naja, eigentlich wollen wir eine App bauen, die alle Mitarbeiter:innen motiviert, in Challenges gegeneinander anzutreten. Oder? Ach so, jeder hat eine andere Vision zu diesem Thema? Vielleicht hätten wir diese Version aus dem Hackathon im „Real Life“ gegebenenfalls noch einmal schärfen sollen, um sie einheitlich zu kommunizieren und nur EINE gemeinsame Vision zu erhalten?

Sind unsere Erwartungen vielleicht zu hoch?

Stimmt, wir sind ja alle Consultants und verbringen bereits nahezu unsere gesamte Arbeitszeit im Kundenprojekt! Eine utopische (oder vielleicht zu hoffnungsvolle) Idee, eine komplexe App mit mehreren Sicherheitsstufen zu programmieren, designen, konzipieren, testen und in einer Community auszurollen, oder?

War die Hackathon-Zeit womöglich keine reale Arbeitssituation?

Was hatten wir für einen Spaß an diesen beiden Tagen des Hackathons, in denen wir gemeinsam, produktiv und unter Zeitdruck an der Aufgabe gearbeitet haben. Ach so, es ist nicht mehr möglich, diese Situation ins reale Arbeitsleben zu überführen? Außer natürlich den realen Zeitdruck 😉 Unser Arbeitsplatz ist immer noch überwiegend im Homeoffice, und die verschiedenen Kundenprojekte führen uns weit auseinander. Kein Wunder, dass die Motivation, einsam eine zusätzliche Arbeit im (manchmal nicht so) stillen Kämmerchen zu beginnen, stark nachgelassen hat.

Einfach losrennen – ist das eher unproduktiv?

Oh! Haben wir vielleicht zu früh ein zu großes Team versammelt und es zu strikt in verschiedene Themengruppen eingeteilt, die alle parallel losgelaufen sind, ohne sich wirklich abzustimmen und auf Abhängigkeiten zu achten? Hat ein Stream vielleicht schon etwas umgesetzt, und der andere hat doppelte Arbeit geleistet? Haben wir unterwegs den Überblick über die Prioritäten verloren und in welcher Reihenfolge Themen angegangen werden sollten? Wenn wir vom hippen Hackathon in die reale Welt springen, vom Entwickeln einer Idee zu ihrer Umsetzung, von Fantasie-Personas zu echten – dann müssen wir uns anders aufstellen, richtig?

fast-fail

Sind wir vielleicht alle zu früh parallel losgelaufen, ohne uns wirklich abzustimmen (Quelle: Adobe Stock / sutadimages)?

Go Big or go MVP?

Macht es vielleicht Sinn, mit dem Minimum Viable Product (MVP) erst einmal klein zu starten? Ist eine 30-Tage-Challenge mit vielen verschiedenen Zielen, mit unterschiedlichen Ergebniseingaben und mit abweichenden Adressaten möglicherweise doch ein bisschen zu detailliert für den Anfang? Vielleicht könnte eine Community die künftigen Entscheidungen festlegen? Aber wo ist diese Community, und wie baut man sie eigentlich auf?

Fragen über Fragen … Und die Luft war raus. Dabei hatten wir so viel Spaß beim Hackathon gehabt, wir haben den Pitch gewonnen, die Unterstützung aus der Geschäftsführung zur Umsetzung bekommen, und es fühlte sich doch an wie ein echtes Team, das da zusammenwächst. Statt am ersten Meilenstein landeten wir jedoch am ersten Tiefpunkt. Eine grundsätzliche Entscheidung musste her: Entweder metaGoals endet hier, oder wir fangen erneut an und lernen aus unseren Fehlern – und zwar schnell!

Aufgeben ist auch keine Lösung

Keine Frage, wir wären nicht die metafinanz und wir würden dem Anspruch an uns selbst nicht gerecht werden, wenn wir jetzt aufgeben. Ein schlankes Team mit unterschiedlichen Fähigkeiten muss her, dass bei Bedarf Expert:innen hinzuzieht, um gezielt und effektiv zu arbeiten. Wir wollen die zusätzliche Zeit mit Vergnügen investieren und dieses Engagement auch würdigen. Persönliche Treffen vor Ort werden stattfinden – mit priorisierten Zeitblockern, einer definierten Strategie, Agenda und Verantwortlichkeiten, einem Sprint-/Meilenstein-Plan sowie einem Planungstool.

Wird es anstrengend? Ja.
Macht es uns wieder Spaß? Definitiv ja!

Also legen wir wieder los und beweisen der Welt, dass Fehler gemacht werden müssen, um aus ihnen zu lernen und einen besseren Weg zu finden. MetaGoals 2.0 – Ready to Hack Again!

Mehr Einblicke in unsere Hackathons bekommen Sie in den Beiträgen „Ideen, Spaß, Zusammenhalt: Hackathon!“ und „Hackathon v2: Von der Idee zur Umsetzung“. 

Sie möchten ein Teil einer agilen Organisation werden? Entdecken Sie hier unsere neue Karriereseite!

Quelle Titelbild: eigene Darstellung / metafinanz

Katharina Kreuzer
Expertin für Veränderung
Mehr erfahren

Weitere Beiträge

Risk & Security

Cybersecurity im Automobilbereich: die neue ISO 21434

Weiterlesen
Risk & Security

Messenger-Security-Check: Wie sicher sind die täglichen Begleiter?

Weiterlesen
Agile & Organisation

Agiles Powerplay

Weiterlesen

Kommentieren

Diesen Beitrag teilen

Alle Beiträge von
IT & Digital