Finding the Right Cycle Time - 10 Rules

Name: Finding the Right Cycle Time - 10 Rules
Type: Rules
Status: final, revised
Version: 2008-08-08

Gist: to explain what influences cycle time in an agile development and how to find the right time for a given situation
Sources: Implementing Lean Software Development, Mary and Tom Poppendieck, Addison Wesley, 2007; own experience; a talk of Mishkin Berteig at Agile 2008

R1: Think about 1 day, 1 week, or 1 month for a start.
Notes:

• You don't have to predict a useful cycle time for a whole 1 year project in advance. Start with anything that seems to useful for the next, say, 25% of the project time, but start now.
• 1 day may seem rediculuos. It isn't. it is likely that people agree to do such an 'experiment'. you get things rolling, everybody is happy about the exercise and you can gather data from your team! Also see R9.
  

R2: Listen to what your team says. Ask why every time someone comes up with an argument against a specific cycle time. Account for the natural resistance to change. Do baby steps towards a change
Note: there's also a valid thought against baby steps. If you try to reduce cycle time from 3 months to 2 weeks, it's tempting to go for 4 weeks first. However, if you decide to *start* with 2 weeks, your will double the chances to learn anything useful.

R3: If your cycles get hectic near the end, you should reduce cycle ime to even out the workload.

R4: If your customers are trying to change things while a cycle is underway, if they cannot wait until the next cycle, then your cycle time is too long.

R5: If you cannot release software very often, think about doing smaller cycles (iterations) within larger cycles (increments, releases). However, make sure that you really can't release more often.
Note: In some organisations, it is painful to change processes so that certain acceptance tests would consume less time. or maybe you have a great many users of your product and you can't find an efficient way to train them new features. But be careful, these arguments may not be the real ones. Keep asking why.

R6: Resist the temptation to do parallel cycles unless you know exactly what you are doing. It's very hard to maintain a strong notion of 'done' if you do it. Do not assume you need it because otherwise the team would not be utilized properly.
Note: Full utilization will slow your team down. Full stop.

R7: Make sure everyone, especially your customer, understands this one "Time, quality, scope - choose any two." -- Greg Larman

R8: If your managers want reports quarterly, surprise them with a telling set of data concerning your progress, not only one cycle's experience or less. Prove to really being in control and to really getting things done.

R9: If you seem to have a rather gigantic amount of things do be done in your project, go for shorter cycle time. You will soon have a pretty good sense of your velocity, thus being able to predict what you will be able to achieve.
Note: However, you have to adjust your prediction after the first 2-4. A very effective way of gathering this amount of data is doing EXTREMELY short iterations (1-day) during the first, say, two weeks. This is EXTREMELY useful to get a waterfall team do short iterations. Most people are willing to do an experiment that is that short. See R1.

R10: If more than 1 or 2 features can't be completed within one cycle, break the features down.