I find myself answering this question often. Sharing a response here…

1. First, accept that you will probably need to focus and go slower. It’ll help you go faster eventually.

2. Second, you must reframe your view of faster. The speed we care about is frequency of learning, frequency of delivering actual value (outcomes), and speed to respond to changes in our environment.

Some ideas…

Make​ ​​psychological​ ​safety​​ ​a​ ​prerequisite,​ ​at​ ​all​ ​levels

1. Research work of Amy C. Edmondson, Project Aristotle (Google)
2. Do​ ​Crucial​ ​Conversations​ ​training
3. Leaders​ ​model​ ​(and​ ​encourage)​ ​speaking​ ​out​ ​about​ ​challenging​ ​topics
4. Disincentivize​ ​managers​ ​and​ ​leaders​ ​from​ ​information​ ​and​ ​feedback​ ​hoarding
5. Address​ ​some​ ​of​ ​the​ ​very​ ​visible​ ​trust​ ​issues​ ​between​ ​parts​ ​of​ ​the​ ​organization

Start​ ​an​ ​agile​ ​coaching​ ​practice

1. Hire​ ​Agile​ ​Coaches​ ​(not​ ​scrum​ ​masters,​ ​not​ ​project​ ​managers)
2. Make​ ​sure​ ​the​ ​coaches​ ​are​ ​​unbiased​,​ ​and​ ​not​ ​connected​ ​to​ ​an​ ​individual​ ​department. Ideally, they should be PULLed into teams. Not pushed
3. Conduct​ ​large​ ​scale​ ​(org​ ​wide),​ ​facilitated​ ​continuous​ ​improvement​ ​events​ ​(k​aizen​)
4. Have​ ​unbiased​ ​facilitators​ ​for​ ​retrospectives
5. Conduct​ ​cross-team​ ​retrospectives​ ​for​ ​larger​ ​initiatives
6. Offer​ ​1:1​ ​coaching​ ​for​ ​managers,​ ​senior​ ​managers,​ ​leaders,​ ​etc.
7. Discontinue​ ​wasteful,​ ​non-value-add​ ​practices​ ​(e.g.​ ​story-point​ ​estimation)

Structure​ ​/​ ​Systems

1. Tighter​ ​integration​ ​between​ ​product​ ​and​ ​engineering
2. Clarify​ ​the​ ​role​ ​of​ ​engineering​ ​front-line,​ ​mid-line​ ​managers
3. Either​ ​address​ ​dependency​ ​issues,​ ​or​ ​make​ ​“products”​ ​/​ ​silos​ ​completely​ ​autonomous
4. Build​ ​team​ ​resiliency​ ​to​ ​the​ ​point​ ​where​ ​most​ ​teams​ ​can​ ​self-manage
5. Reduce​ ​areas​ ​of​ ​local​ ​optimization​. Root​ ​out​ ​“kingdom​ ​building”,​ ​especially​ ​among​ ​frontline​ ​managers/directors
6. Explicitly​ ​call​ ​out​​ ​all​​ ​shared​ ​services​ ​(aspects​ ​of​ ​support,​ ​ops,​ ​infra,​ ​etc.). Aggressively challenge economy of scale assumptions
7. Encourage​ ​more​ ​aggressive​ ​rotating,​ ​​reteaming​,​ ​and​ ​swarming​ ​practices
8. Flatten​ ​the​ ​organization​ ​overall.​ ​Information​ ​loss​ ​is​ likely ​too​ ​high
9. Break​ ​down​ ​structural​ ​silos​ ​between​ ​ops​ ​and​ ​engineering

Visualize​ ​Work,​ ​Manage​ ​WIP,​ ​Optimize​ ​for​ ​Flow​ ​Efficiency

1. Go slower. Be less busy. Be more disciplined. Be more focused
2. Require​ ​everyone​ ​in​ ​product​ ​and​ ​engineering​ ​to​ ​read​ ​​Principles​ ​of​ ​Product​ ​Development​ ​Flow by Donald Reinertsen
3. Deliver​ ​a​ ​training​ ​program​ ​focused​ ​on​ ​lean​ ​principles
4. Adopt​ ​program​ ​and​ ​portfolio​ ​level​ ​Kanban​ ​with​ ​aggressive​ ​WIP​ ​constraints
5. Encourage​ ​lower​ ​utilization​ ​rates​ ​on​ ​teams,​ ​and​ ​WIP​ ​constraints​ ​(focus​ ​and​ ​slack)
6. Visualize​ ​​all​ ​​work​ ​including​ ​maintenance,​ ​triage,​ ​and​ ​production​ ​support
7. Resolve​ ​dependencies​ ​by​ ​blocking​ ​dependent​ ​teams​ ​(not​ ​over-utilization,​ ​not​ ​multitasking)
8. Prioritize​ ​based​ ​on​ ​apples-apples​ ​cost​ ​of​ ​delay​
9. Focus​ ​on​ ​flow​ ​efficiency,​ ​rapid learning, lower​ ​utilization,​ ​and​ ​small​ ​batches
10. Track​ ​lead​ ​times,​ ​cycle​ ​times,​ ​and​ ​categorize​ ​work​ ​into​ ​work​ ​classes
11. Swarm​ ​bottlenecks​ ​wherever​ ​they​ ​exist.​ ​Fluidly​ ​move​ ​resources/focus​ ​to​ ​bottlenecks
12. Move​ ​to​ ​continuous​ ​planning​ ​with​ ​quarterly​ ​reviews​ ​(not​ ​quarterly​ ​planning)
13. Move​ ​to​ ​more​ ​continuous​ ​value​ ​delivery​ ​(over​ ​scrumfall​ ​and​ ​big​ ​project​ ​batches)
14. For​ ​cross-team​ ​efforts,​ ​involve​ ​all​ ​front-line​ ​ICs​ ​in​ ​regular​ ​standups,​ ​reviews