Agile or Design Thinking

I recently had the fortune of completing an engagement delivering current and future state customer journey, and an experience design capability uplift. Coming from a background in agile coaching software development teams, putting on the design thinking hat was a fascinating experience.

The CXD Labs ‘Customer Value Framework’ shares a similar process to the Design thinking approach popularised by IDEO; except it includes the 'operate' phase of the customer's experience.

Design thinking - https://www.ideou.com/pages/design-thinking

The question - Are Agile and Design Thinking compatible?

I found that there is a general acceptance that only the design team should do design thinking. The agile way of working (i.e. values, principles & practices) only starts when the design team hands over their recommendations for the development team to implement. I don't agree with this approach, and fortunately, my team didn't entirely operate this way.

Where Agile worked:

Collaboration and transparency within the team.

We were lucky enough to be co-located in a single ‘immersion' room. We covered the four walls with our journey map, other information radiators and managed to hold our meetings and workshops in the room. The benefits included:

Everybody could see the latest information.
Work and progress were visible.
Reduced time spent on writing status reports.

Responding to change.

The high frequency of customer engagement and internal engagement meant we were continually having our assumptions validated and improving our solutions.

Constant feedback from the team.

The ability for everybody in the team to provide candid and timely feedback meant we were continuously improving and there was no misunderstanding within the team.

What I learnt:

Greater consideration of the end-to-end experiences.

What I realised is that in my previous role I didn't consider the end-to-end customer journey (from advertising and sales, to maintain and manage), the experience of the employees and the external 3rd parties. Also taking the time to map out the customer journey and touch points was very insightful.

The importance of metrics (quantitative & qualitative).

As part of customer journey mapping, we assigned each touch point with operational metrics. These metrics directly linked to our recommended initiatives and changes to measure their effectiveness.

Pain points encountered:

A dedicated CX team is spread too thin.

Because there is a single department/team which is the 'expert' on customer experience, I found that the volume of ad-hoc CX requests and meetings from other teams was disruptive.

Getting accurate information (i.e. metrics, processes, etc.)

Our output can only be as good as the inputs. Unfortunately, reliable information and available metrics were sometimes hard to come by. This was mainly due to a lack of documentation (i.e. all the information was in people’s heads) and systems which do not capture the right metrics.

Project handover.

Once we completed our findings and recommendations presentation, the involvement of the design team ended and we handed over to a delivery team to develop (or it was filed away in a backlog).

Conclusion:

I am sold on the benefits of design thinking, however having a dedicated CX team to support multiple teams/projects is a recipe for burnt out employees and/or poor quality. Often the agile ways of working are the first casualty in an effort to be more efficient. This includes reduced transparency, increased handovers, and a focus on output over customer satisfaction.

Below are a couple of recommendations:

Reduce the number of handovers.

Include the design team as part of the delivery team. Ideally, there should not be a single team which is responsible for CX. Instead, it is a capability distributed to all project teams. It’s common for an agile team to include a CX designer.

Be as clear and specific with each recommended initiative/change.

It should include a clear customer orientated objective, details of the context, a list of assumptions and expected benefits. The benefits should also be accompanied by success criteria and operational metrics to measure the effectiveness of the initiative.

For idea/change assessment, see IMPACT schema.