The mere mention of changing requirements triggers emotional responses in software teams around the world. Clients changing requirements mid-development, customers complaining about features that operate exactly per design, breaking software updates and changes in the compliance landscape create delays, re-work, pain and suffering.
We blame poor change control methods, weak project management and indecision of the individuals involved. But we’re wrong.
The root cause of scope creep, if we’re to point fingers, is the passage of time.
There are two key facts often forgotten:
- We cannot see the future
- There is very little in this world that remains static
Change is inherent
Software is developed for humans, by humans with the help of technology. Two key components, both dynamic and both very much subject to change over time.
People: Customers, stakeholders, suppliers, marketers, sales people, developers, designers and testers are constantly learning and absorbing new information. The needs, opinions, expectations and experience of both individuals and the teams they comprise are in constant flux, as is natural.
Technology: Software development is a complex task. Thousands of lines of project specific code are laid on top of frameworks and third-party components, all of which are maintained by different teams and often written in different languages. Add to this the underlying database technology, deployment pipelines (and equally complex infrastructure) and a web of interconnected variables quickly emerges. Each travelling on their own trajectory and all subject to deliberate change that is often outside of our control.
Meanwhile, as a project progresses, competitors are also out there learning, launching new products and adapting to (or creating) changes in the market. Not only does the project change, but the world around it changes too.
The more time that passes, the more change occurs.
Scope creep is a function of duration.
Fighting Scope Creep is an anti-pattern
Reading traditional Project Management literature, we’re instructed to resist change by employing change management protocols and detailed written specifications.
But do we really want to fight changes in scope?
If new information comes to light that would allow us to build a better product for the customer, do we really want to wave it off? Does clinging to the encyclopedia-sized scope specification document that we spent months writing create any value? Are we building trust and loyal relationships? Are we still proud of what we’re building? Are we having fun? Does anyone win?
If we’re open and able to adapt to the change we add value. As time passes our software, people, technologies and our market stay closely aligned. Each time we adjust course and add value the pie grows. And when the pie grows, the slices get bigger. Everyone wins.
Build change into the process
Agility isn’t easy. It has to be baked into a team’s culture and nurtured as a key driver of productivity.
- Treat the need for change just like any other requirement. Documenting Qualitative Non-functional Requirements like Adaptability keeps them front of mind.
- Build flexibility into contracts
- Work to roadmaps, not fixed timelines
- Deliver quickly and iteratively. Smaller batch sizes, shorter cycle time, more focus, higher quality, faster feedback. The smaller the time interval, the more digestible the changes.
- Build trust by making small, short promises you can keep. Without trust pressure for certainty increases.
Change is normal and to be expected, even desired. Adjust, adapt and create something of value. Something that matters.