Team size and project iteration length.

Question

Do you think that project iteration length is related to project team size? If so, how? What other key factors do you use to recognize correct iteration length for different projects?

Answer 1

Iteration length is primarily related to the teams ability to communicate and complete a working version of the software. More team members equals more communication channels (Brooks's Law) which will likely increase your iteration time.

I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.

Ultimately, the iteration length will depend on the features you wish to implement in the next iteration, and in the early phases your iterations may jump around from 1 week to 1 month as you become comfortable with the team and the technology stack.

Answer 2

One of the main drivers for short iterations, is easing integration between modules/features/programmers. Obviously, the bigger your team, the more integration you will have. It's a tradeoff: short iterations mean you're integrating often, which is good - BUT if its a big team you'll be spending a LOT of team on integration overhead, even without new code. Longer iterations obviously mean more integration each time less seldom, and a lot more risky.

If your team is very large, you can try branched integration, i.e. integrating small subteams often, and integrating between the teams less often... BUT then you'll be having inconsistencies between branches, and you lose much of that benefit right there.

Another key factor to consider is complexity - obviously complex, backend systems are riskier integration, simple Web-UI pages are less risky.

(I realize I didnt give you a clear cut answer, there is none. It's always tradeoffs, I hope I give you some food for thought.)

Answer 3

My experience is that the length of the iterations are somewhat dependent on team size,

External dependencies, like in cases where we had to integrate with in house systems that was not using a iteration based development cycle (read waterfall) where another factor we observed.

Our team were real noobs when it came to iterative development, so in the beginning the iterations where really long (12 weeks). But later on we saw that there was no need to worry, and the iterations shrunk considerably (4-6 weeks).

So another factor in how long the iterations are is how familiar you are with the concept of iterative development.

Answer 4

I think that 2 week iterations, whether you deliver to the client or not, are a good goal, as it allows for very good health checks.

2-week iterations are most comfortable for me and the kinds of projects I usually do, but I disagree that not delivering is a good outcome - the focus needs to stay on the "working software over process" side of things.

I would consider making iterations longer if the product owner / user isn't available, even if only for a showcase every couple weeks, as the same health checks that fast iterations allow on the technical side need to happen on the side of the engagement with the business.

Answer 5

Iteration length should be decided on many factors... and team size is really only part of the considerations made for the "Overhead of Iterating".

This article explains many of them.

The important ones IMO:

1. Overall Release Length
2. How Long Priorities Can Remain Unchanged
3. The Overhead of Iterating

Answer 6

There is relation in terms of how much work can get done but there are a couple of other key factors here like what type of project are they working on, e.g. Windows Application, Console Application, or Web Application as well as how developed is the codebase in terms of size, complexity and stye compared to the current team's style, and what expertise does the team have both within the methodology and the work that they are doing as inexperience may be costly in terms of getting everyone proficient with the process.