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 (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: 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:
- establish a sense of urgency
- build a guiding coalition
- establish the vision and strategy
- communicate the change vision
- empower employees for change-based action
- generate short-term wins
- consolidate gains and produce more change
- anchor new approaches in the culture
Team of Teams
General Stanley McChristal (2015)
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.
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.
Information Every Coach & Trainer needs to know
Secrets of Consulting
Gerald Weinburg (1985)
Great Boss Dead Boss
Ray Immelman (2003)
Thinking Fast and Slow
Daniel Kahneman (2013)
Five Dysfunctions of a Team
Patrick Lencioni (2002)
Principles of Product Development Flow
Don Reinertson (2009)
AntiFragile
Nassim Taleb (2014)
Beyond Performance 2.0: A Proven Approach to Leading Large-Scale Change
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.
Training from the Back of the Room
Sharon Bowman (2009)
The Fifth Discipline
Peter Senge (2006)
Slack: getting past burnout, busywork, and the myth of total efficiency
Tom Demarco (2001)
The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty
Sam L. Savage (2009)
Competing Against Luck: The story of Innovation and Customer Choice
Clayton M. Christensen (2016)
Fascinating book explaining how true innovation happens: by understanding the customer’s Jobs To Be Done.
Demand-Side Sales 101: Stop Selling and Help Your Customers Make Progress
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.
Some Books a Little Bit Dated But Still Valuable
Agile Management for Software Engineering
David J Anderson (2003)
Precursor, written way before LeanKanban
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: Special 100th Birthday Edition
Taiichi Ohno (1988)
I recommend this book for Agile coaches such as myself to help understand from where these ideas originated.
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.”
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
Lean Thinking: Banish Waste and Create Wealth in Your Corporation, Revised and Updated
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.
Specific Agile Techniques Useful for Software Teams
User Story Mapping: Discover the Whole Story, Built the Right Product
Jeff Patton (2014)
Event Storming
Alberto Brandolini (2021)
Specification by Example
Gojko Adzic (2011)
FIT for Developing Software
Ward Cunningham, Rick Mugridge (2005)
Analysis Patterns
Martin Fowler (1996)
Product Roadmaps Relaunched
C. Todd Lombardo, Bruce McCarthy (2017)
The Phoenix Project
Gene Kim (2013)
The Unicorn Project
Gene Kim (2019)
Lean Enterprise
Jez Humble, Joanne Molesky, Barry O’Reilly (2020)
The Flaw of Averages: Why We Underestimate Risk in the Face of Uncertainty
Sam L. Savage (2009)
Release It!
Michael Nygard (2007)
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 (2010)
Exploring the Diversity and Range of Agile Methods
Extreme Programming Explained
Kent Beck (1999)
Reading this in 1999 changed the course of our careers!
This is Lean
Modig, Niklas, Ahlstrom, Par (2012)
Very clear explanation of Lean
Coaching Agile Teams
Lyssa Adkins (2010)
Despite the general-sounding title, this is pretty scrum-specific
Scrum — A Pocket Guide, 3rd Edition
Gunther Verheyen (2021)
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.
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:
- 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 (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
The Goal
Eliyahu Goldratt (1984)
Lean for manufacturing and physical processes
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:
- 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.
Scrum Insights for Practitioners: The Scrum Guide Companion
Hiren Doshi (2016)
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.
Forecasting and Metrics
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.
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.
No Estimates
Vasco Duarte (2015)
Fun read full of wisdom. The keynote video on his website is an absolute gem. Unfortunately it is paywalled.
USEFUL LINKSFrequently visited
Copyright 2023 Ariel Partners. All rights reserved.
Copyright 2023 Ariel Partners. All rights reserved.