What is it about hackathons that makes delivering working
software in a short period of time possible? Why is it so much more effective
than all the formal coaching and training that are aimed to provide developers
with the same set of skills for accomplishing the same goal?
Simple: a hackathon is a powerful tool to demonstrate first-hand
production of a small chunk of working software. Why? Because it holds the
proper psychological aspects that leads developers to perform all those tips
and tricks for producing fast working software's without constraints, combined with
a lot of fun and motivation and without anyone telling them to use this
practice or another.
Most of the times when, as an agile coach, we are engaged in
Agile / Lean implementation inside an organization we, usually hear developers
or team leaders, say that it's impossible to divide a big user story into
smaller ones ! It’s that common and well, that natural to think this way when
you are just starting to adopt an agile mindset. "It’s impossible"
they say "how can we even think of such an impossible thing?"
The resistance can be very strong, and as a coach you know
that you have to face these issues and you need to get those developers from
the theory the practice as fast as you can. We all know that learning how to split big
chunks of work takes time, it's not an easy thing to learn or to get used to. There
are a lot of sides to this division and a few solutions are typically suggested.
The absence of this skill, the mindset or the understanding
of the value in splitting big chunks of work into smaller working chunks can
come in many shapes and colors, some of which I have previously detailed here. There are also plenty
of ways to deal with this issue. But sometimes it’s not enough, or sometimes
after we dealt too much with the theoretical side we might find it difficult to
get practical, to ’walk the walk’ when it comes to actual doing.
Here's where the hackathon can come to our rescue. Although
hackathons were not originally conceived in order to deal with these types of
issues, having participated in several hackathons myself led me to realize that
a hackathon is not only a powerful tool for innovation, it's also an amazing way
to demonstrate the point of producing working software in a relatively short
period of time, using all the tips and trick we aim to teach Agile teams anyway,
such as: peer programing, direct and frequent communication, reviewing small chunks
of code, working demos, and of course the ability to divide the work into testable
working chunks. These tools become
relevant simply because if you fail to use them, you will not be able to
produce working software in 24 hours and be ready for a good pitch.
But first, what is a hackathon?
A hackathon is an event, typically lasting between 24 hours
to few days, in which programmers and others collaborate intensively on a
software project to create a piece of working software in a relatively short
period of time. (Wikipedia)
To put it simply,
it's an amazingly innovative short period of time, in which people volunteer to
do what they like to do (which in our case is coding). During this time, you
decide on a project you would like to do, choose your team, collaborate
intensively (’hack-eat-sleep’) in order to be able to demo a working product by
the time the hackathon’s deadline is reached.
What is it about hackathons that makes delivering working
software in a short period of time possible? Why is it so much more effective
than all the formal coaching and training that are aimed to provide developers
with the same set of skills for accomplishing the same goal?
It’s because a hackathon, intentionally or not (probably
not), holds a lot of psychological aspects that lets individuals overcome the
organization’s control and pressure over producing working software. It releases
us of our commitments and sets innovation free in a way that makes anything
look possible. You don’t have to develop these things out of someone else’s
backlog.
The "when you don’t think of what the other needs
for a minute" factor: No one will tell you what to do, or how to do
it, and you don’t care about them anyway. You are your own boss, doing the
things you want and love to code.
You don’t need to start estimating, or sizing up your tasks.
You don’t have to follow someone else's ideas, your job
security is not dependent on your success, or more importantly your failure in
this task, your boss is not part of it and has nothing to do or say for or
against it -- and whether it will work or not is entirely up to you. And the best thing is, you pick the idea that
you have a passion for, and you are all full of motivation to do what you love
(code) and turn your idea into a reality in your own pace.
The pressure of 24 hours, or any other short and near
deadline acts as a catalyst to find the right techniques to make it happen.
The prize? Well, it does play a significant role (something
that I have a lot to say about, but I’ll leave that to another time). However,
I think that it is less significant compared to the inner motivation and
pleasure a developer gets out of it.
This autonomy to decide, fail, be your own boss (with a
dead line and a prize) can easily drive developers to the obvious solutions which
we have been trying to teach them to adopt as everyday practices all along:
divide, develop, test, demo.
These techniques were initially developed from this exact
line of thinking – by people who hacked their way, enjoyed what they were doing
and were under pressure to produce something that works in a short period of time
(for whatever reason). They simply came to realize that these practices are a
hell of a tool to achieve this.
The “There’s nothing like hands on experience to feel
how it’s like” factor: you can never
know how something will work if you don’t try it yourself, and you can never
get that feel for it from mere
theoretical discussions.
These are the techniques that have proven to be productive
in the past, which we are trying to teach in an environment that does not or cannot
immediately acknowledge their value (in different degrees of acceptance). An
environment where these techniques were never or almost never tried (or failed
due to lack of skill), or were never sold to them in a convincing way or that encounter
actual resistance. You need to convince
an organization that it will see ROI without actually having them experience
it, i.e., convince it on theoretical grounds. It is subject to criticism and
the discussion becomes theoretical. In these situations, when we are trying to
teach these skills to an organization, it’s easy to lose the natural environment
that motivated them to look into the matter in the first place. Even when we do
get a chance to implement the skills in practice, it’s under the pressure of
the need to deliver business value, product constraints, budget issues, time limitations
and more.
It will be much easier to try using these skills in a
safe and welcoming environment like a hackathon. Sometimes, trying something in
its right context brings powerful learning insights which will allow the individuals
who experience them to apply these insights in other contexts, which might be
more complex or harder to understand at the beginning. The person who
experienced it felt how it is and how it should be, so they can move on from
there to scenarios where it would have been less likely to happen if they
hadn’t practiced it before.
Just try having a hackathon: it will do the convincing on
its own. The rest will be easier.
Somehow when developers are part of a hackathon, suddenly they do manage
to produce working, quality software in 24 hours. They manage to demo it and
they manage to win. They also gain insights regarding techniques they suddenly
realized they had used, all the practices that they were probably dead against earlier:
peer programing (“As a team leader I’m telling you it’s a waste of our time”),
small code reviews ( “I don't believe in that”), demo at the end of each sprint (“Impossible”). We just need to help them
connect the dots and show them that what they actually used was "small
chunks", MPV, small code reviews, peer programing, early feedback and
more… and it was possible. That’s all there is to it.
The “fun (theoretical)” part:
Then what?
“…something as simple as fun is the
easiest way to change people’s behavior for the better. Be it for yourself, for
the environment, or for something entirely different, the only thing that
matters is that it’s change for the better.”~ Volkswagen
Everyone wants to have fun. During a hackathon, fun is a
big deal. This does not mean that we should make a joke of it or bring clowns. Fun
is sometimes as simple as enjoying what you do. Artists and athletes do great
things since they enjoy them. And they are not the only ones. Children enjoy drawing,
playing. Developers enjoy developing, they can spend hours doing it if it’s
interesting enough. Hacking for their own idea is enjoyable, and will lead them
to use all of those wonderful techniques that will encourage them to get it
done well and produce a working product. A hackathon is a great stage for this mindset.
"Full engagement in any pursuit
that is meaningful to the individual may not sound like a prescription for fun.
But it is, because it tends to lead to what is called flow: a sense of focusing
so fully that we lose sense of time, discomfort, even self. Artists and
athletes aren’t the only ones who experience flow, children easily merge into
this state. A child may experience flow while engaging in make-believe,
drawing, swinging on a backyard swing, playing the guitar, fixing a bicycle,
even organizing a shelf…"
The “It’s all about bringing the right mindset“ factor
If this exists in your organizational culture naturally you
are lucky. Most companies don’t have it. If you don’t have it you can create
it. Have a hackathon, let people feel a sense of creation and on the way get
them to realize the value of good practices, and why they actually work.
Either way, even if you do try to hold a hackathon it won’t
work if the mindset is not there.
I did see few hackathons fail just because the organization
managed to ruin it all. Statements like “we are having a hackathon this weekend
to close all leftover customer bugs”, or “in this hackathon you need to pick up
ideas from the product backlog” or “my team will not be part of the hackathon
since they didn’t manage to finish the sprint backlog on time” or “there are
urgent issues form customers, you can go back to the hackathon when you’re done
dealing with them.”
If these statements represent your organization’s mindset,
it’s more than likely that you will never be able to create the right culture
for delivering small chunks of working software anyway.
Pics : from @Sisense Hackathon 2014
Things developers say about hackathons that I have
collected during several hackathons(Retrospective hackathon quotes:):
·
We realized in such a short time
what we need to do and managed to produce
something that works.
·
The time flew by so fast. I never
felt the end of the day come so fast until now.
·
It was sooo much fun, connecting
with people , working together
·
It made me love what I did
·
Finally , I have the freedom to work
on what I have always wanted. It’s frightening too, since I need to prove I can
do it. This raises my adrenaline through the roof.
·
Everyone was helping everyone
·
Working alongside Joe I realized
that we were constantly developing together, and it was fast, fun and very
productive
·
I learned a lot from what Joe and Max
were doing, thinking and planning.
·
There were no context switches, we
managed to start and finish something in 24 hours. And we even had time to take
brakes.
·
It felt very creative
·
We managed to use our own minds to discover
better solutions and we didn’t have to get anyone’s approval.
·
When you choose to do something, it’s
completely yours.. it was not handed to me by anybody else. It was mine,
therefore I could make sure it will be delivered.
·
I could see different thinking
patterns other than my own implemented, changed and changed again. We actually
built something using 3 different minds.
·
We thought about our idea a few days
earlier and we were busy thinking about it… so when we finally started coding
we could test our assumptions. We even changed them to better fit what reality
showed us to be a better solution for what we wanted to achieve.
·
We can actually show something that
is DONE
·
I didn’t know what I was doing here
in the first place and what I could contribute, until I had an idea and then...
time just flew by and we coded and coded until it was done.
·
The fact that we had only 24 hours
and didn’t have to stretch the thing out for an entire week was a good for me
-- to start and finish something I can show to everyone without getting bored.
·
The results were amazing. To learn
that there are so many things we can develop in such a short time, I couldn’t
believe it.
·
I loved being part of a team,
working closely, really closely – coding together, testing, reviewing the code.
·
Finally a chance to get out of the
routine of fixing bugs or maintaining code or coding for someone else.
·
It was better than a company fun day.
I felt connected.
·
It was fun
