What wasn't working.
The team was not shipping. New features kept starting before existing ones were ready to release. Work was often functionally complete but never considered truly done. It sat waiting for another round of polishing while attention moved to the next initiative.
Everything flowed through the team lead, which created a single point of failure. Decisions, reviews, and approvals all depended on one person, and that slowed progress and created bottlenecks.
Prioritization was almost non-existent. Dozens of features were in development at the same time and everything was treated as urgent. When everything is a priority, nothing is.
Releases also depended on multiple stakeholders. Marketing, Customer Support, and the CEO all needed visibility into what was shipping and when. Without a clear roadmap, the team spent more time managing expectations than delivering value.
What we actually did.
There are plenty of frameworks and buzzwords teams use to claim they are agile. I did not start with Scrum, Kanban, or any scaled framework. I started by solving the biggest problems first.
The first change was a daily standup. It gave the team visibility into progress, surfaced blockers early, and created accountability.
Next, I worked with management and key stakeholders to bring order to the backlog. We used the MoSCoW method to classify work into Must have, Should have, Could have, and Won’t have. For the top ten initiatives, we applied a cost-impact matrix to identify the highest-value opportunities. This replaced the constant “everything is urgent” mindset with clear priorities, and gave Marketing, Customer Support, and the CEO confidence about what was shipping now, what was coming next, and what could reasonably wait.
With priorities in place, we cleared the decks. Work that was already functionally complete but waiting for endless polishing was released immediately. This created momentum, delivered value to customers, and boosted the team’s confidence.
Once the backlog was under control, we introduced a strict two-week sprint cadence. The goal was not to follow Scrum by the book. It was to create a predictable rhythm for planning, execution, and releases.
Finally, we removed the team lead as the single point of failure. Responsibilities were gradually shared across the team while the team lead focused on mentoring and oversight. This distributed product knowledge, reduced bottlenecks, and let decisions and delivery continue without depending on one person.
Where the interesting calls were.
One of the biggest stakeholder challenges was the “Won’t Have” category in MoSCoW prioritization. To them, it sounded like their requests were being rejected, even though everything felt important. Instead of changing the framework, I changed the language. “Won’t Have” simply meant we would not work on this in the current or next quarter, and would review it again based on priorities after that. That small shift turned a hard no into a transparent not now, and made prioritization much easier to align on.
Another hard decision was to stop chasing the perfect agile framework and focus on fixing the team’s biggest constraints first. We started with simple practices, daily standups, clear prioritization, and a predictable delivery cycle, instead of introducing Scrum, Kanban, or a scaled agile framework wholesale.
The team lead’s hesitation to share ownership was another challenge. Moving responsibilities across the team felt like a direct hit to their role and authority. I positioned it differently: this was not about reducing their importance, it was about increasing their impact. Instead of being the bottleneck for every decision, they became a mentor and technical leader, enabling the team while focusing on higher-value work.
The numbers after we shipped.
Release cycles moved from indefinite timelines to a predictable two-week delivery rhythm. By distributing ownership across the team, engineers gained direct responsibility and visibility into their work, instead of everything waiting in a shared queue or passing through a single gatekeeper.
Stakeholders moved from managing a long list of “urgent” requests to working with a prioritized roadmap that clearly showed what would ship now, what was next, and what could wait. Marketing, Customer Support, and the CEO gained better visibility, and became active participants in planning rather than waiting for updates.
Things I'd carry into the next case.
An indefinite release cycle is usually a symptom of unclear ownership and decision-making, not just a delivery problem. Once ownership was distributed across the team and stakeholders had visibility into clear priorities, shipping stopped depending on one person’s judgment of what was ready.
The biggest shift was not introducing a new process. It was creating alignment: the team knew what they were responsible for, and stakeholders understood what would be shipped. A predictable delivery rhythm emerged from shared ownership, clear priorities, and trust.