Originally posted by Jurgen Appelo at https://medium.com
Without a doubt, Agile development has been one of the most successful global movements in the landscape of business in the last decade. But the growing Agile community has encountered issues with its own values and principles. There are cracks in the Agile foundation.
Mainly in the last five years, we have witnessed an ongoing conversation about the “problem” of scaling Agile development. Book after book, conference after conference, and framework after framework are dedicated to addressing this problem. It is understandable, because a mindless adoption of the values and principles as offered in the Agile community’s fundamental document, the Agile Manifesto, inevitably leads anyone to conclude that Agile doesn’t scale. At small scale, Agile is great. At large scale, Agile is stupid.
Please note that I distinguish capital-A Agile, as it is laid out in its Manifesto (capital-M) versus lowercase-a agility, a powerful attribute of complex systems.
Bottom-up Rules Over Top-down Constraints
Originally, capital-A Agile means favoring individuals and interactions over processes and tools. That’s great! But a focus on individuals and interactions is easy when you’re just 7 people. How can you do that when you’re 70,000 people? Can you work in an agile way with 1,000 Agile units of 7 people in parallel? System laws suggest that shared rules (processes and tools) are crucial for the emergence of creative patterns at a larger scale. The question is, “Where do these rules come from?” Top-down processes and tools as imposed constraints are usually not agile, while emerging patterns of structured collaboration usually are. From a systems perspective, agility means bottom-up rules over top-down constraints.
For example, it is impossible for 70,000 employees to collectively interact and be creative without source control, wikis, recruitment procedures and security policies. But agility means you allow the best tools and processes to emerge. Benevolent peer pressure instead of malevolent hierarchical control.
Holistic Development Over Schismatic Thinking
Originally, Agile means working software over comprehensive documentation. Sound good. Indeed, on minor projects, the quality of the product could have priority over the quality of the paperwork. But what if your product has the size of Netflix? Or Amazon? Or NASA? Information about the product cannot be easily maintained anymore when the product gets too large. And unmanaged data can ultimately destroy a product. The only way of dealing with this is to consider the metadata as part of the data. The product is executable and readable information. It is all part of the same thing! Instead of a divisive approach, judging metadata (text) to be inferior to actionable data (code), it is better to aim for a more holistic approach. What agility should mean is holistic development over schismatic thinking.
For example, to reliably and flexibly grow and expand an enormous code base, the descriptions of interfaces between subsystems should be in source control too. User documentation could be generated from source files. And all data about team members, user stories, builds, and releases should be considered part of the ever-evolving product itself.
Positive Communication Over Negative Assumptions
Originally, Agile means customer collaboration over contract negotiation. This is based on the (correct) idea that trust is better achieved through close personal interaction than formal remote methods. Again, this makes sense at small scale, but not at large scale. Our brains are not wired to trust 100,000 customers at the same time, and therefore we don’t. Large populations without law and order usually degenerate into chaos because there is no law book, no safeguard against our distrust of anyone except our close friends. Instead, what we want is positive communication over negative assumptions. A cheerful but firm rule communicated to 100,000 customers, accompanied by a mild disciplinary fall-back scenario, actually generates more trust than either trust-everyone-style collaboration or trust-nobody-style negotiation.
For example, agility should mean that you start with as few rules as possible, telling everyone in your community that you trust them to do the right thing. However, you also create fallback scenarios for misbehavior, and only when the need arises, you communicate new rules, but in a good-natured way.
Scaling Out Over Scaling Up
Originally, capital-A Agile also means responding to change over following a plan. Again, being nimble is not so hard when you’re small. But the laws of complexity clearly suggest that big systems are slower to evolve than small systems. There’s a short-term competitive advantage to being big, but a long-term competitive advantage to being small. You can get the best of both worlds by being something that merely looks large, but is in fact many small things working together. However, most organizations don’t plan for continuous reorganization. That’s why they end up with structures that don’t scale. The issue is not favoring change over plans. The real issue is a lack of planning for scaling out over scaling up.
For example, even though large animals live longer than small animals, the large species go extinct more easily than the small ones, because they cannot adapt fast enough. Likewise, your product should be managed as an ecosystem of many small projects, instead of one big framework. It will live longer that way.
Agility Scales, Agile Doesn’t
There you have it. Scaling Agile is indeed a problem, because the Manifesto doesn’t scale in the first place. It was intended to describe small projects, not large enterprises.
However, agility of complex systems is nothing new. The global economy is one giant complex adaptive system. (And in the last decade we’ve all noticed it can be quite agile!)
It is not people over processes but bottom-up rules over imposed constraints. Not working software over documentation but holistic development over schismatic thinking. Not collaboration over negotiation, but positive communication over negative assumptions. It is not responding to change over following a plan but scaling out over scaling up.
When defined this way, scaling agile is a no-brainer. Of course agility scales! It’s just the Agile Manifesto which doesn’t. It was never meant to.
Jurgen Appelo is Europe’s most popular leadership author, listed on Inc.com’s Top 50 Management Experts and 100 Great Leadership Speakers. His latest book Management 3.0 #Workout, full of concrete games, tools, and practices, is available as a FREE pdf, and in paperback, Kindle and ePub versions. Get your copy here: http://www.management30.com/workout
