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, it might adversely affect the sprint delivery ratio. 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 of building feature velocity to the sprint team at least for the quarter so that the team can plan its deliverables accordingly. On the other hand, 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’
“Efficiency is doing things right; effectiveness is doing the right things.” – Peter Drucker
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.
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. It 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. It is because effective speed is always highly rewarding than just speed.
The philosophy of ‘first-time-right (FTR)’ helps all team members align themselves to a common goal- delivering robust and stable code for the first time itself. It’s always healthy to spend some extra time to determine the quality of code to ensure feature velocity never slackens. Hurrying and then getting stuck with rework is not what startups would like to do. Some of the tried-and-tested ways to improve the FTR ratio are regular backlog grooming, reiteration of stories, and regular demos to the product manager. Instead of just gathering requirements, the sprint team should focus more 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 simultaneously. This is generally applicable for a team of 4-6 members. However, as the expectation goes up to deliver multiple features, I recommend forming 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 emerging from a ‘logical separation’ 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, it might overwhelm users and impact the user experience.
To achieve better user adoption, tracking user engagement along with feature velocity continues to be the best way forward. While exhaustive user research is an effective 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
People often ignore this aspect yet it 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. However, startups would never want to lose their core members while building feature velocity. 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 regarding feature velocity 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. My intent is to stop them from reinventing the wheel and ensure seamless production.
