Let’s admit it, we have heard the term “Agile” far too many times by now. Due to the very fact that Agile Manifesto is fairly flexible with the details, my view agile is not going to be the same as yours. Similar to the classic adage on opinions — “Agile practices is like wrist watches. Everyone’s watch shows different time, and everyone believes theirs is the most accurate.”.
Here is mine, based on close to a decade of experience participating in and implementing various kinds of agile methodologies.
Agile is the product development practice that keeps the user/market in mind at every phase rather than the product itself. It depends on iterative and incremental development/ship cycles to make sure the product achieves the best possible product market fit. I know, I know, for some of you this looks a mangling of words between Agile and Lean thinking (thanks, Eric Ries!). But that is the truth of it, for me. Without validated learning from the market/user you have just made a thousand cuts on the waterfall model (the traditional, year long ship cycles) — which is worse than just doing it the good old way (which still awesome if you can describe your problem, users/market and solution clearly)!
I am saying this because if you don’t get feedback you might as well make your design “bullet proof” by spending a couple of months on it rather than neither nailing the design, not nailing the product-market fit.
If you want a shorter version of that rant —
If you don’t have validated learning in short time(say a month or two, max) from your “agile” methods, what you are really practising is “death of waterfall by thousand cuts”
Many of us in the tech industry have by now gone through at least one “agile implementation” cycle. I am sure, everyone will agree it is one of the hardest transitions to make, especially for older organizations. The truth is bringing the true agile thinking requires a really strong political will from the leaders and serious efforts at the leaf level leadership. Why?
- It’s a huge shift from those fixed, mega release, in long timelines approach
- Iterations can seem chaotic to the new adopters
- Organizations have always been functionally divided (competency clusters, if you may) whereas agile requires T shaped skillsets (people who are experts at one thing and a few other things reasonably well). Trust me, this is the hardest part to achieve — it takes org changes, training, influencing people and every other aspect of classic change management
- Entire release, deploy/deliver cycles of older software realm is irrelevant because of ship cycles of continuous to a few weeks, at max. As I said, if you can’t do this, I don’t think you are agile enough.
Anyway, back to the original question:
What is really agile, then?
Let us take Zomato as an example. Zomato is one of the leading food ordering/restaurant listing apps in India. They have a great curated list of restaurants along with reservation, food order and many more conveniences.
Let us say you are the PM working on the below highest priority items in the Product Backlog(Wishlist for your Product, the Zomato app).
- Rate/review restaurant
- Filters for search
- Online ordering
If your Agile implementation framework is Scrum, and it’s well sorted, you would have a 2–3 weeks Sprints (time boxed cycles where you must ship something useful to the user, and can get feedback from users/internal and external stakeholders). At the end of each cycle your software team ships code that can be deployed by your Ops/DevOps team and users can start using. While all this is happening continuously, you must make sure you keep the next set of items ready to be consumed by the software team (above three, in our example). To get them to the user, you will surely need these steps at the very least.
- Ideation
- Design
- Implementation
- Testing
- Deployment
Mind you, this is in addition to the market research/user research you need to carry out before prioritising these items in the Product Backlog, and bringing to to the Spring Backlog (items the team will work on, in the next sprint). This will be estimated and planned for in Sprint planning session.
To kickstart the process, you must define the items in Product Backlog as User Stories(Concise requirements which initiate discussions between you and the implementation team). Let’s take our example:
Rate/review restaurant
“As a restaurant customer I want a mechanism where I can leave a feedback for the restaurant after my visit so that others can benefit from sharing my experience”
“As a user looking to dine in my area, I want to be able to view the reviews and overall ratings of the restaurants of my interest, so that I can go to a good restaurant that fits my tastes and budget”
Filters for search
“As a user looking to dine in my area, I want to be able to search for restaurants by cuisine and location, so that I can go to a good restaurant that fits my tastes and budget”
“As a user looking to dine in my area, I want to be able to search for restaurants by rating, budget and location, so that I can go to the best restaurant that fits my tastes and budget”
Online ordering
“As a user looking to ear at home, but not being able to cook, I want to be able to order the food of my choice from a restaurant of my choice”
Note, many of these are just discussion starters and not the ten commandments of your product’s features. Be flexible when discussing with the development team. Many of these will get split into smaller stories if the scope is too wide. For example, can you spot what’s happening with the item “online ordering” above? It doesn’t delve into details of how do you implement a cart, how do you update the address, how do you pay. It’s probably way too many things to implement in a Sprint of three weeks unless you have Chuck Norris on your development team! But as I said, it’s good enough to kick start the process, so let’s get back to the process.
The Process
Ideation
This is where you discuss with the core team which consists of repesentation from developers, designers, other PMs, executives etc and run them through the ideas to see if you have a high level agreement on the intent. You will probably also get some paper prototypes ready so that people are on the same page. Remember, visuals are better than pages of text. There are no more ambiguities about what needs to be done.
Design
In this stage you get to the specifics. The stories become much more detailed. Your development team have charted out the software architecture, designers have mockups ready and there are no more ambiguities about how it can be done (Not always true, especially if you have complex inter platform interactions and not everything is known. So be flexible here.). By the end of this, you should pretty much have a clear Acceptance Criteria defined for each of the user story.
Implementation & Testing
With clear requirements in the User Stories, the development team can pick the user story in the next Sprint. So, they estimate it during Sprint Planning meeting, add tasks required to achieve those. Estimation may be by hours/days/story points. It depends on the comfort level of team, mostly. The goal is not to micro manage how much time is taken to do something, the goal is to get better at predicting how much effort is required for certain kinds of user stories. This helps in keeping the stakeholders sane, in keeping team members sane. And, of course Product Planning/Roadmap (process of telling what comes in next 6–12 months and when will it probably come) gets better too. The development team also holds a daily meetings called Daily Standup, which is for each member to discuss what they did yesterday, what they plan to do today and are there any impediments. In case of impediments, the designated Scrum Master is responsible to address them at the earliest. Note, you can join the Daily Standup, but that’s not mandatory and depends on your teams composition. And, you *cannot* be the Scrum Master. By design these are conflicting roles where you are asking for more features in shorter time and Scrum Master is working on making the model sustainable.
At the end of each Sprint, the team shall demonstrate the shippable iterations/increments they have achieved to the stakeholders in the Sprint Review meeting. This is where the PM makes go-no-go decision for the output. This must be followed by a Sprint Retrospective, in which Sprint team discusses what went well and what did not in the last Sprint and takes action items to improve the process.
Note: I combined Implementation and Testing here. Reason — it is always better to have the implementation to be test driven. Now, what the hell does it mean, you ask? It means your developers continuously test what they produce everyday. Ideally, as programmers write their low level design document in the first couple of days of the sprint and clarify their questions, members responsible for testing the software write test cases to be executed against the acceptance criteria. Both parties run it through each other, as well as the PM, so that all are on the same page. Then, as the programmers implement code, they also write unit tests (code to test code, duh) while the test engineers work on automating their test cases, as much as possible. The idea is to test what your team produces out in automated fashion every day, or better yet, on every new piece of code committed to the code base. Why, you ask? Because you don’t want this feature to break because of something you ship next week, do you? Really, that’s what happens all the time after your product gains a critical mass. So, avoid it as early as possible.
Exception to the above rant — if you are A/B testing or doing any other kind of validation, you could potentially skip the automation part. Reason — you probably will end up throwing it away. You are only trying to validate an idea!
Deployment
Again, this is where many of us have faltered. We produce code every two weeks, but software goes live after 2–3 months. I think that’s almost always terrible. All that discussion, high intensity development effort – all would have faded by the time you have the results from the field. Often the discussions will end up sounding like “Uh, why exactly did we make the rating system a likert scale? I think it should have been thumbs up/down.”, while the fact maybe you would had discussed it to death before implementing. Good DevOps practices are critical to achieve quick deployment cycles.
Aim for continuous build, continuous deployment from the early days so that you don’t find the deployment process scrambling to catch up with the development cycles as the product scales.
Iterations
Let us say you did all that.
Your “Rate/review restaurant” user story may completely bomb. People will probably give a 5 star rating (because your app is lovely) and rant about how horrible the service was. The whole purpose of rating the restaurant will not work then. With that feedback, you may redesign your rating workflow to include a simple thumbs up or down with clear context telling the user, he is rating the restaurant and not the app. This new change is a story in itself, and is technically known as iteration.
Increments
Let us say you implemented only cash on delivery under “order online”, owing to the technical/legal challenges in implementing the payment gateway integrations. In the next sprint you may choose to integrate mobile wallets to payment process. This is adding to your original user story/epic and is known as increment.
Bringing it All Together
Agile is not a one size fits all solution for all the software product world’s problems. One needs to pay close attention to factors like company culture, organization structure, organization culture, software complexity, interdependencies, and more than all the market directions, speed and unpredictability before taking a call on how work with Agile models.
Thought Farming 