When startups move from early to the growth stage, their priorities change by a significant degree. Among all others, feature velocity stands out as a priority and plays a crucial role in their pursuit of growth.
The founder of a seed-funded startup that I was working with, which recently raised its series A round, asked me to double the engineering team to release new functionalities in six months.
However, is that the only relevant factor in reducing cycle time? To answer, I decided to address the ignored aspects behind this prevalent ‘misconception’.
Though resource capacity is one of the critical factors driving frequent releases to production, this alone can’t guarantee reduced cycle time.
While building products for more than 16 startups, I’ve witnessed the transition from early to growth stage multiple times. Out of this experience, here are some crucial factors that I am sharing for startup founders to consider:
Pass On Clarity: The Top-Down Essential:
One of the key essentials while ramping up teams to increase release velocity is the transfer of clarity from product teams to sprint teams.
When a sprint starts with ambiguity or doesn’t have enough stories to start with, the sprint delivery ratio gets adversely affected.
Vaguely-defined stories or mid-sprint inclusion of tasks slow down the pace, as a result, the sprint teams fail to deliver as planned.
A smooth sprint execution is the outcome of notable contributions coming from both the product and sprint teams.
The product team can play its part by preparing and sharing the roadmap to the sprint team at least for the quarter so that the team can plan its deliverables accordingly.
On the other hand, the sprint team should keep pushing the product team to get a product backlog and groom it on a weekly/ biweekly basis to ensure focused delivery.
Automate to Release ‘Bug-Free’:
When you think of automation, it is an example of the latter category. The moment feature development picks up speed, it is highly likely that production will break down unless the right processes are in place.
If the product isn’t stable enough to handle new feature developments, your team spends more time fixing issues than building new features. Consequently, your engineering velocity comes down.
“Efficiency is doing things right; effectiveness is doing the right
things.” – Peter Drucker
This is where CI/CD (continuous integration and continuous deployment)
comes into the picture. Herein, exhaustive unit, integration, and automation test coverage ensure that whatever is shipped doesn’t break the system.
Don’t Just Build More, Else You Break More:
Rework is a big productivity killer and could be a result of various factors such as vaguely-defined stories, lack of dev testing, lack of test coverage, and so on.
Rework can eat up productivity as it would consume the time and efforts of QA engineers in testing and regress, developers in debugging, and release managers in re-releasing.
Slowing down a bit can help your team deliver faster and add value, as the effective speed is always highly rewarding than just the speed.
The philosophy of ‘first-time-right (FTR)’ helps all team members to align to a common goal- delivering robust and stable code in the first time itself.
It’s always healthy to spend some extra time to determine the quality of code, rather than hurrying, and then getting stuck with rework. Some of the tried-and-tested ways to improve the FTR ratio are regular backlog grooming, a reiteration of stories, regular demos to product manager.
Instead of just gathering requirements, the sprint team should be more focused on elucidating them to improve the FTR ratio.
Structure Your Team for Parallel Sprints:
When your startup has a small product team, everyone mostly works on one or two features at the same time (generally applicable for a team of 4-6 members).
However, as the expectation goes up to deliver multiple features, it’s highly recommended that you form multiple sub-teams having distinct focus areas. In this manner, every sub-team gets to run its sprint and define its roadmap.
As compared to one big team, smaller teams born out of a ‘logical separation’ framework are more effective and yield better results.
Individual teams for microservices, different product lines, and various components are among a few examples of the ‘logical separation’ approach.
During the restructuring, it’s always essential to include at least one member from the earlier core team in each of these sub-teams to maintain the DNA.
Though cross-team coordination for deliveries entails an additional overhead, that’s a justified trade-off.
Track Feature Usage Along with Velocity:
User experience is the most vital metric to measure the success of a new feature release. As you start delivering multiple features at speed, user experience often takes a backseat.
When your product has limited features, the user interaction continues to be a smooth unbroken curve.
However, when you start releasing new features, there is a high chance of users getting overwhelmed and their experience getting impacted.
To achieve better user adoption, tracking user engagement along with feature velocity continues to be the best way forward.
While exhaustive user research is one proven way, other significant ones are rolling-out initially to selected users via feature flags, A-B testing, and tracking user journey (via amplitude or similar analytics tools) after every new release.
Don’t Lose Your Core Members:
This might be a very commonly-ignored aspect yet stands firm as a very crucial one. Small teams don’t necessarily need processes and have a
nimble structure and everyone’s voice is heard.
When these teams move up to a state where processes are set up and new engineering & functional members are added, healthy management is the only way to avoid chaos.
As your engineering team successfully scales up, a well-capable product team is essential to feed the engineering team continuously.
A churn becomes inevitable when the team members have no significant work, but no startup would ever want to lose its core members. In this case, senior management holds the key to ensure good relationships with people and understand the dynamics well.
On a Final Note:
The learnings that I’ve shared here are from the experience with multiple startups over the years. I expect it to be useful for startup founders, who already have a lot on their plate, in a way that they don’t end up reinventing the wheel.
