Scaling Agile is hard. Here’s why.

Posted on January 10, 2017.

I went to Barcelona on my holiday last month. Apparently that’s where Santa goes too in the offseason AND he’s a Barça fan.

This post was originally published to my newsletter subscribers (10k of them now). If you’d like to get these updates via email sign up here.

Last year I worked with an executive team charged with leading an org-wide Agile transformation. For those of you who have done executive coaching work, you know how hard it is to wrangle a group of highly intelligent, successful leaders, all with a specific area of expertise, in the same direction. Victories are small but meaningful. In our engagement, one of our biggest wins came when the team leader (the president of the business) left one of our sessions and announced to his direct reports, “Agile is hard.”

It’s hard to overestimate the impact those 3 words had on the teams that heard them. They already knew Agile was a challenge but to hear it from their leaders provided perceived breathing room for further struggles, learning and improvement.

Their president, of course, was right. Agile is hard to implement. Even more difficult is implementing it at scale. The methodologies many companies are adopting to deal with this challenge, like SAFe (the Scaled Agile Framework), offer tactical shifts in the way teams operate while offering leaders a fairly familiar list of tasks that do very little to take advantage of any new-found organizational agility. This list of tasks centers on questions about production — how much “product” have we shipped so far and how can we ship more of it more quickly? There is a perception that if we can only scale the delivery of features we will be able to scale customer value.

The reality is that at each level of your organization — project, program, portfolio — the questions that Agile helps answer change. Very few of these questions focus on production. Sure, we want to get new ideas out the door faster but our goal is learning — first — and then delivery at scale. There is no point in scaling a feature that delivers zero value. As the questions change with the scope of the people and work being managed, the success criteria for those questions also change.

Here’s an example of the right questions to ask and how to measure success at each level of the organization:

Project/team level: Are we solving a real problem for a real customer in a meaningful way? What measures of customer behavior will tell us that this is true?

Program level: Now that we’ve found something that customers value, is the market big enough for us to invest in this effort? Can we as a company support this kind of growth? What market evidence will we look for to help us determine that this program warrants further investment?

Portfolio level: We’ve found something customers love in a market big enough for us to pursue. How do we scale? How do we continuously improve? How do we stay competitive? What is our market share? How does customer feedback correlate with their behavior? How do we know our competitive differentiation is still relevant?***

Investment and scale of work should not progress unless positive answers can be proven for each level. But, as initiatives grow, the Agile framework that manages the growing teams’ efforts should regularly return to these core questions to determine focus, prioritization and ultimately success.

***It’s worth pointing that each of these questions asks a question about customer behavior — an indicator of value. None of them focus on production quantity.

This is why scaling Agile is hard. It’s not a matter of how many release trains you spin up but more a matter of aligning those trains towards discovering the answers to the questions I noted earlier. It’s in these customer-centric alignments that teams truly harness the power of self-organization and agility.

This post barely scratches the surface of Agile at scale but it gets the conversation started. What have you seen work? What have you seen fail?


— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Book News

Sense & Respond — our new business book — goes live on Feb 7.

Sense & Respond comes out in less than a month! If you’ve been waiting to pre-order, do so now. It makes us look good to our publishers and, more importantly, we’re excited to hear your feedback on this important book.

This book is for leaders looking to build agile companies and teams that support a customer-centric, evidence based approach to management. Once you’ve had a chance to read it we’d be grateful for your reviews on Amazon.

Josh & I will be hitting the road to promote Sense & Respond in late March in Europe. We’ll be visiting Norway, Lisbon, London, Copenhagen and Madrid. If you’d like us to visit you, let us know.

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

Upcoming Events

You should join one of these events:

Ask Me Anything — Jan 11, 2017 — FREE — Online, with my friends at

New York City — Jan 17, 2017 — $5 — Agile Experience Design Meetup

Richmond, VA — Jan 19, 2017 — FREE — Lean UX 2nd Edition Book release party at Carmax

New York City — Feb 7–8, 2017–2-day Certified Scrum Product Owner Course with Jeff Patton. We’re 75% sold out here. Don’t wait to get your ticket. This will sell out.

Pittsburgh, PA — March 14, 2017–1 day Lean UX in the Enterprise Public Workshop (Early bird prices on now)

— — — — — — — — — — — — — — — — — — — — — — — — — — — — — — —

As always, if you want me to work directly with your company on training, coaching or workshops, don’t hesitate to reach out.