Pushing for engineers to code faster may not equate to faster deliverables
When faced with slow moving projects, it may be tempting to push for engineers to code faster. Although generally not a bad thing, make sure you aren’t missing other factors impacting project velocity. There are many moving parts in the software development lifecycle, and a myopic focus on “faster coding” may never uncover some underlying problems. Very often, the speed at which your developers code is not the issue.
Here are three other areas to take a closer look at:
How long does it take for coding to start after a project kickoff?
Are the product managers and engineers on the same page about requirement details?
What other tasks are eating up your sprints?
First let’s examine project kickoffs. These kickoffs need to be efficient. Specs must be complete, and a kickoff should not be the first time engineering is reading the spec. Your primary outcome is ensuring that coding is happening ASAP after the kickoff is complete.
This is often a big hidden cost to your timelines if you’re doing this incorrectly.
A tale of two timelines
Poor planning is often the primary culprit. You really have two options to distribute work after a kickoff:
An engineering lead reviews the specs and creates all the engineering tasks
The entire engineering team / pod collaboratively create the tasks
If you choose #1, you only need the engineering lead in the kickoff. If you choose #2, all the engineers needs to be in the kickoff (and you probably need a half day for option #2, minimum). If you however, choose #1, but have engineers try to also review and comment on specs afterwards, this will drag things out. Context will be lost from reviewer to reviewer, wires will be crossed, and everyone will feel rushed by the time coding starts to happen. So don’t do this.
Review cycle of hell
Another cause of long gaps between kickoff and coding: Are the product managers and engineers on the same page about requirement details?
If requirements aren’t thoroughly researched and thought through, this will cause a lot of thrash. No one wants to start coding if requirements are constantly changing. So make sure your product managers have a standardized template, and hold them accountable for anything missed that was obvious. Furthermore, the engineering organization cannot have every detail spelled out before they start. This is quite literally waterfall methodology, and will grind your velocity to a halt.
At the end of the day, a pact between product and engineering is the most important thing, as well as working closely together when coding starts. We are in an agile world, after all.
And this leads us to our last area, what the heck is in the next engineering sprint anyway?
It really is hard to overstate how important momentum is for engineers. Context switching will be the death of your projects. So keep them out of meetings, don’t tap them on the shoulder when they have their headphones on, and keep the queue focused. How many points per sprint is the team spending on features, vs bugs, vs user requests, vs tech debt? There is no standard ratio, and the balance is highly dependent on the goals of the company. But unless there are some extenuating circumstances, achieving an 80%+ focus on feature development is a strong goal.
Some things that can help:
Creating support teams (tier 1, tier 2) to deflect non-feature related work from sprints. This also greatly helps your SLAs.
Learning to say no, and letting fires burn
Better test coverage, because poor test coverage leads to more… wait for it… BUGS.
Well thought through requirements, to avoid review hell.
The result will be leaner sprints, focused engineers, and more feature development. And higher organizational velocity. Velocity in building products is critical to scaling your business and beating your competitors. Learn more about Blitzscaling from Reid Hoffman and Chris Yeh.
If you take the time to examine and improve these three areas above, I can guarantee that you will see drastic improvement to your project velocity. And that’s really what we’re all after anyway.