Agile Principle #2

3 min read

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

Agile Principle #2

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

Defining project requirements is handled very differently on Agile projects and it is typically one of the hardest concepts for a business to embrace. Consider how most projects are initiated. First, you define the scope of the project, then you price each project line item. Lastly, you sign the contract and commit to your customer that you will execute the contract. What if you start and then discover that one of the project line items is a bad idea? Market conditions can change rapidly and that is especially true of technology projects. Locking yourself into a fixed project plan that you already know is a bad idea is a great way to waste a bunch of time and money.

Agile projects take a very different approach to requirements management. Instead of locking down the project scope, Agile projects define the initial requirements as high level objectives then progressively elaborate the objectives into more detailed requirements at the last responsible moment. This empowers Agile teams to use changing requirements and market conditions as a competitive advantage instead of a stumbling block. Requirements defined later in the project are more likely to be correct because they benefit from what you have learned about the project during the period of performance.

Practice 2.1: Embrace Change

Instead of fighting change with a complicated change management process, Agile projects avoid the problem entirely by delaying the "lock in" of requirements until the beginning of an iteration (or the last responsible moment). This allows the Agile team to smoothly incorporate changing requirements and continuously improve the definition of the product even into the late stages of the project.

PDCA Cycles

Practice 2.2: Progressive Elaboration

Rather than trying to define all requirements upfront, Agile teams use progressive elaboration:

  1. High-Level Objectives: Start with broad business goals and user needs
  2. Iteration Planning: Elaborate specific requirements just before development
  3. Continuous Refinement: Use feedback to improve and adjust requirements
  4. Last Responsible Moment: Make detailed decisions as late as possible while still being effective

Practice 2.3: Incorporate Feedback

Having the ability to incorporate changes smoothly empowers the Agile team to actively seek out changes that give the product an advantage. We do this by putting the product in front of customers early and often to get feedback. Agile projects use this feedback to learn about our product and the market where it will live and compete. Information learned from this feedback will guide the team when they elaborate the next objective into requirements and help ensure the product meets the customer's needs.

The Competitive Advantage

When teams embrace change, they gain several advantages:

  • Market Responsiveness: Quick adaptation to changing market conditions
  • Reduced Waste: Avoid building features that are no longer needed
  • Innovation Opportunities: Discover better solutions through iteration
  • Customer Satisfaction: Deliver what customers actually want, not what they thought they wanted
  • Risk Mitigation: Identify and address problems early

The key insight is that change is inevitable in software projects. Rather than fighting it, Agile processes harness change as a source of competitive advantage.

For more information about the origin of the Agile Principles, see the Agile Manifesto site.