Agile

An introduction written for creative agencies covers the ground an introduction for software teams would: the Manifesto, user stories, the Scrum roles, timeboxes and artefacts, then lean principles and Kanban, before eight case studies that include running Scrum for a rock band and mixing Scrum with Kanban.[10] A guide for technical writers on agile teams explains the difference between agile and Scrum, describes both Scrum and Kanban, and then fits documentation into sprints with documentation user stories, a task board and a review cycle, alongside answers to daily problems such as slow review feedback and waterfall inside a sprint.[11]

The planning end of Scrum gets a practitioner's recipe in Joseph Little's release-planning method, which walks a single team from a vision to a product backlog, votes on business value, estimates in story points with planning poker, derives a velocity and produces a first release plan, with an ordering factor the author calls R and advice on continuing backlog refinement afterwards; the author presents it as one person's approach to be adapted rather than a prescription.[12]

A distinctive strand of the Scrum literature is the simulation. Alexey Krivitsky's lego4scrum: post-covid revision, a simulation he began running on certification classes in 2009, has several teams build one LEGO product through Scrum sprints: a pre-game of pitching a vision, forming teams, story mapping, refining the backlog and estimating, an in-game of multi-team sprint planning, building, a joint review and a retrospective, and a debrief. Its principles are deliberate. The product owner asks "where is my city?" at every review, to make the point that a working increment matters more than explanations of why there is none; the game is never run with one team, because a single team makes Scrum look naive; every team works from one backlog under one product owner, on the Large-Scale Scrum argument that scaled Scrum is still Scrum; and the first sprint is designed to fail, since in nineteen of the author's twenty runs it does, and the failure is where the learning is. The 2023 edition reports a session with 120 students in Gothenburg, scaling to more than fifteen teams using requirement areas from LeSS Huge, and an author convinced, after trying virtual substitutes during the pandemic, that physical presence is essential to real team dynamics.[13]

The ball point game is the other standard simulation; its facilitator's guide covers the original, a one-ball variant, Kanban and DevOps versions, a virtual version and a scaled version for groups of more than a hundred people, built so that players feel scaling problems rather than hear them described.[14] A companion from the same coaching series collects fourteen collaboration games whose stated purpose is to leave players with an emotional memory they can draw on when a similar situation arises at work.[15]

Two 2026 books by Jeff Sutherland argue for Scrum from outside the practice literature. The first explains why Scrum works by going back to physics, biology, evolution, neuroscience and economics, with chapters relating it to entropy, self-organisation, Friston's free-energy principle, pattern languages and the OODA loop, and frames the framework as a protocol for an age of cheap intelligence.[16] The second applies Scrum and Scrum@Scale to teams in which AI agents do real work, and is as much about the infrastructure such teams need, containers, memory, work management and chat, as about the framework; its chapters on stopping agents from drifting into waterfall, on WIP limits for agents and on verifying what an agent claims to have done are discussed below under agile and AI.[17]

Gojko Adzic and David Evans's book of fifty ideas for user stories starts from a diagnosis: stories are misunderstood as lightweight requirements that business stakeholders hand to a delivery team, collected in a tool with a ton of detail, when the model they imply is requirements by collaboration, with hand-overs replaced by frequent discussion. Their first idea is to tell stories rather than write them, keeping the card or ticket as a reminder for a conversation; they meet the usual reasons for written detail, regulatory sign-off, distributed stakeholders, specialist knowledge, by moving the sign-off to after the discussion, as teams in regulated environments they worked with did. Their second divides responsibility: the business specifies only the role and the benefit, the delivery team proposes at least three options for what to build, and both decide together, which forces a conversation and moves stories from "in order to sell more" to something specific. Their third is not to worry about story format, since a card is a token for a conversation and no format has been shown to change results; one of their favourite cards carried only two Japanese characters.[18]

The companion book on tests, by the same authors with Tom Roden, is written for cross-functional teams delivering in short iterations and planning with stories, and it reaches back into the stories: its advice to explore capabilities rather than features, illustrated by a contact form whose real risks were an offline user and a support team with no diagnostics, uses the "in order to" clause of a story and the impact level of an impact map as the starting point for a testing session.[19] A 2026 book on use cases, by contrast, argues for the older form, with chapters on use cases versus user stories and on slicing a use case for iteration, and adds a third reader to the usual two: alongside the stakeholders who validate a specification and the engineers who review against it, the AI agent that implements from it.[20]

Estimation divides the field. Joseph Little's release-planning method estimates in story points and uses velocity to plan a release.[12] A 2025 book for engineering leaders argues that most software estimation is wasted effort, and sets out when estimating is worth doing and how, with chapters on effort versus duration, error margins, when not to estimate at all, and standing ground against executive pressure for dates.[21] The flow-metrics books, discussed below, replace estimates with forecasts from a team's own data.

Above the story sits the question of what to build at all. Impact mapping is a planning method that connects a business goal to the actors who can affect it, the impacts wanted on them and the deliverables that might produce those impacts, placed by its own description beside agile and lean delivery as the big-picture view teams moving to agile often lack.[22] The Lean Product Guide, from two ThoughtWorks coaches, gives short entries on problem-solution fit, product-market fit and the balance of desirability, feasibility and viability, warns against judging a new product by lagging indicators such as profit before it has had a chance to show value, and reminds teams that customers can say what they want but not what they need.[23]

Two books from the domain-driven design world describe discovery as a collaboration. Scott Millett's introduction to DDD opens with code that has all the right frameworks and was built with an agile approach yet is hard to change, and presents DDD's remedy as developers and domain experts learning a domain together through a shared language.[24] Alberto Brandolini's EventStorming is a workshop rather than a method: participants write the key events of a business process on orange sticky notes, as verbs in the past tense, and place them along a long paper timeline, marking warnings and open questions in purple. His sample tells two stories, a corporate big-picture session that surfaced a customer-acquisition bottleneck whose fix turned out to be political, and a startup kick-off where developers learned a financial domain faster by modelling it than by being told about it, which he describes as more discovery than translation. The book, a long-running work in progress, was rewritten after 2020 for remote sessions, with the observation that big-picture formats suffer most from the loss of a shared room.[25]

Allan Kelly's book on OKRs in agile teams is the field's main proposal for the mid-term, the gap between daily and sprint planning on one side and roadmaps and missions on the other, which release plans used to fill until continuous delivery made a thirteen-week release plan meaningless. His reading of OKRs is agile at its root: key results are acceptance criteria for an objective, OKRs are test-first management, and a team does not consider itself done until it passes the tests. He sets them bottom-up, in each team's own words, on a quarterly or similar cycle, and argues that a team should drive its work from the OKRs and throw away its backlog, with the objective in the role of an epic and each key result a possible sprint goal. The warnings are as firm as the advice: teams are expected to hit about seventy per cent, a team hitting everything was not ambitious enough, and OKRs must never be tied to bonuses, benchmarks or performance reviews, because that destroys the psychological safety ambition needs. Burrows's foreword notes how close OKRs sit to management by objectives, a framework its creator Peter Drucker disowned, and reads Kelly's bottom-up version as its polar opposite.[6]

Nick Oostvogels's 2012 book answers the five arguments teams and managers most often raise against Kanban, that it loses the ability to plan, that work takes longer, that WIP limits leave things stuck, that stakeholders will not feed the flow and that the team loses cohesion, by tracing each back to lean principles, and ends on why software development is not manufacturing.[26] A 2025 pocket guide written as a companion to The Kanban Guide clears up common myths and puts work item age, rather than boards or WIP limits, at the centre, alongside service level expectations and the basic flow metrics.[27]

Caroli's book on the card wall builds the vocabulary from everyday examples before applying it to software: a workflow is a sequence of dependent stages with a feedback loop between neighbours, a coffee shop has a queue at the register, a queue of marked cups waiting for the barista and a shelf of drinks waiting for customers, and a snapshot of how many items sit in each stage at one moment is the picture a card wall gives a team of its own process.[3]

Daniel Vacanti's Actionable Agile Metrics For Predictability: Tenth Anniversary Edition, revised in 2025 for its tenth anniversary, is the most developed treatment. It opens with the claim that a process is unpredictable because of the policies the team itself has put in place: starting new work faster than old work is finished, working on too many items at once, expediting what need not be expedited, a denial of service attack on oneself. Its foundation is Little's Law in its throughput form, WIP equals cycle time times throughput, and above all the assumptions under which it holds: arrivals matching departures, started work finishing, stable WIP, consistent units, and the one the author singles out, that the average age of work in progress is neither rising nor falling. Letting items age arbitrarily is, in his account, the single greatest reason teams cannot say when something will be done, and the anniversary edition rewrites the book around work item age after a first edition that, he admits, used WIP as a hammer. Two maxims most teams have been taught, that the sooner you start something the sooner it is done and that the more you work on the more you get done, are presented as false. Before any of the metrics, a team must choose where work counts as started and finished, which Scrum does not settle for it.[4] The forecasting that this edition removed is the subject of the same author's When Will It Be Done?, which answers the customer's question with probabilistic forecasts from cycle time, throughput and Monte Carlo simulation rather than estimates, and closes with case studies that include a team moving from Scrum to Kanban.[28] A compilation of articles on the Theory of Constraints and Critical Chain brings the older multi-project flow tradition alongside, with chapters on the laws of flow and on finding the constraint.[29]

Jimmy Janlén's picture book of team walls is examples only, with no theory and, by its own account, no explanation of agile or Scrum. Its general advice is that a wall must be where the team sits, easy to update, designed for the core flows and regularly evaluated, and its examples include written policies with expiry dates, an inbox column where unplanned tasks wait for the whole team's decision at the next stand-up, two avatars per person so that a second task is visibly secondary, a countdown of days until the demo, confidence smileys updated daily as an alternative to a burndown, red blocker notes, and a dependency spider whose legs collect the reasons a team is waiting on others, to be mined at the retrospective.[30]

Bob Galen's book with three co-authors begins by saying what agile coaching is not: family, business or sports coaching, therapy, consulting alone or professional coaching alone. It is a situational craft in which the coach moves between stances, mentor, teacher, advisor, exemplar, facilitator, evangelist and coach in the professional sense, often within one session; the sample's cautionary story is of a vice-president who, after six months with a coach who only ever asked questions, opened the first session with the next one by asking whether he was going to do the same, which the author reads as a coaching failure, not a client problem. The book organises itself around the Agile Coaching Growth Wheel, distinguishes internal coaches, with more at stake and less privilege, from external ones, and is motivated by what the author calls mediocrity in a field where a LinkedIn search for the term turned up some 240,000 matches.[33]

Other coaching books supply models and tools. One sets out a five-part model, catalysing improvements, promoting awareness, boosting ownership, developing competencies and removing barriers, treats coaching as an activity to be democratised rather than a full-time role, and offers delegation boards, health checks and improvement mapping.[34] Another is a catalogue of named techniques from a decade of Scrum Mastering, among them a door calendar, bugs for breakfast, value poker, an in-line definition of done and a not-now backlog.[35] A coaching book on principles organises agile's common practices, visualising work, daily contact, talking to users, demos, small deliveries, by the principle each serves, so that a team can change the practice when its environment changes.[7] A handbook of whiteboard visuals and sketchnoting for coaches covers scenarios such as prioritisation and drifting teams.[36]

The books on leadership run from the concrete to the classical. Patrick Kua's interviews with tech leads define the role as leading a development team while writing code at least thirty per cent of the time, describe the move from developer as lonely, since the skills of refactoring and testing do little to prepare anyone for conflict or team culture, and present the interviews in a shared structure so that novices and practitioners can be compared.[37] Gerald Weinberg's textbook for his problem-solving leadership workshop treats leadership as personal growth, in parts on innovation, motivation and organising teams, with questions after every chapter.[38]

Erik Schön's trilogy reads classical Chinese texts into modern strategy and leadership, and two of its volumes are here. THE ART OF STRATEGY restates Sun Tzu in business terms with John Boyd's OODA loop and Simon Wardley's maps alongside, and its introduction lists the shifts it proposes, among them a move from agility as quick, graceful movement to agility as adapting to and influencing situations better than one's competitors, and from leadership as something managers do to leadership as a service anyone in the organisation can provide.[39] THE ART OF LEADERSHIP reads the Tao Te Ching, in 81 short sections on purpose and integrity, with a glossary in which agility is one of the defined terms.[40] Peter Merel's translation of the same text, with Beck's foreword, makes each chapter a pattern for agile leadership and names the three things agile people do differently as connection, adaptation and simplicity; agile organisations, it says, do not come from a manifesto, a framework or a certificate.[2]

Corey Haines's short book on the four rules of simple design comes from five years of facilitating coderetreat workshops, in which he watched thousands of pairs write Conway's Game of Life test-first. His sample argues that test names should shape an object's interface, so that a test called "a new world is empty" asks the world whether it is empty rather than counting its internal collection, and sets out pairing styles: driver-navigator, which he rates an intermediate style because it decays into a driver and a navigator checking Twitter unless the pair talks constantly, and two forms of ping-pong pairing in which one person writes a failing test and the other makes it pass, which he recommends for newcomers.[41] A free, open-source tutorial on TDD in C#, with notes for Java readers, builds from single objects through mock objects to ports-and-adapters architecture, and opens by asking the reader why they want to learn TDD, observing that its adoption has never become mainstream.[42] A handbook of short how-to guides collects the rest of the XP toolkit, user stories, pairing, TDD and BDD, acceptance testing, deployment pipelines, evolutionary architecture and developer habits, in five parts with pointers for further reading.[43]

The fifty-ideas book on tests assumes an iterative process and short iterations as its setting; beyond its advice on capabilities, its sample offers a test-design heuristic of nine emotional paths, scary, happy, angry, delinquent, embarrassing, desolate, forgetful, indecisive, greedy and stressful, and suggests snooping on competitors' public bug trackers and regulators' incident reports for test ideas, then holding a fake post-mortem as if the incident had happened to one's own product.[19] Janet Gregory and Lisa Crispin's condensed introduction covers the whole-team approach, test planning across levels, example and impact mapping, continuous exploratory testing, the agile testing quadrants and testing in DevOps, as a brief entry point to their two longer books.[44] A guide to testing in DevOps follows the tester into a culture of automated pipelines, feature toggles, testing in production and canary releases, with a section on how DevOps relates to agile.[45]

Dave Farley's handbook on continuous delivery pipelines walks a pipeline stage by stage, from the commit stage through acceptance, performance and non-functional testing to release, and ends with a real pipeline timed stage by stage; agile and lean appear as its context, in small steps and small autonomous teams.[46] A short introduction to GitOps makes Git repositories the source of truth for infrastructure and deployment, compares push- and pull-based deployment, and ends in a Flux quickstart on Kubernetes.[47] Jeff Geerling's Ansible book is a tool book, but its foreword by an Ansible co-founder gives the DevOps idea its plainest statement in this collection: DevOps is meant to shorten the distance between the developers writing the code and the operators running it, adding a DevOps team between the two does not achieve that, and a first step is choosing tools both can use.[48] Mob programming, the whole team at one keyboard, has a remote variant described by three developers in a short book whose chapters are its rules: everyone remote, camera always on, the same working hours, one typist guided by the rest, ten-minute intervals and a handover through git.[49]

The scaling books in this collection favour simulation and organisation design over frameworks. lego4scrum's multi-team rule and its LeSS-derived principles, one product, one backlog, one product owner, one sprint and one integrated increment, are its author's argument that Scrum for multiple teams beats multiple Scrum teams.[13] The scaled ball point game lets a hundred people feel the coordination problem.[14] A long 2025 book on the cybernetic enterprise is written for companies that adopted agile and DevOps but cannot adapt at scale, and places backlogs, sprints, cadence, lean management, Scrum Master and product owner roles and team topologies inside a wider operating model of principles, practices, platform and outcomes, with AI augmentation folded into every layer.[50] The organisation-design novel 10X ORG – Powered by Org Topologies follows an HR director asked by her CEO when AI can replace new hires, and answers with a model of resource, delivery and adaptive topologies and a case for deliberate redesign so that people learn faster and own more.[9]

The agency book and the technical communicators' playbook carry Scrum into creative production and documentation.[10][11] The furthest reach is Edward Abramowich's 2025 book on capital projects, refineries, offshore platforms and power plants. Its sample cites a McKinsey figure that 98 per cent of mega projects exceed their budgets by more than 30 per cent, argues that front-loaded, stage-gated delivery was designed for a predictable world, and points to Shell's Whale project delivered 20 per cent faster with agile, asset-aligned teams and Equinor's Johan Sverdrup platform reaching first oil six months early. Jeff Sutherland's foreword claims the same principles that make Scrum work for software teams can and must apply to the largest projects on earth, and a Shell operational-excellence lead recalls project engineers' first response to lean and agile, that they do not make widgets on a conveyor belt, and the reframing that won them over: the conveyor is the stream of contractor teams passing through a stationary project, and the losses are at the hand-offs.[51]

The question the 2026 books ask is whether agile's forms survive contact with AI, and the answers divide into adaptation and replacement. Sutherland's book on human-plus-agent teams keeps Scrum and Scrum@Scale as the organising frame and treats agents as team members under empirical process control, with WIP limits, a defence against agents drifting into waterfall, and a trust-but-verify stance toward what an agent reports having done.[17] The use-case book calibrates a specification's precision for an AI implementer.[20] Merel's agile way says its patterns apply as much to agentic AI swarms as to human communities.[2]

Marko Taipale's CollabAI: AI Teamwork In Practice argues from a 2024 experiment at Solita with a client, ISS, that AI exposes the real bottleneck: an hour of AI work produced forty prototypes that the customer saw a week later at the next scheduled review, so the tool was not the constraint, the queue was. Citing Donald Reinertsen on queues as the root of waste in product development, he proposes sessions in which designers, developers, a customer and an AI assistant work on one screen toward one goal, with a driver at the keyboard rotating every fifteen minutes and everyone else navigating; his first session produced a working feature with schema, tests, UI and documentation in a day, with no backlog refinement, sprint planning or phase gates. Joe Justice's foreword describes 50,000 people at a car maker splitting a product into pieces for groups of three to five every day.[52] A leadership book on an AI-driven development lifecycle makes the replacement explicit, moving from timeboxes to intents and borrowing mob-style elaboration, with chapters on governance, brownfield systems and the measurement traps of Goodhart's law.[53] The cybernetic enterprise and 10X ORG books treat AI as a multiplier inside an operating model rather than a new method.[50][9]