Failing (too) fast? - Why first iterations often fall flat.

Do you remember the episode of The Simpsons where a hurricane came through Springfield and destroyed Ned Flanders's home? The townspeople rallied together to rebuild his home, but when Ned was given the grand tour, his excitement gave way first to disappointment, then to a rare display of rage.

"Well, my family can't live in good intentions, Marge!" - Ned Flanders

What does this have to do with IT change?

It relates to the concept of MVP - Minimum Viable Product. Agile deliverly is based on the concept of iterative development, with the idea that it's better to get something usable out fast and then build on that based on feedback, as opposed to a big bang waterfall approach.

That first iteration is supposed to have the must-have features that are essential for adoption. Everything else is a "nice to have" and will be planned for future releases.

In practice, it's rarely that simple.

The number of times I've seen a product team present what they built, only to have their very souls crushed by a chorus of "This is IT? Where's the rest of it?" from stakeholders and end users alike.

Why did your MVP fall flat? Two possible reasons.

1) The Minimum Viable Product was not actually viable.

In order to build something, you need a set of requirements. These requirements are then prioritized into "must haves" and "nice to haves".

Safe, functional wiring would normally be a "must have".

Often, when these requirements are being fleshed out and prioritized, a lot of details get missed. Perhaps the wrong people were in the room, perhaps they were the right people but the session was rushed.

If we look at Ned Flanders's house as an example, Homer and Apu should have involved Ned and Maude in the requirements-building process. To identify the "must have" requirements, they should have used the guiding question:

"What needs to be in place for a family of 4 to safely and practically occupy this house?"

They might have come up with something like this:

Requirement	Importance	Timing
Basic electrical - to code	Must Have	First Iteration - MVP
Plumbing hooked up, to code for kitchen sink, and sink, toilet, and shower in one bathroom.	Must Have	First Iteration - MVP
House must be structually sound, signed off by professional engineer.	Must Have	First Iteration - MVP
House must confirm to fire safety code, including functional egress, smoke alarms, and functional doors on the bedrooms.	Must Have	First Iteration - MVP
Interior walls plastered and primed	Must Have	First Iteration - MVP
Windows are in and functional.	Must Have	First Iteration - MVP
Exterior brickwork is complete,	Must Have	First Iteration - MVP
Basic window coverings	Must Have	First Iteration - MVP
Plumbing hooked up, to code for dishwasher, clothers washer, as well as sink, toilet, and shower second bathroom.	Nice To Have	Second Iteration
Driveway is paved	Nice To Have	Second Iteration
Interior walls are painted	Nice To Have	Second Iteration
Grass lawn is planted	Nice To Have	Second Iteration
Construction equipment is clear from site.	Nice To Have	Second Iteration
TV and Internet are installed.	Nice To Have	Second Iteration
Decorative shutters and awning are in.	Nice To Have	Third Iteration
Shrubbery, landscaping, and fence complete.	Nice To Have	Third Iteration
​Pictures are hung	Nice To Have	Third Iteration
Bespoke window coverings	Nice To Have	Third Iteration

The iterative approach would look something like this:

Please forgive my lack of finesse with Snagit. This is an MVP.

2) There was too much focus on the final iteration.

There is a tendency to focus on the positives, and look towards it. It is the technical change that will make your processes more efficient, make your teams and partners happy, and increase your profits.

It is what sponsors and C-levels will show off in town halls. It's what your sales team is probably already talking to prospects about. Most of the iterations that come before it seem lacklusture and not worthy of discussion.

Here's the problem:

It is many, many releases down the road. And it might never get built.

This is dangerous territory. If companies are focusing on the final goal at the expense of talking about the many changes that must come before it, everyone starts drinking the Kool Aid. I've seen cases where stakeholders had a clear demo of the MVP on a Monday, but went to a town hall presentation about it on a Wednesday. They come out of there believing that it is what's coming in the next release because the presentation really sold it.

Focusing on the final iteration at the expense of the rest can also take people's focus off of the "must haves". Those things are dull in comparison, and once everyone is hyped up about it, the pressure is on to deliver a polished-looking change. But don't look under the hood! (Or, don't take down the "load bearing poster")

The Takeaways

When determining an MVP, there are certain questions that everyone involved should ask.

• Do we fully understand the impacts this first iteration will bring?

• In the event that further iterations are delayed or cancelled, can the business sustain any workarounds and risks long term?

• How will we balance the message so that everyone is clear on what will be delivered when, and what's in it for them?

• Does the MVP bring value to customers, even without the bells and whistles?

• Does the MVP meet our regulatory and compliance obligations?

• Does the MVP align with existing Service Level Agreements we may have with customers and partners?

• Does this MVP align with what we have promised our existing and pipeline customers?

If you liked this combo of IT change and stupid TV references…

…head on over to my IT and Change Management humour Instagram, @WhenChangeHurts.