MVP before Effort Estimation.

A constant pain-point for a developer to meet with the business need in a complex product is to streamline the requirements. Freezing requirements make the developer’s life easy but this goes against the Agile Methodology. As the second principle out of the 12 agile principle says.

Welcome changing requirement, even late in development. Agile processes harness change for the customer’s competitive advantage.

So how do we take the best of both of this world and make the developers as well as PM org’s life easy and happy? (As if the executives will let us. ) and being agile.

Let's recreate a hypothetical scenario of a super-hero Developer named Govind’s life through-out the release cycle rushing to finish up a very critical feature in a release cadence. Govind works for this awesome superhero’s team “The Avengers”.

On the first day of the new-sprint after the branch freeze of the last release, Govind is all excited to pick up a new feature and rule the world. On the same day, he works out with his awesome team and the PO’s for the priority items and gets assigned with a critical epic “Acche Din Ayenge: The Good Days will come”

Now here is a thing. The product with which Govind Works is integrated with other in-house products. Also, it gets shipped with the flagship product of the company so making the cross-team collaboration mandatory. Things do not stop here, The product also has dependencies on the multiple cloud-provider hence external dependencies.

Once Govind gets the rough idea of what needs to be done, He consults with the “The Avengers” and gets on a consensus to chalk out a Spike around this feature. If you see the focus is still on How to do things? and on the possibilities of this single question of how? the team is trying to answer what? to be delivered.

After the fruitful discussion with the “The Avengers”, Govind thinks he is back in the game again. The spike is just a small hurdle after which he will get his hands dirty with the code and rule the world.

Govind now has a rough idea of different datapaths that are going to be affected by this feature. He first goes and checks the external dependencies and their support matrix for this new feature, and boom he finds his first blocker. One of the cloud-provider even though mentioned in their documentation that they support this particular type of action, they have a defect in their system. One datapath is completely blocked, so Govind opens up a support ticket with this cloud-provider and moves ahead with another datapath. Expecting by the time other datapaths are ready this datapath will be unblocked.

Govind decided to check the integration path. Expecting everything is working there, but as the feature is, it is not at all easy to bring “The Good Days”. There is one more defect on the integration path as well. Govind needs to work this with the other team lets say “Justice League”, and “Justice League ” have their own priorities to rush for.

With these two major hurdles, Govind’s effort for “The Good Days” comes to a halt. Govind does multiple follow up’s, aligns the release time-line, talks with the “Avengers”, and finally comes up with this brilliant idea to smash all these hurdles like patriarchy in one shot and that is “Put that in the release documents…….”.

By this time, Considerable efforts have been put into the epic, and still our protagonist and the world-saving team “The Avengers” still don't have an idea what does “The Good Day” means. With one shot, Everything is good the major hurdles have been removed and Govind is back in the game. Govind creates a complete plan, the most awaited “Design Document”, and puts it in front of all the stakeholders. Govind announces, Ladies and Gentleman this is how “The good days” will look like. Everyone is happy at the sight of the “The good days”. But “The Avenger’s” see the possibility of making the “Economy Robust”, they say though not part of “The Good Days”, it can be accommodated in these efforts. They again come to a general consensus of let's do a Spike.

Now Govind has two problems in front of him. The timeline and additional scope change due to the possibility of accommodating other requirements, which are still not clear to engineering. Govind goes on with the spike and finds out that making “Economy Robust” can be pulled but it has more technical problems. Looking at the release time-line it is not at all possible to be pulled in this release. Govind puts his findings in front of the stakeholders, now they again do long brainstorming and comes to a conclusion to drop the “Economy Robust” efforts. Everything is good now, the requirements are streamlined but the release code freeze is in one sprint and there is a mammoth work that needs to be completed. Even though Govind made all the efforts to avoid this last-minute rush, all his efforts went to the vein.

Now the MVP is defined at the last stage of the release cycle. Govind stretches himself, The avengers add extra force to help Govind just the way they do always and the team together pulls this feature and ship it in the release. Everyone is happy and finally, Govind could bring “The Acche din: The Good days” home.

This is a typical developer’s life in a complex enterprise product. Though a brilliant developer and doing everything right. He may end up in a position like Govind. I am of a thought clan that thinks of whatever happens to the business, Make the developer's life easy and productive. It will ultimately help the product to be successful. So with all this long story and nagging, the ultimate question that comes up is What could have avoided this?

Define MVP at the start. If possible even before Govind could pick up the epic, but not mandatorily. The MVP might be very small like say in this “The Good Days”, it could be just supporting the backend or it could have been putting the blockers in the release documents. Once it is done, just like a good agile practitioner Govind could add on things iteratively. Keep on adding the changing requirements in the next immediate MVP. With this approach, the focus could have been on what is needed to be done? Answering this is easier than how to do things. I agree that The what question can be completely vague but it helps focus on the scope and hence more time goes into developing than discussing.

This problem might not come for the products that are completely agile. Who releases their product on the daily basis or on a sprint basis. But the products who can’t do that on these small batches, this might be a real problem.

I open up this topic as a discussion forum. Do let me know what you think?