In my last blog, I spoke about some of the products we rolled out at Rapido in a very short span of time and with a small team of engineers. We had to do a lot of things differently from ideation, planning to execution, and launch to make it happen.

In this blog, I would be talking about some of the aspects of the entire product lifecycle we tweaked from our regular process that helped in achieving this.

At startups, one of the constant tussles between business and technology teams typically has been the pace at which the features are rolled out for customers to use.

Business changes quite fast and they naturally expect technology to support them in this fast-moving world, which is a challenging task for technology teams to meet their needs all the time. As systems grow over time complexity increases, teams have to constantly address architectural concerns to align with the long term technology strategy and that takes time.

As technologists, one thing we always have to strive for is to balance between the quality of the product we build and the pace at which we build. Leaning too much on either of these will hurt you as a technology team and the business in the long run.

Focus too much on quality, more likely you are taking chance on missing the market opportunity which is usually time-sensitive as building quality products takes time. Focus just on the pace of delivery we will end up incurring a lot of tech debt because of the suboptimal choices and shortcuts taken during design and development eventually compromising the quality and scalability of the product.

That got us thinking about how do we take on this challenge while keeping a good balance between long term strategy and short term needs. We took this head-on with a promise of a 3 weeks MVP (Minimum Viable Product) challenge.

Teams, Composition, and Working Model

At Rapido, the technology teams are organized as fully cross-functional teams with polyglot skills focusing on a specific domain of the business end to end. We have teams like payments, pricing, onboarding, and few other platform teams focussing on order management, dispatch, geospatial services, and so on.

Teams work in 2-week sprints to ensure we release features at frequent intervals and have quicker feedback loops.

Our app releases are also aligned with the sprints, which means a new app goes to the play store or app store every two weeks with new features, enhancements, bug fixes.

However, most often the percentage of enhancements of existing products are on a higher side than the new features. It has been a challenge to release new features or products within sprint time for the following reasons.

• Most new features span across multiple teams and hence requires a lot of planning and coordination.
• Product and design teams have to be always much ahead of the development sprint to ensure the two weeks are fully utilized for design, development, testing, and releasing.
• High-level tech design and solution discussions to be done with all key stakeholders across teams.
• Managing the priorities of each of the teams and identifying the cross-team dependencies.
• Each team has its own stand-ups for things that they have signed up for and at the end of the sprint is where a lot of integration between the teams gets tested in fully integrated environments which are tricky to automate fully.

As you could imagine, these need heavy coordination and planning between teams to ensure the new feature is delivered with the utmost quality. Obviously this takes time and 2 weeks are rarely enough, hence most times new features always get spilled over beyond a sprint and takes multiple sprints before its completely functional and rolled out to users.

We realized, we had to do things differently if we were to succeed in this 3 week MVP challenge and tried a few things differently.

Tweaks In Our Delivery Methods

• We identified a core set of skills needed across teams to deliver a product end to end and created virtual teams comprising of folks from every functional team and platform teams.

• Developers did not wait for the fully vetted and complete designs or PRD (Product Requirements Document) instead, they had the product team brief the product requirements with the virtual team with LoFi prototypes to kickstart the discussions and gather feedback.

• Apart from the regular functional team stand-ups, we felt there is a need for these virtual teams to sync up regularly to ensure integrations, contract discussions, cross-team dependency, changes in the requirements are all discussed just in time and resolved quickly. No more planned meetings to make decisions, it was this sync up calls which happen every day where decisions were made.
• Product MVP features were broken into multiple milestones with well-defined drop dates. Milestones are focussed on adding increment business value to the MVP while covering end to end integration between systems. Every milestone was tracked in these daily sync-up calls to ensure teams meet the timeline, blockers are resolved, and released to a staging environment for testing.
• Quality Analysts (QA) started testing the milestones and were quick to provide early feedback to the developers. Not just QAs, product, and design teams also started validating the product for its correctness and UX respectively way early on in the cycle.
• Breaking down MVP into multiple milestones also helped in de-prioritizing non-critical features in case we can’t make it in time. And those are pushed to post MVP releases.
• This milestone drops, post initial testing was showcased to all the stakeholders including respective business team counterparts to gather early feedback. This got us a business to appreciate how the product is getting shaped while it’s built and provided them an opportunity to shift gears if any without going through the entire planning, prioritizing exercises.
• As the PRD and the designs are evolved and fine-tuned, daily sync-ups were used to communicate the same to the virtual team who in turn would incorporate if there are any changes in the immediate milestone drops.

How did it all help?

All of these helped in speeding up the entire delivery process, yes it is not very different for a typical iterative agile process that talks about a cycle of discovering, defining, delivering, and repeating.

Just that :

• We reduced the entire cycle to hours and days instead of weeks. There are times towards the end of the three weeks, every 3 hours a new app build was released to QAs after fixing defects for testing.
• Virtual team creation and sync-ups amongst them helped a lot to minimize the communication gaps and eliminated never-ending planning meetings between teams.
• Being flexible on cross-role handovers like Design > PRD > Development > Testing > Showcases and instead start with whatever minimal details available and have the respective teams fine-tune it along the process helped catch up on time.
• The business showcases not only helped technology teams to gather feedback also gave a glimpse of how the product is evolving and what to expect from an MVP so that they can be prepared to take it to market.
• Rapido as a business was able to meet the market needs at a rapid pace.

Well obviously, teams had to put in lot more hours than regular sprints to make it happen within three weeks. This may not be sustainable in the long run and most likely so. However, we started getting better at this as we delivered more and more MVPs with this approach. Started estimating better, prioritization got better, time management got better, collaboration got better, the challenge of 3 weeks got them to innovate on ways of working together for better.

Teams have been quite successful in delivering to that challenge of 3 weeks MVP and ended up delivering not one, not two but four MVPs (Rapido Local, Rapido Store, Rapido Corporate, Rapido on Super Apps) so far in the last two months and we have not stopped at it.

The challenge continues and it is only going to get better over time…

_________________

If you are interested in working on exciting products used by millions of users, join our Engineering team. Check out the link for open roles: https://bit.ly/2V08LNc or drop a note on LinkedIn.

3 weeks MVP challenge was originally published in Rapido Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.

While the world is under lockdown due to the COVID-19 situation, technology companies are using this as an opportunity to prove their value or pivot. Some companies are going beyond their mainstream of business and diverting their focus and efforts to help COVID warriors either by new innovations or by tweaking their current products to service people ensuring safety measures.

At Rapido, we took this as an opportunity to help the society, improve the technical aspects of our existing platform, and add new product offerings. Owing to the lockdown, we managed to implement this in record time, which otherwise would have taken weeks.

Social good:

• We have collaborated with Bangalore South MP’s office to provide essential services delivery with a very nominal charge of Rs. 10 along with many other startups and partners involved in this initiative.
• We are doing a fundraise to support the gig workers so that they can make their ends meet.

Technical improvements:

Just like every other startup story, we too were building tech to meet the market demands and always crunched on time and resources. This ends up in growing technical debt which is never-ending.

While some technical debts are managed by the teams as part of their regular sprints, some of the critical ones always take a back seat. This downtime allowed us to focus on them as there would be minimal impact on the business and no disruption to the end customers.

These are some of the tech transformations we managed to do

• We use MongoDB heavily and most of our databases hosting terabytes of data and take millions of queries every day are on quite outdated version 3.x. Rapido runs on a complex distributed architecture spanning across 80+ microservices. Upgrading multiple databases without impacting a business meant a lot of careful migration path and time-consuming. We managed to upgrade all databases to 4.0 and hoping to see better performance.
• We also use Kafka as our streaming platform and use it extensively across microservices. We upgraded our vanilla Apache Kafka 1.x to Confluent Kafka 2.x. We are hoping to take advantage of the confluent’s schema registry with this upgrade. Without downtime, it would have been an immense task of migrating multiple microservices to use the new Kafka though we have blue/green deployments, coordinating between publishers and subscribers and the order of migration is not a simple task given our service dependency graph.
• Kong is our edge gateway for all the internet-facing APIs, we were on version 1.x which had a lot of issues, one that was haunting us was bulk 401’s which used to log out all the users of the platform at once. While we didn’t make much progress to identify what in kong causes this, we were able to replicate this using chaos testing and performance testing. The only way out was to upgrade as we were not able to replicate the issue with Kong 2.0. Given it was our internet-facing API gateway, it had its own challenges to upgrade seamlessly without downtime. This downtime helped us, also we ensured we did not have to log out users while migrating.
• Multiple GCP projects were in play and some of them were classic projects which are deprecated too. Given a lack of complete automation, it was hard to move all the workload to new GCP projects hence dependent on the tunnel to establish the traffic between the projects. Given one end of the tunnel was a classic project it didn’t have support for HA for the tunnel. These tunnels also had a limitation of max bandwidth it can support, so we were seeing some packet drops when the traffic in the tunnel reached the peak. We took this downtime as an opportunity to get rid of the tunnel dependency by automating and migrating all the workload in the legacy classic GCP project to the new ones. No more tunnel dependency and hence better stability.

New product offerings

We managed to build some kick-ass new products within the mobility space to help the customers in the post COVID world.

• Rapido Local is a product offering by Rapido which helps you send packages from one place to another within the city limits. Pick up of the package will be done within minutes of the request and will be delivered right away, no waiting whatsoever.
• With growing super apps in the market, it only made sense to partner with them to provide Rapido services through those super apps. This meant an investment in building Rapido over the web using Progressive Web App principles. We did that, and do watch out for discovering Rapido on other super apps out there.
• We also started sensing the change in consumer behavior concerning their purchases, especially the essentials. A lot more people are comfortable ordering groceries, vegetables, fruits more than ever. We thought why not help local stores and small enterprises to deliver them within the locality, that way helping the local economy to cherish and support the changing customer needs in this post COVID world. We launched Rapido Store to offer the same, now stores can deliver their customers with the help of Rapido with a click of a button.
• With delivery services increasing there is also a need for Cash on Delivery which was a long pending product feature that never made its way in the priority and COVID downtime made it happen.
• Apart from these notable new products we also built a lot of safety measures in the captain and customer offerings to ensure we get through this corona scare without compromising on safety.

All this with a small team of 35 engineers is an immense achievement and we are proud of the team for the compassion and passion they demonstrated during these tough times and added immense value to the people around.

—

We are always looking out for passionate people to join our Engineering team in Bangalore. Check out the link for open roles: https://bit.ly/2V08LNc

Here is what happened at Rapido during lockdown was originally published in Rapido Labs on Medium, where people are continuing the conversation by highlighting and responding to this story.