Requirements

During the last year or so, I have been caught up several times in discussion regarding ”agile requirements” or some similar catchy phrase. ”Christoffer”, they say, ”as an agile coach, what is your take on requirements? Should we have them? In what format? Who should write them? Where should we store them? And can we really start developing stuff without having them ready and approved?”

The problem with these questions is that there really is no straight, ”do-it-like-this-and-all-will-be-well” answer.

I’m writing this post in a hope to address these questions, and more.

Requirements are neither the paper nor the ink

Let’s start by clarifying an assumption, that is often not fully understood. A requirement is not a paragraph on a piece of paper in a binder on a dusty old book shelf. Neither is it a user story, entered onto the back of an index card on a Kanban board. Those are not requirements – those are the artifacts of the requirement.

A requirement represents knowledge of a need or want, presumably related – at least on some level – to a system that an agile team is (or will be) working on. You need that knowledge in order to develop something. You cannot develop something without requirements.

How do you extract this knowledge? That depends. Usually talking to the person(s) with the need/want helps. Workshops or surveys might also be viable tools.

Who extracts this knowledge? Someone with the required skill set, obviously – but you already knew that. Does that mean that you need a requirement analyst in your team? No, not necessarily. Ask the team if they are comfortable with doing the requirement analysis themselves. Perhaps they have both the technical skill and the communication skill required.

How do you document this knowledge? Again, that depends – it could be in the form of use cases, user stories, mock-ups, prototypes, or whatever suits that particular form of knowledge. Document only when there is a clear purpose with the resulting artifact. If everyone involves have a sufficient understanding of the requirements, there is typically no need to document anything.

The artifacts are still important

Here is a huge, potential pitfall. Because, typically, we believe that we have sufficient understanding of the requirements, while we actually do not. We believe that we have collected all possible knowledge of the need, while we in fact have not. Or, it could be that the need changed, as they often do.

One purpose of creating requirement artifacts is thus to create a common ground, as a help to capture this knowledge and use it as a basis for discussion. But be aware that the use case or user story or whatever you use will change many times – because that is, after all, one of the purposes.

And, obviously, agile methods to the rescue: create something small, based on a few of the requirements – as far as you understand them at this point in time – and then show the result to the one with the need. This will help everybody’s understanding of the actual need, and lets you adjust the end result as you go along.

A philosophical view

A requirement can be viewed as a part of a perfect – albeit constantly changing – knowledge about a need. The artifact used to capture this knowledge  (be it that dusty old binder or that index card) will therefore always be fundamentally flawed. There is no way that an artifact, however detailed, can capture all that knowledge. So let’s not try.

Instead, embrace the fact that requirements evolve and change. Thus, your requirements – in whatever way you choose to document them – will not be done until the need is gone. Let’s not wait with development until then.

Talk to your customer support

I just finished having one of the worst customer support experiences of my life, it feels like these experience are getting worse and worse across the board. But I have a thought about how they could be a lot better for both the companies and the customers if we just think about it a little different.

The customer support problem

I spent many years working customer support for a lot of different products and companies. And I can say, people who are angry about automated systems and outsourced employees for customer support don’t understand the problem fully.

Customer support is a money loser for any company and the larger the company gets, the bigger a problem it becomes.

Think about it this way: (Not real math)

  • You buy a product for 20$.
  • The companies profit margin on that product is 5$.
  • You have a problem with that product and call customer support to speak to a person.
  • A customer support person costs 10$ an hour.
  • You spend 31 minutes on the phone with the agent.
  • This company has just lost money by having you as a customer.

The company is actually in a very tough spot here and in a lot of ways it’s not their fault.

Are you willing to pay for support? Probably not…
Are you willing to pay more for the product? Probably not…

I am actually not angry at the company for this, I understand the problem and why it’s hard to solve.

How companies respond

Companies have to make money. Period.
You also want your product for as cheap as possible most of the time.
Customer support needs to be made to cost less.

This is why you end up in annoying automated systems, this is why you get outsourced representatives in cheap countries, this is why they try everything they can to make you use the website.

And actually most of the time this is a sensible approach. Customers support is 99.9% repetition (made up number), every customers support job I have ever had consists of solving the same 4-5 issues over and over again. Automated systems and cheap people reading scripts is a fairly effective means of solving this. Most people have a very smooth experience when they have the 99.9% issues. And if they don’t they might also make you go away and deal with it yourself, which is also a way of keeping their costs down.

At the end of the day it comes down to this, a company of any significant size works to make their customer support cheaper, because in order to get you to buy their product in the first place they need to keep the product at a competitive price.

A different approach

But what if we approached this problem slightly differently? What if instead of addressing the symptom, the high cost of support, we addressed the underlying root cause, the issues causing the support requests.

What if had the people who build the product, in software: development teams, spend time with the customer support? Or even spend time doing customer support?

I have worked with teams who took this approach in the past, and I can tell you that we see a very different outcome.

The development teams start understand where the problems in their product are, and they are able to attack them at the root cause. The 4-5 most common problems are the first to go.

  • They are able to identify the ones caused by errors and fix them, these calls stop coming in.
  • Then they learn about the calls that are caused by people not understanding the product, they make changes that make it easier to use, these calls stop coming in.
  • Sometimes they see the issues that are too costly to address the root cause of, but a lot of the time they are able to provide the support some tools to address them faster and easier, these calls now cost less to address.

A different way of looking at the problem.

In the first way the company tries to solve the ”customer support problem” they do make it cheaper, but they do so with a lot of upfront investment and ongoing costs.

They need to build and maintain that automated phone system.
Taking on an outsourced support partner is a huge initial and ongoing cost. They need to compare companies, negotiate terms, sign contracts, train people, pay people, deal with legal requirements of that country, quality control the partner is delivering on it’s obligations, the list goes on and on.

But with the root cause approach, every time they fix a problem they save these costs into the future and often for only the upfront investment.

It also provides a much better experience, which creates happy customers, which makes their brand better, which makes more people buy their products.

At the end of the day the root cause approach is better for everyone.

Not a silver bullet

This won’t fix everything, issues will still be there. Some people would still require support and be a higher cost. But maybe the companies support costs are low enough that they can see this as a cost worth taking? And if not, well, they still have a much better experience for the customers who had the original 4-5 issues.