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.
Mark Levison has been helping Scrum teams and organizations with Agile, Scrum and Kanban style approaches since 2001. From certified scrum master training to custom Agile courses, he has helped well over 8,000 individuals, earning him respect and top rated reviews as one of the pioneers within the industry, as well as a raft of certifications from the ScrumAlliance. Mark has been a speaker at various Agile Conferences for more than 20 years, and is a published Scrum author with eBooks as well as articles on InfoQ.com, ScrumAlliance.org an AgileAlliance.org.
You coudl combine the unit testing and the pairing.
Either:
– ping pong pairing
-have the new people only pairing with echother to write tests.
(I don’t like this as it creates a dual society, but hey will learn quickly learn the project and not distribe the other people)
-normal pairing + making sure the tests are written.
Yves – elegant I hadn’t remembered to combine the Unit Testing and pairing. You’re also write that some of these solutions create a dual society, which is unfortunate. However in the short term I might have to make a tactical decision about slowing down the product development or making the newcomers feel less than full members of the team. Its not a choice I like, but I want people to be aware its a choice they might have to make. Frequently the real solution is to say ‘no’: this is a high stakes project that has to ship in a few months don’t hire any new people for me.
Mark,
In Measures For Excellence: Reliable Software On Time, Within Budget, by Lawrence H. Putnam, Ware Meyers, https://www.chapters.indigo.ca/books/Measures-Excellence-Reliable-Software-Time-Lawrence-H-Putnam-Ware-Meyers/9780135676943-item.html, they show that Brook’s law is not in fact correct.
My experience has been that the slowdown cost can be as short as 3 days. Other factors involved are the skill of the people coming in and their familiarity with the problem domain and the quality of the product implementation and its environment.
Norbert I’ve not seen the reference, perhaps you can share it with me tomorrow. You’re right under the best circumstances the slowdown can be short (although I’ve never seen it as little as 3 days). However the circumstances I normally encounter are clients with a complex problem domain, one or more new technologies and who’re new to agile. In these cases new people are highly disruptive in my experience.
As far as I know, a properly-practised Agile model invalidates, or comes close to invalidating Brooks’ Law. Pairing is top-most; have the newcomers only work in pairs. Executable documentation is another parameter. Effective self-organization is yet another. Of course, if you throw in the mix variables that challenge the existing team members — like a move to Agile or management pressure — they will have their own effects.
I coached a team a few years ago that had a new developer join six weeks before the 1.0 ship date. They were practising rigourous pairing and that new member was reasonably effective (in pair settings) within a week. He integrated almost seamlessly. I don’t think they took any productivity hit. I’d argue that in such situations, if the new person provides a continuous dose of Beginner’s Mind, that’s a Very Good Thing.
Gil
Gil – its interesting I’ve not had your experience, I still find adding people to a project especially at rate of > 1mth, new to the company, new to the technologies and new to complex problem domain – is a real slowdown.
Perhaps in the right environment that wouldn’t be such a problem. How do I find such an environment?
Your right, I should have added familiarity with the development process as a factor in the cost of adding people. Upon reflection, I would add whether the person has fixed or growth mindset, see Mindset, The New Psychology of Success by Carol S. Dweck, https://tinyurl.com/26r2ljn, who is a professor of Psychology at Standford. The latter type of people will adapt faster then the former.