Back to blog home

Reducing the cost of delivery in software development

The delivery of digital products and working software invariably involves waste. Here I walk you through Clean Language – a communication tool that can save you time, money, and effort from the outset.

Clean Language AgileImage courtesy of Wikipedia Commons

One of the earliest known examples of people’s ability to record, communicate, and share knowledge with each other can be seen in various cave paintings around the planet.

Over time the meaning of many of these paintings has been lost on us, but as a species we’ve grown better at communicating and understanding each other. 

Whether the medium is walls, parchment, or Twitter, however, the challenge of communicating, being heard, sharing your insight, and being understood is one we’ll continue to face.

With this in mind, I want to talk you through a technique I use to make the business of communicating and capturing our understanding more human in today’s digital era.

Firstly though, let’s consider why communication is key to achieving ROI in software development.

The role of communication in software development

Let’s fast forward from cave paintings and take a look at a modern IT team in a business. Usually this is organised into groups made up of developers, quality assurance, project management, product owners, and business analysts. 

With so many components, the potential for information to get lost between individual groups is high. If we don’t communicate our understanding clearly to each other, ensuring that we’re understood, we won’t end up building the right product or feature.

So how and when do we need to communicate this insight?

The best time to capture shared understanding is before any work begins. Reducing any investment based on vague requirements starts with having great conversations and ensuring you have the right people – together with the knowledge needed to deliver. 

This puts you in a great position to drive return on investment. It also reminds me of my favourite Agile principle:

‘Simplicity – the art of maximising the amount of work not done – is essential’.


Maximising the amount of work not done means we are not wasting time and effort building the wrong product or feature, and instead can have useful conversations that focus on the business goal and the value you’re looking to uncover. 

In other words, it’s about ensuring your efforts are channeled towards the right things (that are needed the most).

So how can you achieve this ideal state of digital delivery?

Recently I collaborated with a team on its user story mapping, a great technique for planning work in a digital project by exchanging ‘user stories’. We did this using a coaching model called Clean Language, which provides a set of questions that can clarify a team’s understanding of the work ahead – without personal interpretations or assumptions getting involved.

The benefits of using Clean Language in digital projects

A common complaint you hear in digital teams is: ‘I don’t understand any of this; it’s all too technical’.

I can think of a client example where a team had been raising tickets. They were able to simply add placeholders for work, without having discussions around them, and were getting straight into heads-down development without a shared understanding of the objectives.

This siloed approach led to to some interesting and possibly valueless stories being created. What was needed was a new approach that would ensure everyone was part of the conversation. 

My approach was to start from what they were doing now, respecting their current context. This meant acknowledging that their current circumstances allowed for them to ‘just get on’ with work without collaborating.


The first conversation was with the new product owner who would be owning and making sense of the work. This seemed like the ideal time to introduce user story mapping to see if there was a way to make sense of the work in the backlog.

User story mapping is a way of mapping out the work that needs to be done by telling stories about how the user will use your product. You start with the user, add the steps they can take, and then add details about the steps.  

This helps to generate a walking skeleton of work, or a spine with ribs as the book 'User Story Mapping' describes. 

So with this visualisation of the backlog it was easier for the team to have a meaningful conversation around the backlog because it was visually apparent which items were duplicated, which needed more work, and, ultimately, which were not needed.

I’m a fan of using online tools in the right context, however I find the best approach would be to follow our ancestors and just ‘paint’ the work on the wall (with cards and post-its of course), and invite conversation.

Story mapping in Agile
 An example of a story map

Whichever Agile framework you choose, making work visible and transparent allows you to tackle the problem of hidden requirements and relationships between them.

A use case for Clean Language

As we walked the spine of the backlog I noticed that a task seemed to make assumptions:

‘User adds request?’ I asked the product owner. ‘What kind of user is that?’ 

To avoid assumptions it was important to clarify who the user was – that it was the customer and not an internal user such as a member of Finance or HR. Now, with knowledge of who the user was, I was then able to ask: ‘and what happens just before the customer adds their request?’ This led to a realisation that steps were missing.

Once added, it was easy to ask a question to get to the next step: ‘and is there anything else about the customer adding that request?’ Until I got a firm ‘no’ I knew we were not ready to move on and any unknowns would allow for investigation before accepting the work for any kind of planning.

The final question I used was: ‘the customer adds their request and then what happens?’ 

After 30 minutes we found that there were enough unknowns to go and gather more information from the stakeholders, which was a great place for me to stop. I would also suggest a short timebox is great, as you don’t want to swamp yourself with all your new understanding. 

The real benefit in asking Clean questions is it allows you to listen to other people's understanding of a problem or solution, and allows them to discover any issue they’re more willing to own. 


It’s a great way for you both to gain clarity without your assumptions being taken into account, or having a shared understanding without making anyone feel incapable or fearful of making mistakes.

So what did I do to get us here? Nothing magical; I listened to gain understanding and then showed that I understood by replaying what I heard using the Clean Language model. 

In so doing, I didn’t need to understand anything about the work, or put my own experience or solutions in from a software developer’s perspective; the right person had the answers and ensuring they owned that part meant I was not a bottleneck in their system.

How to apply Clean Language tactics

So did you notice how the questions were asked? Clean Language allowed me to keep out of the solution and offer an opportunity for the product owner (PO) to grow and find their own solution.

Moving from the 'From' questions below, to the fully-fleshed-out 'To' questions, you can see that I haven’t changed their words. By listening within their own context I could understand what the team wanted to happen.


What kind of X?
Is there anything else about that X?

What happens just before X?

X, and then what happens?


What kind of user?
Is there anything else about that customer adding their request?
What happens just before the customer adds a request?
The customer adds their request, and then what happens?”?

Without much effort we were able to clarify the gaps in understanding and improve how well we could be understood by the rest of the team. 

Reducing risk for future problems like this doesn’t mean you go back to upfront planning; you still create just enough work to test if your direction is right, even so you’re able to take advantage of the questions to decide if the work needs doing in the first place.

Next time you want to clarify an assumption, why not ask: ‘What kind of X’? This alone will give the person an opportunity to clarify assumptions, and from there you may gain greater clarity.

Trying Clean Language for yourself

We have come a way since cave paintings, and Clean Language is a great testament to this progress. What’s so compelling and easy about this tool is its adaptability for various situations; I’ve even heard of instances where people have used it on holiday to gain clarity and enrich the conversations they were having with the locals.

Clean Language may sound odd at first, but try it out and see how, with practice, you find better opportunities to use it.


The beauty of Clean Language is that it allows you clarify things upfront and avoid assumptions that could lead to the wrong things being developed, saving work, costs, time, and customer satisfaction in the process.

Hopefully this taster has given you some insights into how you could better gather requirements and understanding before any software development has begun, saving time, money, and effort for yourself and the business and people with whom you interact.

The questions I’ve demonstrated in this blog post can be used in any context and more often than not when I use then I find people go from ‘What do you mean; I don’t understand the question?’ to *subtle pause* and (within a couple of seconds) an answer that attempts to provide more clarity about their thoughts.

If you’re interested in learning more, do get in touch to book an introductory session with our Agile coaches to understand how they can help you to gain more value from using Agile in your business.

Digital strategy consulting

Our award-winning web and software engineers are enabling businesses to solve their most complex technological challenges. So whether you’re looking to automate business processes, upskill your teams, or deliver better experiences, we can help.

Related reading