A key concept behind agile practices is that once an iteration starts, you try not to change its scope. After all, it is only a short time until the next iteration. Why can't the interruption wait? By adhering to this approach, it allows the agile team to focus and not get killed with interrupts.
How does this approach work with third level support (which by definition works on an interrupt basis). You usually can't wait until the next iteration to start working the customer issue. To do so would typically violate your SLA's.
One approach to this problem is to allocate a certain amount of time each week to support and reduce the team's velocity accordingly. Essentially, you create a budget for third level support activities. This helps keep the iteration stable. It also helps to ensure that one side of the equation doesn't get shorted (either new development or support).
Taking this approach, you can change the budget on an iteration by iteration basis. I.e., if the allocation isn't enough, you can increase it next time or vice versa. You can also alter the budget to try to increase customer satisfaction or to increase the focus in getting a particularly important release completed.
You still might have to move people within an iteration, but this should be the exception, not the rule.
Taking this even further... You could create a third level support sub-team. That way, the folks are entirely focused on customer issues or new features. They don't have to balance the two. This can work on a rotational basis. A developer might be on support for 3 months and then off again for a year (assuming a 20% allocation to support).
There are a few variations to this. Some of the team members might be permanent (this gives stability to the team). If you're doing this with multiple teams, you might combine them into one virtual support team dotted lining into a third level support manager while they're on the rotation (or solid lining if they're permanent). This can help to cross-train team members on the other teams' areas.
One key thing with this approach is that someone on third level support always owns the issue. They might need to work with someone who is currently doing new features (and happens to be the expert on the problem). But, the third level support member always owns it (to try to minimize impact on the iteration).
I'd recommend a rotation or blend (fixed plus rotation) rather than a fixed third level support team because it ensures that the developers doing the new features get exposed to customers directly. It also keeps the third level support team fresh (as it always has people who were recently working on the new stuff). If you go with a rotation, you'll want to make sure it is staggered to ensure that there's not too much instability at once.
Support loads can be much smaller with new projects and much more significant with older ones (that have had time to develop substantial user bases). Or you could be in a situation that the heavy support load is during new deployments (which may be sporadic). The approach you take needs to fit the needs of your team.
Iteration versus Release
I don't think it matters how short you make your intervals. (I'm personally a fan of one week iterations.) It's the nature of product development that you run into unexpected obstacles and make project-changing discoveries at any time. Heck, tasks that I think will take ten minutes sometimes take two days. It's downright silly to stick to the iteration scope in the face of such inevitable eventualities.
The need for adjustments within an iteration doesn't entail chaos. You are still anchored to delivering some sort of customer value and addressing technical risks.
Take, for example a Purchase Items use case. In the first iteration, the team tackles a version of this use case in which a user purchases items with a debit card. The next iteration might tackle a version of the case in which a user purchases items with a credit card.
What if, just as the first iteration is getting underway, the third party that is providing the debit card transaction engine suddenly announces that the engine will be down for the rest of the iteration? Do you plow ahead without any re-adjustment to the iteration deliverable?
If you have any sense at all, you would probably consider adjusting the deliverables in one of the following ways:
Changing your iteration
I don't have an issue with changing the iteration scope for exceptional situations. This should be the exception rather than the rule though.
When you go through iteration planning, you're doing many things. You're taking into account skill sets, availability, and how things inter-relate. You're talking things through as a team. You're setting expectations. Changing the scope affects all of these. That's what I mean when I say it introduces chaos. I don't mean that everything breaks down. I mean that it introduces some instability (maybe a little, maybe a lot).
That's why I would recommend defaulting to not changing the scope in the iteration. If the situation changes, you need to make a judgement call. You need to balance adding chaos to the iteration by changing scope with the benefit of the change you're considering.
Rule Rather than the Exception
Technical and requirements discoveries typically occur numerous times within even short iterations, and these discoveries render the scope either moot or impossible to deliver within the time-box. Scope-changing discoveries are the norm, not the exception.
In short, the true spirit of agile isn't just to embrace change between iterations, but to embrace it within iterations.
Iteration Milestones
I've never bought into this notion that it is so important to maintain the scope of the current iteration. You can't fix both the scope and duration of an iteration unless you are extremely lucky.
To me, the true spirit behind agile points to the exact opposite approach: fix the duration of the iteration while ruthlessly and creatively adjusting scope to ensure that the iteration still delivers some sort demonstrable customer value.
Iteration scope
It is nearly impossible (if not impossible) to fix scope, staffing, and duration of a release. It is just too complex and too difficult to estimate / predict. One of those has to be flexible. With agile, we generally make the scope the flexible part. Prioritize so that the most important things make it, but don't commit to scope.
Iterations, however, are much smaller (say two weeks). It is much easier to estimate / predict tasks of that size. But even then, it isn't important that you estimate exactly right. You could argue that accepting 100% of your stories every iteration is actually a bad sign as it means that you are likely taking on too little / not taking enough risk.
Why fix the scope at all? To avoid complete chaos. You don't want to come in every day and change direction. It is hard to be productive that way. Instead, commit to scope for an iteration. It is a small enough chunk that even if you're totally wrong (unlikely), you haven't given up much. More likely you've made some progress and learned a lot that will influence the setting of the scope for the following iteration.
Fortunately we can look to
Fortunately we can look to experience on this issue. I would say having the need to change deliverables during an iteration/sprint is rare. Sticking to what you commit to is the norm. I would rather stay on course and miss a story and then look back on why it happened. In the case of a cc processor being down, I would say we should have started with working with a test api. Then when converting to the real api for testing, if down, work on test cases or help with the testing of other story cards. Giving people the ability to change scope during an iteration, lessons the importance of the commitment they are making. I would want them to fight for the 100% without relief if outside problems occur. I want them thinking about outside dependency and this will force that behavior. I understand that 100% is not ideal. But 90%+ is. That 10% slack is the scrum masters/project managers understanding that issues can come up. So during iteration/sprint planning, if a contributor creates two big (velocity) story cards, they will think to break them up. That’s the way to a better functioning Agile team.
Different Experience
My experience has been very different. I see significant discoveries and obstacles popping up constantly within an iteration. Something has to give. You can't simultaneously hold the iteration time-box and scope inviolate. The temptation is almost always to extend the time-box, but that reaction usually has much worse ramifications than working as a team to adjust the scope and still meet the time-box.
More thoughts
This has been a good dialog. It has made me re-evaluate some aspects of the iteration that I took for granted.
When I hear changing iteration scope within the iteration, I think of a product owner who can't commit for even a small period of time (an iteration). Changing priorities frequently within an iteration can hurt the team's productivity as they're constantly re-evaluating what they're trying to accomplish. In these cases, it is generally better to push the new stories to the next iteration (in other words, I'd agree with Chris in that in my experience, it is rarely necessary to add mid-iteration). But, you need to do what makes sense for the particular situation.
As we've gone back and forth in this discussion, it sounds like Roger is focusing more on the scenario where a team runs into an unexpected issue during the iteration. In other words, it didn't work out as planned and you need to adjust. For example, a story is taking much longer (or shorter) than expected. Some times these will cancel each other out. Or worst case, you won't complete some of the stories and the remaining work gets captured as new stories in the next iteration (or later if you decide it is less important). My general guidance would be to always finish the iteration on time and split stories as necessary.
In other cases, you might determine that a story (or on a smaller scale an acceptance criteria) is much bigger than expected or less valuable than expected and might not be worth it. Or maybe that something is not ready (i.e., it will be much easier if you wait). In these cases, you need to do what makes sense. Don't do it just because you said you'd do it. Do it because that is what makes sense.
Obviously, if you finish an iteration's stories early, you don't just hang out, you see what else you can take on. Do what makes sense.