Comments on: The effect of adding new people to project teams http://www.markhneedham.com/blog/2009/10/21/the-effect-of-adding-new-people-to-project-teams/ Thoughts on Software Development Sat, 31 Jul 2010 12:46:58 +0000 hourly 1 http://wordpress.org/?v=3.0 By: Mark Needham http://www.markhneedham.com/blog/2009/10/21/the-effect-of-adding-new-people-to-project-teams/comment-page-1/#comment-25126 Mark Needham Thu, 22 Oct 2009 15:08:22 +0000 http://www.markhneedham.com/blog/?p=1745#comment-25126 I don't know if there's a way to do it but it would be quite interesting to see whether there are times in a project when it makes sense to leave the team alone (maybe in the week of a release?) and when it makes sense to make changes (perhaps after having the same team for x amount of months). Speaking to some colleagues I've heard that a similar approach has been used on other projects and having a new person join has added a new lease of life into those projects as well. I don't know if there's a way to do it but it would be quite interesting to see whether there are times in a project when it makes sense to leave the team alone (maybe in the week of a release?) and when it makes sense to make changes (perhaps after having the same team for x amount of months).

Speaking to some colleagues I've heard that a similar approach has been used on other projects and having a new person join has added a new lease of life into those projects as well.

]]> By: Scott Duncan http://www.markhneedham.com/blog/2009/10/21/the-effect-of-adding-new-people-to-project-teams/comment-page-1/#comment-25125 Scott Duncan Thu, 22 Oct 2009 15:02:39 +0000 http://www.markhneedham.com/blog/?p=1745#comment-25125 Your roll off/on overlap example seems like it could work well. Though Brook's point about communication overhead to get new people up to speed probably still applied. It just wasn't in the context of a late effort trying to "make up" time. And the time you invested was well worth it as you would actually lose time otherwise if you had no way to replace people rolling off. Your roll off/on overlap example seems like it could work well. Though Brook's point about communication overhead to get new people up to speed probably still applied. It just wasn't in the context of a late effort trying to "make up" time. And the time you invested was well worth it as you would actually lose time otherwise if you had no way to replace people rolling off.

]]> By: Mark Needham http://www.markhneedham.com/blog/2009/10/21/the-effect-of-adding-new-people-to-project-teams/comment-page-1/#comment-25123 Mark Needham Thu, 22 Oct 2009 14:21:13 +0000 http://www.markhneedham.com/blog/?p=1745#comment-25123 @Rob - I guess it depends how you judge 'value' that different people on a team provide. Someone who knows the code really well, knows how the system works and so on is useful to have on a team but I think new people provide a different set of qualities that complement these really well. I haven't noticed that the new people added to the team I'm working on slowed us down. Actually they seemed to bring a new perspective on how to solve problems and had interesting suggestions on better ways to do things. I don't know if this would always be the case on every team but in this case that's what we've found. I appreciate maybe my wording wasn't great in some areas. @Scott - thanks for pointing that out! I often forget the context in which he made that statement. In our context we weren't adding people to make a project go faster, it was part of a team rotation process whereby new/current people overlap for a month or so before the old people roll off. I found this worked really well. @Rob – I guess it depends how you judge 'value' that different people on a team provide.

Someone who knows the code really well, knows how the system works and so on is useful to have on a team but I think new people provide a different set of qualities that complement these really well.

I haven't noticed that the new people added to the team I'm working on slowed us down. Actually they seemed to bring a new perspective on how to solve problems and had interesting suggestions on better ways to do things.

I don't know if this would always be the case on every team but in this case that's what we've found.

I appreciate maybe my wording wasn't great in some areas.

@Scott – thanks for pointing that out! I often forget the context in which he made that statement.

In our context we weren't adding people to make a project go faster, it was part of a team rotation process whereby new/current people overlap for a month or so before the old people roll off. I found this worked really well.

]]> By: Random Links #68 | YASDW - yet another software developer weblog http://www.markhneedham.com/blog/2009/10/21/the-effect-of-adding-new-people-to-project-teams/comment-page-1/#comment-25081 Random Links #68 | YASDW - yet another software developer weblog Wed, 21 Oct 2009 19:44:21 +0000 http://www.markhneedham.com/blog/?p=1745#comment-25081 [...] The effect of adding new people to project teams Hat schon Recht der Herr, aber wenn zu spät neues Personal hinzu kommt, bringt das nix. [...] [...] The effect of adding new people to project teams Hat schon Recht der Herr, aber wenn zu spät neues Personal hinzu kommt, bringt das nix. [...]

]]> By: Matt Dunn http://www.markhneedham.com/blog/2009/10/21/the-effect-of-adding-new-people-to-project-teams/comment-page-1/#comment-25070 Matt Dunn Wed, 21 Oct 2009 12:57:52 +0000 http://www.markhneedham.com/blog/?p=1745#comment-25070 @ Rob I'd contend that whether newcomers enthusiasm and ideas are levelled to that of the team is an indication of how accepting the existing team is to change. What is value in the context you refer to? New peoples alternate opinions are surely as valuable as others which isn't bound to a persons length of time on a project, and may well prevent the team from repeating past mistakes rather than slowing them down. Cheers, Matt @ Rob

I'd contend that whether newcomers enthusiasm and ideas are levelled to that of the team is an indication of how accepting the existing team is to change.

What is value in the context you refer to? New peoples alternate opinions are surely as valuable as others which isn't bound to a persons length of time on a project, and may well prevent the team from repeating past mistakes rather than slowing them down.

Cheers,
Matt

]]> By: Scott Duncan http://www.markhneedham.com/blog/2009/10/21/the-effect-of-adding-new-people-to-project-teams/comment-page-1/#comment-25069 Scott Duncan Wed, 21 Oct 2009 12:00:18 +0000 http://www.markhneedham.com/blog/?p=1745#comment-25069 It is important to recognize that Brooks was talking about adding people to a late project as a way to, presumably, get the code done faster since the remaining volume would be divided between more people. The communication overhead generated by adding people (presumably) not familiar with the system, and doing so late in the game, was a crucial part of the "adding people" issue Brooks described. Adding people much earlier and in smaller teams (and, perhaps, with some understanding of the domain) is not going to be anywhere as problematic as what Brooks was describing. It is also important to recognize that the adding of people was based on the supposition that a volume of code could be divided by a volume of people evenly. So, to get code done sooner, you'd just have to add more people. We know it does not work that way in reality, but reducing things to sheer numbers can get you to making this assumption. Tom DeMarco's book "Slack" has a number of nice points to make about how to allocate people and avoid treating them (and their time) as some fungible resource. It is important to recognize that Brooks was talking about adding people to a late project as a way to, presumably, get the code done faster since the remaining volume would be divided between more people. The communication overhead generated by adding people (presumably) not familiar with the system, and doing so late in the game, was a crucial part of the "adding people" issue Brooks described.

Adding people much earlier and in smaller teams (and, perhaps, with some understanding of the domain) is not going to be anywhere as problematic as what Brooks was describing.

It is also important to recognize that the adding of people was based on the supposition that a volume of code could be divided by a volume of people evenly. So, to get code done sooner, you'd just have to add more people. We know it does not work that way in reality, but reducing things to sheer numbers can get you to making this assumption.

Tom DeMarco's book "Slack" has a number of nice points to make about how to allocate people and avoid treating them (and their time) as some fungible resource.

]]> By: Rob Bowley http://www.markhneedham.com/blog/2009/10/21/the-effect-of-adding-new-people-to-project-teams/comment-page-1/#comment-25058 Rob Bowley Wed, 21 Oct 2009 08:56:20 +0000 http://www.markhneedham.com/blog/?p=1745#comment-25058 The impact you are referring to is only short lived as their enthusiasm will quickly be dragged down (or up) to the level of the rest of the team and any opinions on the quality of the code will only be relevant whilst they are not familiar with the context. These are valid observations but I thing your wording suggests you feel new people in general will immidiately add as much value as existing team members which I think is misleading. In the vast majority of cases it will only go to slow the team down. The impact you are referring to is only short lived as their enthusiasm will quickly be dragged down (or up) to the level of the rest of the team and any opinions on the quality of the code will only be relevant whilst they are not familiar with the context.

These are valid observations but I thing your wording suggests you feel new people in general will immidiately add as much value as existing team members which I think is misleading. In the vast majority of cases it will only go to slow the team down.

]]>