Once upon a time there was a team consisting of a few developers. They got down to their project with real passion.
They believed that the best way to learn is to learn from mistakes, so they regularly had retrospection sessions to discuss issues such as:
- consistency of estimating and expectations
- test coverage and its effectiveness
- number of bugs detected in the test phase
- code readability
and a few other things. They had real fun, because they felt that they developed in their specialty. Based on those retrospections they came up with some rules and standards. All the team members agreed that these regularities enable them to work more effectively, so they employ them eagerly. They set up their own Wiki, in which they listed all the standards to be applied by the team, and which they later modified to keep pace with the changing needs and experiences.
Due to the fact that their work was exceptionally smooth, the project sponsor started to hire new and new and new developers to join this team. The first team members became its leaders and then managers. Everything went off really smoothly. Of course, the new people in the department (because, naturally, the team developed into a department) were obliged to learn the existing and proven standards, and apply them in a strict manner.
After some time our managers noticed that these requirements were not fully met. They had problems with forcing the developers to apply the standards. It took them a long time to come up with a solution to this situation. Because they were seasoned engineers, they approached this issue in a strictly analytic way and came up with a formula. According to this formula the employees’ premium depended on the degree to which they conformed to the standards. For example: for 80% test coverage you get +2% of premium, for 50 tester-reported bugs you get +1.3% of premium, and for estimating maintained +3.2% of premium… What a bright idea…
And then the
GAME started.
Rules
The intention of the managers was to reward the team for keeping conformity with standards and to encourage the employees to apply them. Nevertheless, the managers completely unconsciously started a
GAME with the following rules:
- team members are the player
- you win once you earn the biggest amount of money
- the rules for getting money are specified by the standards applicable to the team
It soon turned out that developers and testers were seasoned players. They would often win…, but:
- test coverage was perfect, but: getters and setters were tested, the tests were disturbing instead of being helpful
- developers provided perfect estimating every day, but they were very, very, very pessimisti
- testers found dozens of bugs, but most of them were about double spaces in labels, missing full stops, etc.
- coding standards were obeyed, but whenever possible, the developers coded as they deemed fit
- retrospections declined; standards were not further developed, they finally became inapplicable to the then situation and impeded the work
What the heck happened? - the managers asked -
We really meant well!
Conflict of values
A fellow methodology expert who specializes in analyzing the value hierarchy among employees (it happens that the companies want to know what counts for you: development, professionalism, safety, career, and in what order) was so kind as to tell me in detail that no serious test collates professionally-valid values with values such as family or health, because in such a case the former ones always fail.
When the test does not fulfill this rule, we end up with falsificated data, because the test results will always sway in the direction of family, health, etc. It seems logical that when I have to choose between my career and a permanent damage to health, I will always be driven by my self-preservation instinct, and I will protect my health even at the expense of my professional development.
In this particular team the managers made this specific methodological mistake. Because, if I choose between fitting in with estimating (even if we have to overestimate a little bit) and Christmas gifts, the former one is the perfect choice – no matter what! This is not about us being bad or cheating. Nothing of the sort. That's how we are construed. The borderline between just estimating and overestimating is quite fluid and we easily find the rationale for crossing it. In my opinion, the one to blame is the one who has made such goings-on possible rather then the one who really does it.
Disastrous consequences
Due to the fact that conformity with standards was only the managers’ means to achieve a different goal, the standards were neither further developed nor improved. Nobody felt that it was necessary. Why should we change and complicate the ways to earn money if we already know how to win?
Cash motivation is OK, but only on condition that all human activity boils down to earning money. Take salespeople. In simple terms, a salesperson deals with selling products/services and gets a commission for any bill that he/she brings to the employer. It will work. But what if a salesperson gets commission for the number of meetings that he/she arranges? Then, again, the GAME starts. It may turn out that, OK, there are meetings, but with companies that will never become our clients. Who is responsible for that? First and foremost, the one who developed the GAME.
When your employees have a creative type of work (in this case these are programmers) and the rules and standard must evolve and improve with them,
you mustn’t make their salary dependent on the degree to which they conform to the standards. Otherwise you will kill their creativity and work rules will soon become stiff.
Obey standards, because it’s worthwhile
For the standards to work and evolve, they have to be important simply because they are standards. People have to be aware of their value, want to obey them, and see that they make their work better. This is the way our first team members from the image above had worked.
In such a surrounding the standards will evolve and the people will be willing to develop them. Otherwise you will run the risk of implementing the standards on your own, forcibly or through the newly employed members of Committees for Standardization, which will only complicate the rules of the GAME. Then no one will know what is the general idea of it.
And what about money?
We can summarize the situation that I have described here in the following words:
Motivate not by cash, but pay them well…:) There’s nothing awkward in it – when the basic needs are not satisfied, there’s no sense to think about the higher ones. Of course, we all need a sort of a golden mean, because any budget is limited.
“To pay well” does not mean “to pay more than a competitive company does.” It may be even less than in the competitive company, but if you give your employees some non-cash incentives, it will work. Still, I agree that this is a very individual case and it makes no sense to generalize, as it may be unjustified.
