How Alarmy Engineers Work

Based on the Q4 2023 sprint process and a successful product launch experience

I'd like to share how Alarmy engineers work, what kind of development culture we have, and our experience with a unique Q4 sprint that led to a successful product launch.

In Q4 of 2023, we ran a rather unique sprint here at DelightRoom.

A collaborative sprint between the Monetization squad and the Sleep squad

Why the two squads teamed up -
In Q4 of last year, DelightRoom launched a feature that analyzes 'snoring' during sleep to help users have a successful morning. Since building this required various components—like extracting snore audio using machine learning + snore playback and snore severity analysis—we needed the resources of both squads.

Before kicking off development -
The product specs and designs for the snore feature were already well-prepared, so I figured we just needed to code it up. (Endless thanks to our POs and designers 🙏)
Before diving in, we thought about the best way to proceed. We figured it'd be best to start with requirement analysis, so we held a meeting with the following agenda:

1. Requirement analysis (Phase 1)
2. Individual work starting methods
3. Requirement analysis (Phase 2) & architecture design
4. Task division

1. Requirement analysis (Phase 1) -
Analyzing the requirements for the big picture of the feature — keeping it simple

Drawing flowcharts
Organizing main features

We mapped out the sequence of functions and defined the main features. Through this process, we engineers synced up once again on exactly what we were building.

2. Individual work starting methods -
Since everyone has a different way of starting their work, this was the stage to share those approaches and discuss what we should start with first.

Q) Shouldn't we just divide the tasks and let everyone start on their own?
One person might build the view layer first, another might start with data modeling, and someone else might jump into the main logic. But if we do that, usability testing and QA for the product might get pushed back, and if one person gets delayed, the whole project could get delayed.

DelightRoom strives for ‘Clean Architecture’, so everyone started development from the domain layer (main features).

4. Task division
Dividing things up efficiently

During the architecture design phase, different people actively participated in designing specific features. We divided the tasks based on that, which I think made it easy to estimate story points (the time it takes to complete development).

When issues popped up during development, everyone had the same understanding of the features, so we could resolve things quickly and easily.

By going through these steps and quickly starting development from the domain (main features), we saw a lot of benefits not just in the code, but in our workflow.

We could test features quickly using a Test UI.
Rapid feature testing moved up the timeline for refining the machine learning model.
We could develop the view layer asynchronously while feature testing was underway.

Brief retrospective -

Wrapping up the year with a collaboration between two squads was super impressive, and it leaves a lasting impact.
This sprint really showed me that when we come together as a team rather than fighting individual battles, work productivity increases and development stability improves.
Great job to everyone who participated in the Snoring project!