One idea behind Scrum (which is a lightweight agile method) is to have a period of time between 2 and 4 weeks during which there can be no changes to what’s planned to be done by the team during that period. This way the developers know what they should do and one can avoid costly context switching.
However, this doesn’t really work if you have products deployed in a production environment and there are problems with them that require immediate attention. At work this ruined quite a few sprints (a sprint is the name for a planned 2 to 4 weeks period). But as Joel argues, you can’t ignore these problems they have to be fixed.
What we did to solve this, was to introduce a maintenance team that handles the things that require actions right now, and by doing this they act as a shield for the developers working in the sprint. If a problem has a short-term solution but long-term should be fixed in a way that require bigger changes, such an item will be put on the backlog for the development team and it will be considered when planning for the next sprint.
This has worked out great for us! Less context switching for the developers working with the sprint means we get more done and everyone’s happy. Except for the poor souls doing the maintenance work but we’ve solved that by a rotation schema.