Preparing for the hackathon

In the previous blog post I described why hackathons are important for lean vertical market software companies. Now I will explain how you should prepare for one.

Different hackathons for different needs

Again, there are many different kinds of hackathons each with its unique strength. A traditional hackathon is an event where tech teams get a very generic theme, and each team is free to approach it any way they want. Such a hackathon is about spontaneous creativity, innovation, and team building.

The annual Yonder hackathons are more focused and not generic. At our hackathon, each team has a specific goal, set by the customer and will use particular skills and technologies to accomplish that goal. Sometimes the objective is to build a prototype of an application, but very often it will be a technical goal like executing technical spikes or a discovery to validate or have technical risks surface.

You can and probably should combine the two kinds of hackathons as they address different types of needs. The traditional one is perfect for team building, promoting creativity, and discovering new ways of working inside your teams. It is also the preferred way to approach new products or add-ons. As many teams are working on the same objective, you will get a diverse variety of results. This variety is important because, in the end, only your customers can validate the real value of a feature. Therefore, the more features you have at the end of a traditional hackathon, the more your customers can validate and the higher the chances are that you will have something that is truly valuable.

Focused Hackathon for Prototype

Once the ideation process over, you can and should start building a prototype so you can showcase a selection of features that will be the application or add-on to your customers. At this stage, a focused hackathon, outside of the regular production planning and schedule, is the place to create a prototype or where you can validate approaches and technical risks in building the final product.

Organic growth is essential for any healthy company. One way to achieve this is to improve and expand your range of products continually, delivering more value or reaching a wider audience.

Two proven approaches designed to help you discover new customer groups or valuable features for existing customers are: customer-driven development and design thinking. There are differences between the two methods, but they converge at the point of building an MVP (Minimal Viable Product) where you validate it with your customers and then iterate or pivot.

Role of the Product Owner

If the goal of the hackathon is building this MVP prototype, then a typical agile process is the perfect way to approach it. You will need a product owner who can create the backlog of stories. Ideally, he/she should be part of the hackathon team, as questions will arise during the event and decisions need to be made. Plus, there may be situations when the backlog should be done on day one forcing to fortunate product owner to add some new stories.

UX Designer

When there are no mockups or wireframes of the prototype, a UX designer can help the product owner preparing some for the hackathon. Having a brand book or file listing your company’s house style is needed so that the UX designer can create the appropriate user experience using the correct product identity. If you have a UX designer, you can have him/her join the team so that they can work together.

But maybe your goal of the hackathon is:

• proving the feasibility of an approach/technology,
• shedding light or uncovering technical risks or,
• merely gaining insight into a problem.

Then it is vital that you sit together with your architectural steering comity and product owner so that you can clarify what the technical risks are that need to be uncovered, or what the functional goals are that you want to accomplish with a new technology or framework. A good starting point would be a short document describing what the architecturally significant use cases are, and what the constraints and non-functional requirements are.

Architecturally significant use cases are the use cases that have a significant impact on many aspects of a system and are essential in shaping the solution.  Any use case is architecturally significant if at least two criteria are satisfied:

1. High impact – the functionality has some very particular requirements from at least one quality attribute perspective (scalability, reliability, …) or it affects cross-cutting concerns like authorization, auditing, or instrumentation in a significant manner.
2. Business critical – it is high usage / high value, and/or it implies high technological risks.

The constraints are important because if there are any business or technical limitations as the result of regulations, integrations, device support, then the team approaching the technical spike needs to know these.

Regardless of the specific need for the hackathon, prior arrangements need to be made in making sure that, if there are any: integrations required, environments prepared those need to be ready by the hackathon start so the team can focus on solving the challenge from the first minute of the event.

For our hackathon, a Yonder team lead will be appointed to the team and will get in touch to discuss the types of environments, connectivity, integrations, and services needed so these can be configured by the time the event starts.

Depending on the goal, different skill sets, platform and technologies specific know-how might be required. Therefore, Yonder needs to have a pool of people with the right skills ready so that the team lead can pick and choose, forming a proper team to accomplish the desired objective.

Regardless of your goal for the hackathon, it is valuable to have a challenge, technical or platform related, as the event should be fun, challenging and energizing for everybody involved.  And generally, the developers who participate at the hackathon are really passionate about technology and building things, and they are eager to contribute their knowledge, time, and energy in developing wonderful products and prototypes.

Remus Pereni, CTO