Our response

Our team would respond as a group. We'd welcome the change. We'd be grateful that our customer has highlighted this problem to us and that they found it before we released. We would know that incorporating a change won't be a big issue for us; our code, testing and deployment/release strategies are all designed to accommodate this kind of request.

We would work together (our customer is part of the team) to discover more about the missing requirement. We'd use our toolkit to elaborate the feature with our customer, writing out the User Stories (an Agile requirement gathering tool we'll discuss in Chapter 4, Gathering Agile User Requirements) and if necessary prototyping the user experience and writing scenarios for each of the Acceptance Criteria. 

We'd then work to carry out the changes in our usual disciplined way, likely using TDD to design and unit/integration test our software as well as Behavior-Driven Development (BDD) to automate the acceptance testing.

To begin with, we may carry the work out as a Mob (see Chapter 12, Baking Quality into Our Software Delivery) or in pairs. We would definitely come together at the end to ensure we have collective ownership of the problem and the solution.

Once comfortable with the changes made, we'd prepare and release the new software and deploy it with the touch of a button. We might even have a fully automated deployment that deploys as soon as the code is committed to the main branch.  

Finally, we'd run a retrospective to perform some root cause analysis using the 5-whys, or a similar technique, to try to discover why we missed the problem in the first place. The retrospective would result in actions that we would take, with the aim of preventing a similar problem occurring again.