After six months ScrumMaster John has finally found someone to fill the role of Senior Software Developer on the team. The goal is to find someone who can round out the team and play many roles (see: Bottlenecks). After many interviews they’ve settled on Kirby[1] who has over 20 years experience developing software, both server side and GUI. He is a self proclaimed expert in most of the technologies the team uses and that’s where the problems start. In addition the team members assume that he is being very well paid, perhaps better than any of the rest of them.

Attempting to learn the basics of the code base in his first few Sprints, Kirby takes on GUI, Middle tier, Server and Testing Tasks. He asks his teammates for code reviews and the code is pretty good, however it becomes clear that he can be touchy on some subjects and isn’t eager to receive negative feedback. On the subject of feedback he says: “I’m a Senior Developer, I don’t need to learn from you, it should be the other way round”. At first the team just try to accommodate his needs, but after five to six weeks tensions begin to rise. Ian (the Middle Tier guy) feels threatened, he sees Kirby trying to occupy the niche he has occupied on the team. To compensate Ian spends more time doing server side work, which in turn causes Doug some concern. Even Tonia feels a little bit threatened as Kirby starts doing some automation work. Read More…

Be Sociable, Share!

• 

Your project schedule says that you will get 2 more team members this week and 3 more next month. How do you integrate them into the team? How do you bring them on board? How do you avoid slowdowns? In a word you can’t avoid the slowdown – adding new people to the project will slow the existing team down.

On any project it will take from 2-4 months for the team to integrate a new person and recover from the slowdown:

• The person will need to be trained: In your code base, how your application works, what coding style is, how you application works, …
• This person will disrupt the Teams Formation (see Tuckman’s model of team formation) – this is an especially important cost when the team has already reached the performing stage. This happens because the new person alters communication paths and will force people to renegotiate relationships around the entire team.
• The person will be a drag on the team requiring support to learn new tasks.
• The person will increase the communication complexity (i.e. the number of communication paths) within the team.

All of this leads us to discover Brook’s law: “adding manpower to a late software project makes it later” (from the Mythical Man Month 1975, reprinted in 1995). The physics of people hasn’t changed in 35 years.

So what can you do to solve this problem?

• Say no – if its too late in the project – in many cases 4-5 months before release is too late.
• Can’t say no consider what Project Udall (Surviving Object-Oriented Projects Alistair Cockburn, p20) did: Halt the big project, start a small project and add only the people who can contribute to its success to the new project. While its expensive to have people sitting idle, it may be cheaper than having them slow the project down.
• Bring on all the new people at once so at least you pay the costs once in the life of the project as opposed one person at a time.
• Create a new team staffed by the new people with one or two old timers. They won’t get very much done for a while, but at least they get in the way of the others.
• Get them to help with the exploratory testing, with the focus being the stories that are being written in that Sprint of iteration.
• Ask them to write or refactor some automated acceptance tests.
• Get them to read and write Unit tests – start by reading existing Unit tests, after all these should explain the code. If they’re not already Good Unit Tests then take the time to improve. If they’re good then do some small refactorings in the main code base – after you can trust your tests can’t you :-)
• Ask them to pair with another developer

Just remember adding more people to a project is a way of slowing your project down.

Be Sociable, Share!

• 

In Science Daily Week: Which is more effective: bonuses or raises? Guy Kawasaki remarks on an interesting study:

According to this “Bonuses Boost Performance 10 Times More Than Merit Raises” in Science Daily which pointed to a Cornell study called “Using Your Pay System to Improve Employees’ Performance: How You Pay Makes a Difference” by Dr. Michael C. Sturman, a bonus yields far better results.

But both the study and Guy miss what is perhaps the most important point.

Read More…

Be Sociable, Share!

•