HomeBook Recommendations

Here are some books we like. Click on the title for the LeanPub or Amazon page.

Agile Thought Leadership

Actionable Agile Metrics for Predictability

Daniel Vacanti

When Will It Be Done

Daniel Vacanti

Both are extremely important, should be required reading for all coaches and trainers. It is shocking that many popular Agile tools still use averages for forecasting. Vacanti points out that this is likely due to the fact that we were all taught about the pareto principle and bell curves in school. The problem is that software development is not “normal,” that is, completion times do not follow a bell curve. More sophisticated statistical approaches are needed to create usable forecasts. Worse still, software processes that are not under control (those which exhibit a very high degree of unpredictability) may require a very large amount of historical data in order to make any kind of sound prediction. Regardless, Vacanti argues that we should consider re-forecasting whenever new data arises, ultimately leading to “continuous re-forecasting.” We also recommend Vacanti’s forecasting software Actionable Agile. While it is certainly not perfect, it is vastly better to the forecasting functions within the majority of software tools in wide use today.

Software for your Head: Core Protocols for Creating and Maintaining Shared Vision

Jim McCarthy (2002)

Extremely thought provoking. Years ahead of its time in my opinion. Explains what is effective but not how to get there.

Leading Change

John P. Kotter (2012)

Kotter has spent many years working with large organizations as they undergo transformational change. Unsurprisingly, he has come to the conclusion that such change is extremely difficult. So difficult, in fact, that such efforts rarely succeed. Nevertheless, the need to change rapidly has never been greater. Windows of opportunity open and close more quickly than ever, and companies that are more nimble tend to outpace their competitors. Kotter has come up with a “recipe” for change– a set of activities that he has seen over and over again in the organizations that have been successful at undergoing big changes. Kotter indicates that, while following the recipe does not guarantee success, skipping steps makes failure more likely. Although methods such as Kanban generally prefer to avoid such risky and disruptive changes (via an incremental approach), it is undeniable that there are times when an organization must pivot to survive, to take advantage of a massive opportunity, or to avoid a significant risk. Here is Kotter’s recipe:

1. establish a sense of urgency
2. build a guiding coalition
3. establish the vision and strategy
4. communicate the change vision
5. empower employees for change-based action
6. generate short-term wins
7. consolidate gains and produce more change
8. anchor new approaches in the culture

Kanban Change Leadership

Klaus Leopold

Practical Kanban

Klaus Leopold

Rethinking Agile

Klaus Leopold

Very much enjoy Klaus’ writing, and he is clearly honing his vision and sharpening his writing skills with each book. Practical Kanban introduces the concept of Flight Levels and Rethinking Agile hones and polishes this vision. Flight levels provide a useful conceptual model for managing the flow of work and tying strategy to execution by visualizing work at three levels: strategic, coordination, and operational. When combined with the Systems Thinking Approach to Implementing Kanban (STATIK) and the Kanban Maturity Model (KMM), Flight Levels provides a powerful model for organizational improvement and alignment. Companies struggling to implement SAFe would do well to look into Flight Levels and KMM.

a Seat at the Table

Mark Schwartz

Schwartz argues persuasively that IT leadership, in particular the CIO, has a critical role to play in an Agile organization. He argues that IT needs to participate actively in devising organizational strategy, alongside sales, marketing and finance. He stresses that IT should be evaluated not based on adherence to schedule or budget but by achieving outcomes. Agile and DevOps can shrink cycle times to the point that business hypotheses can be formulated and tested quickly. Schwartz advocates the “Beyond Budgeting” concept of setting guardrails, utilizing rolling wave planning and articulating assumptions and goals so they can be revisited when need be. Technical strategies can be linked to business drivers via “Impact Mapping,” a simple brainstorming technique invented by Gojko Adzic. Rather than tolerating change, we should welcome “as much change as results in a better outcome.” The CIO is the steward of three important assets: the enterprise architecture, IT resources and skills, and enterprise data. Some of my favorite quotes: “Unfortunately, we have set up IT around a control paradigm rather than a creative and enabling paradigm. This has caused business stakeholders to perceive IT as a limiter, a constraint, an impediment in achieving business objectives.” “The transformational project occurs when the amount of debt has become too much to bear. It is a painful lump-sum payment at a time when the company has been paying so much interest that it may already be frail and tottering.” “Transformational projects demonstrate waste in a governance process. If the governance process is unable to approve incremental changes to a system to keep it synchronized with business needs and technology trends, then that inability is costing the business money.” and “To be agile, in a sense, means to always be transforming.” Sobering thoughts.

Turn the Ship Around

L. David Marquet

Team of Teams

General Stanley McChristal

Information Every Coach & Trainer needs to know

Secrets of Consulting

Gerald Weinburg

Great Boss Dead Boss

Ray Immelman

Thinking Fast and Slow

Daniel Kahneman

Five Dysfunctions of a Team

Patrick Lencioni

Principles of Product Development Flow

Don Reinertson

AntiFragile

Nassim Taleb

Training from the Back of the Room

Sharon Bowman

The Fifth Discipline

Peter Senge (systems thinking)

Slack: getting past burnout, busywork, and the myth of total efficiency 2002

Tom Demarco

The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty

Sam L. Savage

Competing Against Luck: The story of Innovation and Customer Choice

Clayton M. Christensen

Fascinating book explaining how true innovation happens: by understanding the customer’s Jobs To Be Done.

Some Books a Little Bit Dated But Still Valuable

Agile Management for Software Engineering

David J Anderson

Precursor, written way before LeanKanban

Lessons in Agile Management

David J Anderson

Fascinating account that explains thought process as LeanKaban was being conceived and codified. Valuable anecdotes help explain motivations and benefits of evolutionary approach.

Agile: The Good, the Hype, and the Ugly

Bertrand Meyer

Part polemic, part paean from the inventor of the Eiffel programming language and the author of “Object Oriented Software Construction” the definitive work on that topic. Focuses mostly on Scrum. Interestingly, Kanban answers most of the author’s nitpicks with “agile.” It is in our opinion important and worthwhile for all Kanban coaches and trainers to be aware of agile’s “failure modes.”

Here are a couple related articles:

Why “Agile’ and especially Scrum are terrible
Michael O. Church

The tax you are paying for using Scrum
Martin Cerruti

Specific Agile Techniques Useful for Software Teams

User Story Mapping: Discover the Whole Story, Built the Right Product

Jeff Patton

Event Storming

Alberto Brandolini (LeanPub early access)

Specification by Example

Gojko Adzic

FIT for Developing Software

Ward Cunningham, Rick Mugridge

Analysis Patterns

Martin Fowler

Product Roadmaps Relaunched

C. Todd Lombardo, Bruce McCarthy

The Phoenix Project

The Unicorn Project

Gene Kim

Lean Enterprise

Jez Humble, Joanne Molesky, Barry O’Reilly

The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty

Sam L. Savage

Release It!

Michael Nygard

Show Me the Numbers: Designing Tables and Graphs to Enlighten

Stephen Few (2004)

We think his later 2009 book “Now you see it, simple visualization techniques for quantitative analysis” is even better!

Continuous Delivery

Jez Humble

Exploring the Diversity and Range of Agile Methods

Extreme Programming Explained

Kent Beck

Reading this in 1999 changed the course of our careers!

This is Lean

Modig, Niklas, Ahlstrom, Par

Very clear explanation of Lean

Coaching Agile Teams

Lyssa Adkins

Despite the general-sounding title, this is pretty scrum-specific

Scrum — A Pocket Guide, 3rd Edition

Gunther Verheyen

A good companion to the Scrum Guide. I like two insights in particular:

Recommends we get away from the word requirement and use “desirement” (desire is too fuzzy and requirement is too detailed and overspecified)
Recommends Lyssa atkins model of coaching- scrum master does not resolve conflicts but helps the team resolve their own interpersonal conflicts. If the question is “who resolves x?” for any x the answer is always “the team” rather than the Scrum Master. Some Scrum recommendations made the Scrum master out to be a drill Sergeant, but Master Yoda is a better analogy.

Scrum Insights for Practitioners: The Scrum Guide Companion

Hiren Doshi

Another good set of insights for Scrum teams. Here are some nuggets:

Scrum team may invite SMEs to provide input and guidance during sprint planning
Daily scrum outcome might in fact be an updated sprint goal.
Sprint backlog is set of PBIs selected for sprint plus plan for delivering it
Every retro is an opportunity for raising the bar on the definition of edone
Multiple teams must have same definition of done if they are working on the same product
Even in the very beginning, when most of the work is architecture work, make sure there is a tiny piece of user-facing work done. Over time the amount of architecture work will reduce, but it will never be zero.

Shape Up: Stop Running in Circles and Ship Work That Matters

Ryan Singer

A complete reimagining of what it means to be Agile, going back to first principles. Concise and very thought-provoking. Ryan recommends a way of working that is broken into 6-week cycles separated by 2-week “cool down” periods. Directly customer-valued features are first “Shaped” by senior teams and then “pitched” to decide whether they will be worked on or not. The features are separated into “medium” and “small” sizes– anything larger than a medium (3-4 people for 6 weeks) is further broken down. Here are some of the more interesting recommendations:

Instead of designing something and then estimating, do the opposite. Based on a rough idea, figure out what the “appetite” is– that is, how much is that idea worth? Is it a small or medium? Use those as boundaries and constraints to figure out what can fit in that size.
Shaping the work roughs out the elements but does not create full UX/UI. Instead you get something similar to a “Feature Canvas” that summarizes the problem, the appetite (size), basic outline of solution, explains the rabbit holes, and lists No-Gos (out of scope elements). Only rough sketches a la Balsamiq are used.
Every single development team has a 100% dedicated designer. Basecamp prefers a ratio of 1 designer to 2 developers max. Most teams have far fewer designers.
Feature canvases are then selected by the same senior team: CEO, CTO, product strategist and senior developer.
Two variants are allowed to vary from the 6-week cadence: R&D and cleanup.
A “hill chart” is used to track progress. All features and their “scopes” (aka user stories) are tracked going up the hill (“figuring things out”) and then down the hill (“making it happen”). This way we track elements not just by where they are in the cycle but where they are in terms of risk. This is a brilliant improvement!

Scrumban

Corey Ladas

Showing its age; many of the recommendations or techniques have been superseded by better ones. However, we still prefer this due to the quality and clarity of the exposition over newer Scrumban books

The Goal

Eliyahu Goldratt

Lean for manufacturing and physical processes

Fixing Your Scrum

Ryan Ripley

Despite the title, this is a pretty good guide to state of the art modern Scrum. Don’t Scrum like its 1999. Get this book and see what you have been missing! There are plenty of good insights here. For example:

This book encourages all Scrum teams to create a Sprint Goal and places a very heavy emphasis on it. The sprint goal aligns the team and informs their decisions. If a team achieves the sprint goal, even if they don’t complete every item, the sprint is a success. The Sprint Goal is what prevents Scrum from becoming a never-ending assembly line of stories. The team should actively manage towards the goal. For example, if a team member happens to notice a Product Backlog Item in the backlog that matches the sprint goal better than something not yet started in the sprint backlog, they should bring it to the attention of the product owner.
The book also includes some new ideas for how to run retros; as a venue to gather ideas regarding organizational improvement.
It mentions Evidence-Based Management and lists some very interesting metrics such as feature usage index, installed version index, on-product index and innovation rate.
The book encourages Product owner to act as an agile product manager; evaluating competitor products, assessing customer information, managing budget, etc.
The book emphasizes the importance of creating a product vision and of deleting anything older than six months in the product backlog.
Recommends making all reporting start red instead of green, and only turn green after the product gets into production. That more accurately reflects risks on the project because until the product is actually in production we are in a very high state of risk.
The book recommends Scrum Masters not to be too paternalistic– allow team to skip backlog refinement if they insist, so they can experience painful sprint planning, they need these teaching moments
The book recommends taking on technical debt immediately when it enters the conversation
The author recommends skipping the typical “three questions” and asking different questions during standup: is anything stuck, who needs help, what is most important thing we need to get done, and how can we increase odds of it getting done?
He also recommends tracking work item aging on the sprint board
Contrary to quite a number of Scrum sources, the book recommends never to use public shaming like forced singing or pushups as a punishment for arriving late at a meeting; rather to engage with the team and have the team address their own behavior and establish norms.
Finally, the author recommends setting a specific agenda for sprint review—it is not a demo. In fact, features should be demonstrated throughout the sprint, so that the sprint review can focus on feedback and new requirements.

Forecasting and Metrics

Actionable Agile Metrics for Predictability

Daniel Vacanti

When Will It Be Done

Daniel Vacanti

Extremely important, should be required reading for all coaches and trainers.

NoEstimates

Vasco Duarte

Fun read full of wisdom. The keynote video on his website is an absolute gem. Unfortunately it is paywalled.

Software Estimation without Guessing

George Dinwiddie

A brand new book and worthy successor to replace the venerable scrum-based estimation book by Mike Cohn Agile Estimation and Planning. George covers a lot of ground, but in my opinion misses a few important points regarding large-scale Agile efforts within the federal government space (admittedly, this is an extremely specialized environment). Nevertheless there is a great deal of excellent material to mine here.