A sense of urgency

I once worked for an organization, marketing their product as business critical. We spent a lot of energy and effort getting the customers to maximize their use of the system, something which made them dependent on the system too. When it worked, all was of course well and their productivity was amazing.

But the system was not fool proof and sometimes it just stopped working. It didn’t happen all the time but not as seldom that you would not get a bit used to it.

The first time, it was a real disaster. The customers and we consultants panicked. If the system didn’t work, our customers wouldn’t get paid, their customers would not be serviced and since we’d made them so dependent on the system, they didn’t have a really good process to handle this type of situations.

But when it happened again and again and yet again, the same situation wasn’t handled as an urgent issue. Oh, the servers are down. Too bad. We’ll work on it and hopefully the problem is solved soon. Indexed has as so often caught this in a simple image:

Since we let the failures happen too many times, we lost a sense of urgency. We knew the system would fail so we weren’t that serious about it. A real horror story was when a customer was left with a non working system for many days, not being able to bill his customers.

So, what happened to the customers? Well, first of all the trust was broken. We had stated that we would treat his system as business critical, but that was not how it worked. They lost faith in the product and I guess a couple of customers built a separate system for the times when the system failed. The customer staff of course lost all their trust. Many are stressed at work and need their critical systems to work. I guess they did not recommend this system to their friends and families.

Does this mean that systems cannot fail? Well, of course they can and they will but if you are building business critical systems, the likelihood of failure should be low and not functioning systems should be seen and handled as disasters. Of course that does not apply to all functions in a system. There are few really mission critical functions of a system.

When developing systems we must clarify SLA’s and identify these mission critical tasks in the systems. And we need to build a sense of urgency into our crew when disaster strike.

The non responsive UI – a nightmare for users and testers

If there is something I cannot tolerate as a computer, it’s a non responsive UI.

I’m currently updating my IPod music list and I’m so disappointed with Apple that they still haven’t fixed the responsiveness of the UI. If I click a song in the list, it takes seconds before ITunes starts playing the new song.

My least favorite program is in a class of itself, as always. When I select an e-mail in the Inbox it can take many long seconds before the right message is displayed in the preview. This has sometimes resulted in missed information and always a lot of frustration.

As a tester, the non responsive UI is also a big problem. I click something. Nothing happens. So, I click again. Something happens. Is that because I clicked once or twice?

When you’re buying new software for your staff, don’t be satisfied with a PowerPoint presentation, test the UI yourself. And that does not mean the salesperson showing what he wants to show with the data he wants to display. If you have a product list with 100.000 products, make sure you test the search functionality with that data. And make sure that you are handling the computer. Salespeople know their software, know where the loopholes are. But he won’t be there when the guys can’t complete their tasks because the software is malfunctioning.

We can all blame the software industry for sloppy work in this area but as long as the people buying the stuff does not demand this as much as they demand functions which they rarely use, why should things improve?

What is the problem with your problem?

The other day, I visited a web site with an e-com solution as a wanted to make a purchase. I looked at their product catalog and found that they had the product I wanted.

I turned to the site’s web shop, ready to complete my purchase. But when I searched for the product, I couldn’t find it.

I looked again at the product description. Yes, there was nothing indicating that this wasn’t being sold, or that there was any problems with the stock of the items.

But I still couldn’t find the stuff on the web shop.

And there I could have left it, gone to someone else, but since I’m myself developing e-com solutions, I became curious. So I contacted the help function.

I provided a link with the product description and described how I’d tried searching for the item.

The response I got was that the product was only sold during summers. Yes, I could imagine that the product was for summer days but since people go on holidays during the winters, you might want it anyway. And besides this; why market a product you don’t sell?

The response was that there was no error in the e-com site. The stuff wasn’t supposed to be sold so you couldn’t buy it. And that was it. He wasn’t even interested in why I was spending all this time on this question. So, bye bye.

This is just an example how poorly some companies treat their customers. When a felt error is reported, the definition of a Case or an Issue is being thrown in the face of the reporter and the staff doesn’t anything about taking care of the person’s complaint. What really happened during our discussion was:

I: “There is an error”

He: “Your complaint does not meet our definition of an error. So, bye bye. Since I don’t really care about your feelings about this being an error, stop wasting my time.”

Perhaps this had a good explanation. Perhaps they couldn’t remove stuff from their site based on season. Perhaps the person responsible was sick or something. But since the person I contacted didn’t even wanted to recognize that this was perceived as an error, I lost my trust in his business.

But I also have a happy story to tell. My bike was stolen a couple of weeks ago and I contacted by insurance company and filed a case.

A couple of days later I was called by a person from the firm and after verifying that she had the right person on the phone, she before anything else expressed her condolences for losing an almost new bike. I don’t know if she really cared but the mere fact that she bothered to try to see it from my perspective made all the difference. She recognized me.

This affected our whole conversation and I probably feel better about our deal than I would have hadn’t she been such an empathic person. (Btw, the company is TryggHansa!).

We can all learn from this; from the project manager rejecting a new requirement, the developer getting bugs reported, a boss hearing some complaint from his staff.

Read more in

Wired to Care: How Companies Prosper When They Create Widespread Empathy

What controls your decisions?

Dan Ariely with his research makes me wonder a lot about the rationality of decisions. To be frank, he’s made me think that there is nothing like a rational decision.

 

Look at these offerings from The Economist. This is an offering Dan found a couple of years ago, and of course the middle options doesn’t seem to be a well thought idea. Now, The Economist made this add by mistake, but it might not be as stupid as one thinks, especially when the offering is made to people, trying to be rational.

Dan asked a number of people what they would choose and what he found was that when people were given these options, non chose the middle option, 84% took the last alternative and 16% took the first option.

But here comes the strangeness of the human mind. If a group was presented just the first and the last option, the third option just attracted 32% while 68% chose the first option. You exclude an option that no one wants and that change how people view the offerings differently.

This should have huge implications on usability. I guess we all know that people are not rational, but remembering that when you specify the alternatives of that dialog box is sometimes not easy. Do listen to the whole presentation and you’ll hear the full story. And thanks to Dan Ariely for again pulling away the blindfolds.

The risk of placing yourself in the shoes of the customer

On my first professional job, I was doing a lot of short consultant gigs and the lack of experience combined with the shortness of some of the assignments sometimes lead to some embarrassing situations where my lack of empathy became evident. With that I don’t mean that I didn’t care about the customers, it was just that I tried to place myself in their shoes and to see how their work could be made more effective. Well, isn’t that being empathic? Not necessarily. 

We’re being learnt that you should treat others like you would yourself like to be treated, that you should place yourself in another person’s situation and this will lead to yourself becoming more empathic to others. Well, this is sort of true but only in situations where your values and person are the same as the other person. Let’s say a robbery: you don’t want to be mugged and no one else would like to be mugged either. But take other things like being able to drive your car faster, one person can think that this would just be great while others see no need and some think the speed is already too high.

Another situation is of course the customer communication. I love companies which enables me to contact them over the web. I booked a service time for my bike yesterday and I just loved that I early a Saturday morning without having to speak to someone could just visit their web site, pick out a free service time and be done with it. My mother on the other hand is the calling type. She wants to talk to someone. So, to be empathic with her needs if I was to improve customer relations, couldn’t simply place myself in her situation; I would have to recognize our differences too. Me in her shoes is not her.

So, when I was out on my short assignments, the mistake I made was thinking myself on their position and trying to figure out what should be improved. And sometimes that was disaster. The first time I really took notice of this was when I visited a person who used Excel to gather information from 30 districts. I wasn’t there about that task, but he brought it up, since he had problems with a formula.

I directly spotted the real problem. The districts formed their own spreadsheets and sent them in to this guy, who copied all these 30 variants into one workbook. To summarize, he had to spot the right value on each spreadsheet. Of course, Excel was not the right tool for this, but that was what they had, so my suggestion was that he would send out a standard workbook to all districts, make them fill out the forms where the same value was in the same cell. Copy this to a common workbook and then use formulas which calculated the same cells (for example E4) on all spreadsheets.

I quickly showed him how this would be done. He was silent. Well, he said, I spend about 3 months every year making these summaries and using this method, it would take ten minutes. I wonder if I can keep my job.

Oops.

I would have hated that tedious and meaningless task, but for him it was his work and he could see no other tasks which he could perform.

Well, of course we shouldn’t accept the wasting of organizations’ money and time and just leave things like this untouched. But I should have shown more empathy towards this guy and recognized that he was proud of his work, a pride I ripped from him in a minute.

Having met a lot of administrative staff, I’ve often seen the same. When a bunch of consultants storm into their office, ready to make everything smoother, they know that they want to get rid of the stuff they do. Seeing themselves doing other tasks might not be that easy. You and me might do that, but don’t take it for granted in others. Don’t place yourself in their shoes. Recognize that you’re not wearing those sneakers; they are.

Their actions might also be strange to you. Many hang on to specific details which they state are mandatory for the process. One common example are ID:s. In many manual processes, people are required to know ID:s by heart. “The object ID is 73645256 A4” and a highly effective member of staff can be the person who knows all these numbers and their history. When a new system is introduced, knowing these numbers can become unnecessary and that changes the knowledge hierarchy of the organization.

The key is knowing that we’re all different and getting to know your customers before barking in on their processes. Spending some time during breaks can give you many hints about the different personalities. Management should also be open with what an improvement in process will mean for the people involved.

Business value of the boring stuff

This weekend, our vacuum cleaner broke down. We both looked devastated on the thing. Not so much for the money (which of course is boring to spend) but for the knowledge that we now would have to spend a lot of time buying a new one.

First, I tried to make an educated, good decision and scanned different communities and sites for the most recommended and best value. But I soon lost interest and found myself surfing on more interesting stuff. That is most things in the universe. I tried looking at one of those cleaning robots but realized that with two floors, one dog and a boy into Lego, this would probably cause more time spent than our gain.

So, I just gave up and went to the store. I went to one of those malls where are multiple stores to choose from, but realized when I got there that it wasn’t worth my time shopping around. So, I picked a store and went inside.

There are an silly amount of options out there, folks. One brand can have five or six different models in your average store. People went around there, testing the things. I just stared. How could I possibly choose?

And then I nearly fell into the trap that most product owners do when they prioritize. They think that something is boring so they go for the cheapest option out there. I almost picked the cheapest one when I realized, Hey, I hate cleaning. Why should I have the worst possible tool when I do the stuff I hate the most? Won’t that make me hate it even more?

The same goes for product owners. They probably don’t think upgrades, logging, error handling and installation features are the stuff of their dreams, so they try to get this as cheap as possible. And then they complain when bugs go unnoticed for months. When regression testing is a hassle, when upgrades takes forever and roll back is not possible.

I didn’t pick the most expensive vacuum cleaners. I took one in the upper level without a bag. I don’t like shopping those bags either. Since I don’t even know the model I’m using, I’m stuck trying to find that just to know that the specific bags are not available then. And they cost a lot of money. With a Golden Retriever you tend to spend a lot of bags.

Well at home, I found that the new thingy made it easier to clean at home. And having a remote in the handle is really a good thing. The dog hair is handled much better and one of the rugs are clean for the first time in five years. Well, I thought it was kind of clean before but now I know.

And one thing more, skipping the bag means that I can see all the stuff I vacuum. No more hiding of dirt. And that is also important in software development. Never hide your garbage for your in house staff. Better that they know about it and help with the cleaning.

What can we learn from coffee?

I’ve previously been posting a thought about using The Ultimate Question to show the value in quality. The Ultimate Question is “Would you recommend X to a friend”?

I believe that slipping quality might not drive current customers away but prevent customers from recommending a product. For example, changing a financial system is a hazzle, so those annoying errors which you learnt to live with might not make you switch, but when your friend starts a new business you cannot recommend the system.

I just read Wired To Care. It just happened that I found the book on Audible and thought, why not? I thought it would be one of those nonsense books (or rather all sense books) which already says what you know, they state the obvious. But this is far from true when it comes to this book. Filled with real stories and examples, it presents the not so obvious cases.Like with the coffee industry in the USA.

You probably have already heard this if you’re from the US, but for a Swedish gal, this was news.

Coffee was a well tasting, high quality product in the 1950’s. And then a chill fell over the coffee fields in Brazil and the price of high quality beans sky rocketed. So, what to do?

Maxwell learnt that customers were not prepared to pay the new price, so what they found was that if they added a tiny percent of lower quality beans, the customers didn’t know the difference and they could lower prices. Wonderful. But the upcoming year, they wanted to cut prices even more, tested a blend with slightly lowered quality and since the customers didn’t mind, they were on a slippery slope. After many years, Maxwell found that they didn’t get any new customers. The young turned away from coffee. But their customer evaluation showed that the customers liked the blend and were not prepared to pay more.

But then came Starbucks. They realized that the old customers had slowly learnt to cope with the failing quality and they were not prepared to pay more. But the new customers hadn’t learnt to handle the change and were baffled by their parents drinking this vile coffee. They were not prepared to pay little for crap.

Thinking that lowering the quality when the customers accept it is probably a bad idea, but it’s easy to walk that path. To think that they don’t mind? Why bother with that pixel? It probably don’t mean anything for the user if the system becomes a couple of seconds slower. It’s all those many, smart decisions which makes that horrible coffee, while someone else with pride can present a prime product and even charge for it.

How some piece of software started a very bad habit

I’ve never been a person who’d been late for meetings. I think I was late once to school and is the kind of person who really makes sure that I’m on time. We’re always first arrivals at parties.

But when I started working for my current employer, I started missing meetings and becoming late at occasions. I even have double booked meetings in my calendar. After having worked for nearly 15 years, one cannot help wondering what started this bad habit.

And it boils down to software which does not help me in the most fundamental way. When I’m invited to a meeting it is crucial to know if I’m already booked. I guess that this is just not me; most people have a problem being at two places at the same time. So, a calendar for professional use should probably warn me directly if I’m invited to a meeting when I’m already booked in my calendar.

Also, if I make a booking, it’s good to know if the participants are available or not during the time in question. And again, this is hopefully not just me but a universal need for everyone.

So, what happened was that I started using the calendar in Lotus Notes, and who ever is responsible for this system does not find this to be a fundamental need: I need to do some clicking before I learn if I’m already booked or if I try to make a booking when people are already busy. And if I accept or suggest a double booking, I’m not prompted or warned. I guess the product owner at Lotus Notes is a super hero with the power to be at several places at the same time, so I guess that is why he haven’t seen this need as a universal, fundamental need for the booking process.

So, what has sneaked into my habits during the months past is that I’m always double booked for meetings. Since I can accept or book meetings without this being flashed in my face, I’ve started to see it as less of a problem. But it is a problem and a bad habit.

But the lesson is more important than so. If we just imagine the product owner of Lotus Notes being that super hero who can be at many meetings at the same time, he can either realize that his reality is a bit different from others, why a need that he doesn’t have is really important. But one cannot wonder how often you just disregard a crucial need just because your reality is a bit different from everyone else.

Measuring productivity

You get what you measure

So true, so true. These famous words from Mary Poppendieck point at an important objective of anyone interested in their work.

But there is a risk to these words. Because you can be lead to believe that you can measure everything you want.

I want my son to love me. So, following Mary’s words I should probably measure his love. This should ensure me success in getting his love.

Sounds goofy? Well, to most sane people this sounds crazy. I cannot take out a chart and plot my son’s love for me.

But how about productivity? In the agile community I’ve read a couple of discussions about if you can use velocity to measure productivity. I don’t like this idea much. I use velocity for predictions and my priority. Story point estimates are in my world a relative value of size, and if I start measuring how many dots they complete every month, they are not sure to start making their estimates bigger. I still don’t measure productivity but I’ve also lost my chance of predicting my upcoming deliveries.

So, how do I measure productivity of the developers on my team? Well, I measure it by how happy my users and stakeholders Do they feel that the investment was worth it. But, but, you might say: that is too vague! And I say that just this is what matters. If the customer is happy about the investment. Can they make the money they hade anticipated or save the cost they were counting on.

And frankly, I have a hard time finding a good measurement of productivity. I can just look back at my role; project manager. What is a productive project manager? Is it the one who makes the most Gantt chart bars? Or holds the longest steering groups? How does a project manager know if he’s been productive a day? For me it’s a feeling. Some days I can have had this ten minutes meeting which clarified a lot of stuff which will save us a lot of coding time or make us reach our goals. But a numeric calculation, I don’t know.

It was perhaps easier when I was a test leader. And yet not. A productive tester does not find a lot of bugs, he prevents them from occurring in the first place. And how do you measure that? Yes, you can measure the decline in bugs, but how do you know if a specific tester was the reason.

So, to summarize; I wouldn’t feel productive as a project manager if I was asked to measure the productivity of team members.

Don’t forget to harvest the passion of the developers

Most of the software developers I’ve worked with want to solve the problems of the users. Many are real professionals with the attitude of a craftsman. Many are innovative about different solutions. And most of them love to write code.

If you take a developer who wants to solve problems, is a craftsman, innovative and loves to write code you are sure to hear loads of good ideas of what he could do, if he only was given the opportunity.

Many times, his suggestions are not highest on the priority list from the business people. And then you run into the situations when his stuff is never done. Yes, I know that there are other stakeholders who’s ideas never becomes a reality too, but this guy stands there with his hands deep into the code every day, thinking about those things he could do, given that he get the opportunity.

So, you should leave some room for that in your plan. For example, if you’re using scrum or another iteration based method, let the guys pick one thing if they are successful in a sprint.

If you’re doing kanban, you can be a little bit more spontaneous. The other day, one of the developers came up with a great idea. I could see the passion in his eyes. He really wanted to do it. And I could hear that he’d given the thought a lot of thinking (this proved to be correctly later). Since we’re in a situation where the next stuff on the list cannot be completed due to lacking resources of a specific competence, I was considering what we should do next. So, why not? So, I said to him to go ahead. Given that the stuff in progress is done, this will be next.

I think we’ll get so much more code/function/quality out of this than we would have if the stuff had been done with someone who didn’t think this was his stuff, someone who wasn’t thrilled about the idea. And this joy about his work will probably continue after his work with this is done. Just because now it’s done.

But besides from sometimes prioritizing the stuff the developers have passion for, one can also help developers becoming more passionate about all the other stuff. And that is best done (I think) by including them in discussions, requirements and story writing.