Features weren't reaching customers. Then 90% shipped when promised.

The situation

The engineering organization wasn’t delivering. Work kept changing, people moved from project to project every week, and features weren’t getting into the hands of customers.

The CTO was a co-founder, technical and a builder. Managing the team and the work wasn’t their priority: building was. The CEO’s frustration was growing, but they didn’t know what to do, so I was brought in to get delivery back on track.

Diagnosis

I started by observing: sitting in on the planning and status meetings to understand how the teams were organized, how work was assigned, and what updates looked like.

I found three problems:

• Work changed too often. The CEO would pull people back and forth, and developers didn’t get a chance to finish what they had started.
• Features weren’t discussed. Developers were given a high-level description and left to fill in the details. There was no dialogue about what the implementation would take, what the edge cases were, or what was important to do now versus later.
• There were no estimates. Not even rough ones, so nothing indicated how long a feature should take, or how to tell whether it was late or taking longer because of complexity.

The approach

The primary change was to commit to a feature until it was finished and deployed.

This meant two things:

1. There needed to be a clear definition of done / deployed
2. The number of tickets being worked on (work in progress, or WIP) for a given period needed to be reduced

The CEO’s buy-in mattered most. The CEO was one of the people changing what the team worked on, and also the proxy for what customers wanted, so the commitment only held if the CEO held to it too. It also took buy-in from the entire team. I drove it, and held the line when shortcuts were proposed.

Other changes built structure around that commitment:

• Areas of focus. I divided the team into areas of focus, so engineers gained expert knowledge in one area and people knew who to ask about it, each led by a team lead.
• Scrum. I formalized planning into two-week sprints and trained the leads in Scrum. Sprints set a time when the work can change (the next sprint) and a time when it can’t (the current one). In sprint planning, the team talked through each feature before committing to it: what the implementation would take, what the edge cases were, and what mattered now versus later. The retrospective kept the process improving.
• Estimates. Very rough at first, to get people used to them, and made as a team, so there was some expectation of how long work would take once it started.

Ad hoc work was still coming in, so the sprint teams, which included the CEO, held 20% of each sprint’s capacity open for it.

We also said no to large initiatives and refactorings, meaning anything over one sprint. The team needed to get used to the new process and comfortable estimating first. Larger features have more uncertainty and need more thought and effort to break down into chunks that fit within the sprint, and that complexity could wait.

To know it was working, we tracked three things:

1. The number of features delivered each sprint
2. The percentage of committed sprint work delivered within the sprint
3. The share of sprint capacity taken by ad hoc requests

We agreed up front that the estimates wouldn’t be great at first, and that this would affect the numbers.

Results

By month 6, delivered sprint commitments had grown from under 40% to 90%, while ad hoc requests stayed under 20% of sprint capacity. The team doubled in size, to 18 engineers, while these changes were being adopted.

What stayed after the engagement

The engagement left three teams led by team leads trained in Scrum, a shared definition of done, the start of each sprint as the set point at which the order of work could change, estimates made as a team, and three measures showing whether it was all working.