Customer support or customer success?

Have you ever called a help desk line for a product or service and ended up feeling like the primary objective of the person on the other end of the phone was to get rid of you? Sure, they were helpful but there were just enough underlying behaviors to make you feel like the person truly did not care if you were successful with their product or service. While this particular topic is not directly related to Agile product development, I believe it to be relevant for anyone developing products with some form of customer. The problem runs deeper than telephone support. Face to face interaction with an individual often produces the same feelings – this individual does not really care if I am successful or satisfied. They simply would like the me to go away – successful or not.

Often times providers of service will do their best to generate a state of perceived success in order to satisfy a mis-used measurement system. My recent experience with a car dealership is the perfect way to demonstrate this. Here is the story. Again, it does not directly apply to Agile development but it does apply from the perspective that customer success is a key to the success of any product.

The Dropoff

It seems to me if a business has the objective of retaining long term customers, the primary focus must be making them successful with their products. I recently made a trip to Momentum Mini here in Houston, Texas to have my car serviced. The car did not have a major problem. I had noticed a few times the engine had died while it was running and wanted them to take a look at it. In addition, there were some other maintenance items to be completed. They were fairly simple requests. I dropped the car off on a Monday morning after making an appointment. They have a program where you can pick up a rental car from them. It took an hour and fifteen minutes to get the rental car. Additionally, the first place I needed to visit was the gas station as they had given me a car running almost out of fuel.

The Callback – Not

The service manager told me they would call me the next day. On Tuesday, I did not receive a call. Wednesday morning I left a message on the voice mail of the service representative. Still no answer or call back. Another day passes. This time its Thursday and I am furious. I leave another message for the service representative and the service manager. The message was fairly strong and asked them if they were having technical difficulties with outgoing calls. A few hours later after leaving the messages, I finally get a call back. Basically, there was nothing they could do about the problem and all they had done was rotate the tires.

Picking It Up

When I went to pick up the car, the service representative knew I was upset.  This particular service representative actually seemed to care that I was unhappy.  When they brought the car around to me she noticed there was tree sap all over it and offered to wash it for me.  I accepted the offer even though I was in a hurry.  While they were washing the car, she said the service manager (her boss) wanted to speak to me. She indicated they would be sending me some coupons for dinner at a local restaurant.  This helped a little.  When her manager came out, he apologized for the experience and asked me how they can improve.  When I was finished giving my feedback, I was actually becoming more satisfied.  Then as he left, he destroyed the experience for me.  He said “Now you know you will be getting a survey in the mail.  Feel free to write any comments regarding your experience but it only helps us if you rate us a five (the best rating) on all the questions.”  I told him he had some nerve asking me that and went on about my business.  By the way, I never received any dinner coupons.

Reflections

By now you may be asking yourself, why is this relevant to either Agile development or management, hasn’t everyone had similar experiences?  The primary reason to discuss it here is simply to highlight the fact that measurement when implemented the way the dealership above has done can cause employee behaviors which actually harm the business.  My feeling as I left the dealership was that the only thing the service representatives and management cared about was getting a good score on their survey.  When it was clear they would not, they gave up.  This is why I believe the sales manager never followed up with the dinner coupons.

The lesson here is to carefully choose the mechanism you will use to measure your employees.  Make sure that it truly encourages them to achieve the results you desire.  In this example, having the service manager actually analyze and observe the experience of the customers would have been a much better approach. Or perhaps, reading the comments from the survey and using them to gain a qualitative understanding of how well the service department was doing would have been better.   Nonetheless, in this instance, I am not a successful or satisfied customer and I truly believe the measurement system used by the dealership greatly contributed to my dissatisfaction.

Agile Axiom #2 – Without automation it is mathematically impossible to stay releasable at the end of every iteration.

Based on my experience, without automated testing it is mathematically impossible to stay releasable at the end of each iteration. To prove this point, I will walk through an over-simplified example. The key take away here is as follows. Having an automated nightly build process and a functional automated testing strategy are prerequisites for staying “releasable” when executing even a small Agile project.

Assume the following…

• You are executing an Agile project that will take 6 iterations to complete
• You have to implement 20 user stories, for purposes of illustration assume they are all the exact same size
• You will be design, building, and testing 4 user stories per iteration
• There is one hardening iteration at the end
• Your team is made up of 5 people – 3 developers and 2 quality assurance engineers

• For simplicity in this example assume
  • each iteration is 2 weeks long
  • 6 ideal days of velocity each iteration for development
  • 4 ideal days of velocity each iteration for quality assurance
  • Each story takes 1.5 ideal days for development and .75 days for testing
  • Once built, each story requires .5 days to regression test in subsequent iterations

Iteration 1

4 stories are built taking all 6 IDDs for development and all 4 IDDs for QA

Iteration 2

4 more stories are built taking 6 IDDs for development and all 4 IDDs fro QA

Team absorbs the regression tests requiring two days to complete. The product remains releasable given the fact that the team is confident regression testing has been complete.

Iteration 3

The development of 4 more stories is complete, this is now a total of 12. The QA engineers have tested the 4 new features.

This time the team must absorb 2 days in order to execute regression tests and ensure the product is releasable. The quality of the regression testing becomes compromised given that the work required to complete the testing for the current iteration requires all available velocity.

Iteration 4 and 5

The story is the same. The completion of user stories continues and iteration demos look good. However, the quality is questionable given the lack of velocity spent on regression testing.

Iteration 6

Full regression testing now requires 10 days of QA velocity. The developers are not available to perform the testing because their time is spent fixing bugs. Each fix that goes into the code must be retested and more regression tests must be run. It is likely the team will enter into a series of mini (test, fix, retest) cycles during this iteration. The developers are challenged because many of the problems that were found in hardening are in features that were complete over a month ago. Fixing them takes time. At this point, either the schedule will slip or the quality of the release will be compromised.

The Bottom Line

While this example is extremely over-simplified, the point is the same. The more stories that are developed, the more time is required to perform regression tests. There are two ways to address this.

1. Acknowlege during release planning that velocity will shrink as the iteration progress. In this scenario, you would simply plan fewer stroies in the later iterations. This approach does not optimize the productivity of the team
2. Have a good automated test strategy which enables the team to run automated regression tests every day without requiring the team to waste their precious velocity executing repetitive regression tests. In this scenario, the teams would adopt criteria that includes (Design + Build + Test + Automate) before a user story is “accepted”.

It is true that good development techniques which secure the stability and reduce the turmoil of the code (object oriented programming) as it is developed can reduce the risk caused by the problem identified above. However, these techniques combined with a successful automation strategy will enable teams to deliver high-quality, feature rich, code on time.