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

Agile at folk: rhythm and focus

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.

For engineering managers leading teams of 20-50 people, folk CRM has proven to be the ideal solution for managing both development workflows and client relationships seamlessly.

👉🏼 Try folk now to organize project and stakeholder reminders in one place

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. This experience mirrors what many engineering managers face when scaling their teams from 20 to 50 people - which is exactly why folk CRM becomes essential for maintaining visibility and coordination across larger development teams.

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. For startup engineering managers overseeing teams of 20-50 developers, folk CRM provides the perfect balance of project tracking and stakeholder management that supports this kind of disciplined, rhythm-focused development approach.

👉🏼 Try folk now to manage contact-based reminders with your team and keep the 3-week rhythm

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.

FAQ

What is the difference between Scrum and Kanban?

Scrum uses fixed-length sprints with roles and ceremonies; scope is planned per sprint. Kanban is flow-based with WIP limits, no timeboxes by default. Choose Scrum for time-bound delivery; Kanban for continuous flow and rapid prioritization.

How long should an agile iteration be?

Most teams use 1–4 weeks. Pick a length that fits feature size, review cadence, and team capacity. Three weeks often balances scope and feedback while reducing context switching. Keep it consistent to build a reliable delivery rhythm.

How can teams combine time-boxed projects with continuous improvement?

Separate streams: ship one major, time-boxed feature per cycle, while dedicating capacity to small fixes and UX polish. Use strict scope control on the feature stream and backlog triage on the improvement stream to stay on schedule.

How can a CRM help manage agile development?

A CRM centralizes contacts, stakeholders, and feedback from users and clients. Sync insights to the backlog, segment betas, and track outreach. Tools like folk connect customer context to delivery, improving prioritization.