Agile Methodology

Intro
Agile is an extremely useful methodology of software development. In recent years, it has been adopted by a majority of software companies and it has replaced the traditional approaches like Waterfall. The reasons are obvious — the world is uncertain and product requirements change often. Technology is growing rapidly and companies want to use the latest and most robust tech stack. The market disruptors like Uber & Airbnb have found success using this approach. This raises the question — what is Agile?
Agile is a mix of incremental and iterative approach towards software development. It reaps benefits of both the approaches and ensures we save time and effort while building a software that is relevant and is accepted by the user. Let us understand what incremental and iterative approaches are.
Incremental Approach
An incremental approach is one in which the product team understands the required features well but likes to stagger the build and release of those features in order to minimise effort, ensure product-market fit and utilise market feedback to make the features more relevant. For example — say a recently launched food delivery app wants to offer various payment options like Credit/Debit cards, NetBanking, Mobile Wallets, Cash-on-delivery etc. Following an incremental approach, the product team decides to implement the card payment option first. Once the phases — design, implementation, testing and deployment — of this payment option are completed, some time later, the same approach follows for the NetBanking option, and some time further later, the same approach follows for mobile wallets and cash-on-delivery option. So the required features are well understood but the build and release process are staggered.
Iterative Approach
Contrary to this, an iterative approach is one in which the product team understands user problems but is not completely sure of the desired solution. That’s where a product manager makes a paper prototype of a solution and presents it to the existing/prospective customer. The customer provides some feedback and the product manager utilises that feedback to improve the prototype. Later a click-based wireframe is created using a tool like Balsamiq and is presented to the customer. Once again, the customer shares feedback. Further updates happen and finally the actual product is built. The feedback so far refers to a conversation, but in practice, this feedback is also derived from user surveys. BookMyShow (BMS) used the iterative approach extensively. The goal of BMS was to make movie watching experience easy and convenient. They started as a platform that helps a user buy movie tickets. Some time later, through interviews and user surveys, BMS realised that their target audience faced some more challenges, like standing in a queue to get movie tickets from the counter and standing in a queue to purchase snacks and drinks during interval. So BMS came up with M-tickets which had a QR code that could be scanned at the entrance of the theatre. No longer standing in a queue to collect a ticket that you have already purchased online! Similarly, BMS came up with an option to purchase snacks and drinks online. Once you buy them online, the snacks and drinks are delivered at your respective seats.
Agile Methodology: An Example
Having understood the 2 approaches in isolation, let us see how the benefits of both the approaches can be reaped in the Agile methodology. Let us look at the feature release of an Indian restaurant discovery app — Zomato. Assume that Zomato is in its infancy and does not have features like rate/review restaurant, filters for search, online ordering etc. The product team at Zomato needs to decide the best way forward. For the sake of this article, let us assume that only the following 3 features need to be built:
- Rate/review restaurants
- Filters for search
- Online ordering
As mentioned earlier, Agile uses a combination of incremental and iterative approach. So we will take an incremental approach and will not start building all the features simultaneously. Instead we will utilise the user interviews and surveys to find the most valuable features for the users. Once we figure that out, we will take an iterative approach to build those features.
Let us assume that the user surveys and interviews indicate that the users will find “rate/review restaurants” most valuable. So we know the required feature now. But we don’t know the best way to bring that feature to the user. We don’t know what UX will be delightful and effective. So we will take a staggered approach. We will further break down this feature into smaller features and start the implementation process.
Rate/review restaurants feature can be broken down as follows:
- User feature: Provide a rating on a scale of 0 to 5
- User feature: Write a review
- Restaurant feature: Reply to user review
- User feature: Like a review written by another user
We can start by implementing the first sub-feature: ask users to provide a star rating to a restaurant. This is easiest to implement and we can gather user feedback quickly. We can do AB tests to find the most effective UI/UX. Once this is implemented successfully, we can implement the next sub-feature: ask users to write a review. If the feature does not get desired adoption, we can conclude that market doesn’t need this feature and we might have arrived at a wrong conclusion through our research. The other possibility is that our user research was accurate but our UI/UX is not effective and users are not able to find the rating feature. So we can experiment with various UI/UX options till we get the desired adoption. We can then incrementally build the remaining sub-features.
However, we can adopt an alternative approach as well. As soon as the first 2 sub-features of the “Rate/review restaurants” are built, we can start working on the 2nd feature: Filters for Search. That’s because the 1st sub-feature of “Filters for Search” option might be more valuable than the 3rd sub-feature of “Rate/review restaurants”.
Let’s look at the possible sub-features of the feature: Filters for Search:
- Filter restaurant by location
- Filter restaurant by cost
- Filter restaurant by star rating
- Filter restaurant by cuisine (Asian, continental, North Indian etc.)
- Filter restaurant by category (dine-out, drinks and nightlife, Thali etc.)
- Filter restaurant by offers (discount offers from various banks)
Again, we can start the implementation incrementally, moving from the 1st sub-feature to the last sub-feature. The first 3 sub-features are most important. These are essential details to find a nearby restaurant within your budget. The other details like cuisine and category can be easily found on the restaurant description page, even if there is no filter. So we can choose to implement the top 3 sub-features first and move on to the remaining sub-features of “Rate/review restaurant” or we can choose to implement the third feature.
Implementing the third feature, Online Ordering, comes last because clearly it requires a lot of effort, not just in terms of product development (integration with mobile wallets, payment gateways etc.), but also in terms of working on the delivery logistics. Moreover, it has a dependency on the previous two features. For example — it does not make sense to have this feature without the more fundamental features like rating/review of the restaurants. If a user cannot figure out the quality and the taste of food at a restaurant, why will she make an online order? Similarly, without location-based filters or price-based filters, it will be cumbersome for a user to find the right place to order food from. So the adoption will be low. That’s why this feature will be implemented last.
The following could be sub-features for Online Ordering:
- Payment implementation: Integration with a payment gateway like CCAvenue and partnering with a last-mile delivery vendor
- Capturing the Net Promoter Score after order delivery
For the purpose of illustration, we assumed that Zomato just needs to implement 3 features. However, in real life, requirements are not static. They are dynamic and their influx has to be managed by the product manager. Unlike Waterfall, Agile provides a way to accommodate new features and changed requirements. For example — if we realise that users are adding fake reviews, we can add a new sub-feature that requires users to signup using their personal email address in order to add a review. This changed requirement can be implemented very fast using the Agile methodology.
Agile further helps because the features implemented using Agile methodology reaches the customer fast and the customer feels engaged when we seek their feedback. This engagement is essential for retention and recurring revenue.
Conclusion
Both Waterfall and Agile have come from the human experience in manufacturing industries. However, Agile is way more superior as illustrated in this article. Agile is the modern way of building a software. It is an industry standard and you should adopt it at the earliest. It will be your competitive advantage. Do bear in mind that the spirit of Agile should not be lost behind a mountain of processes.
