Why every IT department should compete in a Hackathon

Opinion

Aug 30, 2017

Digital Transformation

Every IT department is trying to move from a slow moving operation to a fast, agile and finely tuned machine. It is very easy to write up a new vision statement, hire a few young UX designers and install a fluffy sofa. But how do you really move into a fast IT mindset as a new way of operating, without increasing the risk of failure. Encouraging your team to compete in Hackathons is a perfect way to experience the thrill of a fast IT ecosystem, without the risk of highly visible failure or incurring a huge cost. Competing in a Hackathon should be one of the first steps for this transition to a fast IT way of working.

We entered an IT team into a travel hackathon, and based on that experience we learnt more in those 40 hours about agile, fast IT than we could have ever learnt at any number of conferences.

Firstly, some background about our IT department. We are a mid size IT department, spread across 3 locations. Like every IT department, we have to continually do more with less. We have introduced agile methodology three years ago and now use either agile or waterfall methodology depending upon the project needs. Like all IT departments we continually try to get better in the areas of rapid prototyping, quickly developing a Minimal Viable Product (MVP), and releasing solutions with bugs still in them.

What we learnt

One key reason why we learn so much is that a 40 hour hackathon highlights the same problems an IT project may have, but since we are effectively doing a six month project in 40 hours, it accentuates any failures much more visually. Our key learnings which we can take back to IT are:

Do more, talk less

In day to day IT, it is too easy to keep talking about what is possible and effectively stall a project with theoretical presentations. Rather than talking about what could be possible, spend that time building a prototype and then you will know if it works or not, making all those presentations irrelevant.

Define architecture before a project starts

One should not be having major architectural discussions during a project. These decisions should be made at a “in principle” level prior to any specific project. If they are made at a project level, there is a risk of the decision not being strategic but rather tactical.

Focus only on the MVP

It is important to focus only on building a MVP first, and only once you have a MVP, then look at other features. This is for two reasons: firstly, until you have a MVP, you have nothing, so get that built quickly, secondly, in line with “Design Thinking” principles, the customer should define subsequent features, they need a MVP to accurately define what additional features are needed.

Communication is still critical

Clear communication about scope, delivery, status, is still absolutely critical. At one point we had our front end developers working on one table and the back end developers working on another table. To deliver a working solution in 40 hours, one cannot waste any time with vague directions. If a six month project had those same vague directions, one would waste much more time and money.

No replacement for skills

The hackathon team should consist of a front end developer(s), back end developer(s), scrum master and a UX designer. These are specialized and skilled roles. If the team is not proficient in these skills then it will be very difficult to deliver a solution.

Elapsed time is critical

During a 40 hour hackathon each team member is fully dedicated to the competition, resulting in an immediate response to a task or request (it is very inspiring to work in an environment where everyone is fully dedicated to the common task and we receive immediate responses to requests).

Back in IT, we are all multitasking, meaning that we need to wait “our turn” for someone to action our request. Realistically, we cannot expect everyone to action our requests immediately, but we need to put a time gate on the elapsed time from the time of the request to the action being performed. For example, if the task is 2 days in duration, we should expect a response within 5 elapsed days.

The right team attitude

Many times over a 6 month project, we tolerate dysfunctional behavior from a team member. This behavior within a 40 hour hackathon is toxic and the team would not tolerate it. It makes us question, why we tolerate this in a normal project.

Tips for your first hackathon

Prior to the event:

1. Design and order team hoodies. Nothing brings a team together like a team uniform. Have some fun with the design. We had bright green hoodies, as the event was based in Dublin.

2. Recruit for specific positions scrum master, Front End developer, back end developer, UX

3. Ask people to apply for positions, it’s a great way to see who is motivated.

4. Define the team communication tools, architecture, develop the storyboard, and understand the technical design of the relevant APIs

During the event:

1. Run the event as a series of 3 hour sprints.

2. Only focus on the MVP, until you have that working, park all other features

3. Have strict time limits on feature developments, if a developer doesn’t get it don’t by x hours, then move onto the next feature and eliminate that one if possible.

Post the event:

1. Present the lessons learnt back to your team,

2. Celebrate the great achievement

In conclusion

Just like firemen compete in competitions to hone their skills, your IT department needs to compete in Hackathons to fine tune their IT skills. In addition, it brings the IT professional back to the reason why they work in this profession – having fun building great solutions.

What is a Hackathon ?

A hackathon is an event where teams compete to develop the best solution (app, website, etc) based on a predetermined problem. Often, it is held over weekends, starting on Friday evening with “pens down” at mid Sunday afternoon. Winners receive cash prizes and / or entrance into subsequent innovation programs. There are usually about 30-50 teams, with 4-5 people in each team. Developers can come as a team, or teams can be formed upon arrival.

The host company should provide APIs to expose. By using these APIs, programmers can resolve the pre-determined business problem.