How to reconcile MVP/fail fast with a 'replace existing product' project?

Question

In general, we as agile IT developers/PMs want to create a Minimum Viable Product (MVP) as a first iteration, get it in front of users, and then iterate and improve upon it.

How does one reconcile that with this?

"We need a new in-house-developed app to replace the 3rd-party app we currently use, which does this and this and this and ... The new app needs to do everything the old one does. We can't turn the existing product off until the new one meets our needs."

...Cue 3 years of development before the 'MVP' is ready?

Answer 1

TL;DR

In my experience, all-or-nothing cloning projects are often a trap companies fall into when they have a non-agile mindset. It often indicates an underlying struggle with process introspection, workflow adaptation, or acceptance of the trade-offs inherent in the iterative/incremental development model.

Don't allow the organization to fall into this trap blindly. Make the costs and the alternatives visible.

Analysis and Recommendations

"We need a new in-house-developed app to replace the 3rd-party app we currently use, which does this and this and this and ... The new app needs to do everything the old one does. We can't turn the existing product off until the new one meets our needs."

While the last sentence is probably true, the agile path to success lies in frame-challenging the assumptions. Since the company wants to move away from the current solution, it's a great time to evaluate how the existing product is being used, and what the desired future-state workflow looks like.

An MVP is really a validated learning opportunity, so you might think of it as a "product spike" to evaluate level of effort, cost, or market demand. What you really need here is a list of minimum marketable features (MMFs) that are truly essential for the to-be workflow. You might be surprised at how few of the existing product's features your various workflows actually depend on.

An organizational desire to clone a product is often covering up an X/Y problem related to:

• Total cost of ownership (TCO), e.g. licensing, support costs, professional services, labor, etc.
• Unresolved bugs or misfeatures.
• Tool/workflow impedance or mismatch.
• Other issues related to integration or support.

It's generally better to make the business decisions about what to build, and what features it needs to have to replace your existing solution, based on real data about each feature. For example, if you want to replace Word with an in-house word processor, you might say:

1. It's a bad idea; it literally took decades to refine Word.

   What are the odds we can build a better mousetrap? Do we have the internal resources to recapitulate 35 years of software development by one of the largest companies on Earth? Is the juice really worth the squeeze, or are we just trying to avoid having to evaluate our cost structure or change our workflow?

2. We don't really need an editor with WordArt or OLE support, so we won't try to clone those non-essential features.

   Maybe we just need a lower-cost editor that can be embedded into our web UI, or some other less-ambitious project. Likewise, do we really need to replace our widget embiggener with a homegrown version that also does turnip-twaddling? Is anyone in our company even twaddling turnips?

3. What's the "simplest thing that could possibly work?"

   Maybe the cloned product truly has zero value unless it's 100% complete. In the real world, though, it's rarely that cut and dried. Chances are you could solve some pain points without solving all of them. Maybe leadership's all-or-nothing approach can be re-envisioned to fit an iterative or incremental development model.

These questions, and other pragmatic and solutions-focused frame challenges can help you identify the real why driving the effort. Without a solid understanding of why, it's hard to properly identify what needs to be done in a test-first or iterative fashion. And without a well-defined set of "what," it is nearly impossible to estimate the level of effort, schedule and cost, and sequential priorities for work packages. If everything is a top priority, then in reality nothing is.

By adopting a more iterative/incremental approach, the company acknowledges that the business objective (e.g. cloning Word) might not succeed. The benefit of an agile approach isn't that it's faster to do the unlikely; it's that it allows more frequent opportunities for the organization to evaluate whether the costs and level of effort involved remain sensible investments for the business. In this case, building the minimum viable product (MVP) consists of just enough effort/features to feed the project's inspect-and-adapt cycle, which then informs the executive sponsors' decision-making process to fish or cut bait.

Answer 2

If I was in this situation, I would start with a simple proposal: run both applications side-by-side.

There are a few different ways to start. You can either start with the most used functionality in the 3rd party application and move this data and functionality over first or you can start with the functions that are most painful to accomplish in the 3rd party app and make them easier to accomplish for end users. Then, iteratively improve them. If you use the same product management techniques that you'd apply to any other Agile Software Development project, you'd eventually reach the point where you can just turn off the original application and be left with yours.

If there's a huge cost with continuing to use the 3rd party application, that may also drive how you do this. This may affect how you prioritize work and when you say that you've implemented enough to make the cut-over. You may realize you don't need complete parity before switching.

Although if there's no good way to get data out of your 3rd party application, this becomes infinitely more difficult. You need to be able to either access the same data in both applications concurrently or be able to build mechanisms that synchronize the data at the appropriate time.

In the absolute worst case, you'd just run your application in a sandbox or demonstration environment and cut over in a big bang style. Probably the most risky, but it would still let you build the replacement application iteratively and then waterfall a cutover strategy from one application to the other. Your IT organization may even have policies and practices in place from other times they've migrated from one app to another, perhaps between two 3rd party applications.

Answer 3

If we make a pretty bold assumption that the 3rd party system is absolutely perfect and there's nothing about it that needs to be improved in the in-house version, then this initially appears to be a project where there is a very comprehensive spec for what needs to happen in any state - the existing system.

If the business logic is all sound but there's going to be a new UI, then you can certainly get going on the domain layer (again, the existing system being a perfect starting point for TDD) whilst going through wireframes and mock ups with the relevant people to decide on the best approach for the presentation layer.

If there are things that need to change in the flow (and that would contradict their statement that the new app needs to do everything that the old one does) then you need to get these bits isolated. It really depends on the nature of the original system as to whether this can be done in an agile manner; perhaps it'll be possible to roll out the new system for a specific type of customer, in whose flow the previous issues existed, but ultimately you are likely to be dealing with separate data storage implementations and so it'll be down to the customer to determine what they prefer there.

The best you could do would be to highlight the various (probably imperfect) options to the customer and let them decide. If they go for the "don't give us anything until it's all complete" then it can still be developed in an agile manner, because you know what the system needs to do.