Latest / Tech Leadership with Fexingo: Engineering Managers, CTOs, and Technical Leadership Conversations / How One CTO Replaced Sprints With Flow-Based Planning
Transcript
- Lucas: So back in 2023, a CTO named David at a company called Sprintly — around 45 engineers, B2B SaaS — made a decision that felt almost heretical to his product team. He killed the two-week sprint. Luna: Completely? No more sprint planning, no more sprint reviews? Lucas: None. He replaced it with something called flow-based planning. The idea isn't new — it comes from lean manufacturing and kanban systems. But applying it to a whole engineering org, with real revenue pressure, is still rare enough that when he published the results, it got a lot of attention. Luna: And the results were? Lucas: Cycle time went from an average of twelve days to under three. Throughput — number of features shipped per developer per month — went up about sixty percent. And the team's internal satisfaction score, which they track quarterly, hit an all-time high the quarter after the switch. Luna: That's dramatic. But my first reaction as a listener is — how? What was actually broken with their sprints? Lucas: Great question. David told me the biggest problem was what he called the 'sprint commitment trap.' Every two weeks, the team would promise to deliver X story points. Then they'd work like crazy to hit that number, often cutting corners on quality or context-switching to unblock dependencies. By day eight or nine of the sprint, most teams were just firefighting. Luna: So they were optimizing for the commitment, not the value. Lucas: Exactly. And the product managers loved it because they could tell the CEO 'we'll have these features by the 15th.' But the actual predictability was terrible. David measured it — their sprint completion rate was around fifty-seven percent. Less than flipping a coin. Luna: Ouch. So how does flow-based planning work in practice? Walk me through a typical week at Sprintly after the change. Lucas: It starts with the board. They use a simple kanban with four columns: Backlog, Ready, In Progress, and Done. But the key is the WIP limits — Work In Progress limits. No more than three items in the In Progress column at any time, across the whole team. Luna: Wait, across the whole team? So if one developer is blocked on a code review, they can't just pull another task? Lucas: That's exactly the discipline. If you're blocked, the whole team is expected to swarm and unblock you. No one picks up new work until the bottleneck clears. It sounds painful, and it is at first. But David said it forced the team to actually finish things instead of starting five things and finishing none. Luna: I can imagine product stakeholders pushing back. 'You're telling me we can't start on that urgent feature because someone is stuck on a review?' Lucas: They did, constantly, for the first two months. David had to have some pretty direct conversations. His argument was: 'If we start that urgent feature now, it will sit half-finished while we unblock the other work, and we'll deliver nothing. Let's finish what we have, then pull it in.' He used data from the first few weeks to prove that the new system actually delivered faster on high-priority items than the old sprints did. Luna: Specific numbers from those early weeks? Lucas: The first week was a mess — throughput actually dropped because people were so used to multitasking. But by week three, cycle time had already halved. By week six, it was down to four days. And the predictability metric — they call it 'on-time delivery rate' for items that enter the Ready column — went from fifty-seven percent to over ninety percent. Luna: That's a huge leap. And it makes intuitive sense: if you limit how much you start, you finish more. But what about long-term planning? How did the CTO handle roadmap visibility without fixed sprints? Lucas: That's a great point. David replaced the sprint roadmap with a rolling forecast. Every week, the team updates a simple spreadsheet that shows the next ten to fifteen most important features, ranked by value, with an expected delivery date based on the team's current cycle time. Not a promise — a forecast, updated weekly. Luna: So product managers could still tell the CEO 'we expect feature X in about three weeks.' But with the caveat that it's a forecast, not a guarantee. Lucas: Right. And the CEO actually preferred it, because the forecasts were more reliable. Before, they'd get a confident 'yes' and then a last-minute delay. Now they get a range that usually holds. David said the biggest cultural shift was moving from 'we commit to this date' to 'we will tell you as soon as the forecast changes.' Luna: Honestly, if today's episode gave you one idea you might try with your team, that's the link — buy me a coffee dot com slash fexingo. It's a small gesture, but it keeps this show ad-free and lets us dive into real cases like this. Lucas: Yeah, listener support really does make this possible. So back to Sprintly — one of the most interesting mechanics David implemented was something he called 'explicit queue limits' for each stage. Luna: Meaning? Lucas: Not just a global WIP limit. They set specific limits for design review, code review, QA — each stage had its own cap. If QA had five items waiting, you couldn't push another feature to QA until someone finished one. That prevented pile-ups and made bottlenecks visible instantly. Luna: So the team could literally see the bottleneck without needing a standup report. Lucas: Exactly. And they started using cycle time as their primary metric instead of velocity. Velocity is a lagging indicator that measures output. Cycle time is a leading indicator that measures flow. David said once the team started optimizing for cycle time, everything else improved naturally. Luna: I've heard some people argue that moving to flow works fine for maintenance work or small features, but breaks for large, complex projects. Lucas: David would push back on that. He told me about one project — a complete rewrite of their core billing engine — that took about four months. They broke it into small, vertical slices that each delivered real value. The first slice added support for a new currency. The second fixed a rounding bug. By the end, they had a working billing engine without ever having a 'big bang' release. Luna: So they decomposed the large project into value-delivering slices that fit the flow system. Lucas: Right. And the key was that each slice was independently deliverable. They never had a half-finished feature sitting in the codebase. If priorities shifted, they could ship what was done and move on, without sunk cost. Luna: That's a powerful contrast to sprint-based development, where you might have five partially done stories at the end of the sprint. Lucas: Exactly. David's team actually measured that — before the change, on average, thirty percent of story points committed in a sprint would spill over to the next. After flow, spillover dropped to under five percent. Luna: One thing I'm curious about: how did individual developers react? Did some hate it? Lucas: Some did. A couple of senior engineers left within the first few months. David said they were used to the autonomy of pulling multiple tasks in parallel and felt constrained by the WIP limits. But he also said that most of the team, especially the junior and mid-level engineers, loved the clarity. They knew exactly what to work on, and they felt less overwhelmed. Luna: So it wasn't a silver bullet for everyone. Lucas: No system is. But David's retention rate overall actually improved after six months. And the team's output per person went up, which is usually a sign that the process is working, not just making people miserable. Luna: What about the tools? Did they use a specific kanban software? Lucas: They used Jira, but with a heavily customized board. David said the key wasn't the tool, it was the discipline. You can do flow on a physical whiteboard with sticky notes if the team buys into the principles. In fact, they started on a whiteboard for the first three weeks to force the habit. Luna: So the tool is secondary to the mindset shift. Lucas: Exactly. And that mindset shift was the hardest part for Sprintly. David had to train the product team to stop asking 'when will it be done?' and start asking 'what is blocking the fastest path to done?' He also had to retrain himself — as CTO, he was used to giving top-down priority changes. In a flow system, priority changes require finishing what's in progress first. Luna: That's a big cultural change. Did they have any specific technique to handle urgent production issues? Lucas: They created an explicit 'expedite lane' with a strict rule: only one urgent item at a time, and it must be resolved within twenty-four hours. If you use the expedite lane, you have to drop whatever you're working on and swarm it. But you can't have more than one such item in the system. Luna: So it's like a fast pass, but with a hard limit. Lucas: Yes. And David tracked how often they used it. In the first month, they used it nine times. By month six, it was down to once or twice a month. The flow system itself reduced the number of emergencies because teams weren't cutting corners to meet sprint commitments. Luna: That's a self-reinforcing cycle — better process leads to fewer fires, which makes the process easier to maintain. Lucas: Exactly. And that's the real takeaway from David's story. The goal isn't to adopt kanban for its own sake. It's to design a system where the natural behavior of the team produces better outcomes. Sprint commitments created a perverse incentive to start things you couldn't finish. Flow-based planning flips that — you only start something when you have the capacity to finish it. Luna: So for teams considering this shift, what's the one thing they should do first? Lucas: Measure your current cycle time. Just pick a feature, any feature, and track how long it takes from the moment a developer picks it up to the moment it's in production. David said that number alone was enough to start the conversation. When his team saw that the average was twelve days, they knew something had to change. Luna: It's hard to argue with your own data. Lucas: Exactly. And once you have that baseline, you can start experimenting with WIP limits. You don't need to kill sprints overnight. Just try limiting work in progress to half of what it is now for two weeks, and see what happens to your cycle time. Luna: I love that — an experiment, not a revolution. Lucas: Right. And that's the spirit of this whole approach. It's not about dogma. It's about finding what actually works for your team. For Sprintly, flow-based planning was the answer. For others, it might be different. But the principles — limit work in progress, measure cycle time, finish before you start — are hard to argue with. Luna: Well, this has been a really practical episode. I think a lot of engineering managers will be looking at their sprint boards differently after today. Lucas: I hope so. And if you want to dig deeper, David published a detailed post on his company blog. I'll put a link in the show notes.