One of the problems I've had in previous positions was that sales people wanted more features and less bug fixes. The reason was that they thought that the lacking of certain features made customers go for another option or just skip the purchase all together while bug fixes had no effect on sales. The sales people thought if a bug wasn't visible on the demo, it wouldn't affect the sales. Now, this might seem harsh and the truth is not that black and white. Of course the sales people cared about their current customers (especially if they called and whined about the bugs) but in principle, they thought that bug fixes didn't affect new customer sales.
I can sometimes see the same strategy with some "waterfall project managers". With this I mean project managers who believes strongly in a fixed specification and sees the goal of the project being meeting that primal specification to the budget and within the time frame. Fixing those irritating bugs just don't lead to that objective, if the bugs are not directly hindering the stuff in the specification.
I've seldom have had great arguments which these guys have grasps. Yes, I do have arguments but these work best on those who already are sold on agile values. But with The Ultimate Question and the research discussed in this book also gives me the figures to back this up. Because bugs do affect new customers sale even if you can hide the bugs during demo. And bugs are directly contra productive when it comes to forfilling project objectives.
If you've read my previous posts on The Ultimate Question, you know that question. In other cases, here goes again. It's a question you ask a customer: How likely is it that you would recommend product/organization X to a friend or a collegue. The people answering 9-10 are called promotors while people answering 1-6 are called detractors. If you subtract the detractors from the promotors you have a value, Net Promotor Score, which is a value of your customer relations. This gives you an idea of future sales, since detractors talk other customers from selecting you and the promotors works like recruiters.
So, what about the bugs? If you look at software, what keeps people talking about software in common discussions. Well, some people can talk positively about a feature or two but what really gets people talking is faulty software. "I tried purchasing X from e-com store YU, and it didn't work even if I tried ten times", "Oh, that crappy software failes every time I try downloading a file to my computer". You don't have to go far on the Internet to read someone complaining about bugs in software. As for my self, the reason for my having almost no confidence in IBM/Lotus isn't the lacking features in Lotus Notes, but the loads of bugs. And I complain about that. I'm more likely to complain about software that doesn't work than bragging about something that do work. I never went around spilling the beans about the lacking bugs in Exchange and Outlook. Occasionally, I could just mention this, but more often it was in response to someone else's complaining about their failing e-mail system.
So, I do think that bugs creates more detractors than features creates promotors, and this is why bug fixing should be of highest priority to every sales division. The features might get the demo to result in a closure, but the bugs might preventing you from ever giving that demonstration. I don't have the research here to back me up, but this would be a really interesting field of research. But I think that the principles described in The Ultimate Question backs this up.
All projects should aim at creating more promotors than detractors and with this in mind, the bug fixes should also be of interest of hard core waterfall project managers.
Reading The Ultimate Question is easy, understanding the principle is not that hard, but living up to the statements is probably one of the hardest things any organisation can do. This is also stressed in the book; giving the customers and the users so much power and influence can be hard, especially if you're a manager used to KNOWING what is good for your company. So, to get back to my previous cliff hanger. What is the ultimate question?
The ultimate question is the one question you can put to a customer and from which derive the quality of the customer relation but also the future economics of an organisation. In it's purest form, the question is:
Would you recommend organization X to your friends or collegues?
So, why is this the ultimate question? As I've stressed earlier, you should really read the book yourself. See this only as a teaser. But the idea is that questions concerning the own experience is just not enough. The reason for you staying with a business can be complex. There might be costs with switches, etc. But if you are willing to give a recommendation to someone, it means that you stick up your head and state that this is something you think is really good. And also the opposite; if you find an organization that poor that you actively or when questioned about it, recommend another alternative, that is really powerful. And if you have more people talking bad about you than good about you, you're probably in a bad organization. You might still have paying customers but that are talking ill of you and given the opportunity, they will abandon you. If you instead have customers talking well of you, they are probably more loyal and are the best sales people for you.
So, what you do is that you ask this question to your customers, giving them the option to answer on a scale, 1-10 how likely it is that they would recommend you. And then you take the 9 & 10's and retract the 1-6. Now you have a value which you can compare in time, between departments, divisions, etc.
When it comes to software development, asking the ultimate question about the result of a delivery might not give much, but if the numbers change between deliveries or if different customer groups are differently affected by a delivery, you have something to discuss.
And also, as it is with all these questions. If you post the question in the team room and state that this is the goal, to make the people recommending your business more and the negatives fewer, you can also focus on what makes them more delighted in your product and what pisses them off. Low quality and bad user interface really annoys people but is probably hard to give a business value but with these findings perhaps we are in the making of giving them a value. How about that?
I will get back to this subject!
Occationally, you read a book which affects the way you view your daily work or thinking. I can probably name five or so books, so when they come into my life, it's thoughtworthy. I guess a lot of my thinking during the daily runs on my vacation will be around this latest books. Having read the work of Collins, the reading of The Ultimate Question by Fred Reichheld was yet another eye opener. As I've mentioned before, I got a disturbing response from a former business partner that he measured his customer's satisfaction by if they paid their bills or not. Having working with customers during my entire working career, this gived me the chills about the future of this actually really nice guy's business, and this chill is confirmed in the works of Reichheld: a business who does not care what the customer feels about his experience is doomed in a modern business situation.
So, what is The Ultimate Question? Well, it's nothing from The Hitchhiker's guide to the galaxy if you thought that, but there is a connection. If you haven't read that book, there is a culture who wants to know the meaning of everything, so they ask a computer which replies (after a seriously long time) with the nonsense answer of a number. And the reason is that the question was stupid. If you ask the wrong question, you get the wrong answer.
The Ultimate Question is related to this issue in the sense that most businesses wants to know what their customer's think about their products and the book discusses how they misses the answer by forming the wrong question, using the wrong form and not responding to the answer. And that these businesses sees this as a part of marketing, while a truly successful business sees the customer's views as the core point of improvement and business.
So, what is the ultimate question? I should answer you that you should read the book by yourself, because if you had the time to read this post you should really take the time to read the book. But instead, I leave you with a cliff hanger and say that I'll get back to this. Because this is a blog dedicated to agile software development and software development who does not focus on this question should not call itself agile. Agile is about responding to the customer, and that is what the ultimate question is all about.
I'll get back to this subject! Now, I'm heading for some dinner with the family.
I just read that author Frank McCourt has died of cancer: http://www.google.com/hostednews/ap/article/ALeqM5jlTCrLZI9MXHoFOm8L3bK4aO-HuwD99HRS282
For you who haven't read his book, Angela's Ashes, this is a time as good as any to read this amazing story. I know, you've seen the movie, but that is not the same. I really hope that I can get my son to read the book when he's old enough. You often read about these horror stories of people's upbringing but to see this, in modern time and in a not so distant country is an eye opener. At least it was for me.
When we started helping out a single mom in our neighborhood a couple of years ago, I bought an old stroller for two kids. It must have been at least 15 years old, ugly and heavy, both strongly built. I then had in mind a future soap box car since the modern strollers are not exactly built for that but then it all just came to nothing. But since the stroller has been standing there for quite some time now, the kids turning five this year, we just decided to make it happen. You could call me the product owner. I just said to my husband that wouldn't it be nice to build that soap box car now? I imagined the simplest possible thing, built in a couple of hours, but now, four days later, we have this monster (which we have no idea where to put) which takes at least three kids and with a braking functionality.
So, what is the conclusion on this? Well, as always as a product owner, you will have another mental image of your requirement and how hard something should be. But it's also interesting how we all felt that this became so much interesting that my original idea of a soap box car. (B t w, all I did was pain the thing)
I like fast and easy access tools, and Posterous seems like the thing for me! Posting to blog and social networks via e-mail, including images.
And btw, here is the soapbox car my husband and son are building.
I met Dan BerghJohnsson on a lunch in June and we were discussing our common interests in Domain Driven Design and agile methodologies. We share the notion that the agile values walk hand in hand with DDD and how DDD help the communication in agile projects.
Getting developers involved in agile is often no problem, instead one of the biggest challenges is getting the commitment from project managers and the chosen product owner. Too often agile and DDD is seen as a developer’s question but to be highly successful, the commitment starts in the product owner.
Developers often meet and exchange ideas, they blog about their findings and build communities, but the product owners deriving from the business perspective (project/product manager–>product owner) are not common in the agile community.
So, Dan and I discussed how we can build a network for product owners/agile project managers in Sweden, starting here in Stockholm. We’re planning an informal get-together sometime in early autumn so if you’d like to participate, do contact me or Dan. If you’re not a product owner but is still interested in such a network, of course you’re also welcome.
When do you use kanban? When I read the recommendations from Swedish Crisp, I see that they recommend kanban for support organizations and software development teams where the possibility to solve problems is most important.
The reason for me turning to kanban is just that I want to solve problems. That, I want them solved, things done. Completely done, according to a definition of done.
If you work with a time boxed methodology like scrum, I’ve found it hard to handle scenarios like these:
- One day after deployment, a crucial bug is identified so we cannot install on customer sites until the upcoming delivery.
- In the middle of a sprint, a resource becomes unavailable (sick, has to solve issues outside the project).
- At the end of the sprint, it becomes obvious that the story cannot be completed and that to meet the deadline with acceptable quality.
With kanban, I can handle these problems much easier and this is why I like this approach in one of my current, very complex projects. Of course, we’ll run into other problems but as a project manager I want the right things done to the right quality.