Focus hackathons
Focus is as close to a panacea as software developers will ever come. A team that solves a single problem together is the gold standard of productivity.
Yet most of us aren't doing that. Most of us move unrelated tickets from left to right. We close sprints rather than solve problems.
Moving from this ticket-by-ticket mindset to a focused one is tricky.
We can't just decide to "be focused" from one day to the next. Old habits die hard.
One of my favorite ways to get started is by organizing a "Focus Hackathon". We carve out three days where the team gets to solve a problem in isolation. That means no backlog, Slack, Jira tickets, or meetings. We then identify a valuable problem. This can be something that's already on the roadmap, but in most cases, we'll have to come up with one.
That's because most software teams implement solutions rather than solve problems. If your organization has a long wish list of features, that's not what the hackathon is for. The idea is to introduce the team to self-organization through focus. A good source of valuable problems is asking what our customers are complaining about. The problem is only valuable if it hurts the users.
Depending on your organization, Product might need to help identify and describe the problem. That's OK. Writing out a detailed problem description in the lead-up to the hackathon will be very helpful. Let's make sure it contains only the problem, not some premature solution.
So, now that we've identified a valuable problem and carved out the time, we need to assign a facilitator. This person runs the meetings and reports progress to the rest of the organization. The team's direct manager is usually a safe choice. The facilitator isn't involved in the result of the hackathon. Their job is to ensure the team stays focused and doesn't do overtime.
We start with a kick-off meeting where we ask: "What is the most valuable solution to the problem we can build in the coming three days?". Expect this to take a while. Discussions and designs will lead to a first solution and a plan to build it. Management and Product need to resist the urge to get involved here.
On the last day of the hackathon, the team will present the solution to the rest of the organization. They need to show how this solution alleviates the pain for the users.
Teams usually enjoy buckling down on a single problem. Software developers are problem solvers by nature. Taking ownership of a solution and avoiding constant context-switching works wonders for productivity and morale.
But invariably, they will be disappointed by the outcome. The first hackathon will be messy, and that first solution won't be good enough to publish. That's not the point of this exercise. Whatever obstacles stand between now and your focused future become evident during that first iteration.
If you work in an environment where people spell out solutions for the developers, that will become visible. Teams will struggle with their newfound freedoms and responsibilities. They need to work on maturity and self-organization.
Product managers used to solutioning often dislike whatever concept the team came up with. If your organization has overly hands-on product people, they will feel uncomfortable taking the backseat. That indicates that the relationship between Product and Engineering needs some work.
If teams can't build a solution without relying on outsiders, that tells you about their lack of cross-functionality. A typical example is a mobile app team that relies on a back-end team to make changes to the API.
By mitigating these uncovered issues for the next hackathons, we gradually get better at solving problems. At a certain moment, one of the hackathon solutions will go live. Your organization will adapt, and teams will get stronger. Focus hackathons are a great way of training that muscle in your company.