Bug? More like feature request.

The MVP plays a key result in the final outcome. The MVP can turn a loss into a win. Keeping it simple, on target, doing the right stuff at the right time.

That of course is the Minimum Viable Product. Or MVP as we shall refer to it henceforth.

MVP is the antithesis of “scope creep”, the malicious virus that kills projects, bankrupts businesses, disemploys staff and disillusions developers. So let’s see how this works…

Zextext

Our imaginary customers have asked us to create a new website called “Zextext” that allows their staff to send a text message (SMS).   It’s cool because it means they don’t have to use their phones, and the cost of the text will be billed to one all-expenses-paid corporate account.

The customer budgets 10 hours, and off we go. 5 hours in, coffee included, we have our first empty MVC home page.

Ok, you know how this goes. The developer puts a mobile number text-box and message text-area on the screen, with a “Send” button. However, the button is a dull grey. Not cool. The next five hours are spent getting the green gradient effect with rollover glow working. Cutting edge CSS3 stuff – the customer is going to love it!

An hour to go. The only thing left is to wire up the button to the text service provider. It’s the last 20% of the work, which … typically … takes 80% of the time. 20 hours in, we have a working web page. Type in the number, type in the message, hit send, and ding-a-ling, you get the message on your phone. Time for a celebratory drink and a selfie (because it’s a one-man project).

Hold the Phone

What’s the problem then? Obvious. The project ran 10 hours over-budget. This one looks like a combination of wrong estimation, and basic developer scope creep.

You see, there was no need for a green button – it had no material impact on whether the application worked. Minimum Viable Product is the least amount of features needed for the project to complete its basic objective. Maybe we wouldn’t ever have achieved the task in 10 hours, but we could have done it in 15.

And Now It Starts

If you think we’ve hit rock bottom, hang on, we’re about to go subterranean. The customer comes back with a list of bugs:

• • 1. The page title says “MVC Template”
    2. The label next to the mobile number says “moblei number”
    3. The message area is not big enough
    4. If you don’t type in anything and press the button, you get the default custom error page
    5. The green gradient button looks wrong in IE7
    6. If you type in more than 300 characters, the message gets truncated after it’s sent
    7. The button goes off the screen when viewed on a mobile device
    8. If you type in a long message, there are no scrollbars on the message area
    9. There is no confirmation of successful send
    10. International numbers with a + sign prefixed are not supported

The customer says these are bugs and they will not pay extra to have them fixed.

Bugs vs Features

First off, the customer has raised some real issues – any developer proud of his work would have spelled a label correctly. As for a success or failure message, these are surely pretty close to basic tools of the trade, or Minimum Viable Product.

However, following from that is a failure by the customer to grasp MVP and the agile process. Support for outmoded browsers is always an edge-case, and you would expect users to enter decent data in nearly all cases, so excessive error checking is usually not as beneficial as you might think.  Certainly, supporting all the issues in the list would never have been possible within the original budget.

Does IT Have Business Sense?

Ask yourself in very simple business terms: will the feature or the fix pay itself off? Will a shiny button increase your profit? Will checking for certain error conditions prevent income loss?   Sometimes yes, in our example no.

Most developers don’t actually grasp economic realities – they’re being paid a salary regardless of whether their work pays for itself. There’s a real case for developers almost fighting back against the customer’s wishes, in order to protect the customer from wasting their own money. At the turn of the century, the web bubble popped, and bubbles continue to pop.

The Guile of Agile

Agile software development has really helped us to refine our core requirements, because it forces us to prioritise. The first few sprints produce the core of the product, and the limited time allocated to each sprint helps us to place more urgency on those features. Additionally, if funds run out down the line, there is a far stronger chance that we’ll have a working product to hand over.

The waterfall methodology, however, attempts to plan and produce a complete product, to over-spec. It ends up over-spending on analysis and then allows non-priority features to be moved higher up the pipeline than they should.

The time is right for everyone up and down the chain, from the customer, to the validation team, to the IT managers, to the developers, to ask why their work is going to pay their salary?   Especially the green button.