Mark is a graph advocate and field engineer for Neo Technology, the company behind the Neo4j graph database. As a field engineer, Mark helps customers embrace graph data and Neo4j building sophisticated solutions to challenging data problems. When he's not with customers Mark is a developer on Neo4j and writes his experiences of being a graphista on a popular blog at http://markhneedham.com/blog. He tweets at @markhneedham. Mark is a DZone MVB and is not an employee of DZone and has posted 492 posts at DZone. You can read more from them at their website. View Full User Profile

Increasing team sizes: Parallelising work

11.26.2010
| 3916 views |
  • submit to reddit

One of the trickiest things to do when working in bigger teams is ensuring that it is possible to parallelise the work we have across the number of pairs that we have available.

From my experience this problem happens much less frequently in smaller teams. Perhaps inevitably it's much easier to find 2 or 3 things that can be worked on in parallel than it is to find 6 or 7 or more.

As a result we can sometimes end up with the situation where 2 stories are played in parallel with a slight dependency between them.

It may be possible to start those two stories at the same time but one may rely on an implementation of the other in order for it to be considered complete.

It's not an ideal situation but it still seems doable if we ensure that the two pairs work closely together both metaphorically and in terms of their physical proximity.

I think a more useful strategy is to look at how many things can be worked on in parallel and then deciding the team size rather than choosing the team size and then trying to find a way to make the way the stories are written/played fit around this decision.

This is rarely what happens since budgets/need to get to market quickly often take precedence so we end up working in a sub optimal way.

While this is a trade off that the business may be happy to make I still think it's useful to identify the risk we're assuming by taking this approach as well as recognising that the amount of work we can flow through the system is limited by how much we can process in parallel.

 

From http://www.markhneedham.com/blog/2010/11/26/increasing-team-sizes-parallelising-work/

Published at DZone with permission of Mark Needham, author and DZone MVB.

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)

Comments

Loren Kratzke replied on Sun, 2010/11/28 - 6:42pm

I fully agree with your final axiom and will add that to my mental list. I raise an eyebrow at your seemingly default choice of pair programming though. Your axiom should apply to pair programming as well. It's good for when circumstances are right like for troubleshooting or consultation, bad as a general practice, and at worst very wasteful. Personally I learn best when I am the one doing the thinking and the typing. This combined with your axiom makes pair programming a non-starter for me.

 I prefer heated discussions in a locked room with 4 or more developers and a white board or short consultations-over-the-shoulder over pair programming. I would even prefer virtual pair programming sharing a screen across the net over sharing a mouse, keyboard, and monitor, and coffee warmer, etc. It's my space. I like my space. Perhaps it's just me.

Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.