Hackathons : Paving The Desire Path

Desire Path

There is a very interesting Urban Planning concept called "Desire Path". The idea is pretty simple. People walking through a park will take the shortest or easiest routes. This is regardless of whether this path is paved or not. Eventually, due to erosion from the foot traffic the path will become visible. The designers can choose to ignore this or make this path official by paving it. Paving the desire path is a great design decision (most of the time). That is probably the reason behind the Lean and Agile UX communities having embraced this concept. If the user keeps going to the same part of your app over and over again, and it takes 4 clicks to get there, provide them a shortcut in the next release that makes it one click. Twitter making hashtags and @ mentions official features is another example of this. As Twitter users started communicating through hashtags and @ mentions, Twitter saw the desire path and not only made it official, but enhanced their use.

What does this have to do with hackathons?

My company has a great tradition of doing two hackathons per year. We call these events 48 hours as developers have 2 days to build anything they want. The projects could be product enhancements, internal tools, automation of processes, even apps to decide where to go for lunch. The results are often amazing. It is incredible that when left to their own accord, how creative and productive developers can get.  There have been entire features that have been built in 2 days that have eventually made it into the product. In fact, 48 hours is looked upon as a great way to get product innovation and ideas from the folks who are knee deep in the code every day.

In our latest hackathon, a few developers from one of our teams submitted and completed their 48 hours projects.  One of the projects also won an award at the closing ceremony for 48 hours. A small team of developers was able to build an award-winning feature in 2 days. Here is the interesting part of it though - The average time it takes for the team these developers belong to, in order to complete a feature, is over 200 days. In fact 2 days is close to a tenth of the time it takes for the team to complete user stories. A lot of this difference is due to the processes that the team has in place. There is definitely some factor of time spent exercising quality control for a production quality feature. I would argue though, that most of it is due to the processes that the team follows.

During hackathons, developers are forging a desire path. This is the ideal process they would like to follow, instead of the process that has been paved for them.

During hackathons, developers are forging a desire path. This is the ideal process they would like to follow, instead of the process that has been paved for them. What is interesting is that our teams have a lot of liberty to adjust and change their processes. Many a time the paved process path, has been created by the team itself.  They have full control over branching strategy, testing policies, definitions of done and to a good extent technologies they can use. For some reason though the hackathon desire path does not match the paved daily process path.

Paving The Desire Path

In my previous life, I am proud to have led a team that won every hackathon that it presented in. You can see their happy faces in the picture below. 

I cannot take any credit for their success as I did not write a single line of  code or test for these projects. But I did notice that they were doing a few things that were different from our "paved" process. Every time I would pick one of the things, for example, using slack to collaborate, when our company itself was not using it and make it a part of our daily process. The team(as enlightened as they were) would catch on to the trend and start incorporating other things that worked for them into their daily work. This would often mean removing unnecessary process. I clearly remember our prototype and product UI code merging and becoming the same soon after a hackathon where our UX designer had actively paired with one of our developers for two days. The team (with a slight push from me) paved the desire path that they were travelling.

Hackathons for me, as a manager, became not just celebrations of how good our developers were, but also retrospectives on our process. 

This does not mean that the two processes became the same. They just became more alike. Hackathons for me, as a manager, became not just celebrations of how good our developers were, but also retrospectives on our process. We as a team, sometimes consciously and other times, sub-consciously learned from our hackathons, both in terms of the processes we should use(or discard) and the technologies we should use(or discard). Our hackathons were often proof of concepts that with some modifications made it to the product itself. It allowed our engineers to play with technologies that get the job done the fastest and then incorporate them into our product.

Since our 48 hours event is very developer focused, the managers and team leads, usually continue doing their daily jobs as usual. Due to the fact that not everyone is participating, "official work" still happens. Stand-ups, meetings and other day-to-day activities are still going on for the teams.  I think this is a great missed opportunity. Team Leads and managers should be able to observe the team's behaviour during these hackathons. They should then encourage the team to behave in similar ways during their everyday work. Any organization that invests in hackathons, should look at this as a learning opportunity and a retrospective on their process. What process do the developers follow when they are most productive and have cycle times that are 100 times shorter? How far away is our current process from that and what are the tweaks that we can make to bring the two closer?

Hackathons reveal your team's desire path. Make it official! Pave It!