Agility Language

Agility is the degree that you can rapidly sense, adapt and succeed in changing situations and uncertainty. As technology and society advances ever more rapidly, our agility defines our success. And so, some of the best and most well-known companies, celebrity, politicians, and countries are extremely agile—they encounter problems and, unlike their slower-moving competitors, they very rapidly adapt and thrive.

You, your team, and your company can be more agile. You can use agility personally to achieve celebrity, or just establish a great reputation in your field. Your team can use agility to produce more value faster. Your manufacturing plant can use agility to reveal sources of  Your company can use agility to discover customers, adapt rapidly as laws change, technology mature, and competitors emerge.

Unless you want to learn the hard way, it’s probably useful to learn how others did it. One way to convey a field of knowledge deeply is to organize it into something called a pattern language. Christopher Alexander used a pattern language to describe the fields of urban planning and architecture.

Agility as a language that can be used by almost anyone exploring a new challenge. You use similar words, whether you build cars, design websites, write software, or organize students, similar words and concepts help. It is a pattern language, where each approach is represented by a pattern.

Agility includes a bunch of related practices that have different names and operate in different fields—agile development, Scrum, Extreme Programming, Lean Startup, DevOps, Design Thinking, Lean Manufacturing, Getting Things Done, Pomodoro, Beyond Budgeting are all practices that help you achieve higher agility. You can use all of them simultaneously; they are largely complementary. For example, if you use Lean Startup to design products, you’ll get better results if you’re working with a development team that uses Scrum.

I have studied all these agile techniques, in depth. I have taught large companies, small startups, teams, and individuals how to use them. They became more successful and more productive as a result. One executive complained she had not seen any improvement, so I made a study of release frequency over a seven year period: during the time that we weren’t using agile methods, our release frequency declined from every 6 months to every 24 months. Upon adopting agile methods our release frequency, customer satisfaction and market share all improved dramatically, to be better than at any previous time. I published the results [gree2011].

These practices are organized in a pattern language. A pattern language organizes patterns hierarchically to help you rapidly learn gross fundamentals first, then subtleties later. So, if you’d like to understand agility generally, read the Agile pattern, which is the first pattern in the Agility pattern language.

Every pattern in this blog starts with an leaf icon and a pattern name, like this:

Measure What Matters

The pattern name is either something well-known already, or something easy to remember.

The description starts with a Context and a Problem. If the context and the problem seem to match your context and problem, the pattern will likely help you. If the context and problem don’t match yours, maybe there’s another pattern that does.

To understand pattern languages generally, see How to Read and Write Pattern Languages.

Click on any of the titles below to see each pattern.

  • Agility

    Context: We have a goal requiring creative effort. We want to succeed.

    Overplanning increases risk …

    When embarking on a creative project, success seems certain. We plan optimistically, and then almost immediately after we start, delays and challenges emerge. The plan and likely outcome keep diverging. We become more realistic. We double down on effort. We plan with more detail, but encounter even more problems.

  • Align to a Driving Purpose

    People are working. Their efforts should produce something important. But…

    Unfocused activities produce poor results

  • Limit Work in Progress

    Context: We measure progress and experiment with processes and products. However, experiments can take a long time, and failures can have huge costs. We have a lot of balls in the air, a lot of inventory to sell, and a lot of great stuff that isn’t quite done yet.

    We have a problem …

    We adapt too slowly …

  • Measure Progress with Leading Indicators

    Context: We can study others who succeed, imitate their activities and gain their skills. But these activities create nothing new. Once we have reached their capabilities, how do we know if we’ve improved?

    Completion metrics distract us from incremental improvement …

  • Experiment to improve

    Context: Plenty of data informs us. We can forecast when things will happen. Our progress metrics are aligned with long term goals. But externalities impede our progress: competitors emerge, delays harm us. We are passive victims of outside circumstance.

    Passivity until risks are revealed can be too late …

    We suspect unknown dangers, economic loss, and growing ineffectiveness. Our friends reassure us, choosing their words carefully. Existing data is eerily stable. We aren’t learning anything new.

  • Embrace Collective Responsibility

    Context: It takes us time to decide to fix problems, and we let some problems fester because we don’t want to get anywhere near them. When we are on a team, we can blame someone or something else for a problem, and often do. We might blame our own permanent flaws for a problem, feeling guilty. None of this blaming seems to fix anything, but we stick to our comfort zone. Pitching in to fix problems can associate us with the problem and put us in danger. It might be a tar baby.

    We delay improvement by avoiding responsibility, leaving problems unresolved…

  • Fix Systemic Problems

    Context: When unimpeded by outside forces, we rapidly adapt to circumstances and succeed, but this perfect independence rarely exists.

    Problem: External factors limit our flow …

    We don’t have the knowledge, specialty resources, elasticity or authorization to do everything ourselves, but relying on others puts us at risk.