Agile CanonAgility 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 can be agile. You can achieve celebrity, or just establish a great reputation in your field. You can lead a company, civic organization or society to success. But unless you want to learn the hard way, it’s probably useful to learn how others did it.
This Agile Base Patterns category synthesizes and organizes fundamentals that are present in virtually all related frameworks. They 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, Theory of Constraints. They are all practices that help you achieve higher agility, and they borrow from each other. 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, the average time between releases increased from 6 months (when it was a startup) to 24 months (years after it was acquired). The company was on the road to failure. Upon adopting agile methods the time between releases dropped below 3 months. Customer satisfaction and market share all improved dramatically, to be better than at any previous time. The company was saved, and agile saved it.
These Agile Base Patterns are a stand-alone pattern language. A pattern language organizes patterns to help you rapidly learn 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 and the summary. The remaining patterns in this category (five as of this writing) form the second layer of the pattern language.
Every pattern in this blog starts with an leaf icon and a pattern name, like this:
Agile
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.
Context: We have a goal requiring creative effort. We want to succeed.
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.
Context: People are working. Their efforts should produce something important.
Context: We measure our economic 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 …
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?
Creative efforts operate in an economy, a system where people manage limited resources to maximize return and growth. Economies drive everything. They need not involve currency. We can measure philanthropic efforts by the number of lives saved per unit of volunteer effort. We can measure companies by price-earnings ratio, market share, civic contributions, employee welfare, or religious conviction. We can measure artists by profit per work hour, the number of event attendees, the number of references on a social network, the devotion of fans, the artist’s technical improvement, the artist’s personal satisfaction, or the political effect of the artist’s message.
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.
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.
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 are responsible for an outcome if our action or inaction affected it. People assert we are “responsible for a failure,” if we could have prevented it. We assert we were “not responsible for a failure,” if we were not authorized or equipped to prevent the problem that caused the failure. People characterize us as “a responsible person” if we act to prevent or recover from failures.
Context: When unimpeded by outside forces, we rapidly adapt to circumstances and succeed, but this perfect independence rarely exists.
We don’t have the knowledge, specialty resources, elasticity or authorization to do everything ourselves, but relying on others puts us at risk.