I want to make sure I understand the question correctly. Are you asking how agile teams handle things when they hit a technical roadblock, because it will take time to work around the roadblock, and that will throw off all of their agile planning? If that's the question, then what I've seen many times on many different agile teams is that they handle this situation much better than traditional software development teams.
What would traditional team that does most of their requirements gathering and planning up front do in this situation? The team are working on a spec and following a project plan, which were both approved by managers, and they discover a technical roadblock. Now they need to go through some sort of change control process. This could mean a simple change to the plan, but it might require a major spec rewrite. All of that will delay the project, and cause plenty of emails, meetings, and trouble.
The reason that this is a problem for a traditional team is because when they approve specs and plans, they assume those specs and plans are mostly correct, and that changes can be handled individually. When unexpected technical problems happen, if the plan highly detailed that can severely derail the project.
Agile teams, when they're effective, don't assume that they have near-perfect knowledge at the beginning of the project. Instead, they put off most project decisions -- especially planning and requirements decisions -- as late as possible in the project. They expect that they'll hit technical roadblocks, so they use iterations to deliver the software in small increments, and use what they learn in each increment to go back and constantly adjust their plans. And all the while, they constantly collaborate with their users, stakeholders, and managers, so that everyone can keep their expectations in line with the project team.
The big difference between these two teams is that the traditional team has committed to delivering a specific piece of software, as defined in the spec, and they've committed to build it in a very specific way, as defined in the plan. The agile team, on the other hand, hasn't made those commitments. They've made a commitment that's much more valuable to their company: to deliver the most valuable software that they can, as quickly as possible (without being unrealistic), and to collaborate with their users, stakeholders, and managers to really understand what "valuable" means to them and the company.
This is one of the big reasons that agile teams handle technical roadblocks better than traditional teams. There are other reasons as well -- especially XP teams, who use test-driven development, refactoring, and incremental design to build software that can be changed easily, which allows them to have an attitude where they welcome and embrace change, and which helps them discover technical roadblocks earlier in the project. Jenny and I have a lot of discussion of this throughout
Learning Agile.