1: Stability & predictability - AgilityHacking.com

Phase 1: Stability & Predictability
Be easier to do business with
Goals
What are we trying to achieve?

Gain stable, sustainable velocity
Flatten out the peaks and troughs, building sustainable delivery foundations to build on

Give your business predictability over deliverables
Offer your business counterparts the opportunity to plan by being predictable and delivering the things you say you will, when you said you would
Method
How do we achieve these goals?

Work with what you've got
No big investment needed
Work with what's in front of you - the people, the software architecture - tweaking and improving. The ask may be a little (little!) patience, i.e. time, but nothing more. Right now we don't have the credibility for a bigger ask. Let's not have that battle.
Experiment and tighten the ways of working
Adapt the small but obvious
Work closely with each team, inspect how they work, iron out all the clearly impeding process issues. Look at everything from work ingestion, development and debugging efficiency, testing effectiveness, internal team processes. Introduce, or amplify, some basic agile methodology, such as Scrum, or lean thinking. Work to continually improve.
Structure the work
Gain some control
Gain control of the work coming in. Understand it, categorise it, break it down. Get it agreed. In the short-term make this area more formal, until it is under control. Implement one route for work flowing into a team - no walk-ups, no PO persuasion via favours, no developer coercion via beer, and bugs are just work. One route, one backlog. This should allow each team to move from reactive mode to proactive mode, thinking at least one sprint ahead.
Visualise the work
Visualise everything!
Leave nothing in people's heads. All the work that's been asked for, mentioned in the corridors, actioned in meetings. All. The. Work. Make it all apparent to everyone - the teams, the stakeholders, the management. Whether it's covering your world in sticky notes or filling up virtual boards with cards, make it happen. Understand all the work that each team is undertaking. Use this to gain a single view of priority, make trade-offs.

(If you chose to take only one, single piece of advice from this entire site, then this should be it!)
Prototypical changes
What are examples of things that might be undertaken or changed in this phase?

For example:
Form fully-skilled, stable IT teams
Give team ownership of something(s)
A single work ingestion mechanism
Stable backlogs
Stable velocity - reduce carry-over
3-month rolling plan for all delivery work - start looking beyond the next sprint
Developer efficiency - local debug, low PR burden
Reduced defect leakage
Factory metrics (throughput, carry-over, work type, happiness)
Scrum training/coaching
Indicative gains/benefits
What benefits will be demonstrable in this phase?

As this phase progresses, you should see velocity stabilise, carry-over reduce, and deliverables arrive more in line with promises.

If this succeeds, you should notice that "pressure" from the rest of the business changes (it probably won't decrease, when does it?!) but the prior coercion techniques, for getting work into the system, should dissipate in most cases - the artificial deadlines to "ensure" delivery are a particularly good example.

It's too early for the majority of people across the business to change their opinions of the IT bottleneck, but those most heavily involved should recognise that you've become more reliable - easier to do business with

Example noticeable changes:
Vastly fewer missed promises
Teams being less reactive
Less unplanned work emerges
The ability to plan emerges, potentially for the first time
Data is available to back this up and point to