Flow metrics, work in progress limits and the engineering practices that decide how fast a change reaches a user.
Delivery gets faster when the queue gets shorter, not when the team works harder, and the books here make that argument with evidence rather than assertion. The list is ordered from the measurement you can start using this week, through the practices that change the shape of the work, out to the engineering and structural conditions underneath. It suits delivery managers, Scrum Masters and product people who have been asked why a small change takes six weeks to reach production.
The quickest route to saying something honest about predictability. Cycle time percentiles and a scatterplot give you a forecast on day one, without asking anyone to re estimate the backlog first.
Where work in progress limits, explicit policies and classes of service come from. The evolutionary framing matters, because it lets you improve flow starting from the process you already have rather than after a reorganisation.
Names five thieves of time, including unplanned work and the dependencies nobody tracked, and gives the board design that exposes each one. The book to reach for when the team is plainly busy and delivery is still slow.
Deployment frequency, lead time for changes, time to restore service and change failure rate, with the research method published alongside them. Four numbers a senior audience will accept as evidence.
Flow problems that survive every process change are usually boundary problems. This gives you the four team types and the vocabulary to propose a different shape rather than another ceremony.
Theory of Constraints told as a novel, which is the version colleagues who will never open a methodology book will actually finish. Good for building shared understanding of why the bottleneck decides everything.
Fixed time and variable scope, with appetite set before the work is shaped and a circuit breaker at the end of the cycle. Worth reading for the alternative to the sprint even if you keep the sprint.
Once flow is understood, release frequency is usually the constraint on learning anything. Humble and Farley cover the deployment pipeline, testing strategy and data changes needed for a release to become a business decision.
Cohn separates estimating from planning across several horizons, which is the piece most flow discussions leave out. Useful when you still owe somebody a release plan and a date.