The Agile Wilderness: Principle #2: Changing Requirements

Agile Principle #2: "Welcome changing requirements, even late in development. Agile processes harness change for the customer’s competitive advantage." (1)

Image from medium.com (2)

I do not think I have ever had anyone choose this as their favorite principle through all the trainings I have done with teams. I think so often as a team we still think of change as bad even after we adopt agile practices. What we need to realize, change is inevitable but how we handle the change is key and a large part of the agile mindset. We need to look at change as something we have learned and therefore can respond and delivery better value.

Digging into the agile principle

There are several parts to this principle. First it talks about "welcoming" changing requirements. In general folks agree with this conceptually from the manifesto to respond to change over following a plan however when we say "even late in development" you see everyone cringe. Too often the team has been so used to planning in a way that they are unable to respond to changes. This principle is a great reminder during those hard conversations with stakeholders and the team that how we respond to change is key.

The other part of the principle is really sharing the why behind it, which is to give us a customer competitive advantage by responding to new things we learn where others continue down their old path. When we think of change as good and a sign that we are learning from our customers, we respond better to changes. Practices such as scrum help us regularly reflect in order to give us the space to talk about what needs to change so we can deliver more value.

Comparing the agile principle to Scrum values and SAFe scaled principles

The scrum value (3) of focus really supports this idea. We focus on the highest valuable work which means that things will change, and we need to be open to this. Frameworks like scrum support this focus by giving you a timebox of work to focus on a certain part of scope. This then allocates time to review and reflect on what we did the last 2 weeks and determine what we have learned and what pivots we need to make and change focus in our next 2-week timebox.

When we look at scaled agile principles (4), we see that this is taken a bit further. Scaled agile principle 3 is focused on the technical side of things, specifically that our solution needs to "assume variability and preserve options". We want to make sure that as we build we leave our solution open to changing as we learn more. We want to preserve options so that we can respond to the changing requirements that come from what we learn. The other scaled principle that is related to this is the fourth one which is "build incrementally with fast, integrated learning cycles." The key is that these are learning cycles. And what do we do with learning... we make changes in order to have competitive customer value we can deliver.

Suggested changes to the original agile principle

This is another principle as you really look at it the language is very outdated. I would update this to "Respond to validated learning throughout product delivery. Agile Processes harness learning for the customer's competitive advantage"

This brings some of the language from the manifesto, specifically that we need to respond rather than just welcoming change. As in previous articles, I think we need to bring attention to what the change comes from which is learning instead instead of talking about requirements. I also changed instead of "even late" as "throughout" to capture that this should be our mindset always. Lastly I changed product delivery instead of development.

Closing

In closing, responding to what we are learning is key to the empirical cycle of learning by doing. Let's make sure regardless of the methodology we use that we keep a focus on the highest value for our customers and pivot based on what we learn. Here is a summary of this principle.

I hope you have enjoyed this article and as always feel free to reach out to discuss further or drop a comment below to join the discussion. Thank you for your time and look forward to sharing my thoughts about "Principle #4: Working Together" next time.

About the Author

Jeff Mortimer?(#theAgileMoose) is an Agile Enthusiast with over 10+ years of experience working in various roles on agile teams including business analyst, product owner, scrum master, team leader, technical delivery manager and now an agile coach consultant focused on product transformations. In additional to his certifications in CBAP, AAC, CSP-PO, SAFe Agilist and SAFe LPM, Jeff?has presented at several conferences throughout North America and joined the blogger universe a couple years ago to bring a voice to the everyday agile practitioners. He also just received his EMBA at Quantics School of Business and Technology. He is a husband to an amazing intelligent wife who has her doctorate in math education, father to kids who bring him joy every day, friend that brews beer and plays soccer, and citizen who helps organize volunteers to give back to the community.

Follow #theAgileMoose for the latest insights in the agile wilderness.

References

(1)?Agile Principles?from agile alliance

(2)?Principles Image?from medium.com

(3)?Scrum Values?from scrum.org

(4)?SAFe Scaled Principles?from scaledagileframework.com