Strategy, discovery, metrics, growth, pricing, design, delivery and leadership. Each entry says when it is the right one to pick up.
Krug wrote the follow up to Don't Make Me Think about the one activity he believes teams should do and mostly do not, which is watching somebody use the thing.
A single volume account of the Scaled Agile Framework written by two of the people who built it. It works through the seven core competencies of business agility, then through the framework itself at team, programme, large …
Dunford's follow up applies positioning to the sales conversation. The structure she proposes moves from insight, to the alternative approaches available, to the perfect world criteria those imply, then to the product as the way to meet them, followed by proof and objection handling.
Larman and Vodde's first book on large scale agile, focused on thinking tools rather than practices. Covers systems thinking, lean thinking, queueing theory, false dichotomies, and organisational design for multiple teams on one product.
Kniberg's field report on how one team ran Scrum and Extreme Programming together, written up as a set of decisions with the reasoning behind each. It covers how they wrote product backlogs, ran sprint planning, sized stories …
Watts contrasts a good Scrum Master with a great one across a series of behaviours, using the acronym RETRAINED for the characteristics involved. Covers building the team, the servant leader stance, running the events well …
Galen writes for the product owner who is accountable for value in a Scrum team and has found that the Scrum Guide says very little about how to deliver it.
Verheyen's compact guide to Scrum, written by a Professional Scrum Trainer and closely aligned to the Scrum Guide. Covers the origins in agile thinking, the framework itself in precise terms, and the tactics that sit outside the framework but are commonly confused with it.
Sutherland's account of where Scrum came from and why it works, aimed at a general reader rather than a practitioner. He draws on the Toyota Production System, OODA loops and his own fighter pilot and research background to …
Gothelf and Seiden argue that software changed what a company can learn about its customers and how fast, and that management practice has not caught up. The first half describes the shift, which is from planning and executing to sensing what is happening and responding continuously.
Basecamp's own working method, published free online and in print. Work runs in six week cycles with no extensions, is shaped at the right level of abstraction before it is bet on, and is handed to teams who take full responsibility for discovering the tasks.
Google's account of how it runs production systems, written by the engineers who do it. The central ideas are the service level objective as an explicit reliability target and the error budget that follows from it, which turns …
Google's account of the practices that let thousands of engineers work in one codebase over decades, organised around culture, processes and tools. The opening argument is that software engineering is programming integrated over …
McConnell separates an estimate from a target and a commitment, then builds a practical toolkit for producing the first of the three. He covers the cone of uncertainty, the principle of counting and computing before resorting to …
Schwaber and Sutherland wrote this for managers and executives rather than teams. Covers why software projects fail on the traditional model, what Scrum changes about that, and how a manager should think about funding, governance and risk under an empirical approach.