How We Achieved 40% More Output with No New Hires

Some projects don’t leave room for error. When a client comes to you with an investor demo locked in and an app that needs a near-complete overhaul — you don’t get to ask for more time. You figure it out with the team you have.

That’s exactly where we found ourselves.

Not all projects can be done without mistakes. We were approached by a funded startup who had an investor demo signed and an app that required a full re-architecture. New features, clean architecture, better UX — huge scope, short time. Their initial reaction was to find a driver. We understood why. However, when it came to the way the team spent the day, it wasn’t a matter of headcount. There were little inconspicuous inefficiencies consuming real development time, one after another, every sprint.

Thus we corrected our team’s collaboration. Eight weeks later, the complete revamp was delivered on time, and there was about an 40% increase in production per sprint.

Here’s what actually moved the needle.

The One Thing That Made the Biggest Difference: A Smarter Morning Meeting

Not a standup. One planning time (15 minutes) focused on three questions.

The recurring theme: developers experiencing a blocker at 2pm which anyone could have expected at 9am. Plan A was stalled, and there was no one who had thought about anything else. Hours vanish in that space in between when the blocker hits and what to do next.

Therefore, we set out three plans for each day.

Plan A

main objective of the day. Specific, owned, completable.

Plan B

Your B plan if Plan A fails to work out. Planned ahead, not after the blocker has hit.

Plan C

A task that you can complete independently, with progress.

The whole meeting runs 15 minutes. Everyone leaves knowing exactly what they’re doing — and what they’re doing if that falls apart.

In week two, developers arrived at the meeting with their Plan B in place. Blockers came up before they turned into delays. It took the team lead a few minutes in the middle of the day to quit the habit of losing hours while redirecting people. A simple design and has proven to be the most durable of the many designs we have tried.

It’s not complicated. That’s the point — complicated systems don’t survive high-pressure timelines. This one did.

Tackled the challenge of the ticket problem before it struck Sprint.

Much of the rework was due to one single cause: tickets being sent into sprints without enough information to work on. The acceptance criteria was either not specified or not set. No edge cases were marked. Designs weren’t attached. If a developer could come up with something reasonable, take it to review and discover it wasn’t what the product team was thinking about.

We added a short def of ready checklist – the acceptance criteria that were written, the designs were linked, and the dependencies were identified, and edge cases were noted. No one had signed off before entering in the sprint. A bit more than 15 minutes of work per ticket. In three weeks, rework fell by about a third.

However, many people simply did not realize that PR Review Lag was a silent killer.

PRs had to wait 24 to 36 hours to be seen by a first look. That caused cascading delays – whatever function it depended on could not run either, or anything that depended on it, either. It did not seem to be an issue, as it was simply the way things were.

We agreed that if there was a PR open and you had capacity give it a first review within four working hours. It’s not a formal approach, it’s just an explicit approach. The team honored it. Merge times were reduced and so were the merges that resulted in down stream pile ups.

Weekly Check-ins – Not Just Retrospectives

Retrospectives are great, but they are not happening often enough to resolve friction when it’s small. We introduced a weekly ‘what slowed us down this week’ question and a ‘what one thing can we do’ if this week realistically question of what can we do differently?

One change. Not a list of action items. In week 6, the team had gone through more than 20 small improvements, none of which were dramatic, but all of which were real.

Other Things We Improved

Talking tooling. The systems that the company used for its project management were Jira, Slack, GitHub, and Confluence. The company didn’t have automations between these systems; we added them — ticket statuses changed on commits and merges, deployments triggered alerts in Slack, Confluence created reports about sprint results automatically. Two days of configuration, after which everyone could see all the necessary information without contacting any person.

CI/CD done properly. The company had a CI system that was Jenkins, yet, the process of deployment required presence of the senior engineer and took 3–4 hours every single time it was needed several times a week. We completely rebuilt the pipeline for the company and made deployments take less than 20 minutes, and most of the time they happen without the presence of engineers.

Properly filled tickets. Another big part of rework was rooted in a problem: there was no information in tickets about acceptance criteria. We introduced the checklist of things to be mentioned in a ticket before starting its development. The rework level was reduced by a third.

Shortened PR reviews. Sometimes pull requests had to wait 24–36 hours before receiving any comments from another engineer. We informally agreed upon 4-hour SLA, which greatly shortened merge times and eliminated many problems with cascading PR delays.

The Results

• Sprint velocity of ~ 40% above the average
• The deployment time is 3-4 hours with the possibility to be reduced to under 20 minutes.
• Rework rate, down ~one-third.
• On time delivery of a revamped full product to the investor demo.

There was no expansion of the team. The days were no longer dotted with holes.

All the while, Hiring Is Actually the Right Call was in progress.

The exact opposite occurs with some teams you’re making a mistake hiring more developers — there’s just more work to do than the hours and no process cleanup will make up the difference. However, that is not the case as is often the case. Most teams are shedding actual capacity that is correctable and adding more manpower doesn’t solve anything, it just gives more people the same problem.

A 40% improvement means that your staff is working for 1.4 teams. It’s important to know before you post a job.

Working With Innostax

Develop Web apps, mobile apps, APIs and platforms. Additionally, we support the existing engineering team in delivery, infrastructure, and process — where needed.

We’ve been there too if your team falls behind schedule on a roadmap or if you are running into a critical milestone.

Let’s talk →