La cadence️, or how folk's tech team found its balance

Today, I am going to tell you about how we approach agile software development at folk.

If you are not familiar with agile software development, there are some good resources on the web. At folk, we have decided to build our roadmap with 2 objectives in mind: rhythm and focus.

To do so, we have defined two different ways to manage our projects:  

• A: 3-week iteration that leads to the release of a major feature.
• All the other projects fall into a continuous improvement stream.

Our intention

In September our tech team quadrupled in size (we went from 2 to 8 people). We are still a small team but we quickly realized we needed to improve our project management system. So far, we were handling a backlog of tasks using the Kanban approach. It was a simple solution and it served us well at the beginning. After all, it's not that hard to keep track of 3 or 4 issues at a time. But with 8 people now in the team (and more soon), this process no longer worked for us.

When we started thinking about what we wanted the process to look like, this is what came up:

• We wanted to release at least one big project every 3 weeks. Since we are still building the product, it's important to keep developing and creating core functionalities. We set our minds on 3 weeks because 2 weeks felt too short and 4 weeks seemed too long.
• We needed to devote some time to continuous improvements. The product we have built so far is great and we are proud of it, but since we’re creating something quite new (a no-code CRM), it needs to constantly be refined.
• We decided that projects shouldn’t be endless. We needed a definite deadline.

Mixing those goals wasn’t easy:

• Improvements are scope-based. When you want to improve something, you usually want to do it all at once. You also tend to discover other issues along the way. Thus, it's harder to stick to deadlines.
• Projects are time-based. But if you commit on dates then it's harder to stay on track of the scope-based improvements.

In the end, we decided that nothing was more critical to achieving our goals than rhythm and focus.

Rhythm is here to keep everyone going, making sure that projects don't drift. While the focus is here to make sure we remain efficient and able to keep the rhythm. We then had to come up with our own agile software development approach.

Agility, yes of course but...

In most of my previous experiences, the approaches used were either Kanban or SCRUM. That still felt like an improvement compared to older ways of working, but those approaches had their weaknesses: Kanban is not timed-constrained at all while SCRUM is.

I always found SCRUM to be a source of disappointment and stress, for two main reasons:

Classifying tasks by size: using an abstract scale to measure tasks leads to a wrong estimate 90% of the time. The good news is that since you are on an abstract scale you can always cheat the system and fall back on your feet. Eg: "We said 5 points for that? No way. I think we meant 13. Let's just review the sprint accordingly."

Planning: planning is nothing but trying to fit a certain amount of abstract points into a fixed period of time. It’s something very hard to predict. I doubt I have ever experienced a sprint that ended when it was supposed to. Sprints always end either before or - in 98% of the cases - too late. Both options are bad because they indicate that the sprint wasn’t planned properly.

Using the iron triangle, we wanted to have a system that has both time and scope constraints. Of course, we consider the resources to be fixed because we don't hire new developers every day.