Often when we ask customers what their MVP is, they don’t fully understand the question. Here’s a simple illustration to illustrate my point throughout. You need a chair to sit on. Anything additional is extra features.
I decided to outline the benefits of iterative incremental development approaches (and there are a lot!)
With Drupal (or any other CMS), you can pretty much achieve all the basic things you need, out of the box. Our challenge (and the reason customers come to us) is that they don’t know what comes out of that box and assume it’s all custom.
Their current site is dated, they need a new one. They need internal buy-in for the change, so they gather a list of requirements based on feedback from users with the aim of keeping everybody happy. They end up with a list of “nice-to-haves”.
The aim was to find out that their old “seat” is now wonky, or maybe needs a backrest. And to fit that into the given budget and timeframe, they need to see the bigger picture. We’re there to remind them what their MVP is. Of course, features can be added, within reason.
So how, and why, do Code Enigma advise against some of these added features? Are we being lazy and difficult?
The following facts were pointed out to me at my Scrum Alliance course:
80% of the value comes from 20% of the functionality
(Forrester Research)
60% of the functionality delivered in successful projects is rarely or never used
(Standish CHAOS report)
So, here comes the benefit of an iterative approach… It’s been tried first. Core modules work one way because the UX has been tested. I’m not implying you should never go out of the “box”, but do think carefully.
For example, complex custom algorithms can be replaced by manual fields; it all depends on how often the data is needed. Complex sets of algorithms can lead to future bugs. Classic problem areas are automated VAT calculations according to Geo locations, altering order workflows, custom payment gateways and changing user journeys for different user groups.
By going out of the “box”, common bugs won’t be fixed by patches posted by the software’s community, but on time and to budget by a dedicated developer. Add-ons to the functionality will also need to be custom coded.
Modifying standard text strings that come with a module often means having to create custom patches, as there are other dependencies elsewhere. Therefore, we always advise trying the basics first to test the site early on in development; essentially to ensure you have the time and budget to make sure you can at least sit! Then we think of the added features. This is the advantage of iterative and incremental development. How many users will need it? Will it add genuine value? Is it worth the risk, or the money?
If we deliver the sitting functionality first, we have appeased the minimum for all parties. Further into the project, you will gain a better sense of which functionality needs more investment. Developers will know you and your project better and can highlight more effectively potential dependencies and advise on the best solution. You may want to spend more on finishes (design and frontend) adjustments rather than adding functionality as you may discover that what you have at that point does the job.
Why do we advise to take this approach although it appears more lucrative for us?
We hate when things break because of overly complex requirements. It’s frustrating for both parties and throws our credibility into question. Although the over-customisation and following dependent add-ons are the root cause, it just makes us look bad. From our perspective, we get no satisfaction from building functionalities we cannot contribute back to the community, because no one else will ever need them.
You could run out of budget spending on things no one really cares about in the long-term, at the cost of the benefits of additional design work. We want a great site for you, not all the gimmicks. The Code Enigma geeks would be gutted if we couldn’t build a unique functionality that would make us all look very clever, whilst benefiting the community. Ultimately, we’d rather you kept the budget and came back to us post-launch, with functionalities you genuinely need, so we can build a long-lasting and trusting relationship together.