Iteration Length

[James Trott]

One of the programs that I am working with came to me with the following challenge:

The Technology managers are convinced that if they can shift from the current pattern of 2 week iterations to 3 week iterations that they will gain 2 more weeks of productive work over the next Planning Increment.

BTW: when they came to me was 1 day before then end of the first iteration of the current planning interval (6 iterations)

The challenge was: What is your guidance on the pros and cons of moving from the current 2 week iteration to a 3 week iteration cadence. Below is what I gave them – based on a couple of hours thought. Hindsight is 20/20 – but I want to get better in my response for next time. So any suggestions, tips or thoughts are appreciated.

Thanks

My Response:
Executive Summary:
Team Heads Down time: Small gain of approximately 4 hours per team across all of PI 6
Agility – ability to adapt:
• The shift from 2 weeks to 3 weeks sends a strong signals to the teams that miniature waterfalls is OK.
• The flexibility and adaptability is much less when doing 3 weeks iterations versus 2 weeks iterations.
Productivity: A management driven change in the cadence and pattern will combine with other management changes to substantially decrease team productivity.
Predictability – ability to deliver on the plan: Will be substantially worse – The above impact to productivity will impact the predictability and the just completed PI 6 planning will be largely erased.
Quality: A likely shift more towards miniature waterfalls will lead to more last-minute testing and more delayed quality impacts.

Perceived Benefits:
Perceived Benefit #1: Less Time in Planning and grooming once every 3 weeks
My Experience
• Effort to plan is the same – typically a larger chunk less frequently.
• When less time is spent in planning, then there is less consistency and predictability
Perceived Benefit #2: Less Time in other Sprint Meetings (Demo, Review, Retrospective)
• These meetings will happen less often and will get a net gain of a few hours per team
• The cost is that the team will be doing 2/3 the number of inspect and adapt sessions – on the product and the process
Perceived Benefit #3: Longer heads down cycle time
• Likely to make the Dev / Test divide worse – there is typically more temptation to continue developing and have a large chunk to test at the end of the iteration
• To the extent that the team is working in small stories, there is no difference.
• Working in small deliverable stories is the goal, not mini waterfalls

Reverse Thinking
If I was advising an organization that was currently using 3 week iterations and considering moving to 2 week iterations, I would advise them of the Pros and Cons as follows:
1. Planning:
a. Planning effort – In the near term, there may be a small increase in planning effort – but in a few sprints, the planning effort should be the same as for a 3 week sprint.
b. Planning quality – since the planning efforts are focused on a 2 week horizon, planning tends to be very accurate and precise
2. Sprint Demos, Review and Retrospectives:
a. Time in Sprint Demos, Reviews and Retrospectives – the teams will likely spend more time in these meetings since they happen more often. The meetings will not be substantially shorter but there are 50% more of these meetings.
b. Agility of the organization – By having the different inspect and adapt meetings more often the organization adapts and learns faster. The Product Owners can inspect and adapt the product faster, the team learns faster and the organization learns faster.
3. Development Cycle Time:
a. Learning to work faster – If the organization needs to learn how to develop in smaller pieces with fewer handoffs, a shorter iteration cycle helps to force the team to learn how to work together to get the work done quickly.

Long Term Impacts
Cost Likely Impact Experience
Planning
Likely Impact: The iteration planning will likely spend about the same amount of time and be less effective. OR teams will spend less time in the planning meeting and have a much less reliable plan.
Our Experience: We typically see that as teams short-cut the iteration planning time, that even more time is needed during the iteration to compensate for the ineffective planning.

Predictability
Likely Impact: If the teams are struggling to deliver on time with a 2 week iteration – They may be able to deliver more predictably using a 3 week iteration
Our Experience: Typically teams that are struggling with a 2 week iteration will also struggle with a 3 week iteration. Usually the issues that prevent them from delivering completely in the cadence are not

Agility
Likely Impact: Longer iterations are more likely to become miniature waterfalls.
Our Experience: Moving in the direction of a longer iteration sends a strong signal to the teams that working in silos, large batches, waterfalls is OK.

Defect Carry-Over
Likely Impact: No Impact
Our Experience: The number of defects that are carried over could decrease – if the testers have more time to test and the developers focus on fixing those defects. Our experience is that teams rarely make this shift and the current pattern of carried over defects continues.

Work Batch Size
Likely Impact:
• Stories will tend to get larger
• Teams will commit more in each sprint
• Fewer integration points (Team demos force the team to integrate)
Our Experience: In theory the size of stories is independent of the iteration length, but in practice the longer iteration length leads to larger batches.

Quality
Likely Impact: Small decrease in quality
Our Experience: The tendency towards miniature waterfalls and larger batches will lead to more “last-minute” and late testing which will decrease quality.

Dependencies
Likely Impact: Longer waits when there are inter-team dependencies
Our Experience: The inter-team dependencies tends to cause work to stretch out – and take the same number of iterations, but each iteration is longer.

Costs in the Change
PI Planning – Established PI plan will need to be re-done – The teams’ sprint planning efforts will not be leveraging the PI 6 plans as a baseline. The teams will likely need more effort to plan for each of the next 2 iterations.
Team Performance – Every time a team changes its process or cadence there is an impact to performance. The magnitude of that impact is multiplied when the team is not driving that change and the change is imposed on the team. Our experience is that the teams will lose 10% – 20% of their productivity over the next few sprints.

• This topic was modified 6 years, 8 months ago by James Trott.

[Al Shalloway]

This has a lot of good information.

I would add the key issue is quicker feedback (and although it was implied I didn’t see it). I would add:

2 weeks is better than 3 because it provides for:
•Quicker feedback on what is being built
•Quicker feedback on if people are truly in synch (saving time at integration)
•Quicker feedback on how dependencies are being managed – providing more time to correct

This quicker feedback will actually reduce more waste than any extra energy it takes ot implement.

In addition, the negative impact of more frequent planning should be offset the planning cycles being shorter. The only true negative thing is that items will _have_ to be smaller to fit in to 2 week cycles. However, this is a good thing – as stories need to be small. We appreciate that most people have troubles creating small stories – but instead of backing off of that we should provide some assistance in writing smaller stories. People object to do what’s right because they have a fear that is grounded and don’t see the advantages.

BTW – your comment about faster
1.Development Cycle Time:
a.Learning to work faster – If the organization needs to learn how to develop in smaller pieces with fewer handoffs, a shorter iteration cycle helps to force the team to learn how to work together to get the work done quickly.
May be misinterpreted. You mean quicker and shorter feedback. Telling people to work faster is not accurate and can be interpreted as saying they are not working as fast as they should. They may also feel ‘faster’ means more harried when they are already harried.

[Al Shalloway]

I agree with everything said above and I want to second the smaller work-items note. It’s something that seems to get overlooked a lot even though it’s really valuable.

Quicker feedback is, of course, of paramount importance but the smaller work-items are valuable in and of themselves. That is, even if you didn’t have a shorter sprint but your work items were small enough that you could, you’d still get some benefit.

Smaller work items, necessarily, have fewer moving parts and are therefore easier to implement and validate. Shorter iterations (as Al said) force you to make smaller work items.

[Author]

Posts