Most teams adopt agile ways of working to move faster. But there’s a point where the process starts to get in the way. When that happens, the right answer isn’t to double down on rituals. It’s to step back and remember what process is actually for.
We were brought in to support a team part-way through a migration from Xamarin to .NET MAUI. The clock was ticking. The tech they were moving off had hit end-of-life, and the new build wasn’t ready. What they needed was speed and certainty. We had done it before, at scale, and we knew how to get it done.
But from day one, it was clear that process, ironically, was slowing things down. The internal team had relatively recently adopted Scrum. They were taking it seriously. Too seriously, maybe.
📖 Developer Diaries: Phoebe Davin on When Process Becomes a Problem
“They’d only really gone towards Scrum about three months before,” said Phoebe, our delivery lead. “And I think it’s quite natural when you’re adopting something new to go hard. But that meant they were rigid. Too rigid.”
The sprint goals were gospel. Very seldom was anything dragged in late. Even when a developer was free, they weren’t allowed to get ahead unless it was planned at the sprint’s start. The default answer? Pair up. Swarm on something. Get it over the line. That can work. But if it's your only tool, you miss chances to move ahead, reduce risk, and build momentum.
Then there was the decision-making hierarchy. A blocker in test might need to go through a tech lead, then a product manager, then a senior stakeholder. Only then could a decision be made. No one wanted to overstep. Everyone wanted to be seen to follow the rules.
“There was autonomy in theory,” Phoebe said, “but a lot of decisions still had to travel up the chain. That filters back down too slowly when you’re trying to hit deadlines. At times, it felt like the team were trusting the process more than they were trusting each other.”
We’ve all seen it before. A team in transition. A new methodology. A process that’s meant to free you up, but ends up boxing you in.
So we proposed something different.
We carved out a standalone delivery team. Still visible. Still accountable. But with room to breathe. Our developers knew the tech inside out. Experienced specialists. That gave us the confidence to switch from story-pointing and sprint goals to a flow-based approach. Less ceremony. More delivery.
We moved towards a Kanban model, pulling work in continuously rather than sticking to fixed-scope sprints. It wasn’t a total break from the client's way of working. We still did planning, retros, check-ins. But the emphasis shifted from hitting the plan to hitting the deadline.
It wasn’t always smooth. There was healthy tension. We had to earn trust. There were code reviews, oversight, pushback. But we were able to accelerate. Fast enough, in fact, that we went beyond what was originally scoped and over delivered.
“Because we weren’t chained to the sprint cadence, we could make space for that. We could move quicker and pick up more. It made a real difference.”
This wasn’t about tearing up the rulebook. It was about remembering what the rules are for.
Agile is supposed to be agile. Process is supposed to help. It’s not a checklist. It’s not a badge of honour. It’s a framework to get things done. If it isn’t helping your team deliver, it’s time to rethink how you’re using it.
We didn’t succeed here in spite of process. We succeeded by insisting that the process had to serve us. That meant loosening the grip, leaning on the team’s expertise, and showing what’s possible when you prioritise outcomes over rituals.
Scrum can be powerful. Stand-ups, retros, story points. They all have their place. But only if they’re working for you. If your team’s best path to delivery is a focused Kanban stream with lightweight planning, do that. If it’s pairing and mobbing, do that. If it’s a fast, isolated team blazing through high-priority work, let them.
This project proved that. Process doesn’t ship software. People do.
👉 AI Native Software Development
This is an AI generated summary of a conversation with Dootrix Delivery Lead - Phoebe Davin
