Customer Support

A couple of days ago I had a good conversation with a friend of mine regarding customer support. Before going into the actual discussion, I want to say that I'm a very strong believer in actively engaging your customers/users on all level, specifically one of the competitive advantages any organization can develop is having great support. In fact there is no excuse for not having great support. You don't have to be a big company, you don't have to use any fancy management system, you don't need to hire special experts at doing so. All you need is the will to establish great support and the persistence to actually go and do that.

Establishing great support, from my experience, has one of the biggest ROI in the organization.

But back to the discussion, specifically what we talked about is how far will they go and expose their support database to their users. Currently, while they do have great support, from a user perspective, once a call has been acknowledged as a defect or a needed feature there is no visibility as to its progress.

In most cases, either you have stumbled on a critical thing, resulting in an almost instantaneous fix (sometime in a matter of hours), or you have stumbled on something less important which go into an arbitrary hidden to do list. as a user there is no middle ground. The things that go into that future to-do list are going into a big black hole and there is no telling how long it will take to actually get a fix.

On the other hand when I asked why do they not publish the above mention to-do list, he told me that currently he fears that seeing the entire picture might scare off some potential and even existing users.

To that I said not likely!

Granted I'm sure that some will be scared if the list is big enough, However like I any kind of relationship being honest is probably the best long term strategy. Hiding the truth from your users has a big chance to backfire. As been demonstrated in several occasions (and being on that end as well I also can testify), you can't hide forever behind a hidden to-do list. At the end the users, will start noticing that some defects are going down that drain hole never to return. And if enough of them does so eventually you will have to deal with a damaged reputation and that's even less fun. Hearing once and again that "this will be fixed/added in a future version" without committing to a time frame, becomes annoying unless you actually see those in a reasonable time. And you never but never want to have annoyed users.

Personally I prefer to hear the truth, if you decided that the issue is not that important just let me know. If its that important to me maybe I'll be willing to pay for it. If not, just help me to work around this. I'm a grown up and I expected to be treated as a grown up.

of course we have also discussed some middle ground, one option was to allow all users to track only their open cases. Which probably wont change the fact that these things are not fixed, but will give a better indication to the actual status of things.

naturally in the long run the only true solution is just to make the product so good and the number of defects so low that this will become a non-issue. However that's probably a whole different story.

So share with me how are you handling your support at your work place? what more can be done in order to mitigate and find a good compromise?

Read more »

Posted in: Random Thoughts,Self Improvment

Flexible Planning

I sometimes have trouble with explaining to people the basic concept behind agile way of thought regarding project planning and management. Recently i cam across this gem, which as far as i could tell is unrelated to software but in my eyes does a marvelous job at explaining these ideas.

just to make sure i understand, I’ll recap his main points.

there are two way of planning and managing a project:

the classical way – set your goals as the result you want to achieve, from those goes backward and derive the steps needed in order to achieve these goals.from these decide on your plan of action and than just try to follow that plan.

Flexible Planning – goes a little different. you still start out by setting the goals as desired results. but instead of going backward from them, you start by examining where you are and then pick a single action to do that will bring you closer to these goals.when you finish doing that action you evaluate your position again and again pick a single action that will advance you towards your goal. hopefully given enough time you reach your goal.

these two approaches are completely different, the first one when applied to software projects will result in a Gannt chart depicting your plan and by trying to forcing the organization follow that plan. in some places management will even put several check points to and allow the plan to change (which in most cases when facing reality that is a must). The second approach is in my opinion embodied in all agile processes. its an inspect and adopt process. you take one step inspect your new state and adopt you next actions.

The funniest about this, is that i used to work at a company which was in all aspects attempting to be and was an “agile” company. However, in one of the higher management meeting, I was told to plan my work and my team goals using the first approach. Sadly only today I can recognize the contradiction.

Read more »

Posted in: Agile Principles,Planning,Random Thoughts

Experience of a beginner

One of the thing i really like about being a consultant, is that i get a chance experience first time reaction of people i’m consulting to the new practices. Sometimes these reaction are suspicion, fear and doubt. But in some (happy) cases when I’m able to bypass these, I see beginners takes these practices and leverage them in ways I only expect to see much farther down the line.

so what am i talking about?

Every programmer is given from time to time a task to change/fix sections of the code he is unfamiliar with. Over time I’ve noticed that there seem to be two basic approaches in this situation:

Lets read and understand

one approach taken by many when facing new code is to treat it as a text book to be understood. First the programmer will collect every piece of information he can get his hands on, specifically those related to design. If possible he will even ask for tutoring sessions with someone more knowledgeable. When that’s done, this programmer will continue to investigate the source by reading it, until he reaches the level of understanding he feels comfortable with. ONLY then he will actually start changing the code in order to perform his given task.

Lets Feel the code

This is a different kind of programmer. (Once I believed i was unique in doing this, but over time I saw that many are doing just the same) Anyway, this programmer when approaching new code to learn, will start out by diving in with an editor, and immediately “refactor” the code to his pleasing. In fact refactor is a little over statement, in most cases its just pure formatting and does not involved any real changes to the code. I think that what the programmer is doing is trying to “feel” the code through the keyboard. Recently i spot the same behavior in my kids when given a new toy. they start out by physically feeling the toy and only after they feel comfortable actually start the “playing’ phase. When dealing with software, the closest one can get to this is by applying an editor on the source text. Over time I understood this is a very powerful technique, but I came to realized the context of this process i.e. pure learning. Today I tend to throw away the result of doing this and start over when I’m done.

Using tests to Grok new code

When doing TDD for some time you develop a new technique for handling new code. And this is what i saw one of the people doing here (although his experience with actual TDD was minimal at best). I think its the ‘feel it’ approach taken one step further. Instead of reading the code or blindly hacking it. he used tests to drive out your learning process. That person was given a task to do on a part of the code he was unfamiliar with so the first thing he did was to just write some tests to for that code (the organization is new to TDD so most of the code is not yet covered) in order to understand what was going on.

doing that helped him uncover several strange behaviors which really made him realize that something is not right there (later on one of them even turned out to be a hidden bug), and as an added bonus the tests written were included in the team suite of unit tests.

For me seeing that was a really nice surprise. I recall it took me quite a while to adopt that and use that approach and i was starting to do it on a regular base only after several months of actual TDD experience.

so what’s the moral of the story?

1. always look for new beginners to see how they adopt new habits. There is much to be learnt there.

2. when dealing with new code, try approaching it with tests.

Read more »

Posted in: Engineering Practices,TDD