Hackathons with Remote Teams

As the workforce paradigm has shifted from predominantly in person to work from home, it has highlighted how adaptive technology has made us. Part of ensuring success in remote teams is finding ways to keep engagement up and supplement the human element of in-person interactions with solutions specific for what you are trying to achieve.

A hackathon when done right is a great way to spur interest from teams, and leveraging specific features of development tools can help bring back the human element to a remote development team. The concepts covered in the post will not be solely applicable to a remote hackathon, but is written as a holistic approach I have seen successfully applied.

Prior to starting an in-person or remote hackathon there are some items that are critical to ensure success. If you skip these items you can actually make it considerable more difficult for the developers when compared to an in-person hackathon. As a remote team you may already be struggling with engagement and having to overcome obstacles can exponentially compound engagement issues you may be facing.

Choosing your team

When selecting members of a team I like to take a similar approach to forming an Agile team, meaning finding a diverse group of engineers where you may have individuals that can be viewed as pillars in certain data domains, but also have some level of familiarity across the other areas required within the project. This will help to embody a concept of T Shaped team members where by the use of collaboration you help to cross-pollinate knowledge throughout the team. The desired end result is better preparing the team for success by selecting the right engineers and helps to collectively improve cross-functional skills within the team. If you were to form a team comprised of solely of senior Django developers for a NetChatOps deliverable you may be very successful in the middleware/web framework but could be setting yourself up for pain points on the integration of Django with orchestration tools or automation frameworks.

Designating Advisors

It is quite uncommon for everyone on a hackthon team to have all the knowledge they need at their disposal and you may find for specific items you may not have a team member that can help troubleshoot certain issues. You may also find a team that is comprised of mostly senior engineers which gives that team an unfair advantage. In both scenarios you may benefit from some of the senior engineers participating as advisors instead of contributors.

When running a hackathon with multiple teams designating a small group of advisors that are readily available to offer advice and guidance can help substantially with engagement. This group would be a set of engineers that have a deep understanding of the critical aspects of the technologies you are working with and are not participating in any specific team. These engineers should make sure their attention is locked to just the hackathon and not other priorities to ensure they are readily available to jump in at a moments notice to help a team out. For an in-person event this group should have a designated area where teams can drop in to ask for help. Remote and in-person events should have a dedicated meeting solely for the advisors that is shared prior to starting and should take advantage of breakout rooms as needed.

Defining Scope

This is very much a double-edged sword–on one side providing guardrails on what is to be developed prior to starting can help ensure you are able to make more informed decisions on planning, team structure, and increases the chances of delivering a working solution in the allotted time. However if the guardrails are too confining you may be limiting creative intuition. In a previous competitive hackathon there was a considerable amount of lead time for each team to form organically, discuss what ideas they had for the end product, and ensure all necessary infrastructure was in place prior to starting. In this scenario, the guardrails were demonstrating a working integration or extension to Nautobot. The scoring criteria was based on completeness, usage of new core features, documentation, and “special pizazz”. The minimal use of guardrails, but considerable time to plan allowed the team to really think out of the box and come to a great end solution.

Minimal guardrails should be paired with additional preparation time, whereas asserting firm guardrails and limited scope can also set a team up for success. Think of this as needing to eat a a giant ice cream sundae; both ways you are one bite at a time. The difference is the former gives the team the ability prepare, scoop, and portion those bites ahead of time so when it’s time to eat they only have to focus on eating. The latter may be a team receiving a pre-scooped & portioned sundae, still eating one bite at a time, but maybe the team wanted neapolitan with sprinkles instead of vanilla with syrup. In the end, the goal was achieved as both teams have full bellies and empty ice cream dishes.

Build Prerequisites

The most successful hackathons I have participated in had ALL external dependencies pre-built prior to starting. This may sound like a no-brainer, but in my experience has been a huge time suck for the team to set up small things like infrastructure hosting, CI, repositories, or even things as simple as meeting room or GIT repository. By eliminating this time suck the team can focus on working on the fun part of the hackathon and dedicate more time to the end deliverable not building the ice cream shop where their sundaes are made.

Stub Out Backlog

Now that you have your team formed, some rough idea on what you want to deliver, and dependent infrastructure built it’s time to throw some tasks on a backlog. For an in-person hackathon I’ve found it very beneficial to have a stack of sticky notes and some form of a board that I can organize in a kanban board fashion. For a hackathon, I typically keep the tasks more generic when compared to typical Agile backlog, the backlog is more meant to help identify who is working on what and any dependencies chains that may form. By providing this visibility, you reduce the chances of someone pulling a blocked task or not knowing what to work on next therefor value can more easily flow through pipeline.

In a remote hackathon I will substitute a tool like Jira or GitHub Projects in place of a physical backlog. When doing so, you should elect one person to help manage the backlog; for me, this is typically a team lead. This is where it starts becoming critical to pay attention to these small details in a remote hackathon. In an in-person hackathon having a physical visual backlog of tasks to be done keeps everyone on the same page and understands what is still waiting to be done. When you move the backlog to out of site it will become out of mind, which the common response would be everyone will own the backlog. Which in theory sounds practical, however in practice when everyone owns something, no one ends up owning it. Having a dedicated person to own and manage the backlog can prevent this paradigm.

Breakout Rooms

During an in-person hackathon, it’s very common for two or more individuals to collaborate on a task and do so at either a shared work area or at each other’s desk to avoid pulling focus and distracting others that are working on their own task. This is also a common thing to occur in remote hackathons. The difference is typically everyone on a team starts off in a common meeting; by doing so, it becomes increasingly difficult to stay focused as people pair off and start collaborating. While the knee jerk reaction is to have everyone spin up their own meeting and you divide in conquer, but that is not always the most efficient course of action. By disbanding the common meeting room and everyone going their separate ways, you start losing ownership and outside (non-hackathon work) may start sneaking in. One great way to have your cake and eat it too is to have breakout rooms for people to jump in and out of as needed but the main meeting remains open for everyone to work in. This helps emulate an in-person dojo atmosphere where anyone can ask/provide help to others and brings back the a human element to remote work.

Remote Plugins and/or Screen Sharing

Screen sharing within a meeting is a great start to pair-programming, but what if you could actually share the same IDE? With VSCode Live Share, you are able share your IDE just as if you were collaborating on a document in Google Drive or OneDrive. Why would you choose this over separate branches and screen sharing sessions? Well, you are able to get a more immersive interaction in a pair programming session, improve efficiencies by not having to git fetch && git checkout <branch name>, and everyone can remain in the main dojo area of the meeting while still pairing on a task. This extension also allows you to show the person you’re pairing with what you may be explaining instead of dictating where to go and what to do in their IDE. For me that is a huge benefit because we all communicate differently, and there are times it is considerably quick to fix the typo your partner made instead of go to line 34, you misspelled instance.

The Live Share extension is not limited to just two people within the session. This feature can also be used as a powerful tool for an engineer to join a pairing session that is already in progress to help others with an issue. If we take this concept and look how it applies to the T shaped engineer concept discussed previously you can quickly see how small things link this extension can help the pillars of a data domain share their knowledge and experience. This can also substantially improve the efficacy of hackathon advisors by letting them jump directly into code without having to dictate via a screen share on what they want to see to offer advice on.