Motivating People – Black Dan Developers

Motivating People

Motivating People on a Project

One way of motivating people is to give them a sense of achievement. Instead of threatening them with deadlines let them achieve.

My cousin is a fifth dan black belt at Karate. I thought that it was pretty good when he progressed through the various belts to become a black dan. I thought that this was it. He had arrived. I was even more surprised to find that he continued to progress through the dans and that he had become a bit of an expert. He had never been that confident before.

Now his self-esteem is extremely high and he carries that into other areas of his life. He had left school at fifteen to go into the shipyards. After succeeding at karate he went back to university and got himself a university degree.

Software Developers

Compare that to software developers. There are trainee developers, developers, and senior developers. At senior developer you have arrived. And then you don’t go anywhere – no matter how much better you become at software development. To progress you have to do something else like business analysis or project leadership

I’m not suggesting that you should call people fifth dan senior developers (exposing yourself to ridicule), but perhaps you could have Expertise Level 5 senior developers. Achieving these levels could be related to their productivity levels, quality levels, and customer satisfaction levels etc.

Objective Measures

If the measures are objective instead of based on management opinion, the developers know what they have to achieve instead of having them harass their managers at their reviews.

Striving for theses higher levels gives them objectives, keeps their interest, and motivates them towards continuous self-improvement. It also gives them status among their peers, status which they may not be able to transfer to another company.

Learning from Mistakes

Learning from Mistakes on a project

Learning from Mistakes

Learning from mistakes is crucial to your success on projects.

One of the axe-sharpening activities for which there is seldom time is the activity concerned with understanding why mistakes were made and crushing them out of the process so that they do not occur again. One of the reasons why these activities are not usually allowed is that the time they take is not usually in the schedule and because many of the benefits are for future projects.

You can cure this in several ways. In the beginning do not attempt too much. Preventing defects, like politics is the art of the possible. Prevention of Defect meetings should happen, during projects, only when sub-systems are delivered into test, not when individual programmes are delivered. They should only analyse higher category defects. At one organisation, they had nine categories of defects of which they analysed only the top five categories.

The Lesson Learning meetings should last only an hour. There are two purposes for the meetings. The first is to ensure that the person who created the defects understands why they happened. If they take time out to understand why they created the defects they are less likely to create them again. This activity happens in other professions.

Football Clubs

At football clubs they use video evidence on a Monday morning to analyse the problems that occurred in the match at the weekend. The players are then able to analyse and visualise what they should have done. It breeds good habits. When Liverpool were the top team in the country, whenever a player was transferred from them to another club, the manager of the new club would always try to find out from the player what the Liverpool secret was.

But there was no secret. As Bill Shankly said, they hired the best people and did the simple things. They didn’t do things like pass the ball across their own area. They had cut out all the mistakes which had caused them problems in the past. This was good people with good processes.

Mistake Analysis

The second purpose is to allow the analysis of these mistakes so that the process can be changed to prevent the mistakes happening again. In the past I have found that many of these problems occur because of misunderstandings at various stages. Very often this analysis leads to elements of Rapid Application Development (RAD), especially Joint Application Development (JAD) being taken into the process and the use of developers rather than analysts, designers and programmers. The fewer handovers, the fewer misunderstandings there are.

Standard Practice

Fortune magazine once analysed the software practices of the top 500 companies in the USA. They found that there were four main practices which separated the best performing software departments from the worst. These were:-

o  Standardisation – of platforms, methods, models etc.

o  Joint Application Development (JAD)

o  Timeboxing

o  Prototyping

You may short circuit many of your defects by implementing these best practices.

You should analyse your mistakes so that you are constantly learning from mistakes and getting better and more productive as an organisation.