Forced to "predict" MVP delivery

Why not offer them an MVP each and every Sprint which allows product assumptions to be validated, and risk and uncertainty to be controlled?

Hi Ian. Here's their thinking

Existing Old App has the following features:

1. Able to login

2. Able to view available flights

3. Enable filters and search functionalities in the flights

4. Book a flight

Let's say the MVP app should have the above features plus this:

1. Should have a push notification for events and discounts

I was able to convince them that the MVP shouldn't include the  new feature just yet. But still they argued that why release a NEW app if it has lesser features than the old one. I find the reasoning logical (or am I missing something?) If that notion is correct, how can I convince them that pressuring the team to deliver on a specific date for the MVP could be hurtful in the long run?

Marvin, is there a thin layer for each of your features that can be part of your MVP?

For example, 

1. One user type able to login, or the ability to login without any additional signon features like password masking, password rules, etc.

2. Able to view one type of flight

3. Enable one filter to search for one flight attribute

4. Book a flight

5. Enable a push button to display events

Then, build additional functionality on top of this 1st "cut", and continue building it out until you reach whatever target date they have in mind.   All the functionality desired might not be completed by then, but they'll have every opportunity to select what can be built by that date.

how can I convince them that pressuring the team to deliver on a specific date for the MVP could be hurtful in the long run?

Aren’t there technological risks and uncertainties in developing the new app that ought to be brought under control, Sprint by Sprint? How can the organization guarantee to your team that this will happen by a certain date?

My advice is to consider delivering an MVP every Sprint, each of which will address a significant part of the technical uncertainty. Rather than starting from scratch, consider gradually upgrading elements of the app. Architecturally this could mean applying the “strangler” pattern for example. There might be a need for component teams, at least initially.

@Timothy if we do that approach, does it make sense if we "release" each and every sprint?

@Ian please pardon my ignorance but how do we create an MVP every sprint? Do we create an increment from scratch every sprint?

Also, does Strangler effect work on mobile apps? I'm sorry I don't have a dev background so I'm not so sure.

@Timothy if we do that approach, does it make sense if we "release" each and every sprint?

Wouldn't the product sponsor(s) make that decision?   Isn't it still important to have something potentially releasable at the end of each sprint, to allow for that decision to be made?

@Ian and @Timothy have given good advice and I'm going to add a verbose discussion that I hope points out a way of thinking that could benefit you in justifying your position.

But still they argued that why release a NEW app if it has lesser features than the old one. 

To answer that let me go back to you original post.

It's shabby and their users hated it. They wanted to change that so they decided to overhaul the app. Probably use new technology and the team will have to start form scratch.

I am going to assume that by overhauling the app and using new technology the app will be more stable with better performance. Isn't that delivering value to your customer base?  Providing an MVP with exactly the same functionality that works better is going to give you an opportunity to measure and validate the assumption that drove the decision to overhaul. 

If that MVP is successful, then add new features.  It is possible that your overhaul decision fails in the marketplace.  You may have to revert back to the original product and try another approach.  If you add features to the "new" MVP, rolling back will require that you implement a new feature before doing so. 

If you are the Product Owner(PO) you should be able to reflect on why the decision was made and arrive at some kind of argument similar to what I provided.  If you are the Scrum Master(SM), then you should be letting the PO deal with this as they are responsible for ensuring the Development Team is working on the correct things to deliver the value that is needed. As SM you should support the PO in any way that they need you to. 

BTW, I know this all sounds great in your head but actually doing it is not easy.  Welcome to agile. It won't make everything easier or faster but it will surface organizational problems.  This situation is an organizational problem. 

Thanks everyone. Seriously this is what I love about scrum.org.

PO hates me more than ever. She says i'm too stubborn to insist that deadlines shouldn't be focused in agile. I raised to my manager but he said that I just need to "work my way around it".

It's just frustrating that because of these so called controls in place, the team focuses on "CYAs" instead of actually delivering a product.