We can agree that waste, in almost all contexts, is bad. With regards to software development, there are a number of agreed methodologies aimed at reducing waste but are we still making a massive oversight?

Software development is suffused in lean-thought, even if teams aren’t specifically following Lean methodologies. One of the main lean obsessions is the elimination of waste, in fact it’s the first of the seven lean principles.

Lean-people have developed some nuanced and deep ideas about the nature of waste, but for the most part we just understand it as ‘doing something unnecessary’. Fortunately, the industry overall has found some good answers to mitigating it.

The DevOps movement has created a fearsome machine for turning code commits into live software in moments – hundreds of times a day in some organisations.

And then we have agile delivery frameworks, whose discourse is like a never ending family reunion where everyone is in furious disagreement but united in a common relief that at least they don’t ‘do waterfall’.

Whatever the framework adopted (87% Scrum), these approaches have undoubtedly reduced waste by emphasising shortening planning timelines and frequent feedback loops.

For actually writing code, we could nominate XP or Test Driven Development as approaches for reducing waste but they’re hardly industry norms. In fact the coding world is so fad-driven that it’s difficult for /any/ practice to become embedded in the industry.

Realistically, it really doesn’t matter. Writing code is where the least harm occurs (as long as the other parts are in place). Frequent inspection and adaptation (Agile+DevOps) will catch the worst of the problems.

So far so good, right? But there is one largely overlooked question that threatens to derail even the most efficient development projects and leave developers with few answers other than “it’s what the scope said”.

How do we know what we’re building is the right thing?

Deciding what needs to be built in the first place is one of the industry’s greatest blindspots and waste-free execution of the wrong requirement is still 100% waste.

The current ‘State of…’ reports for established practices tells the same story.

The State of DevOps report is a treasure trove of information that can help organisations improve their development speed and quality, and the State of Agile report tells us that practically everyone is using Scrum and they’re mostly happier for it.

Those that do it best have people-centric values, clear culture, ‘tools’ and leadership empowerment.

We do not, however, have a ‘State of… building the right thing’ report.

Hideous old waterfall was famous for spending so long on working out what to build that once completed, the right thing had become something else entirely. The less said about that the better.

Agile development is predicated on developing user stories to quickly understand user needs, and then it’s left up to teams to turn these stories into code. In order to be successful, stakeholders need to be deeply involved in that process and firm oversight from team leaders is required to ensure the project scope is contained.

At Digital Village, we’ve found design sprints enable us to build solutions based on business outcomes rather than a technical scope. Bringing stakeholders into the development process and developing a user-tested prototype maintains alignment and ensures what we build is solving a real problem.

It’s unfortunate that, as an industry, we haven’t come to a consensus on a united approach for executing the part of a project that has the greatest impact on its success.

In your organisation, how do you ensure you’re building the right thing?