Welcome changing requirements, even late in development.
Agile processes harness change for the customer’s competitive advantage.
In software development…
- This is one of my favorite principles because in many cases, changing requirements is a huge cause of stress for the team and often the scapegoat for product and project failure. We should be embracing change, not fighting it.
- Changes are powerful. They are a signal that there is new information about the product. We can take that new information and use it to make the product better!
- Stress around requirements changing often stems from the fact that you’ve got a deadline looming and now that timeframe is shot to hell due to something changing late in the game. Why do we do this to ourselves?
- Imagine a world where there are no deadlines. When what matters most is that you are producing a product of value that makes your customers happy. When the team, including our customer is responsible for when that product is released… could we more easily welcome change and use this new information for the customer’s competitive advantage? Yes!
- Change happens. How can we respond to change in a welcoming way? What kinds of things can a person do to “increase adaptability” and “decrease resistance”?
- I love this idea of harnessing the power of change in order to gain a competitive advantage. I think we can get a lot of power by just changing the terminology. Swap out “change” for “opportunity” perhaps… it helps get rid of the negative connotations we’re associating with the word at a psychological level.
- Don’t panic.
What would the Jedi say?
There is no scope creep, there is improvement.
There is no deadline, there is readiness.
There is no change, there is opportunity.