Some time ago I got a question from Sebastiaan, one of my colleagues. He told me he was struggling with an important issue:
Should we spend time on things the customer didn't (explicitly) ask for?
Here's his full question:
Hey Jurgen,
I am curious about one aspect of Scrum that I don’t really like. Right now we have acceptance criteria and we adhere to them strictly. So strict even, that we’re now starting to say [to the Product Owner]: "No, we are not going to do this, because it is not in the acceptance criteria."
However, a lot of times, we know that this will mean one of two things:
- rework later;
- customer not dissatisfied, but not extremely happy either.
I think part of the reason that we get return customers is not just because they got what they wanted, but also that they got more than they bargained for, with minimal effort on our side. Sometimes you just want to add some real value to the work item that you’re busy with, that will only take an extra hour and will “wow” the customer. How do we deal with that in an agile/Scrum way?
Sebastiaan
This question was so interesting that I had to think about it for six weeks before feeling able to reply (sorry Sebastiaan). Anyway, here are my thoughts:
The underpromise, overdeliver principle tells us that we should manage our customer's expectations in such a way that we are able to deliver more than the customer asked for. It is easy to see why this works. You save yourself some slack in case things go wrong, meaning you have some time to solve any problems. But if things work out well, you have some time left to do something extra for the customer, assuming (note I'm stressing the word assuming here) that the customer will be pleasantly surprised with the extra cherries on top.
The question of how best to satisfy customers has been described in the Kano model, published in 1984 by Dr. Noriaki Kano. In Implementing Lean Software Development, Mary and Tom Poppendieck wrote this about the Kano model:
Kano noted that increasing performance [implementing more features] gives linear results - customer satisfaction is increased in direct proportion to the increased performance. To get an exponential increase in customer satisfaction, you need to discover and meet unmet needs and thus surprise and delight customers. Kano said that great products do not come from simply listening to what customers ask for, but from developing a deep understanding of the customer's world, discovering unmet needs, and surprising customers by catering to these needs.
So, does that mean that the team should build what they think will delight the customer?
Absolutely not!
As Kano pointed out in his work, it takes deep understanding of the customer's world to understand how to delight a customer. The average team member is usually too far away removed from the customer to really understand her world. That's why there's a Product Owner in Scrum. The Product Owner represents the customer, the users, and any other external stakeholders. It is the Product Owner's job to deeply understand the customer's world. It is the team's job to deeply understand the technological world. Together they should be able to build a product that will delight the customer.
(Of course, it is even better when the team tries to understand the customer's world, while the Product Owner tries to understand the technological world. But never should a team be allowed to implement features without asking.)
A year ago, in my blog post Oh My God, They Killed the Bug (You Bastards!), I blogged about someone having solved a "problem" in my car that I didn't want to be solved. I had a rotating knob on my gear stick, but when my car was returned to me the knob was fixed. It was a fine example of a technical team trying to understand my needs as a customer, and attempting to overdeliver by (literally) fixing something that I had not pointed out as a problem. They completely missed the mark, and I was furious. I had grown fond of my silly old rotating gear stick, and it took me a month to get used to the new situation.
The road to hell is gold plated with good intentions...
So, here's my 4-step guide to delight your customers:
- As a team member, while planning a new sprint, make suggestions to the Product Owner about things that you think might delight the customer. Don't feel bad if the Product Owner doesn't agree with your suggestions. He is supposed to understand and speak for the customer. (But I'm sure the Product Owner will appreciate your ideas.)
- When the Product Owner asks for a change during the sprint, and when you agree that the change is a good idea, then do it! Who cares if the changed feature wasn't listed among the acceptance criteria of the sprint? Agile is about "people over process". If the people involved want it, then it must be good. Sticking to acceptance criteria is a process. And process is for wussies.
- If, during a sprint, you have a great idea that you think is worth doing within the sprint, talk about your idea with the Product Owner first. Don't assume he is going to be pleasantly surprised later during the sprint review. I'm sure he will be even more pleasantly surprised if you contact him first and ask him if it's OK to spend some time on your suggested change.
- If, for some reason, the Product Owner is unavailable, and you think implementing your idea now will save you serious problems down the road, then do it. But make it reversible! Try to delight the Product Owner as soon as he is available, but roll back the change if it turns out he doesn't like it.
Fixing the knob on the gear stick in my car was not on my acceptance criteria. I probably wouldn't have minded the technical team "fixing" it, if they had shown immediately what they had done when they delivered my car. And if they had been able to "unfix" the gear stick before the color of my face had turned shiny red, I would have been delighted at their proactive, communicative and technical skills.
(pictures by nutmeg and mccun934)
Twitter -
Subscribe -
Newsletter -
Bookmarks
Latest, greatest and favoritest posts:
Great Managers Have No Secrets
Communication = Information * Relationships
Oh My God, They Killed the Bug (You Bastards!)
