Welcoming Changing Requirements
Removing the curtain between the customer and the developer
19 May 2017
Anyone who has spent time in the traditional software development life cycle can attest that the Agile principle of welcoming changing requirements can be one of the most difficult for transitioning organizations to undertake. In traditional lifecycles, changing requirements are met with frustration, anger, despair, and, in some cases, lawyers and fees. The Agile movement asks that customers and development organizations work together and embrace change for the benefit of the end user. This level of transparency requires that the curtain come down between the customer and development. It also requires the customer to acknowledge the impact the change will have on the project and the additional cost of the change to the project budget, as well as to have a greater level of understanding about the work.
Customer and developers reach an understanding
In a bad Agile implementation, the customer thinks they can change requirements as often as they like, and the development staff has to deal with the changes. "Hey, you said you were Agile, right?" In a good implementation, the customer and the development staff work closely together to inspect and adapt the product at every possible opportunity. As the product is inspected, the customer and team maintain a shared understanding of the current state of the product and the current state of the market. When the customer changes requirements, the change and the ensuing cost of implementation, and impact to the project as a whole, are mutually understood.
Jeff Sutherland uses the phrase "Money for nothing and your change for free" when he advises organizations about how to write Agile contracts. In essence, this allows for both sides to have maximum flexibility; the development team allows for changing requirements without modifying the contract or charging change fees, and, in exchange, the customer agrees to fully participate in the Agile process and full software development life cycle. In the event the customer is satisfied by less work than originally planned, they can end the contract early, with the payment of a predetermined portion of the remaining contract.
Change is good
The undertone in this is that change is good. It allows the customer to satisfy the end user with the highest-value features and end the contract early. It allows the development entity to receive compensation for delivering early and enables them to move to the next opportunity.
"Welcome changing requirements, even late in development" does not mean that the product owner is free to adjust acceptance criteria after the sprint has begun. The Agile processes that harness change for competitive advantage should be implemented before sprint execution. Admittedly, there is a process for ending a sprint early; however, this is rare. Agile processes that facilitate progressive elaboration, decomposition, backlog refinement, increment, and sprint planning do harness change while protecting the team.
Opinions represent those of the author and not of Scrum Alliance. The sharing of member-contributed content on this site does not imply endorsement of specific Scrum methods or practices beyond those taught by Scrum Alliance Certified Trainers and Coaches.
Current rating: 4.4 (5 ratings)
The community welcomes feedback that is constructive and supportive, in the spirit of better understanding and implementation of Scrum.