Your company follows a very rigid long-running stage-gate process, which takes around two years between first ideation and go-live.
You have three to four releases per year.
You cannot change anything which already passed a gate.
Issue, Problem, Risk
The 1%-requirements creep rule is ignored, thus after 24 months more then a quarter of your project’s results will be wrong.
If you are held responsible for the software design you will insist on getting a frozen requirements specification document.
If you know your failure will be recognized by your peers down the line and reported through the hierarchies – to finally land on your desk again, you become a cautious and fearful person.
Thus, maybe the biggest reason for the absence of a culture for change is silo thinking in combination with well established blaming mechanisms.
Mitigation, Remedy, How to avoid
Reduce fear by establishing a culture for failure and a culture for change.
Establish a culture for change by establishing a change process for all projects.
Agile embraces change. It is one of the four values of the Agile Manifesto: ‘responding to change’ and one of its principles is ‘welcome changing requirements, even late in development.’
Agile thinking requires the working implementation of a concept called ‘feedback loops’.
Thus whenever we do something, there should be some kind of planning before we do it (Cf. ‘I guess I’m just a fool, who never looks before he jumps.’ in ‘Everything happens to me’ as sung by Chet Baker, in https://youtu.be/MaGl6zd3rHg).
And after we did something, there should some kind of check, and some kind of a reaction of what we found out. Other forms of feedback loops:
- OODA (Observe, Orientate, Decide, Act)
- PDCA (Plan, Do, Check, Act/Adjust)
- PDSA (Plan, Do, Study, Act)
- Build, Measure, Learn (Lean Startup)
See e.g. http://prince2.wiki/Change.