Client experience

Responsiveness #

One of the things our clients value most is responsiveness. Many will be under pressure to get things done quickly, and will be expected by their colleagues and managers to know what is going on at any given time, and to manage us effectively. If we’re not quick to respond to their queries, questions and concerns, we reduce their ability to maintain the confidence of their colleagues.

So, when we are on sprints, we endeavour to respond to our client quickly. It’s not always possible to resolve a problem or get an answer quickly, but that shouldn’t stop us from acknowledging a message or giving regular updates. As with tickets, being responsive to a query is just as important as giving a definitive answer.

When we get enquiries for clients who are not currently sprinting, we still answer as quickly as we can - but clients who are sprinting come first.

We also expect most communication with clients to happen with the project’s delivery lead. We don’t hide anyone on the team from the client, and they are free to ask questions of whomever they wish. But if you’re a developer and you get a question that’s really for a delivery lead to answer, refer the client on. This will help to keep you productive, and will help the client understand who on the dxw team does what.

Progress in every sprint #

Delivering projects in an agile way requires trust between everyone involved in delivery. Clients must have confidence in us for the process to work. One of the quickest ways to lose confidence is to finish sprints with little to show for the effort we’ve made. In all of our work, we maintain a clear relationship between sprints and their associated costs, and visible, tangible changes to the service we’re working on.

This means that we structure work so that visible progress and supporting back-end work happens side-by-side. We don’t work on back-end or supporting code first, and then bolt front-ends on later. We make sure that what we’re doing is visible to our clients as early as possible. This helps us to maintain trust, and gives us more opportunities to learn what works and what doesn’t by involving users of the service in testing.

Involvement #

We involve clients in every aspect of our work. Projects work best when everyone involved feels part of the same team. So, other than the internal retro, there’s no aspect of our process that we do without client involvement.

In particular, we should go out of our way to involve clients when decisions are being made about design, user needs, or strategy (among other things). We’re not here to make decisions for our clients: we’re here to help them to make good decisions themselves. So we shouldn’t make decisions about important things without them.

This isn’t to say that we require clients to participate in everything. Clients and projects have varying needs, so this aspect of the process is flexible. But we always make the option of involvement available. If they want to join daily standups as well as participate in sprint planning, they can.

Last updated: 20 March 2024 (history)