Books

Curated Reading

Book Recommendations.

Books play a critical role in shaping how we think, learn, and evolve as professionals and organizations. At Ariel Partners, we believe that continuous learning is essential to delivering meaningful, long-term impact for our clients across government and commercial sectors. The books featured on this page represent ideas, frameworks, and perspectives that have influenced our approach to leadership, strategy, and execution. We share these recommendations as trusted resources to support deeper understanding, practical application, and sustained improvement in complex environments.

Agile Thought Leadership.

Kanban Change Leadership
Practical Kanban​
Rethinking Agile

Kanban Change Leadership

Klaus Leopold (2015)

Practical Kanban

Klaus Leopold (2017)

Rethinking Agile

Klaus Leopold (2018)

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.

Actionable Agile Metrics for Predictability
When Will It Be Done?

Actionable Agile Metrics for Predictability

Daniel Vacanti (2015)

When Will It Be Done?

Daniel Vacanti (2020)

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

Software for your Head

Jim McCarthy (2002)

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

A Seat at the Table

A Seat at the Table

Mark Schwartz (2017)

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

Turn the Ship Around

L. David Marquet (2013)

Team of Teams

Team of Teams

General Stanley McChristal (2015)

Leading Change

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

Information Every Coach & Trainer Needs to Know.

The Secrets of Consulting

The Secrets of Consulting

Gerald Weinburg (1985)

Training from the Back of the Room

Training from the Back of the Room

Sharon Bowman (2009)

Great Boss Dead Boss

Great Boss Dead Boss

Ray Immelman (2003)

The Fifth Discipline

The Fifth Discipline

Peter Senge (2006)

Thinking Fast and Slow

Thinking Fast and Slow

Daniel Kahneman (2013)

Slack

Slack

Tom Demarco (2001)

Five Dysfunctions of a Team

Five Dysfunctions of a Team

Patrick Lencioni (2002)

The Flaw of Averages

The Flaw of Averages

Sam L. Savage (2009)

Principles of Product Development Flow

Principles of Product Development Flow

Don Reinertson (2009)

Competing Against Luck

Competing Against Luck

Clayton M. Christensen (2016)

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

Demand-Side Sales 101

Demand-Side Sales 101

Bob Moesta (2020)

This book takes human centered/user-centric approach and explains the profound effect it can have on sales and marketing. Great read for consultants, entrepreneurs, marketing, and sales professionals.

AntiFragile

AntiFragile

Nassim Taleb (2014)

Beyond Performance 2.0

Beyond Performance 2.0

Scott Keller (2019)

Fascinating read from McKinsey senior partners documenting practices and approaches taken during 100s of organizational transformations, both failed and successful. The book provides many specific recommendations, all well-documented with footnotes and backed by statistics. It is a sequel to a previous edition by McKinsey and will be followed up with an expanded edition as more and more experience is accumulated.

Some Books a Little Bit Dated But Still Valuable

Agile Management for Software Engineering

Agile Management for Software Engineering

David J Anderson (2003)

Precursor, written way before LeanKanban.

Agile; The Good, the Hype, and the Ugly

Agile: The Good, the Hype, and the Ugly

Bertrand Meyer (2014)

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.”

Lean Thinking

Lean Thinking: Banish Waste and Create Wealth in Your Corporation

James Womack (1996)

This is a classic originally written in 1996. I read the 2010 edition. This is one of the early books that attempted to translate the teachings of Taiichi Ohno and the Toyota Production System to make it consumable by western readers. The book explains the five lean principles: specify value, identify the value stream, flow, pull, and pursue perfection. A good and quick read.

Lessons in Agile Management

Lessons in Agile Management

David J Anderson (2012)

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

Taiichi Ohnos Workplace Management

Taiichi Ohnos Workplace Management

Taiichi Ohno (1988)

I recommend this book for Agile coaches such as myself to help understand from where these ideas originated.

Specific Agile Techniques Useful for Software Teams

User Story Mapping

User Story Mapping

Jeff Patton (2014)

The Phoenix Project

The Phoenix Project

Gene Kim (2013)

Event Storming

Event Storming

Alberto Brandolini (2021)

The Unicorn Project

User Story Mapping

Gene Kim (2019)

Specification by Example

Specification by Example

Gojko Adzic (2011)

Lean Enterprise

Event Storming

Jez Humble, Joanne Molesky, Barry O’Reilly (2020)

Release It!

Release It!

Michael Nygard (2007)

Product Roadmaps Relaunched

Product Roadmaps Relaunched

C. Todd Lombardo, Bruce McCarthy (2017)

Show Me the Numbers

Show Me the Numbers

Stephen Few (2004)

FIT for Developing Software

FIT for Developing Software

Ward Cunningham, Rick Mugridge (2005)

The Flaw of Averages

The Flaw of Averages

Sam L. Savage (2009)

Analysis Patterns

Analysis Patterns

Martin Fowler (1996)

Continuous Delivery

Continuous Delivery

Jez Humble (2010)

Exploring the Diversity and Range of Agile Methods

Extreme Programming Explained

Extreme Programming Explained

Kent Beck (1999)

Reading this in 1999 changed the course of our careers!

This is Lean

This is Lean

Modig, Niklas, Ahlstrom,

Par (2012)

Very clear explanation of Lean

The Goal

The Goal

Eliyahu Goldratt (1984)

Lean for manufacturing and physical processes

Scrumban

Scrumban

Corey Ladas (2009)

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

Coaching Agile Teams

Coaching Agile Teams

Lyssa Adkins (2010)

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

Fixing Your Scrum

Fixing Your Scrum

Ryan Ripley (2020)

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:

  1. 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.
  2. The book also includes some new ideas for how to run retros; as a venue to gather ideas regarding organizational improvement.
  3. 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.
  4. The book encourages Product owner to act as an agile product manager; evaluating competitor products, assessing customer information, managing budget, etc.
  5. The book emphasizes the importance of creating a product vision and of deleting anything older than six months in the product backlog.
  6. 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.
  7. 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
  8. The book recommends taking on technical debt immediately when it enters the conversation
  9. 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?
  10. He also recommends tracking work item aging on the sprint board
  11. 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.
  12. 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.
Scrum — A Pocket Guide

Scrum — A Pocket Guide

Gunther Verheyen (2021)

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

  1. Recommends we get away from the word requirement and use “desirement” (desire is too fuzzy and requirement is too detailed and overspecified)
  2. 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

Scrum Insights for Practitioners: The Scrum Guide Companion

Hiren Doshi (2016)

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

  1. Scrum team may invite SMEs to provide input and guidance during sprint planning
  2. Daily scrum outcome might in fact be an updated sprint goal.
  3. Sprint backlog is set of PBIs selected for sprint plus plan for delivering it
  4. Every retro is an opportunity for raising the bar on the definition of edone
  5. Multiple teams must have same definition of done if they are working on the same product
  6. 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

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

Ryan Singer (2019)

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:

  1. 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.
  2. 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.
  3. 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.
  4. Feature canvases are then selected by the same senior team: CEO, CTO, product strategist and senior developer.
  5. Two variants are allowed to vary from the 6-week cadence: R&D and cleanup.
  6. 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!

Exploring the Diversity and Range of Agile Methods

Actionable Agile Metrics for Predictability
When Will It Be Done?

Actionable Agile Metrics for Predictability

Daniel Vacanti (2015)

When Will It Be Done?

Daniel Vacanti (2020)

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

No Estimates

No Estimates

Vasco Duarte (2015)

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

Software Estimation without Guessing

Software Estimation without Guessing

George Dinwiddie (2019)

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.