Technology Change is about more than technical delivery, a broader process wraps around this, and while nobody loves honourous process, Frameworks guide people to do the right thing.
Delivery Management
Purity doesn't win prizes
Your don’t need to be a ‘pure’ implementation of any one methodology
Your implementation needs to be coherent, consistent, & understood
‘Agile’ fails without stakeholder input, time for spikes & iteration
Waterfall fails without proper change control
Products over Projects
Tend to your systems
Your system is never complete
Software, APIs, the ecosystem goes stale over time
Iterating on a working system reduces the need to replace every n-years
Contracts aren't magical
Just because it's written down...
Well drafted contracts are crucial to set the terms of engagement
But something being written down, doesn’t mean it’s feasible to implement
Work with suppliers for easily measurable, definitive goals
Process Overheads
No more than needed
Have enough process to be useful, and no more
Make the right way, the easy way
Beware unintended consequences of rigid rules
Workload
Things take as long as they take
Routine long hours are definitively shown to be counterproductive
Remember the Mythical Man Month and be wary of just adding people
Step away from story points and other synthetics for estimates
Intervention
Show support, without interfering
Be careful when jumping into teams to “help out” during problems
It’s rare that there is an internal ‘silver-bullet’ to resolve things
Reduce scope and WIP to help team recover
Quality
Deliver good, without gold-plating
Quality has many properties, different components have different priorities of these
Most are better considered while components are being built
Add just enough quality as you build
Technical Debt
Focus on what's slowing you down
Stop saying “technical debt”, overuse has made it meaningless
Approach patching/upgrading as a “little but often” task
Give teams input into planning, they know what is causing operational or development ‘drag’