How to constantly deliver user needs

A common approach to building pretty much anything is to follow a layered process. For instance, if you were building a house, you'd follow a fairly strict process of laying the foundations, building the walls, putting on the roof, and finishing with the decoration.

It's not unusual in software development to try and follow a similar process, where each member of the team is allowed to have their turn layering up the solution:

1. The analyst reviews the client's needs
2. The designers create screens showing the proposed end result
3. The developers implement the solution, merging the needs and the screens
4. The client reviews the solution

anyone involved could (and almost always does) find something with the solution that needs changing

The problem with this process, is that at any stage, anyone involved could (and almost always does) find something with the solution that needs changing.

This problem can be mitigated in part by spending a very large amount of time and money on steps 1 and 2 ensuring that the planned solution has all bases covered. However it's unlikely even then that you'll capture all issues in advance, leaving you with problems to fix, and less disposable cash to fix them with.

If, in the worst case, problems are found during the client review in step 4, you may need to go back through days/weeks of work to make the change that is requested, and unpicking that work could be challenging especially if this new requirement conflicts with others.

Time lost can be damaging for the business and the client

Time lost due to changing requirements, regardless of how it comes around, can be really damaging for both the business and the client.

How can this be avoided?

The slice

A nice way to avoid too much impact from changing requirements is to stop focusing on building a complete product in one go. Instead we should focus on just one requirement at a time - and ideally this requirement directly maps to a user need.

For instance, if you are creating a piece of software that has an account section, you could say a requirement of this product is that the user can log into their account. The team then focuses on implementing a solution that allows a user to log into their account; spending the smallest amount of time building something which perfectly matches the need. Because it's such a concise feature, it can be considered by the whole team simultaneously, developed in less time, more coherently, and demonstrated to client earlier. And very importantly, after each requirement is complete, you always have something which works end-to-end.

you always have something which works end-to-end

As a solution like this cuts through all of the layers of the product, we call it a slice. The thinner the slice, the better, as it's delivering the most concise feature, which stops too many requirements being considered at the same time, and ensures a quick cycle back to the client for review, shortening the Gap Of Uncertainty™.

Right now I need two positives.

Sure, a more concisely-developed product which can be developed quicker and with less uncertainty is a tough sell. To help convince you, here are some further thoughts.

A solution which is end-to-end by default.

Something I love about this approach is that because each slice forces every aspect of the product to be considered, after each slice you have an immediate view of the current state of the solution. Do the design assumptions really work? How effective is the error copy? What does it look like on my phone? With a solution which is end-to-end by default, all of these can easily be answered constantly, repeatedly, throughout development.

Also, because you're able to ask questions sooner, you're far more likely to find fundamental problems sooner, which can be fixed much sooner. Does the choice of database suit the registration form design requirements? Shouldn't the user be able to stay logged in for more than 30 minutes? Why does the home page look so odd in Android?

You may complete the solution sooner.

Finally, and my favourite consideration, is that you may complete the solution sooner, as you're able to see the point where enough slices have combined to deliver the client's overall need.

How about building a house room-by-room, and finding out the owner is perfectly happy and their needs are all fulfilled with just 3/4 of the original planned complexity and budget?

That's not possible with a house of course, but it certainly is with software.

Credits