Category: customer management

Just Say No… To Customer Satisfaction?

Most of us genuinely care about doing quality work and want our customers to be satisfied with our work. When we receive customer requests that are questionable or even ill-advised, we are usually not happy about having to sacrifice craftsmanship for customer satisfaction. But as agile practitioners who strive for customer satisfaction, we can offer our opinion and feedback, but at the end of the day we need to deliver what the customer wants. Right? Or are there times when flat-out saying no is the right thing to do?

My company maintains a complex stack of applications, and the dependencies between layers sometimes leads to bickering between teams over who is responsible for implementing X or Y functionality. Our team was recently asked about making a change in our application to accommodate a certain quirk in one of the lower layers. Normally, we would just grumble about cleaning up another team’s mess and get on with our lives. But this particular quirk wasn’t just inconvenient, it was non-compliant with an industry specification, and our external customers would notice. Implementing a workaround at our level of the stack would have left our customers with a defective product and a long release cycle to wait before they could receive a fix. And less importantly, but still relevant, that workaround meant adding unnecessary cruft to our application that would increase the maintenance burden on our team.

I felt that was unacceptable and firmly explained to the product owner why the defect should be fixed at the source instead of asking us to implement a workaround. When he brought up the workaround again, I explained it again. When he tried to justify the workaround, I explained it again. And a few days later, the product owner told me that the other team had accepted responsibility for the defect and would be handling it.

Even though the very first principle behind the Agile Manifesto says that “our highest priority is to satisfy the customer,” we need to remember that that is not our only priority. Or put another way, sometimes you need to consider customers beyond the immediate ones whom you deliver software to. Sometimes pushing back on a request, even if it was properly channeled through the product owner, is the best thing to do.

Now, I’m not saying that challenging your product owner should become your usual way of interacting with them. There should be far more collaboration than clashing within a scrum team. But knowing when to step outside the lines a little bit is, itself, an agile virtue. And I believe that being able to make those (hopefully infrequent) calls is one of the things that separates those who strictly follow agile “rules” from those who are truly agile.

Why “Don’t you Have Anything Better to Do?” Should Be Your Mantra

As agile practitioners, we need to focus not just on delivering value, but on delivering the most value we can within a given time frame. But precisely defining “value” can be challenging because what a person considers to be valuable might depend on their job title, social status, time of the year, and many other variables. Identifying that value, and then working relentlessly to deliver software that meets the customer’s current definition of value, is at the core of agile development. The Agile Manifesto mentions several processes and artifacts in software development, and divides them into two short lists: those that have value, and those that have more value. (If you haven’t read the Agile Manifesto, go read it now. It will take you 15 seconds.) This means decisions need to be made between what we can do and we should do.

It took me some time to realize this. I remember telling my boss when I was a new scrum master (-slash-product-owner) that we had a large backlog for several applications. My thinking was that if an item was on the backlog, it should get done at some point. He said that we should work on those items if there was value in them. Another time, we had scheduled time during the sprint to develop a custom module for an open source application that we used. This was a nice-to-have, but far less valuable to our customers than most of the other items we had in our backlog. My boss quickly shot that down and said we should only work on that kind of thing if we had nothing else to do. I resented his “meddling” both times, but eventually realized that he was right.

We generally use the phrase, “Don’t you have anything better to do?” as a way of blowing someone off. But in agile development, that should be our guiding mantra every day. It is another way of asking, “Is this the most valuable task I can be working on right now? Am I doing this just to feel the satisfaction of checking off an item on the list, or am I doing this because it is what the customer most wants to see in the next release? When I am done with this feature, will the customer be disappointed that I wasn’t working on a different one instead?”

So every day, ask yourself, “Don’t you have anything better to do?” Encourage the team members to ask themselves that. It will help them hold themselves accountable. And don’t be offended when they ask you that question, because it will help you remain focused on customer value as well.

Being Transparent with our Customers Is Like Getting a Haircut

Scrum relies on transparency. All parties must be able to see what is being currently worked on and, as far as the product backlog is defined, what other work is planned for the future. Any decrease in transparency decreases the customer’s ability to inspect the product and adapt it to changing conditions (e.g. market demand), and can lead to diminished trust between the team and the customer. Transparency can be an intimidating concept for some people, perhaps because they are afraid that their mistakes or any hidden agendas will be exposed. But that is precisely why transparency is so critical to a culture of continuous improvement: you cannot improve what you cannot measure, and you cannot measure what you cannot see.

Think of a situation where you might get frustrated while waiting for something, like waiting for a meal at a restaurant. In that case, part of the frustration probably comes from not being able to see the work that is taking place. You know that something is happening — you know the chef must be mixing some ingredient with another, or perhaps the chef is still working on the previous customer’s order and hasn’t started on yours, or any number of other things — but you do not have any more detailed information than that.

Contrast that with how you feel while waiting for your barber or hairdresser to finish your haircut. You can see in real-time which part of your head is being cut, how your cut is looking so far, and you have a fair idea of how much is still left to do. If at any point during the haircut you change your mind about how you want your neckline to look or you remember that you wanted your sideburns a little higher, you can ask the barber to make the adjustments right there. The sense of frustration while waiting for the haircut is greatly diminished and you might actually be willing to wait a little longer so the barber can get your look just right, as you requested.

What is the difference between those two cases? The amount of transparency in the work that is being done. When the work is a black box that you can’t understand or control, it is easy to feel frustrated and even helpless. But when you can see the individual steps that are being taken to carry out your request, and you have a say in how they are done (to a certain extent; you wouldn’t tell your barber which scissors to use, because that’s his domain of knowledge and not yours), you feel more comfortable with the process and are more likely to be satisfied with the final outcome.

That is the importance of transparency in scrum. Our ability to interact and collaborate with our customers, and respond to changes in their needs, depends largely on how transparent we are with them regarding the work we are doing. That transparency can be achieved in many different ways: burndown charts, kanban boards, letting stakeholders listen in on our daily scrums, traditional status meetings, and other methods. As we strive to maintain a high level of transparency, we should remember (and teach our teams) that doing so is critical not only to our customers’ success, but to our own.