Viele Firmen versuchen, steigende (Produkt-)Komplexität mit Prozessen und Struktur zu kompensieren. Das ist prinzipiell nicht die schlechteste Herangehensweise. Leider sieht man in der Praxis immer wieder, dass die Prozesse dann so starr sind, dass sie wenig Raum für Experimente abseits von Produkten, Release und Planung lassen. Und das kann sich langfristig auswirken. Denn dann kann die Kreativität auf der Strecke bleiben, was sich reduzierter Motivation und langsamerer Ausführung äußern kann.
Wer nicht regelmäßig experimentiert, läuft Gefahr seine Strategie nicht zu hinterfragen und neue Ideen zu generieren. Und das kann schnell dazu führen, dass die Konkurrenz und der Markt einen überrollen.
Aus diesem Grund stelle ich mir heute ein kleines Tool vor, mit dem ihr einfach dafür sorgen könnt, dass ihr regelmäßig die Kreativität eurer Mitarbeiter mit kleinen Experimenten anzapfen könnt – die sogenannten Continues Hacktivities.
Hacking cultures
Eine beliebte Methode, um Innovationen zu fördern, kennt wohl jeder: Hackathons. Mit Pizza, Kaltgetränken und Schlafsäcken bewaffnet, treffen sich Entwickler, Producer, Designer und alle anderen, die mitmachen wollen, übers Wochenende und erzeugen so viel Code wie es geht. Mit viel Energie und Motivation wird dann innerhalb von 1-2 Tagen oft ein brauchbarer POC (Proof of Concept) oder sogar ein MVP (Minimal Viable Product) erzeugt. Die Mitarbeiter sind aus dem Tagesgeschäft herausgenommen und können sich so voll und ganz auf die Entwicklung konzentrieren. Und ganz nebenbei fördert man Innovation und Kreativität, vernetzt die Mitarbeiter besser und schafft ein besonderes “Wir”-Gefühl, welches oft einen langfristigen, positiven Effekt auf die Teams im Unternehmen hat. Zusätzlich können sie helfen, Mitarbeiter zu binden und die Zusammenarbeit zwischen Teams zu verbessern.
static vs dynamic hacking
Aber Hackathons sind nicht immer die Lösung. Denn nicht jeder Mitarbeiter ist begeistert davon, das Wochenende fernab seiner Familie, Freunde oder der Playstation zu verbringen, um für den Arbeitgeber Produkte zu basteln.
Eine Alternative dazu sind Hacksprints (oder Hackweeks, wie beispielsweise im Spotify Modell). Die Idee: In regelmäßigen Abständen werden die Sprints nicht mehr mit User Stories verplant, sondern mit Ideen aus einem Hack-Backlog. Den Entwicklern wird frei überlassen, woran sie arbeiten, einzige Bedingung: Es muss einen Mehrwert für die Kunden und/oder die Firma haben. Dies ermöglicht es, praktisch während der Arbeitszeit zu hacken, was die Akzeptanz, besonders von Eltern, erhöhen kann. Die Herausforderung hier (wie übrigens auch bei Hackathons, die unter der Woche stattfinden): Die Mitarbeiter können leichter durch das Tagesgeschäft abgelenkt werden. Ein wichtiger Support Request, eine Nachfrage der Accounting-Abteilung, eine kurze Bitte eines Kollegen, und schon ist man wieder in seiner normalen Arbeit.
Und beide – Hackathons und Hack Sprints – haben noch weiteren einen gemeinsamen Nachteil: Sie sind statisch. Das heißt sie
- finden an einem fixen Datum statt, das sich selten verschieben lässt.
- binden eine große Anzahl an Mitarbeitern. Bei Hacksprints ein oder mehrere Teams. Bei Hackthons unter Umständen große Teile der Firma.
- bedürfen einer größeren Vorbereitungszeit. Um Projekte nicht zu gefährden, bedarf es einer sorgfältige Zeit- und Ressourcenplanung
Besonders durch die aufwändige Planung und das Binden von Ressourcen kann es schnell zu Widerständen gegen statische Hack-Ereignisse kommen. Besonders, wenn die Vorteile dieser Ereignisse nicht verstanden werden und nur der Blick auf die Fertigstellung von Projekten gerichtet wird.
Auch kann es passieren, dass sich plötzlich Widerstände regen, wenn ihr regelmäßige Hacksprints einführen wollt. Gerade wenn ihr gerade anfangt, das Mindset in eurer Organisation hin zu einer stärkeren Experimentier-Kultur zu entwickeln, können schnell Benken kommen, dass Entwickler zwei Wochen lang nicht am “eigentlichen” Produkt arbeiten, viel zu lang sei. Und diese Bedenken muss man anerkennen. Veränderung brauchen manchmal eben Zeit.
Continues Hacktivites
Aus diesem Grund haben wir Continues Hacktivites entwickelt. Das Prinzip dahinter ist ganz einfach: Anstatt Hack-Activitäten zu einer bestimmten Zeit im Jahr zu planen, erlauben Hacktivities das Hacken zu jeder Zeit, quasi dynamisch und kontinuierlich.
Um den Nachteilen von Hack-Sprints oder Hackthons entgegenzuwirken (intensivere Planung, komplizierte Einführung), beschränken sich Hacktivities auf maximal drei Tage. Die kürzere Zeitspanne ermöglicht, Hacktivities jederzeit durchzuführen. Denn drei Tage sind immer drin, da es in jedem Projekt zu kurzfristigen Ausfällen von Mitarbeitern durch Urlaub, Krankheit oder andere Dinge kommen kann. Ein guter Projektmanager hat solche Fehlzeiten schon mit eingeplant, und damit können die Hacktivites laufende Projekte nicht gefährden. Das bedeutet, dass sie keinen signifikanten Einfluss auf die Entwicklungsgeschwindigkeit der Teams haben.
Zusätzlich ist die Anzahl der Teilnehmer einer Hacktivity auf drei beschränkt. Während bei Hacksprint und Hackthons üblicherweise eine größe Anzahl an Entwicklern teilnimmt (und in dieser Zeit nicht an Projekten arbeiten können), hilft die Reduzierung der Teilnehmer zusätzlich das Risiko auf laufende Projekte zu minimieren.
Eine Hacktivity kann also über 3 Tage mit bis zu 3 Mitarbeitern laufen. Deswegen können sie auch manchmal als “3×3 Hack-Activity” bezeichnet werden.
Übrigens beschränkt sich die Job Family der Teilnehmenden nicht auf Engineering. Jede andere Job-Function (Design, Product, Program Management etc.) kann eine Hacktivity vorschlagen oder an ihr teilnehmen.
How does it work?
Bevor du mit Hacktivities startets, solltest du eine vernünftige Umgebung aufgebaut haben, um für diese Mini-Projekte zu pitchen. Denn Ziel ist es ja, die Kreativität in deiner Organisation zu fördern, und das geht eben nun mal am besten gemeinsam. Als guten Ablauf für Hacktivites hat sich in der Praxis folgendes 5-Punkte Modell bewährt.
- Pitch
Als erstes kommt es auf einen guten Pitch an. Dieser sollte schriftlich nach einem einfachen Schema erfolgen. Titel, Idee, Support reichen in den meisten Fällen schon aus. Wichtig ist, das es kurz sein sollte. Denn wir wollen ja für ein 3-tägiges Experiment nicht zwei Wochen Evaluierung betreiben. Auch hier sei noch einmal die Betonung auf das Wort Experiment gelegt. In der Natur der Sache liegt es, dass man mit einer hohen Unsicherheit startet. Die Idee steht im Vordergrund, nicht die Planung.
Am besten erfolgt der schriftliche Pitch über ein Medium, das alle Leute sehen können. Nutze Foren, Chat groups, Mailinglisten – Hauptsache der Pitch erreichte eine große Anzahl von Leuten. Ziel des Pitches ist es, das Thema der breiten Masse vorzustellen und Begeisterung zu wecken.
Zusätzlich hat es sich als nützlich erwiesen, wenn der Pitch in einem Meeting vor einer größeren Menge erfolgt. Dies ermöglicht schnelle Rückfragen. Dabei sollte der Pitch selbst nicht länger als 5 Minuten dauern und auch die Fragerunde auf 5 -10 Minuten limitiert sein. Andernfalls kann es passieren, dass die Idee zerredet wird. Und genau das wollen wir ja nicht. Denn es geht darum, Dinge auszuprobieren, von denen wir noch nicht wirklich wissen, ob sie am Ende funktionieren.
- Plan
Nachdem der Pitch klar ist und das Team sich gefunden hat (max 3), dann wird es Zeit die Hacktivity zeitlich zu planen. Im Prinzip sollte man jede Zeit starten können, dann die Idee hinter der kurzen Zeitdauer ist es ja, dass Mitarbeiter immer für einen Zeitraum von drei Tagen ausfallen können und dies keinen Einfluss auf das Tagesgeschäft haben sollte. In der Praxis mag das anders aussehen. Je nach Business kann es Zeiten geben, in denen diese Regel nicht immer einzuhalten ist. Zum Beisoiel wenn tatsächlich geschäftsschädigende Gründe dagegen sprechen, beispielsweise wenn du dich mitten in der Cyberweek mit einem durch Krankheit stark reduzierten Team befindest. In solch einem Fall ist das Management gefragt den schnellstmöglichen Zeitpunkt zu finden, an dem die Hacktivity starten kann. Wenn du (als Management) nicht bereit bist, die Idee voll und ganz zu unterstützen, dann wird es immer eine Ausrede geben, warum man nicht mit dem Experiment starten kann, und dann wird die ganze Idee nie funktionieren.
In der Regel wird es aber kaum Gründe geben, nicht sofort oder wenigstens zeitnah zu starten (zum Beispiel direkt nach dem Ende des laufenden Sprints). Und das ist auch wichtig. Denn wenn die Idee zu lange liegt, kann schnell die Motivation schwinden. Außerdem neigen Menschen dazu, mit größerem Abstand die Ideen immer kritischer zu betrachten.
Also ran an die Idee, solange sie noch heiß ist!
- Execute
Im dritten Schritt wird dann die Hacktivity ausgeführt. Um wirklich effektiv und konzentriert an der Idee arbeiten zu können, empfiehlt es sich, eine Umgebung zu schaffen, in der alle Beteiligten möglichst nicht abgelenkt werden. Meistens ist es am geeignetsten, wenn sich alle an einem Ort versammeln. Das Büro bietet sich dafür an. Ablenkende Faktoren im Homeoffice wie Haushalt, Postboten oder Kinder fallen dann weg. Aber auch das kann im Einzelfall anders sein. Schau einfach, was für die drei Mitarbeiter am besten geeignet ist. Wichtig ist allerdings, dass es schnelle Kommunikationswege gibt, denn drei Tage sind nicht lange und sollten effizient genutzt werden.
Von Management-Seite kann es helfen, wenn du die ersten Hacktivities unterstützt, indem du ab und zu vorbeischaust und “Hallo” sagst. So kannst du nötige Trigger geben, falls sich die Gruppe verrannt hat und nicht nicht mehr richtig weiter kommt. Aber Vorsicht: Halte dich so weit wie möglich zurück. Denn du willst ja die Ideen deiner Mitarbeiter haben und nicht deine eigenen umsetzen.
Nach drei Tagen, egal was passiert ist, ist die Hacktivity vorbei. Achte darauf, dass dies auch wirklich der Fall ist, und dass nicht plötzlich mehrere Wochen aus dem Projekt werden. Dies hat zwei Gründe:
Zum einen wird die Akzeptanz für die Hacktivites beim übergeordneten Management immer mehr sinken, wenn du den Zeitraum regelmäßig beziehst, denn dann ist es mit der Planungssicherheit vorbei.
Zum anderen werden deine Hacktivites mit der Zeit immer größer werden. Denn wenn man weiß, dass andere mehr Zeit hatten, dann plant man in der Regel auch mehr Zeit ein. Die Ideen werden größer und größer, und damit steigt auch das Risiko, dass am Ende gar nichts geschafft wird.
Also, in der Kürze liegt die Würze!
- Present
Nach erfolgreicher Hacktivity ist es natürlich wichtig, die Ergebnisse entsprechend zu demonstrieren – und zwar auf großer Bühne. Denn wenn du das Mindset in deiner Organisation hin zu einer Experimentier-Kultur ändern möchtest, dann solltest du auch allen zeigen, dass es dir damit ernst ist. Also ab mit den Präsentationen ins All-hands oder ein anderes Organisations- oder Abteilungsweites Meeting.
Und auch dann – oder gerade besonders dann – wenn nach drei Tagen nicht viel geschafft wurde, sollte die Idee präsentiert werden. Denn so ist das nun einmal mit Innovation und Experimenten, sie gehen halt manchmal schief. Edison’s Glühbirne brannte schließlich auch nicht gleich am ersten Tag (glaube ich zumindest).
Willst du ein kreatives Mindset schaffen, dann musst du demonstrieren, dass der Misserfolg genauso wichtig ist wie der Erfolg. Denn nur aus Fehlern lernt man. Also gibt jeder Hacktivity den gleichen Raum.
- next steps
So, die Hacktivity war ein Erfolg – ein kleiner Prototype steht, ein entwickeltes Konzept sieht vielversprechend aus oder der Klick-Dummy hat im User-Experiment die vermuteten Thesen bestätigt. Und nun? Zurück zur Tagesordnung? Natürlich nicht. Denn jetzt kommt ein weiterer wichtiger Schritt. Jetzt geht es darum, aus der bestätigten These ein Produkt zu entwickeln. Das solltest ihr vom Management natürlich unterstützen. Stellt ein kleines Team zur Verfügung, welches die Ergebnisse weiter untersucht und tiefer in die Materie einsteigt. Nehmt einen Produktmanager, Business Analysten, Projektmanager – was auch immer ihr braucht – und entwickelt die Idee weiter. Mit etwas Glück habt ihr gerade eure zukünftige Cash-Cow vor der Nase. Und genau das wird euer Team motivieren weitere Ideen zu spinnen und in Hacktivites auszuprobieren.
Zum Schluss
So, das war’s auch eigentlich schon. Nicht kompliziert, oder? Aber wer sagt denn auch, dass es kompliziert sein soll? Manchmal können eben auch ganz kleine Dinge einen großen Effekt erzielen.
Hacktivities (wie natürlich auch andere Hack-Aktivitäten) können euch helfen, mehr Kreativität im Team zu erzeugen und schneller bessere Produkte für eure Nutzer zu bauen.
Egal wofür ihr euch entscheidet: Vergesset nicht, wie wichtig es ist, den Innovationsgeist in eurer Abteilung, Organisation, Business Unit oder Firma aufrechtzuerhalten. Innovationen sind das, was euch langfristig von der Konkurrenz unterscheidet. Ein starkes Brand allein kann euch nicht für immer im Business halten.
Was noch wichtig anzumerken ist: Das ändern einer Kultur braucht Zeit. Seid nicht gleich frustriert, wenn nicht jeder sofort auf die Idee der Hacktivity anspringt. Das Ganze braucht Zeit, Geduld und eine ordentliche Portion Changemanagement.
Wenn Hacktivities für euch interessant klingen, dann probiert es aus. Ich bin gespannt, wie es bei euch funktioniert!
