Quests - the way we structure our work

Software development is famously hard to predict. Books have been written about this since the mid-70s, yet it persist despite modern methodologies like Agile, SCRUM, and Kanban.

Many hypotheses have been put forward as to why that might be. It is generally agreed that the industry struggles to meet deadlines due to the complex nature of software projects and our innate optimism in estimating time frames by humans. While at the same time expectations evolve throughout the process changing the necessary work and the expected outcomes Additionally, what is considered "ready" varies widely between different parties involved (as the famous tree swing cartoon illustrates since the 1960th).

The situation gets even trickier in when developing a startup-style Minimum Viable Product (MVP) in a community-engaged, transparent way. For once, because not everyone out there is familiar and comfortable with the industry default of being late on all deadlines. On the other because you do want to communicate more and more transparently than most "stealth"-startups do. But how do you do that?

We are struggling with that, too. But rather than issuing unreliable road maps or unrealistic timelines, we want to focus on transparency about our working process. Our goal is to provide a realistic view of our progress and thus expectations, offering clarity rather than vague assurances.

Urgency-Driven Kanban Approach

In the past six months, we've embraced a kanban-like system. Each week, our engineering team meets to reassess task "urgency" based on recent developments or heightened relevance. We then prioritize tasks with greater urgency. This approach aligns well with our rapid development cycle and enables swift responses to community feedback. However, it's less effective for longer-term or non-urgent issues.

Another challenge is external visibility. Understanding our progress requires close involvement in these meetings and development activities, which is unrealistic for most people. To address this, we've implemented end-user-driven changelogs. Compiled automatically for each release, these changelogs provide a detailed summary of all changes, improving transparency and understanding of our development process.

Introducing: Quests

While our urgency-driven approach has its merits, it doesn't fully convey our long-term goals and priorities. To address this, we've started structuring our work into "quests". Borrowed from the analogy of computer games for every quarter the team now agrees on some major or main quests and some side quests "to go on". As in computer games the main quests are larger storylines that bring us forward while side quests are collections of things that are nonetheless useful for us to work on but less essential.

Through this lens, we can focus our work, make sure we don't get too distracted by things that feel urgent right now, and give us breathing room to also work on larger not that imminent aspects.  It also clarifies our current focus and what we're not working on, improving communication.

In the final quarter of 2023, the main quests for us were Smooth Chat, Notifications, and Onboarding, while our side quests read Bugs & Stability, Clean UI, and Tech Debt. This framing helped us immensely. For example it took more than a work month to just get the first cross-platform mobile notifications framework ready. Or with super_invites, a quick shot for improving "onboarding", which required some longer focus on the task to see the long-hanging fruit available. Something a lot harder to to into the mindset for if you are jumping from one product aspect to the other very often.

Another great thing about thinking in "quests" is the flexibility they offer. We aim to progress as far as possible without strict deadlines, allowing for unforeseen challenges. For instance, while working on Smooth Chat, we discovered inadequacies in our space-chat relationship management, a hurdle we hadn't anticipated. A more rigid framework might have led us to quick fixes to meet deadlines. However, with the quest on our mind we rather addressed this issue thoroughly, accepting the unexpected as part of the journey.

The Quest Not Chosen

Selecting our quests also offers insights into what's omitted. Our backlog is extensive, and while many ideas are eagerly awaited by our community, our week-by-week approach lacked transparency regarding when these features might be implemented. By identifying the quests we choose not to pursue each quarter, we provide clearer expectations. For instance, last quarter, we consciously excluded popular requests like a web version, off-grid communication, and encrypted spaces. Our aim is honesty, replacing vague "soon" timelines with a definitive "not this quarter".

Expanding the Quests

This framework worked so well for us that we decided to keep it for the time being - at least for product engineering & development. At the same time, we are still a young and growing project and thus need to be flexible and agile (ehem) in what we do. So we are actively agreeing on a fresh set of quests for the next quarter just ahead of it starting. With some anticipation of quests to come after, which also informs us about the quests at hand this quarter.

We're also experimenting with applying this quest idea to other areas like communications, community building, and fundraising. However, with engineering comprising over half our workforce, extending the quarterly quest model beyond engineering remains a challenge.