Tuesday, March 20, 2007

Types of customers

From time to time, I come across this complaint: developers tell me sad stories about some customer managers that "just don't get it". They do not understand Agile principles and the process they impose is somewhat sick. Are they morons?

No, they are not. First of all, it is counterproductive to consider them as inadequate people. There's always a thing that we just don't understand about them.

The most typical thing that happens is that customer managers do not try to help the team to adopt some good Agile engineering practices. Almost always the customer loves all the things about Team and Customer collaboration and Agile project management, but it looks like there's something magically annoying about unit testing, test driven development, refactoring, code reviews and pairing.

After all, we're all reasonable people and we all have the same goal, aren't we? So there must be some consensus about the way we do things. Or we have some deep misunderstanding of our goals.

So why do we need Agile engineering practices? Well, it allows us to shorten the test cycle, which is important for frequent delivery. It raises the quality of the code and the system becomes easier to maintain. As far as money, engineering practices just make the system cheaper to develop.

But note that it will make the development cheaper in the future. At the beginning of the project, it’s just a pure investment. There's no need to spend hours on automating testing if it takes a few minutes to do manual regression testing for the whole system.

So it looks like there are 3 types of customer managers:

  1. Product-Driven managers: People that value their product. They know that their welfare depends upon how successful their product is going to be. Typically they are the owners of the company. Their goals are long-term one: several years or more.
  2. Project-Driven managers: People that value their project. They will be rewarded if the project will be successful. They are mostly hired managers from bureaucratic organizations. Their goals are based on their reward system and are mid-term one.
  3. Demo-driven managers: There are some managers (thanks god I've seen only one) that value next demonstration to their stakeholders.

Obviously, product-driven managers invest enough efforts on technical excellence. Otherwise they going to fail in a year or so or at least might loose some money on trying to develop the system that is not as flexible as it supposed to be. This is the most comfortable customers for the team that value Agile principles.

Project-driven managers are the most typical ones. They always have the battle in their head. The angel tells them how important is to maintain high-quality in the system and how XP engineering practices can help in doing it. And the devil just make them realize that their bonuses depends how great the system's going to look like the next few months and doesn't depend upon how easy it would be to maintain the system in several years - it's going to be another project with some other manager.

Demo-driven managers don't have a struggle in their head. They just don't want to spend a minute on ensuring quality.

So if you have product-driven managers, you are lucky. Your development is a kind that prevents the problems rather than struggling with them.

If you have project-driven manager, just help the angel win ;-). Otherwise, you will spend most of your time heroically fighting with problems that could be easily avoided.

If you have demo-driven managers, God help you.

1 comment:

Michael Vax said...

Very clear and good classification, Askhat. Right to the point.
I think Demo driven manager may be interested at least in some aspects of Agile - short releases, open to changes.
With Project driven managers our main obstacle is the fact that we openly acknowledge our inability to predict scope and budget. This goes into direct conflict with their objectives and overall ways how organizations are run.
Do I have good answer to this problem? Probably not, but it is worth further discussion:)