How we work at Assista

First of all, we are a very small team of 3 people. As part of Camplight we often jump onto other products and initiatives inside the cooperative, but our main focus is Assista. We work in a few cycles:

Weekly

Each Monday we talk about what we have done last week, what we will do this week, and if there are any showstoppers that we need help with. This meeting is our only synchronous meeting which we try to wrap up for mostly an hour and that's quite nice. The rest of the week is free of distractions.

Monthly

At the end of each month, we send out a newsletter to the cooperative to update them on our business metrics and how we are progressing towards our goals. This is because each member of the cooperative is also an owner and investor in the products we build and we feel accountable to each other.

Quarterly

This is where the majority of uninterrupted work happens. Through experimentation, we've identified that 3 months gives us enough time to build more complicated features but also it's short enough that there is some pressure on us to deliver on time. If we were a bigger team, we would have probably worked in smaller intervals, but c'est la vie.

At the beginning of each quarter, we do a few things:

• Review our goals and metrics for the previous cycle. (we use OKRs for that, but we are not heavy on it) - retro
• Set new goals for the next cycle. - goal setting
• Discuss what we want to build for the next cycle. - betting
• Shape new features. - shaping
• Build new features. - building

How we do retros and goal setting

Nothing too fancy. We just discuss what we have accomplished, what we didn't, and mostly why we didn't. We review together our product dashboards and think about what we need to be focusing on next from a business perspective. Until now we have only had one goal per quarter. We often go back and forth and argue a little about how much we can actually do in a 3-month period and after a short discussion we agree on what makes the most sense. After doing this, we also broadcast it to the whole cooperative so the rest of the company is aware of where we are and where we want to go.

How we bet

We discuss which features we want to build for this cycle and usually choose one big feature to focus on and a few smaller ones, depending on what's a business priority for us right now.

How we shape

We gather feedback from users, other people from the cooperative, and our own ideas all onto a Trello board, but we never try to build them right away. We shape them first. We use Basecamp's definition for shaping and appetite, but in short, independently from building new features, we get an idea from the list of ideas we already gathered in the past, and depending on the complexity of the feature we want to shape, we either shape something as a team or one of us does it. If it involves too many moving parts - like a lot of changes to the existing backend codebase + a lot of new UI functionality - we mostly do it as a team. We also talk about how much time we want to spend on each of those features (appetite) and try to fit them into this time slot. Here is the level of abstraction we expect from our shaping process:

As you can see it's pretty low-fidelity, but enough so a designer and/or engineer can have fun with it while building it.

How we build

Once we have bet on what we want to build for the cycle, this part is already straightforward. We design and / or program depending on the needs, but we always do it as a team. Something we find extremely valuable is to have a designer role and an engineer role working on a single feature implementation. We are not fans of separating the two activities, like we often see in teams.

In fact, the whole workflow above (retros, goal setting, betting, shaping and building) is done this way because we want everyone to be involved in the business, design and implementation phase as one single team. And even though we are a small team and we can do that easily (we pretty much have no choice), this approach also works in bigger teams as long as they are mindful about it. Separating the business, design and implementation too often leads to confusion, misunderstanding, disalignment and failures.