Agile is not magic


Agile and Cloud Computing isn’t magic.

TLDR: A given technology or process is not going to fix your digital woes. Because the real problem is culture. Culture drives process, which in turn drives technology. Not the other way around.

As you know, Kessel Run was as simple as buying some cloud platform and sprinkling it with ‘Agile DevOps’ right? Those things are magic!

Wrong. Agile processes and Cloud Software are not magic (and neither is scaling them).

The Defense Inovation Board came out with a report: Detecting Agile BS. Which pointed out that too many offices are claiming to be “Agile” but are in fact just BS’ing. But there’s another problem, perhaps more dangerous than Agile BS: it comes from leaders touting Agile as if its “Magic.”

Here’s the problem:

Admitting that Kessel Run was not magic, and instead the result of a change in culture and thousands of hours of effort is problematic for two reasons:

  1. If it’s not magic, then everyone else could have done this all along, which makes status-quo leaders look bad.

  2. It means everyone who hasn’t put in the thousands of hours of deliberate practice can’t take credit for the achievement and are not qualified to lead it.

Leadership will attempt to scale KR’s success by parachuting in the ‘brightest leaders’ and telling program offices to “become Agile” without regard to people and culture. Which may make the culture problem worse.

This stems from perpetuating the myth that cloud and ‘DevSecOps’ are some new magic and that scaling Kessel Run’s successes is something anyone can do if they buy the right tech and get the right Agile certifications.

The Explanation

Unfortunately, there is no escaping the Mundanity of Scale in the real, non-magical world. Scale is the aggregate of thousands of hours of deliberate practice. Hard work by gritty people, and their growth rate determines the growth rate of the entire program.

This means, leaders, that you require deliberate practice, too. Or at least this understanding:

That “experienced” 18 year senior service member you want to parachute in has zero hours of deliberate digital practice (or contracting for it) while that “inexperienced” six year junior service member now has thousands of hours.

When it comes to growth rate, the collective team skill x effort = collective achievement. The status quo method of scaling actually lowers collective team skill immediately by the insertion of unqualified leaders and by dilution, as well as over time by the pathological, non-growth culture they bring.


Focus on culture, and scale people first . As individuals grow, leaders and expert practitioners will emerge.

If an organization wants to be agile, then it must adopt the agile culture and its values. Use mitosis to grow your organization. Use the gritty guys who put in the thousands of hours to grow your current effort / spin off, and remember that rank is just a pay scale. Don’t assume time in service = better qualified.


Excellent post! It easier for Consultants to sell leaders on training a tool or process to “do Agile” than change the culture become an agile organization.

If you haven’t seen it, this was an amazing thread about a Hertz software project disaster:

1 Like