The Agile Manifesto Principles: Welcome Changing Requirements

Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage.

In traditional development methodologies, like waterfall, a customer might try to specify how a system should look and behave completely upfront before they even start development. The problem with this is it assumes that it is possible to completely understand the customer’s needs before development begins. We know this isn’t true.

Agile helps us turn this old notion on its head. With agile, as the customer sees the features we’re developing, they’re going to change their mind about what is important, how the system should look, and how the system should behave. That’s why agile is structured in a way where change can always be introduced even very late in the development cycle.

During one of my consulting engagements, we ran into an issue where our client wasn’t ready to accept changes from the customer late in development. The client was mired in the waterfall methodology. They were working within a one-month development cycle in which they went all the way from feature definition to delivery. As the cycles neared completion, the customer would often ask for changes to a feature, and our client kept asking how the customer could change their mind so late in the cycle.

We knew we needed to shift our mindset. Rather than asking, “how could the customer change their mind?”, we should have expected the customer to change their mind, because they had seen more and now understood the system better.

In order to shift their mindset, we suggested that our client start thinking about refining their development processes to better accommodate change requests, especially late in cycles. Some of the first steps in moving towards more adaptability were building software more efficiently and automating some tests so we could test in tighter cycles.

We also wanted the development team to adopt a mindset where the team was responsible for delivering the feature. One way we accomplished that was having members of the development team put themselves in the customer’s shoes. The customer wants a system, but when the project starts, they probably don’t have a full picture of what the system is supposed to look like, even though they might think they do. Once the customer sees a working feature, they can adapt and decide if that’s really what they’re looking for.

When we understand that customers aren’t all-knowing, and will likely ask for changes throughout the project, development teams can be vigilant, ready to welcome changing requirements, even late in development.

I’d love to continue the conversation with you in the #agile channel on the TechWell Hub.