The main goal in web development: Deliver business value from the start

Though a logical sequence of events is a natural part of the human experience, when it comes to any type of web development, it can actually do more harm than good.

Consider the process of building a bungalow. Without first laying down a stable foundation and later erecting some sturdy walls, it makes no sense to install new functioning windows. Yet this is exactly what the Agile methodology proposes, so long as the windows are where the value lies.

The key word here is value, of course. As the Agile manifesto makes clear, the methodology is first and foremost about individuals, so it’s important for any software development company to provide their customers with tangible benefits — from the start of the development process. This means that we should always prioritise requirements with demonstrable business value in mind.

For example, if the main value of a corporate reporting system is in the final report it generates, we can start development from this feature and simply postpone any “logical” dependencies. As a result, many basic features like user login and registration — however important they may intuitively seem — will intentionally be given lower priority.

At the same time, it’s worth noting that this approach is particularly relevant for sectors like travel and hospitality software development, where delivering immediate business value can be a competitive advantage.

A no-dependency approach
But how then do we accomplish this in practice? After all, just as a window can’t possibly support itself on its own, surely one cannot develop major features without first considering their dependencies!

Well, as it turns out, the old saying “fake it till you make it” is particularly true in software development.

How does Agile eliminate dependencies
Let’s imagine that we are currently working on the above-mentioned reporting solution. In order to do away with user login and registration, we could simply rely on placeholders that would enable us to make-believe they were there. A “logged in” user might be called “John Doe,” for instance.

These so-called “fake objects” or “stubs” are extremely useful to software developers, as they enable them to fill in the gaps of any less valuable upcoming features.

How are requirements prioritised in Agile
So who then has the right to determine which features provide business value to the customer? Once again, we can turn to the Agile manifesto for clarity:

“…we have come to value […] customer collaboration over contract negotiation […] responding to change over following a plan.”

In practice, therefore, when it comes to Agile development, no software requirement is ever set in stone. It is the customer, working in collaboration with the software company, who decides how important it is to their business — and consequently its ultimate priority.

The role of MVPs in software development
Yet another way that Agile teams seek to deliver immediate value for the customer is in the development of the minimum viable product (MVP). This consists of a stripped down version of a future software solution that is limited to its core functionality. When companies are unsure of which features to prioritise, a minimum viable product will most definitely come in useful.

The benefits of an MVP in web development
Much more than just a half-baked solution, MVPs are built for stakeholders and early adopters. For this reason, they are ideal to discern the experience and features that are currently in demand among target users. By delivering key features early on, we can generate a fast feedback loop and a sense of movement in the right — or wrong — direction. This enables companies to change tack if needed.

Conclusion and advice for the software development process
As stated at the start of this article, a logical sequence of events will often do more harm than good. Though it is of course perfectly normal to wonder if it makes sense to implement a feature before another, if this is due to a logical connection, an Agile team’s response should always be the same: don’t worry about dependencies! Instead, companies should follow this straightforward checklist: