Agile transformation: Explaining Agile when you already have an old car

Usually when you explain agile for the first time to any audience, you put focus on reviewing the values and principles, with a quick example on how minimum valuable increments will help you reach safer to the goal solution, incrementing your knowledge base on what you are trying to solve. on each delivery.

A common example is that of the car being built with the waterfall and the agile approaches.

As a first take on agile, this always proves to be clarifying. But sometimes difficulties start to show up when this is put into a real situation in a organization facing an agile transformation.

Most likely, if you are in a company which already has an IT area, it already has a software product -or set of products- that covers everything they need to keep the business running. That means, to follow the analogy, that you "already have an old car", so the customer might have a clearer idea of what he's expecting.
Under this circumstances, is when the concept of MVP -as in Minimum Valuable Product- starts to form differently in IT and customer's point of view.

Have you analyzed creating a ship of theseus?

The Greek myth of the Ship of Theseus, talked about one which was kept docked in a harbor for posterity as a tribute to Theseus’ travels. However, as it weathered and aged in port, parts of the ship were replaced, until, eventually, all of the ship had been replaced.

The question is: Once every part of the ship has been replaced — where none of the original components remain — can it rightly be called Theseus’ ship?

while this is an interesting philosophy question,  we'll focus on its application to any creation and its maintenance: So you can create a new product without disposing the old one.

One thing that we usually tend to think is that when a lot of tech debt piles up, we have a legacy product, that needs to be deprecated in order to make space to the newly fresh and improved product, done from scratch as new. Unless you need to do a language or technology jump, what you have there is legacy code, and legacy code ceases to be legacy when a new feature demands a refactor.

There are a few questions that are key for us to consider to make that decision:

• Was it done with high quality? 
• Is it on the modern tech stack?
• Is the future more important than the now? 
• Are the legacy product programmers still part of your team?

To create a whole new product is a decision that needs to weight -for starters- each of these questions.

Are the capabilities not useful in the future?

So to keep using analogies, you might have an old car but might be trying to build an airplane. Some of the things are similar but most likely, you can't say that the MVP is "at least the old car", since the Car might not be aerodynamic and its design will make a lot more difficult to change it all together than to create a new one. So, What to tell people expecting that? Well that the first delivery will aim to fulfill the original objectives you have, "transport and built to be able to fly", so maybe the ash tray and the comfortable reclining seats won't be there -at first-. You can always with the first delivery define that the seats are the next priority, instead of flying higher, having a bathroom or whatever else is on your backlog.

 Was it done with high quality? With capabilities useful in the future?

If this is the case, you probably shouldn't dispose the legacy product so lightly. Most likely by refactoring only the things needed you'll be fine. Either old or new tech, is still working tech.

Is it on the modern tech stack? with low quality?

If it's on the modern tech stack, most likely you'll find people that will be able to improve it. Now it will depend on how much pressure you have to have that working now vs having worrying about the future. If you are in a hurry, then moving to a whole new product might not be an investment in time you can take.

I don't want to go too deep in this subject, since there's a lot to talk about, but here's a small table  with a few example cases for you to take note:

Legacy Product	Future > near term	High quality	Legacy devs still part of your team?	Modern Tech stack	THEN
Product A	No	Yes	No	No	Keep it and refactor.
Product B	Yes	Yes	No	No	Keep it working and start moving things to the new product.
Product C	Yes	Kinda	No	Yes	Keep it, and fix only when its impacting the client.
Product D	Yes	No	No	No	Start over
Product E	Yes	Kinda	Yes	Yes	Keep it. Part of the job will be to refactor to make new features fit.
Product F	No	No	Yes	Yes	You'll have to work with what you have and start thinking on what to do when you get out of the fire.

Product A	A working product as this one does not need to get retired, specially if there's no need to add major capabilities.
Product B	If you don't have the team who built this but is still a great product, and you need to add capabilities that are widely different, reuse what has been created, bringing it to the new tech stack. Have the stakeholders keep using the old one and join you for feedback on the new one.
Product C	Most likely you can keep this working, but you'll need to avoid changing things that are not impacting the client. It's possible that you get a case of whack-a-mole chain reaction.
Product D	Nothing useful to keep, noone to explain you how did they do this, this not being part of the modern tech stack: starting over is a good call.
Product E	Even if some things "could be better", that's not reason enough to drop it and move forward with a new other product. You will still face problems like the Product C had, but to solve them should be a lot easier with the team that worked on the legacy still here.
Product F	It's where no one would like to be, you have people with constant complains about the product. But you'll have to work with what you have.

Pitfalls (going back to the old way)

This product was more or less good but it became too complex, let's create a new, better one.

Make sure you have analyzed thoroughly the variables I presented along with the ones you already had. Reinventing a whole product will demand between 40% to 80% of the original time spent in the old car to get you something resembling to it, working, and until then you will get no actual value.
Still you'll need the stakeholders/clients to understand the value of having a short user feedback represented by short deliveries. Having something not even resembling to the old car but fulfilling all the specified functional needs being demoed, is a step taken in the right direction. The problem resides in the difference of expectations, you need the PO to be clear with what can and can't do the product you'll have on its first delivery, and push back on stakeholders threatening you to consider the product as unuseful if you don't do a specific feature: avoid getting your teams blackmailed on features. This is a long term vs short term game you are leveraging, so make sure you choose what's best there. Stay truthful to the vision you are trying to accomplish.

(With the legacy product) We already know all the things we want in the product, so let's document all of it and do this right now.

We know what we want now, but it could be that with tech upgrades, market movements, or many things more that could happen in the future, we have a change in our priorities, and we embrace in Agile that we can't predict the future but we can cut our losses a lot better by short adjustments,  otherwise you might be building the new legacy product.

I cannot approve a page/screen that is not completed as an MVP.

A full screen, "with the cherry on the top", even if this feature is the first one you agreed as MVP, could be an overreach when you have multiple features to deliver. Even if not, you need to cease the opportunity to maximize the amount of work not done, by delivering only what really fulfills the purpose, which would be earlier than when the full page/screen would be, and again, get the feedback that will move you forward on the next most important thing.

How to do it

In my experience it's not that the stakeholders lack understanding on these facts, but instead that they do not feel responsible of the product's outcome, as if getting to the project's success would be something IT has to figure out by themselves. What you'll need to work on, (if this is your case) is on involving them in the process: they are part of the project and a key part to its success (or failure). Under the agile framework The stakeholders and the IT side should have a common goal and a shared vision, which is the success of the product/project.
The ways I used to get that from them is by sharing constructive gathered feedbacks and doing activities with the stakeholders, where they had to be the team:
An engagement and alignment survey feedback done with everyone directly involved in the product
A group of activities where they had on firsthand the team's experience.

Activity

There's one of those short activities I've done that got everyone entertained through a self educating experience, which was to get people to create their own agile story mapping.

Duration: 40 minutes
Materials: several post-it notes blocks, preferably of different colors. set of sharpies.

Phase one: Distribute the post it notes within groups of  4 to 7 people and tell everyone on each group to get consensus on all the things a person (an average of everyone in that group) does from the moment they wake up to the moment they get to the office on a regular working day.
For each thing that regular person does, write a post it. Take 10 mins for them to write them and paste them chronologically in a horizontal way. Have them also use a particular color of post-its to group the ones that have a shared objective and put that colored one below the group it represents (e.g.: take bath, brush teeth under "personal hygiene").

Phase two: Now tell everyone the next day they need to get to the office first time in the morning for a really important and unavoidable meeting, but they realize that same morning their alarm broke and and have only 45 mins before commuting. To that effect move one line up all the things that they would be doing on that timeframe and writing new ones if the already written were too time-consuming. Take 5 mins for this phase.

Phase three and four: Iterate on phase two but with 20 mins to commute and 5 mins to commute. Take 5 mins for each phase.

Phase five: Take 5 mins to get every team to explain what they did for the 5 mins before commuting.

Phase six: Take the remaining 10 mins to explain the results.
Have them draw a line between each exercise:

You should end up having 5 lines of post-its aligned in columns:

• The colored ones at the bottom are called epics.
• The first line is what you should aim for the first release.
• The second to the fourth one are each the subsequential releases

Conclusion:
They were able to prioritize what's it's escential from what's not with their own life and have learned how agile story mapping looks like in the process!