Pattern Description

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.

Root Cause

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.