A Case Study on Zomato - How Agile Can Help to Generate Early Feedback While Building New Features

Disclaimer: This is not an official post from Zomato. This post is more of the strategical quest to understand how Agile could help Zomato to generate early feedback cycles from end-users to gain more user insight while rolling out new features.

Brief Introduction About Zomato

Zomato is an Indian multinational restaurant aggregator and food delivery company founded by Deepinder Goyal and Pankaj Chaddah in 2008. Zomato is a restaurant search and listing application that provides information, menus of restaurants as well as food delivery options from partner restaurants in select cities. As of 2019, the service is available in 24 countries and in more than 10,000 cities. They are on a mission to better food for more people.

Why I am here?

I am here to share my views about how Zomato can generate early feedback from their end-users while developing new features. Lets’ talk about the development of the following three features of Zomato:

• Rate and Review
• Filters
• Online Ordering ( Payment )

Before start discussing features, let’s understand why Agile is having the upper hand in comparison to the conventional software development model — Waterfall or V Model?

Waterfall — Conventional Software Development Model

Waterfall Model is a sequential, linear development process. It consists of several discrete phases that flow like a waterfall through all phases during the development process. Flow like waterfall means no phase begins until the prior phase is complete. Waterfall does not provide us the liberty to return to a previous phase if parameters change along the way. The only way to revisit a phase is to start over at phase one. The waterfall model is having 5 different phases.

Fig 1. Different Phases of Waterfall

Fig. 2 Waterfall Model

Even though this model is ideal for developing software when we have more knowns than unknowns. But with this model, we’re not able to get user insight early in the development cycle. The major disadvantages are:

• Users are not involved in the design and implementation stages so users are often not aware of what they want at the end. They start raising change requests and new features later in the process when they’re harder to accommodate.
• Deadline creeps — when one phase in the process is delayed, all the other phases are delayed.

In a nutshell, Waterfall is rigid and inflexible. To introduce flexibility and generate early feedback during Software Development Life Cycle aka. SDLC process, V model start becoming popular.

V Model — Improved Version of Waterfall

V Model is based on the concept of Verification and Validation. In each step of development in the V-Model, there will be a corresponding assurance phase that will be validating the respective step. Testing Phases will be planned in parallel with development phases.

Fig 3. Different Phases of V Model

Fig 4. V Model

Although the V model is able to provide flexibility to accommodate changes but still user often not aware of what they want at the end as there is no working software to visualize. To provide transparency and generate an early feedback cycle Agile methodology comes into the picture.

Agile Methodology

The rapid pace of development today has given birth to the Agile methodology. It incorporates both iterative and incremental product development processes that emphasize continuous planning, understanding, updating, team collaboration, development, and delivery.

Iterative development refers to when the team builds the product requirements in iterations and there are constant releases of iterations for feedback by users.

Incremental development is an approach that breaks down the product into fully working slices known as increments.

Fig 5. Example of Iterative Vs Incremental Development

image credit — What is the difference between iterative and incremental in Agile?

There are four values that drive Agile working.

• Individuals and interactions over processes and tools
• Working software over comprehensive documentation
• Customer collaboration over contract negotiation
• Responding to change by following a plan

There are different branches of Agile methodology

• Kanban
• Scrum
• XP ( Extreme Programming )
• Crystal
• DSDM ( Dynamic Systems Development Method )
• FDD ( Feature Driven Development )
• Lean

Scrum is the most popular is majorly used Agile methodology so we’ll be going to discuss it further with Agile Scrum.

Scrum Methodology — Most Popular Agile Framework

Scrum is not a process, technique, or definitive method. A process framework within which people can break complex adaptive problems into the smallest releasable chunks, while productively and creatively delivering products of the highest possible value. Scrum is founded on

• Empiricism asserts that knowledge comes from experience and making decisions based on what is observed. This is based upon 3 scrum pillars ( Transparency, Inspection, Adaptation )
• Lean Thinking reduces waste and focuses on the essentials.

Fig 6. Scrum Cyclic Flow

Scrum is a continuous development process that works on continuous delivery and continuous improvement.

Fig 7. Scrum Process at a glance

Scrum in a Nutshell

• The Scrum framework consists of Scrum Teams and their associated roles, events, artifacts, and rules.

Fig 8. Scrum in a nutshell

Scrum Roles

• Scrum Master

1. Servers as a Servant Leader .

2. Coaching the team members in self-managed and removing their impediments

3. Helping PO to find techniques for effective Product Goal definition and Product Backlog management

• Product Owner

1. Developing and explicitly communicating the Product Goal

2. Creating, communicating, and ordering Product Backlog items

• Developers

1. Accountable to turn the Product backlog into releasable increment

2. Creating a plan for the Sprint, the Sprint Backlog

3. Instilling quality by adhering to a Definition of Done

Scrum Artifacts

Each artifact contains a commitment to ensure it provides information that enhances transparency and focus against which progress can be measured

• Product Backlog

Owner: Product Owner

Commitment: Product Goal

• Sprint Backlog

Owner: Developers

Commitment: Sprint Goal

• Increment

Owner: Developers

Commitment: Definition of Done

Scrum Events

• Sprint
• Sprint Planning
• Daily Scrum
• Sprint Review
• Sprint Retrospective

Fig 9. Scrum Events

Scrum’s approach to product development is as follows:

• Analyze requirements and break them down on the basis of features and sub-features level.
• The feature is known as Epic
• All sub-features related to common features will lie under the same Epic
• Sub features are known as user stories.
• Break the total work of Epics into multiple releasable chunks (also known as a user story)
• Start analysis for User Story — 1
• Design of Feature1
• Implementation of User Story — 1
• Testing of Feature1
• Release User Story — 1 as a working increment and move to User Story — 2
• Based upon team velocity, the team can work on multiple user stories of the same feature or a couple of stories of different features at the same time too.

Let’s back to the task for which we are here — development of the following three features of Zomato:

• Rate and Review
• Filters
• Online Ordering ( Payment )

Below are a few considerations & Assumptions before we kick start resolving.

1. The listed features are not yet implemented and the Product Manager and Product Owner are figuring out Creating Stories for the Features.

2. We’re planning to build web, iOS, and Android applications.

As mentioned earlier, let’s use Agile-Scrum to develop three features for Zomato. It is not possible to pick all three requirements simultaneously. As a Product Manager, I would propose to set up two scrum team which includes 1 Product Owner, and 5 Developers ( 1 backend + 1 front end + 1 iOS + 1 Android + 1 QA engineer) for each team with 1 Scrum Master.

Before kick starts the sprint as a PM I will set up a few initial Ideation sessions with both Product Owners to discuss, refine the initial requirements and do initial Story Mapping. Once we are all three on the same page then we’ll create 3 Epics for Rate and Review, Filter, and Online Ordering Feature. Team A will be going to own the Rate and Review and Filter feature and Team B will be going to take ownership of the Online Ordering ( Payment ) feature. Now both the teams need to start working in Agile Scrum fashion as follows

Product Backlog Maintenance

Product Owner of both the teams start writing initial user stories for their respective Epics and maintain all users under the same Product Backlog to maintain the transparency for other teams so that other teams will not go to plan and pick any redundant work. Before PO will be going to starts discussing user stories with the team we all 3 ( PM and PO ) go for another round of refining sessions to check for any gaps and order the stories of both teams based on user expectations, complexity, and market needs, and other required parameters.

Tasks are arranged in priority order with the highest priority on top to the lowest on last. Now Product backlog is ready for scrum teams to start to discuss for planning and estimations.

Once the product backlog is ordered PO of the respective team goes for one more round of Story Mapping sessions with their team to identify any gaps or complexity in requirements so that they will be able to give initial estimates on iteration delivery.

Story Mapping

Rating & Review Feature

Fig 10. Rating and Review Story Map

Filter Feature

Fig 11. Filter Story Map

Online Order ( Payment ) Feature

Fig 12. Online Order ( Payment ) Story Map

Sprint

Normally 1–4 weeks. Let’s assume our sprint teams decided to opt for 2 weeks sprint to generate early feedback.

Sprint Planning

During the sprint planning meeting, PO will be going to explain stories from the top of the Product backlog and the team start discussing and refining the stories and plan to deliver. Once everyone is on the same page developers need to estimate stories based on complexity. After estimations team needs to pick stories based on team velocity. Before ending the sprint planning team needs to set a sprint goal so that during the sprint team will be focused.

Daily Scrum

• Daily Scrum is to inspect progress toward the Sprint Goal
• Adapt the Sprint Backlog as necessary, adjusting the upcoming planned work

Sprint Review

• During Sprint review developers will showcase the increment of the current sprint and gather feedback.
• The purpose of the Review is to inspect the outcome of the Sprint and determine future adaptations. This is never a PowerPoint presentation but it is a working session.

Sprint Retrospective

• The purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness
• Inspects how the last Sprint went with regards to individuals, interactions, processes, tools, and their Definition of Done.

At the end of every sprint, both needs should deploy their increment for users’ consumption. This way we can get users’ insight on newly to build feature and we can inspect and adopt them in subsequent sprints

Summary

This is how product features are added using Agile methodology. It all depends on the requirements and complexity to choose the development process. During every sprint, the Agile Scrum team follows the following steps to deliver work and gather feedback to adapt accordingly.

• Ideate
• Design
• Implement
• Test
• Deploy

Agile helps teams to

• Embrace Uncertainty
• Welcome Changes
• Celebrate Failures
• Always Learning
• People First
• Full Collaboration
• Value Obsession

Agile methodology allows the Product Manager to generate early feedback and accommodate change requests raised by users. This increases the transparency which in turn provides happy consumers.