richrtesting

Many years ago during my first history lesson at a new school, the teacher wrote the word ‘EMPATHY’ on the blackboard in large capital letters.

She asked us to consider this in our approach to learning. She explained how we could learn to understand the events of history by looking through the eyes of the people who witnessed them. Over the following weeks, we watched several episodes of the wonderful 1970’s documentary series “The World at War” which was produced by Jeremy Isaacs and David Elstein and narrated by Laurence Olivier.

The great strength of this series was its ability to provide an insight into the experiences of the people who lived through the events leading up to the Second World War, how the conflict affected their day-to-day lives, and the consequences for them in the years that followed. In a 2013 interview with the Guardian, Jeremy Isaacs said,

“I wanted to hear not just the voices of people who dropped the bombs, but also those they targeted.”

I was fascinated by the possibility of putting myself in the shoes of these witnesses to history. This was a world away from my previous experience of history lessons; seemingly endless lists of events and dates, not much more than a memory exercise.

Which year did Charles II become King of England? I have no idea without a quick Google search or a visit to Wikipedia. But ask me how the people of Normandy felt towards the Allied soldiers during and after the D-Day landings of June 1944? I can tell you that they felt elated, but terrified of repercussions from the remaining Nazi forces, grateful for the sacrifices made but angry at the continuing devastation the conflict brought to their families, homes and land. I remember all of this because I was able to hear it from the humans who were affected.

Human feelings and emotion create empathy, facts and figures do not.

The IT empathy gap

During my career in software testing I have realised that the IT industry is subject to an empathy gap.

There is often a lack of empathy between people working together on projects. When the pressure is on to deliver a new website or application, it is all too easy to be critical of colleagues without understanding the pressure that they may also be under. Testers point in the direction of Developers and cry “poor quality” or Developers look at Business Analysts and mutter “changing requirements”.

Meanwhile, there is also a lack of empathy between the project team and the most important person of all – the customer. How can we be successful if we fail to meet customer expectations? How can we understand customer expectations if we don’t know who our customer is?

This is a failing in many organisations, which keep those strange technical types in a bubble far removed from customers. Frigyes Karinthy’s famous theory of ‘six degrees of separation’ could be modified and reapplied – any IT professional can be connected to a customer through a chain of no more than five intermediaries.

For many years, requirements documents have been used as the bridge between the people who build technology and the people who it is intended to serve. The basic premise that these documents accurately capture the needs and expectations of customers has underpinned the approach to delivering software. Following this premise to its conclusion means that anyone working on the build and test of software is not required to think for themselves. If we build it exactly as the requirements state and then test that this is how it has been built we have a great product for our customers, right? Well, no.

Written requirements are often ambiguous and inconsistent. This causes misunderstandings and inefficiency which in turn cause delays and inflated costs. Many projects manage to combine late delivery and increased costs with a failure to deliver what was intended in the first place. This certainly isn’t a revelation. Many studies have been carried out on the subject and the findings are fairly consistent:

“between 65 and 80 percent of IT projects fail to meet their objectives, run significantly late or cost far more than planned” – Portland Business Journal (2008)

“Over 50 percent of respondents stated that they do not consistently achieve stated project deliverables” – KPMG New Zealand Project Manager Survey (2010)

“On average, large IT projects run 45 percent over budget and 7 percent over time, while delivering 56 percent less value than predicted” – McKinsey (2012)

Closing the empathy gap is a key factor in addressing these failings. We need to deeply understand customer expectations and focus on the people we are serving, regardless of the task we are carrying out.

Is Agile the solution?

Of course, by now you may well be thinking “Ah yes, but that is the old world. We follow an Agile approach”. It is certainly true that Agile principles focus on the customer. The first two principles of the “Agile Manifesto” are:

1. Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

2. Welcome changing requirements, even late in Agile processes harness change for the customer’s competitive advantage.

If you work in an environment that genuinely embraces these two principles you may be more successful in delivering what your customer wants. Evidence suggests that despite the adoption of Agile the outcomes on projects are still quite poor. Ambysoft’s 2013 IT Project Success Survey revealed that whilst ‘Traditional’ projects recorded a 49% success rate, Agile projects recorded a 64% success rate. There is still plenty of room for improvement.

What is perhaps more revealing is the definition of success in the same survey. Whilst 58% of respondents valued delivering on schedule, and 36% valued delivering to budget, only 14% valued delivering to specification. This is worth reiterating – based on this survey, only around one in seven IT professionals consider delivering what was specified as a success factor. Not much empathy for the customer there.

Whilst Agile methods encourage us to involve the customer, the application can be as flawed as traditional methods. In Scrum, for example, we have the concept of the ‘Product Owner’. Amongst other responsibilities, the Product Owner should be the link between the customer and the team delivering the software and should therefore have an intimate understanding of the customer’s expectations.

Perhaps the Product Owner is holding customer interviews to really get to grips with this part of the role. Perhaps not. Even if this is happening, there remain degrees of separation between the customer and the development team. The Product Owner must have:

1. the ability to understand the customer’s expectations (which will change frequently)
2. time to communicate these to the development team
3. the ability to communicate these to the development team

This is a challenge even if the Product Owner is talking directly to the customer. If they aren’t, then how can they hope to convey needs to the team? The Product Owner simply becomes the mechanism by which customer expectations are miscommunicated.

In reality, many large projects are using a hybrid of Agile and Waterfall development methods. What this probably means is that there is still a single product launch at the end of many months of design, build and test, and the poor old customer has probably been forgotten somewhere along the way.

Closing the gap

There are of course many success stories and great products which prove that individuals, teams and companies can deliver something which not only meets customer expectations, but exceeds them. And this is the good news – every person who works in designing, building and yes, even testing software is also a customer. We all know what we expect, what we like and what we love in technology and software.  We can all point to a great product, whether it is our favourite smartphone or tablet, a simple and useful website or an app that we can’t get by without.

In many cases we may actually be customers of the very product we are working on. If not, we can at least find similarities between that product and other things we use. Perhaps the degrees of separation between the IT professional and the customer aren’t so great after all. Perhaps by thinking about our own expectations or talking to our friends, family and colleagues about their expectations we can break the dependency on requirements documents or Product Owners.

Being prepared to raise concerns and make changes based on these expectations should be encouraged and not suppressed. If we build and test to a defined list of requirements whilst ignoring our feelings about what we are building or testing then we will fail to deliver a great product.

However, if we can focus on the needs of the human who is going to use the technology then we are likely to deliver something which will at least be used and possibly even loved. We should regularly ask ourselves “What would the customer expect here?” We can close the empathy gap by putting ourselves in the shoes of the customer, and if we succeed we can be confident that we are building something with lasting quality.

 

For some further reading on this subject, check out Joe Colantonio’s blog ‘Customer Empathy Based Testing’.

http://bit.ly/1lropNt