Home » Agile » Increasing team sizes: Boredom

About Mark Needham

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.

Reference: Increasing team sizes: Boredom from our NCG partner Mark Needham at the Mark Needham Blog blog.

[ratings] Start the discussion Views Tweet it!
Do you want to know how to develop your skillset to become a sysadmin Rockstar?
Subscribe to our newsletter to start Rocking right now!
To get you started we give you our best selling eBooks for FREE!
1. Introduction to NGINX
2. Apache HTTP Server Cookbook
3. VirtualBox Essentials
4. Nagios Monitoring Cookbook
5. Linux BASH Programming Cookbook
6. Postgresql Database Tutorial
and many more ....
I agree to the Terms and Privacy Policy
Notify of

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Inline Feedbacks
View all comments