Why have a hackathon?
A hackathon is an opportunity to remove the distractions of daily work, get into a new environment and focus on one particular project.
By setting aside 5 days to try something new, we could be more experimental in our approach to solving a key user issue. And by tackling a brand new problem with a team of people who don’t usually work together, we could approach the task with fresh and varied perspectives.
Normally, we all have multiple projects to work on and inevitably spend some time on other tasks and meetings. Focusing on one project in this way, outside of our usual roadmap work, allows us to get work out the door much faster.
What were we trying to achieve?
It can be tricky to decide what to build in a hackathon. We wanted to choose something that we could build in a limited amount of time, but that would also be useful. Equally, we didn’t want to plan out the week's work too strictly, because the value of the hackathon is getting different viewpoints and a mixture of ideas so we can solve a problem creatively.
So while we didn’t have a set plan, we did go into the hackathon with a clear idea of the problem we wanted to solve.
The Salesforce developers and admins using Gearset to manage their DevOps processes know how useful Gearset is in their daily work. But people who aren’t using Gearset every day also want to understand its value. Sometimes senior managers in larger enterprise teams find it difficult to know how Gearset impacts the performance and health of their DevOps operations, and whether they’re getting the most value out of the tool. We wanted to find a way of presenting more information to these individuals, so they can better evaluate their DevOps performance.
To solve this problem, we decided to build a reporting API that allows senior managers to extract key metrics about the speed and stability of the DevOps processes that they’re carrying out with Gearset. Managers will be able to import this data, combine it with all their other data sources and build their own reports and dashboards that work for them.
We decided to focus on delivering the 4 key DORA metrics, which have become a universal standard to measure DevOps performance:
Deployment frequency - how often an organization successfully releases to production
Lead time for changes - the amount of time it takes a commit to get into production
Time to restore - the time it takes to recover from a failure in production
Change failure rate - the percentage of deployments causing a failure in production.
These are a crucial way for team leads and managers to understand both the resilience and the velocity of their release pipeline.
How we worked during the week
The hackathon team was made up of 7 software engineers, a UX designer and a marketer (me!).
The developers split into 4 groups, each focusing on a separate DORA metric and finding a way to extract useful data from Gearset about that metric. We also needed to visualize the data, so some developers worked with our UX designer to present the data and build an example report that can be integrated into users' own dashboards. And finally, we had to tie all of that together by building a bridge between the data and the visuals to make the information usable and easy to consume.
For the duration of the week, we turned off our notifications, canceled our meetings and set up a new Slack workspace dedicated only to the hackathon. Every morning after breakfast we’d have our morning stand-up, where we hashed out the key objectives for that day. We’d get some music going and then get our heads down to work.
The working environment was super collaborative; being in one room together, with a single shared objective, we were able to really bounce ideas off each other and ask each other for advice when challenges arose.
With a mix of experience, ranging from team leads to developers with just 6 months at Gearset, we were able to make sure the hackathon experience was productive, efficient and a good learning opportunity. Unfortunately one of our team leads, Ben, was unable to join us in person due to illness, but he joined in remotely and we had him on the projector every day!
Getting to know our colleagues
We spent the week in a large country house, just outside the Cotswolds. There was more than enough space, and it was great to have a comfortable environment in which to get on with our project. We had a fully stocked fridge, plenty of coffee and ample snacks to keep us going!
Living and working together in one space was a great way for us to get to know our teammates better, especially as some of us hadn’t met in person before due to remote working. Even though we were working hard, the social side of the hackathon was a great way to recharge and keep momentum for the project.
We spent our evenings playing pool or having a chat around the fireplace. Several members of the team showcased their skills in the kitchen, so we had a lot of delicious dinners, including a BBQ - despite the chilly March weather! And we even ventured into the city of Bath on our final night to celebrate a successful hackathon.
What’s the result?
The hackathon has been a huge success. After writing thousands of lines of code and merging over 70 PRs, we’ve got a working prototype of the reporting API that gathers data for the four DORA metrics and visualizes it in graphical form.
This represents some crucial groundwork for the reporting API, and we’re really proud of what we achieved in such a short space of time. The next step will be to build on these foundations to fine-tune how and what senior leaders want to see. It’s not quite ready for customers yet, but we’re hoping to begin testing with a small group of users in the near future, before making it more widely available.
Not to mention, we’ve had a blast. It’s been an amazing experience to come together and work really closely on a shared goal.
If you're interested in the reporting API and want to know when it's available, join our mailing list.