Many companies try to compensate for increasing (product) complexity with processes and structure. In principle, this is not the worst approach. Unfortunately, in practice we see time and again that the processes are so rigid that they leave little room for experimentation beyond products, releases and planning. And this can have a negativ long-term effect. Creativity can then fall by the wayside, which can result in reduced motivation and slower execution.
If you don’t experiment regularly, you run the risk of not regularly scrutinising your strategy and generating new ideas. And that can quickly lead to the competition and the market overrunning you.
That’s why today I’m introducing a small tool that you can use to ensure that you regularly tap into the creativity of your employees with small experiments – the so-called Continues Hacktivities.
Hacking cultures
Everyone knows a popular method of promoting innovation: hackathons. Armed with pizza, cold drinks and sleeping bags, developers, producers, designers (and anyone else who wants to take part) get together over the weekend and create as much code as they can. With a lot of energy and motivation, a usable POC (Proof of Concept) or even an MVP (Minimal Viable Product) is often created within 1-2 days. The employees are taken out of the day-to-day business and can concentrate fully on development. In addition, innovation and creativity are promoted, employees are better connected and a special “we” feeling is created, which often has a long-term, positive effect on the teams in the company. They can also help to retain employees and improve collaboration between teams.
static vs dynamic hacking
But hackathons are not always the solution. After all, not every employee is enthusiastic about spending the weekend away from their family, friends or Playstation to tinker with products for their employer.
An alternative to this are hack sprints (or hack weeks, as in the Spotify model, for example). At regular intervals, sprints are no longer planned with user stories, but with ideas from a hack backlog. The developers were free to decide what they wanted to work on. the only condition: It must have added value for the customer and/or the company. This makes it possible to hack during working hours, which can increase acceptance, especially from parents.
The challenge here (as with hackathons that take place during the week, by the way): Employees can be more easily distracted by day-to-day business. An important support request, a query from the accounting department, a quick request from a colleague, and you’re back to your normal work.
And in addtion, both hackathons and hack sprints have another common disadvantage: they are static. This means they
- take place on a fixed date that can rarely be moved.
- involve a large number of employees. In the case of hack sprints, one or more teams. In the case of hackthons, possibly large parts of the company.
- require a lot of preparation time. Careful time and resource planning is required to avoid jeopardising running projects
The time-consuming planning and commitment of resources in particular can quickly lead to resistance to static hack events. Especially if the benefits of these events are not understood and the focus of the management is only on the completion of projects.
It can also happen that resistance suddenly arises if you want to introduce regular hack sprints. Especially if you are just starting to develop the mindset in your organisation towards a stronger culture of experimentation, you may quickly encounter concerns that developers not working on the “actual” product for a fortnight is far too long. And these concerns must be recognised. Change sometimes takes time.
Continues Hacktivites
For this reason, we have developed Continues Hacktivities. The principle behind it is very simple: instead of planning hack activities at a certain time of the year, hacktivities allow hacking at any time, dynamically and continuously, so to speak.
To counteract the disadvantages of hack sprints or hackthons (more intensive planning, complicated introduction), hacktivities are limited to a maximum of three days. The shorter time span allows hacktivities to be carried out at any time. After all, three days is always possible, as employees can be absent at short notice in any project due to holidays, illness or other reasons. A good project manager has already planned for such absences, so hacktivities cannot jeopardise ongoing projects. This means that they have no significant impact on the development speed of the teams.
In addition, the number of participants in a hacktivity is als limited to three. While a large number of developers usually take part in hack sprints and hackthons (and cannot work on projects during this time), reducing the number of participants also helps to minimise the risk to ongoing projects.
A hacktivity can therefore run over 3 days with up to 3 employees. This is why they are sometimes referred to as “3×3 hack activities”.
Incidentally, the job family of participants is not limited to engineering. Any other job function (Design, Product, Program Management, etc.) can propose or participate in a hacktivity.
How does it work?
Before you start with Hacktivities, you should have set up a proper environment to pitch for these mini-projects. After all, the aim is to promote creativity in your organisation, and the best way to do that is together. The following 5-point model has proven to be a good process for hacktivities in practice.
- Pitch
The first thing you need is a good pitch. This should be in writing and follow a simple structure. Title, idea and support are sufficient in most cases. The important thing is that it should be short. After all, we don’t want to spend two weeks evaluating a three-day experiment. Once again, the emphasis should be on the word experiment. It is in the nature of things that you start with a high degree of uncertainty. The idea takes centre stage, not the planning. The written pitch is best made via a medium that everyone has access to. Use forums, chat groups, mailing lists – the main intent is that the pitch reaches a large number of people. The goal is to present the topic to the general public and generate enthusiasm.
It has also proven to be useful if the pitch is made in a meeting in front of a large crowd. This allows for quick questions and anwers. The pitch itself should not last longer than 5 minutes and the Q&A session should also be limited to 5 minutes. Otherwise, the idea may be talked over. And that’s exactly what we don’t want. Because the point is to try things out that we don’t really know yet whether they will work in the end.
- Plan
Once the pitch is clear and the team has been formed, it’s time to plan the hacktivity schedule. In principle, you should be able to start at any time, because the idea behind the short duration is that employees can always be absent for a period of three days and this should have no impact on day-to-day business. In practice, things may look different. Depending on the business there may be times when this rule cannot always be adhered to. For example, if there are actually reasons that are creating business risks, such as if you are in the middle of Cyberweek with a team that is severely reduced due to illness. In such a case, it is up to the management to find the fastest possible time for the hacktivity to start. If you (as management) are not prepared to fully support the idea, then there will always be an excuse as to why you can’t start the experiment, and then the whole idea will never work.
However, in most cases here will be no reasons not to start immediately or at least promptly (for example, directly after the end of the current sprint). And that is important. After all, if the idea lies around for too long, motivation can quickly dwindle. What’s more, people tend to take a more critical view of ideas the longer they wait.
So get to work on the idea while it’s still hot!
- Execute
The hacktivity is then carried out in the third step. In order to be able to work on the idea in a truly effective and focussed manner, it is advisable to create an environment in which all participants are not distracted. It is usually best if everyone gathers in one place. The office is a good place for this. Distracting factors in the home office such as household chores, postmen or children are then eliminated. But this can also be different in individual cases. Just see what works best for the three employees. However, it is important that there are fast communication channels, because three days are not long and should be used efficiently.
On the management side, it can help if you support the first hacktivities by popping in and saying hello from time to time. This way you can provide the necessary triggers if the group gets lost and can no longer progress properly. But be careful: hold back as much as possible. After all, you want to have your employees’ ideas and not implement your own.
After three days, no matter what has happened, the hacktivity is over. Make sure that this is really the case and that the project does not suddenly turn into several weeks. There are two reasons for this.
On the one hand, the acceptance of hacktivites by higher-level management will decrease if you refer to the period regularly, because then the planning security will not exist anymore.
On the other hand, your hacktivities will get bigger and bigger over time, if people think it is not a big deal to extend. After all, if you know that others have had more time, then you generally plan more time. The ideas get bigger and bigger, which increases the risk that nothing will get done in the end.
So, brevity is the spice of life!
- Present
After a successful hacktivity, it is of course important to demonstrate the results accordingly – on a big stage. Because if you want to change the mindset in your organisation towards a culture of experimentation, then you should also show everyone that you are serious about it. So take your presentations to an all-hands or another organisation- or department-wide meeting.
And even – or especially – if not much has been achieved after three days, the idea should be presented. Because that’s the way it is with innovation and experiments – sometimes they go wrong. After all, Edison’s light bulb didn’t light up on the first day (at least I don’t think so).
If you want to create a creative mindset, you have to demonstrate that failure is just as important as success. Because you only learn from your mistakes. So give every hacktivity the same space.
- next steps
So, the hacktivity was a success – a small prototype is ready, a developed concept looks promising or the click dummy has confirmed the hypotheses in the user experiment. And now? Back to business as usual? Of course not. Now comes another important step. Now it’s time to develop a product from the confirmed thesis. Of course, you should support this from the management. Provide a small team to further analyse the results and delve deeper into the matter. Take on a product manager, business analyst, project manager – whatever you need – and develop the idea further. With a bit of luck, you’ll have your future cash cow right under your nose. And that’s exactly what will motivate your team to come up with more ideas and try them out in hacktivites.
In conclusion
So, that’s actually all there is to it. Not complicated, is it? But who says it has to be complicated? Sometimes even very small things can have a big effect.
Hacktivities (as well as other hack activities, of course) can help you generate more creativity in your team and build better products for your users more quickly from pseudo-agile waterfall processes.
No matter what you choose: Don’t forget how important it is to maintain the spirit of innovation in your department, organisation, business unit or company. Innovation is what will set you apart from the competition in the long term. A strong brand alone cannot keep you in business forever.
Another important point to note is that changing a culture takes time. Don’t be immediately frustrated if not everyone jumps on board with the idea of hacktivity. It takes time, patience and a fair amount of change management.
If hacktivities sound interesting to you, then give it a try. I can’t wait to see how it works for you!
