Over the course of years of working on the most diverse web development projects in the role of a project manager, I was always facing up to the issue of additionally motivating the good programmers, eliminating the weak ones and waking up the potentially good, but lazy people. Everybody is a story in themselves and what motivates one – inhibits another; what interests one – is boring to another, what makes one happy – makes another angry… I was always thinking how to find a balance among all these differences and to make a system that would provide an objective picture of the state in a team and that would motivate everybody to give more effort than they used to. I turned to a very simple and always objective mathematics for help and the results were great.
I came up with a very simple idea that can be applied in any area of activities, and I will now present how I applied it to the team engaged in software development. The most important thing is to establish the main indicators of successful progress on a project. Parameters should be found that will provide a clear picture of how fast and to what quality extent we move within the framework of the project. On the basis of that, we may place objectives and measure whether we achieve them and to what extent each individual team member contributed to the realisation or non-achievement of the objectives.
It is important to mention that I have been using some parts of agile methodologies in project management, especially the Extreme Programming (XP) approach, for years now. What is most interesting in those methods is that all work that is to be done is presented through a group of very short stories that are recorded using as few words as possible. Afterwards, each story is evaluated and awarded the points needed for its ending. One point represents time, which is equal to an ideal programmer day – that is 8 hours of programming by one man without any external disturbance or problems that might occur. These evaluations are used with extreme programming in planning iterations, i.e. planning one week’s work. This planning is done simply by taking the most important stories that should be implemented and only the number that may be finished during one iteration. The iterations usually last one week, but they may be longer or shorter, which depends on the individual decision of a team leader.
This brief introduction into Extreme Programming (XP) is necessary to facilitate my presentation of the ranking system that I introduced and this approach would not be possible without the direct help of the XP methodology.
As each short story that describes a part of the software that is worked on, also simultaneously represents the programmer’s task, and as each story has the time evaluation during which it can be performed – the number of points that are awarded to it, everything is ready to introduce a system of ranking and motivating the programmer.
For each completed task, the programmer is awarded points that equal the value of the task. Over the course of a month, everyone has an insight into the ranking list and the daily changes. In that way, a competitive atmosphere is created that incites everyone to do more. However, it is not sufficient to look at the number of points alone in order to determine the quality of work of each programmer. Testing of the completed code is very important in programming.
I often met programmers who did not really like to test their code and to advance it; therefore I introduced the practice of having one person in the team whose duty was to test each completed task. During the testing, the number of errors found in the story that should have been implemented is recorded. Each error found brings a certain percentage of negative points. The number of realised points affects the ranking list and this is how we measure the working speed, as well as the number of the errors made that are used to measure the work quality. These two parameters together form the final ranking list.
Now, we arrive at the subject of motivation. If we want to additionally motivate the participants in this small contest, we introduce pecuniary bonuses for the places won on the ranking list. There may be various approaches, but I apply the following most frequently. At the beginning of the month, the budget for the bonuses is allocated and it is announced that the top n programmers (n depends on the number of people in the team) will share the bonus among themselves. All of them will get a part of the total bonus amount, which is reached by a simple mathematical division, whereby the number of the awarded points realised by each person is taken into consideration, the total number of realised points together, and the individual share in this total points number. With this approach, we motivate people to fight for the maximum number of points until the last day in the month, because the further ahead they get with the number of points won from their runner-ups, the more money they win.
At the beginning of each month, the whole race starts from nil, so everyone has the opportunity to prove themselves each month. At the end of the year or at the end of the project, a deeper analysis can be made to see everyone’s performance over a longer period of time, and annual bonuses may be introduced that would take into account all the months in the year.
In this manner, the competitive spirit remains in the team; it is easy to follow up who did what quantity of work in a month as well as the quality of that work.
Apart from the aforementioned, it is highly important to permanently incite internal cooperation between the staff in the team, good interpersonal relationships and a cosy atmosphere, as that is the absolute pre-condition for their personal satisfaction. A satisfied man produces much better results.
During my work with one of my former teams in the AlefBrain company, following the introduction of this evaluation system and ranking the programmers, I felt totally free to experimentally cancel the mandatory working hours. Everyone could come to work whenever they wanted or whenever was convenient. I had no need to monitor their arrival at work as the focus had transferred to the work results. If a programmer has good results, as the team leader I am not remotely interested in whether he accomplishes the results working at home, while travelling, sitting in a café or a park. That was one of the most interesting experiences that I had as everything functioned better than when we had regular working hours.
Therefore, do not hesitate, establish a system to measure the results and set people free! On making that move, you will be surprised to see that you get multiple results in return in the better quality software that you will be getting.
Miljan Vranic / Миљан Вранић 