If you want to teach a Scrum team how to deliver small chunks of working software, have a hackathon.

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:

Sometimes, people simply don’t want to do what you want or need them to do. http://johnstepper.com/2013/02/02/applying-the-fun-theory-at-work/ but they will perform greatly on things they want to do even, if the two are one and the same.

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…"

 http://www.deepfun.com/fun/2013/01/the-fun-theory-in-education/"

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