Agile is a Fractal
Think of an org chart, with its CEO perched at the top, and the hierarchical tree of divisions and departments scattered underneath. The basic shape is that of the triangle, and it has been the prevailing shape of business for a long time. There's something very comforting, very reassuring about the shape of a triangle. It gives us a sense of order, a sense of belonging. Think of the pyramids, the prismatic rainbow. There's a military precision about the triangle. To a certain type of person, the triangle just feels right.
But think of what else the triangle does. It shrinks to a single point at the top. It reinforces a sense of hierarchy, the notion that the grunts on the lower rungs of the org chart are there because that's where they belong. It encourages a fixed rather than a growth mindset. It reinforces organizational silos, together with all the distrust, dysfunction, and moat-digging behavior that typically ensues. Much of the work of Agile is simply an attempt to undo the rigidity of the triangle.
Taylorism and the Rise of the Triangle Mindset
A lot of the triangle-shaped mindset goes back very far in our history — think of the feudal system, with its prescriptions of landed aristocracy's rights over and responsibilities to its serfs and peasants. More recently, in the early 20th century, the work of Frederick Winslow Taylor cast a long shadow over how modern enterprises are managed. To Taylor, workers were like infants who would undermine a company's productivity at every opportunity unless incented, cajoled, or swindled into doing otherwise. To fully appreciate Taylor's attitude toward the working class, one need look no further than his seminal work, The Principles of Scientific Management:
Now one of the very first requirements for a man who is fit to handle pig iron as a regular occupation that he shall be so stupid and so phlegmatic that he more nearly resembles in his mental make-up the ox than any other type. The man who is mentally alert and intelligent is for this very reason entirely unsuited to what would, for him, be the grinding monotony of work of this character. Therefore the workman who is best suited to handling pig iron is unable to understand the real science of doing this class of work. He is so stupid that the word "percentage" has no meaning to him, and he must consequently be trained by a man more intelligent than himself into the habit of working in accordance with the laws of this science before he can be successful.
Underlying nearly everything that Taylor writes is his belief, spelled out in detail, that the common laborer cannot be trusted with the work he or she has been tasked to perform. His thinly-veiled distaste for his workers undermines his routine protestations that both labor and management will benefit from adopting his regime. Needless to say, Taylorism is completely antithetical to the Agile mindset. However successful Taylor may have been in guiding factory workers engaged in routine, repetitive labor, his ideas fall flat in a knowledge economy. In Agile, it's a given that the individual contributor knows more than his or her leadership, and must be consulted an included in any commitments the team makes. And yet how many self-professed "Agile" shops still treat their workers like petulant infants who need to be "managed"? The triangle is deeply embedded in our habits, and Taylorism still lives in the hearts and minds of managers everywhere.
The Agile Fractal
The shape of Agile never really occurred to me until I studied Lean UX, Test-Driven Development, and SAFe at the same time, and I realized something that Dean Leffingwell and other contributors to SAFe baked into their attempt to scale Agile frameworks like Scrum up to every level of an organization. I will leave aside, for now, the question of whether or not SAFe is the best Agile scaling framework; as a confirmed Agile Agnostic, I find that question deeply uninteresting, for reasons I may get into in a future post.
What is fascinating in SAFe is how much the work at the top resembles the work at the bottom. Your individual developer, using TDD, creates a mini-hypothesis on how the system ought to work, and then creates code to prove out that hypothesis, with the unit test written in the process giving immediate feedback. A development team working through an iteration uses this approach to put together a set of stories, which themselves have a set of acceptance criteria, which serve as another hypothesis at a larger scale. Proving out a set of stories will eventually roll up to an entire feature, which will in turn become a capability, and then an epic.
The code resulting from this hypothesis will be rolled out to production using Continuous Integration and Continuous Deployment (CI/CD), which create their own learning cycle. Once the code is in production, product managers can use A/B testing to prove out their own hypotheses around business outcomes, and at the C-Suite, metrics from these outcomes will be used set the priority for the company's entire portfolio, and will spawn new hypotheses that will eventually reach down to the individual developers. The resulting virtuous cycle of learning and improving continues pretty much until those involved decide to retire or seek employment elsewhere.
In place of the hierarchy-reinforcing triangle, SAFe proposes a system where every level of an organization has a prioritized backlog, a system for testing out hypotheses, and a process for capturing and using any lessons gathered from any previous step. Such self-resemblance of a given pattern throughout and at every scale is best understood as a fractal. In the fractal, you are never "lower" than your colleagues. Rather, you merely have responsibilities in another domain. Those responsibilities might incorporate one or more smaller fractals, but there's no status, and no chain of command. Rather there is organic growth, a replication of what worked before to new domains. Where the triangle is infantilizing and demeaning to those at the bottom, the fractal is liberating to everyone, not least to top-level executives, who can now relax and trust that teams throughout the organization are aligned to the strategic mission, and are doing their jobs.
This image helps to explain both the Agile mindset, and why so many organizations fail so badly at Agile transformation. The same sort of person who finds hierarchy reassuring will be deeply confused, perhaps even angry, when asked to adopt a fractal thought pattern. You will often hear that Agile is communist, or that it is some kind of brainwashing hippie propaganda, when in reality Agile is the best recent idea capitalism has to offer. We have been conditioned by the triangle to expect a predictable pattern of abuse in our organizations, so the idea that offering people respect, autonomy, and purpose is actually the best way to make money is a huge pill for some folks to swallow. Confronted with empirical data, your committed triangulist will reply with something like, "I don't care what the research says; I know you're wrong!"
Any organization with a preponderance of triangulists will respond to an Agile transformation by trying to reassert a triangle-shaped dominance. They do so not out of any ill-will, but because they literally cannot see the alternative, even after it has been spelled out for them. The fractal is a fragile thing. It will fall apart if not properly cared for. So when you hear horror stories about how badly Agile has failed a given company, be very skeptical. Chances are that a triangle brigade within the company strangled Agility in the crib before its transformative power could be realized.
But that's not the final story. Just as Feudalism gave way to Monarchy, and then eventually to Democracy, it's entirely possible for our organizations to improve and change, even if that change is imperceptibly slow. We, as Agilists, must be patient. We are playing the long game here.