· agile

Increasing team sizes: Boredom

Although the majority of the teams that I’ve worked on over the past few years have been relatively small in size I have worked on a few where the team size has been pretty big and perhaps inevitably the productivity has felt much lower.

I think this is somewhat inevitable since although the overall throughput of these teams may be higher than on smaller teams, due to problems such as having difficulty parallelising work, not every pair is working at maximum productivity.

This tends to mean that you’ll end up with some pairs who have development work to do for only part of the iteration and will then be unable to pick up a new story because there are dependencies on other stories which are currently in progress.

As a result the people in this position will get extremely bored and eventually they’ll start to distract the other people on the team which means that their productivity goes down as well.

Another side effect of knowing that there isn’t anything else for you to pick up is that you subconsciously won’t finish the story you’re working on as quickly as you otherwise might be able to.

One suggestion I’ve heard is that people should pick up technical debt when they find themselves in this situation but from what I’ve noticed unless you were the one who noticed the technical debt there is both context and motivation lacking.

Another possibility in this type of situation is for the developers to try and help out elsewhere perhaps by doing some technical analysis on upcoming stories or helping out testers with their work.

The former seems to work reasonably well but the problem when doing this offshore is that you can often only get up to a certain point at which you need some help from guys onshore.

As a result technical analysis often isn’t enough to keep a pair occupied for that long.

I’ve previously seen the latter work reasonably well whereby a tester would help the developer to work out which unhappy path scenarios needed to be automated and the developer could then write the automation code.

I haven’t seen that work particularly well on my current team and I think the reason is probably down to the fact that we keep separate sets of 'dev' and 'QA' functional tests.

I can’t currently think of a good solution to this problem other than matching the amount of work and the number of pairs more carefully so that everyone is occupied for the majority of the time.

  • LinkedIn
  • Tumblr
  • Reddit
  • Google+
  • Pinterest
  • Pocket