Rolling out features for Zomato, using Agile

Note — This is not an official post from Zomato. Its more of an exploration of how Agile can be or could be used for rolling out new offerings for Users of Zomato.

In the current product development cycle, its difficult to imagine a world without the now all pervading Agile.

But it may be quite a surprise that Agile was born not too long ago.

From shmula.com —

The idea of agile business all began back in 2001. In the Wasatch mountains of Utah, seventeen people got together to ski, relax, share ideas and of course, sample some tasty food. Amongst them were Agile pioneers Alistair Cockburn and Ken Schwaber. The participants were a group of software developers and programmers who all agreed that a change was needed. Furthermore, they brought their own well-defined methods to the table, including Extreme Programming (XP), SCRUM and Crystal. The meeting culminated in the ‘Agile Software Development Manifesto’, in response to the need for an alternative to the heavyweight, documentation-driven software development processes of the time.

Frankly, ever since I started my career in Product Management/Development, I have grown with Agile, so an earlier Waterfall model is fairly alien to me. I did read about it and it looks something like this —

In the absence of Agile, even this worked for decades.

Looking back, this is the model which is gone for good and rightly so. From perspective of cost, predictability, turn-around time, resource optimization and most important to be nimble, this model is adequately inadequate.

Imagine the whole org doing analysis and then design and so on…crazy eh!

Now lets look at Agile —

Thousands, if not millions of people/teams/projects use this every single day!

Apart from fast turn-around time of all functions in each cycle, what is most critical in Agile is the feeling of various cross-functional team coming together and working as one. This shared buy-in and understanding in my opinion is alone the price one pays for Agile, as a matter of speaking.

Now lets back to the task at hand, as a PM I need to Release the following 3 features, which essentially is my Product Backlog —

  1. Rate & Review Restaurants
  2. Filters for Search
  3. Online Ordering

To simultaneously start all 3 will surely be stretching our whole team and it would also mean no shipping for a long time as each has its own challenges.

For the very first feature which is Rate & Review which goes hand-in-hand I would go for 2 sprints of 2 weeks each.

As a Product Owner I would set-up a team which includes 1 more PM, 2 developers, 1 designer, 1 from Product Marketing and 1 Scrum Master. This team of 7 I believe is sufficiently capable to take a product from concept to launch.

To accelerate the process, we would spend half day on what problem are we solving for the user, how will it help the user once the problem is solved and what is the story/value proposition for the User. From these are Epics, User Stories and Tasks will emerge.

Once the User Stories and Tasks have come out, post assigning it to respective members, its time to get to work.

PMs along with PMM will work on the Story and other Metrics to track. Designers and Developers will work together to start initial brainstorming on how it can potentially look like and how the structure/IA is laid out. Scrum Master is keeping a track at the overall level.

At each of end day, we all will spend 30–45 mins on reconciling what we did and whether directionally we are in the right direction. Key is to iterate as a team and build on incrementally instead of building the whole thing and potentially discarding all of it.

Minor disagreements, we will commit and move on rather than debating about it endlessly. Major disagreements needs to be tackled asap as the presence of this will ensure a healthy co-working atmosphere is forever absent.

While groups of people such as PMs are done with their bit at the initial stages and other functions(Design, Development) are working on it, PMs can also start ideating on the next Feature — Filters for Search and start working on what problem are we solving for the user, how will it help the user once the problem is solved and what is the story/value proposition for the User. From these are Epics, User Stories and Tasks will emerge.

This is essential the power of Agile. Simultaneously different moving parts are working and ensuring collectively we reach our Goals.

We can take this a step further and even invite our actual Users (existing and prospective) to test on Prototypes on the last day of Sprint so that their Inputs and feedback can be considered while planning the next Sprint. Here again the thought process has come from the intent of building incrementally (small features of large features) and iteratively (take feedback often from first within us and then even with Users).

This approach saves tremendous amount of resources and one significant side outcome is that teams are motivated as they are seeing “ship-worthy” code being churned out in a much short cycles instead of waiting months or may be even years of endless design, development and validation cycles.

Depending on the nature of the product, Teams can also involve yet another bigger group in terms of Marketing, Legal, Finance and get their feedback and buy-ins while the process is on. Its like slowly jumping on a moving train, not falling and also not stopping the train.

Here I have attempted to describe more the overarching style of how Agile works rather than going into details at each step which will lead to a much bigger post without adding much value.

We can always have a follow-up post on this, post our successful launch of new features and how the metrics are faring. :)

All things Product Ops & User Research, currently @ Tally Solutions, Bangalore, India