How do Agile teams handle changes to requirements?

Embracing change doesn't mean changing willy-nilly in the middle of developing a user story. We work in small increments, and deliver frequently in short iterations. If our customer sees some early deliverables and decides to make changes, we can do that in the next iteration, maybe only one or two weeks away.

Here's a recent example from my team. Our application automates all aspects of managing 401(k) plans. Our product...

owner asked for a new report to show a detailed history of employee deferral election requests for all employees within a given plan, and the date each request was approved. As we started on the story and did some research, we realized that an employee's deferral election could also be changed by someone other than the employee, such as the plan sponsor or a third-party administrator. Our system did not log details about those changes, and it was a lot of work to add that functionality. We delivered the report as per the original requirements, but in the next sprint, we did all the work to capture the missing information in the database and provide it on the report.

When I worked for a company with 25 Scrum teams, the daily Scrum of Scrums and the automated continuous build kept teams communicating. If one team "broke the build," they knew about it immediately and addressed it right away. Production releases occurred quarterly, with time built in at the end of each release cycle to resolve any integration issues.