Scaling Like Organic Systems

A System

A system – as we will define it – consumes resources and energy to produce something that is more than the sum of its parts. Not only does is produce value it does so in a way that sustains its own existence. If we consider Henry Ford’s early Model-T production system that assembled automobiles, the raw materials – rubber, coal, plastic, steel – were meaningless as an unformed heap. Along the way, the “intrinsic” economic value of the raw materials were destroyed and could no longer be sold for their original price as raw materials. At the time, there would have been no resale value for many of the assembly pieces, because Ford created an entirely new value network and disruptive business model to create a market that could properly assess the value of the non-luxury automobile. Yet, once assembled, the assembly line put these pieces together to create value greater than the sum of its parts.

An example of a relatively simple organic system is a single-celled organism like some species of Plankton our oceans. A plankton lacks sophisticated embryogenesis, there is no differentiation of multiple tissue types, no embedded systems, and no coordination mechanism across cells. Nevertheless, the simple biochemical processes and the internal workings that complete these processes have continued for billions of years by not only producing its own self-maintenance, but also by managing to reproduce. There is a surprising large amount of DNA for such a simple, small, organism – but why did this legacy of code begin amassing in the first place? Whether we venture to call it “divine” or not, there was certainly a spark of some kind that began an explosion that has yet to collapse back into chaos and the dark.

Even with these simple systems, where we can trace each exchange in the value-transformation process, including materials, structures, energy, and ecological context, the sum total of the Model T and the factory that produced it is more than its parts heaped separately in a pile. Our difficulty in understanding such systems is a problem of multi-fractal scaling. For now, let it suffice to say that making a variable in a system better may not result in a linear change in outcome.

 

A Complex System

We have major issues understanding how (or worse yet, why) a system consumes resources and energy to produce value in excess to the sum total of the elements and energy amassed in the absence of the system that produced it. This problem is only compounded when we begin embedding specialized sub-systems within an organism. In the example of an automobile factory, we could say that every cell of every person is a system, that each person is a system, and that each distinct functional area, separated by distance, is a system. The accounting and finance “system” and the inventory and assembly “system” must interplay as part of Ford Motors, a system in its own right.

So we can define a complex system as having embedded sub-systems, causing the observer to not only see that the whole is greater than the sum of its parts, but the observer may also slip into a “confusion of levels” if they attempt to manipulate a part of a system to shift the outcome of the whole. Worse yet, confusion of levels can have disastrous, non-linear results that are the opposite of the intended change due to confusion of cause and effect. When sub-systems are embedded within each other, their interrelationships may act on differing scales, either in time or place. So we must careful when attempting to improve a complex system. We must use empirical process control to chart the change in systems outcomes rather than simply optimizing subsystems in isolation.

 

Multi-Fractal Scaling

A fractal is a pattern that repeats self-similarly as it scales. One of the most common fractal scaling patterns in nature is branching. From the trunk of a tree, to major its major limbs, to twigs, and finally leaf structures, this fractal scaling pattern enables a lifetime of growth cycles. Leaves can bud purely based on opportunism, in a relatively disposable manner. This is because the tree, as a seed, has all the legacy of generations of trees locked inside it. The tree does not aspire to be “the perfect tree” or assume that it will grow in perfect sunlight, humidity, soil pH, and water availability. The tree does not get angry when a major branch is broken off in a storm or struck by lightning. Instead, its fractal scaling pattern is prepared for intense competition for sunlight in the sky and resources from the ground. The tree’s scaling pattern has risk mitigation “built in” because it grows the same in the middle of a field with frequent rain as it does in a dense forest.

We see this branching strategy throughout nature, from ferns to human blood vessels. However, an even more effective approach to self-similarity comes from multi-fractal scaling. The ability to adaptively select between more than one repeating pattern or differentiated patterns based on scale requires a different kind of fractal: time-cycle. It is not just the branches of a tree that result in an environment-agnostic strategy for growth, it is the adaptation to cyclical daily growth, scaled to cyclical annual growth, than scaled to multiple generations of trees that grow. This final step is an important one. Multi-fractal scaling is not only the source of novelty and adaptiveness “built in” for a single tree, it repeats at an even larger scale as a species competes for dominance of a forest. Multi-fractal scaling encourages “just enough” opportunism to enable small-scale experiments that can be forgotten without loss at a greater scale, or thrive when conditions change.

 

Adaptive Multi-Fractal Scaling

The strength of multi-fractal scaling, from branch to tree to forest, is its total reliance on empirical process control.  The legacy code is a confusing jumble of competing messages that a human mind, attempt to “engineer a perfect tree” would attempt to simplify and beautify. That legacy code, however, wasn’t written with any intention of crafting a perfect tree. That code was written to create a minimally viable reproductive system. It is built for one thing: continuous experimentation.

Continuous experimentation happens at each level of multi-fractal scaling, risking economics appropriate to its scale to find asymmetric payoffs. An Oak tree risks very little per leaf that grows over the entire course of its life. In a dense forest, however, that continuous experimentation of growing leaves higher and more broadly opportunistically based on local returns on investment can suddenly break through the forest canopy or unexpected fill the hole left by another tree’s broken limb. An Oak tree does not require centralized control of where leaves will grow or which limbs to invest in. Instead, the legacy of continuous experimentation enables multi-fractal scaling that competes locally and opportunistically.

Again, we do not need to understand what spark set this fire ablaze, we only need to see that it is still spreading and we are a part of it. Over-simplification of superficial outcomes will lead to poor decisions about inputs. Organic leadership relies on context, structure, and enablement of continuous experimentation. Organic leadership is a “pull” system that relies on scaling patterns for decentralized empirical process control. Artificial “push” systems force requirements and attempt to bandage the inevitable inefficiencies of a non-adaptive system.

 

A Complex Adaptive System

A complex adaptive system does not merely take in resources and energy to produce itself and reproduce itself as a unified “whole” that is greater than the sum of its parts. It does not merely embed subsystems with multi-fractal scaling and decentralized control. A complex adaptive system also operates with a continuous experimentation system built in to its normal framework of activities. When we make the leap from an Oak tree to the human body (or any other mammal on Earth), we can truly appreciate just how complicated it is to improve the health of an individual, or an entire population, when we observe the interrelationships of various physiological and socioeconomic systems and sub-systems. Creating lasting change is not only complicated in terms of finding the correct level and understanding the full ramifications across the entire system, each complex adaptive system is also continuously experimenting and will adjust against such changes based on short-run, local, decentralized opportunism.

To care for a complex adaptive system requires not only an understanding of inputs, processes, and outputs, but also the multi-fractal scaling of continuous experimentation that maintains long-run viability. When short-run economics are working against long-run viability, it is not sufficient to reward “correct” behavior to counteract short-run opportunism.  Instead, we must shift the context of local decisions so that short-run opportunism serves long-run viability.

Accidents Will Happen

Accidents may seem to the observer to be unintentional, but continuous experimentation is built to test the boundaries of success, to ensure that precise empirical process data is also accurate for the needs of viability. In other words, if you’ve ever accidentally tripped and fallen, or accidentally loosened your grip on an egg and dropped it on the kitchen floor, this was a natural element of complex adaptive systems quietly running experiments.

Embedded in our own human code, our sub-systems are all built for continuous experimentation as a method of calibrating precision to accuracy, using multi-fractal scaling on short, long-short, long, and distributed cycles. A short cycle is an immediate reference point for an event, using data held in working memory, and is reactive to immediate changes. A long-short cycle compares current data to immediately recognizable patterns of events, more embedded memory or conditioned responses that have proven useful over time even if we assume the event is an occasional outlier. More significant, painful events can skew our “normal” for decades and even become passed to the next generation as part of our genetic code. A long cycle has been stored to our genetic hard drive for future generations. A distributed cycle is a socioeconomic artifact that requires a medium of exchange and may last for centuries.

As humans, our multi-fractal scaling of continuous experimentation results in the creation of complex adaptive socioeconomic systems. Our legacy code drives us toward exchange, tooling, building, and reproduction because the experiments that are in motion are far from complete.

Like our occasional fumbles and falls, our social systems produce results that appear to be accidents with no guilty party, pure coincidences of circumstance, which occur due to failed experiments. Organic leadership harnesses this natural propensity for decentralized opportunistic experimentation by encouraging it but setting boundaries for it, feeding it but ensuring checks-and-balances from opposing interpretations, and guiding it by changing context and opportunity rather than directly managing outcomes.

Orienting is Essential to Agility

Responsiveness and disruptive influence are the cornerstone of agility, because change through continuous experimentation is fundamental to life. Healthy and viable systems maintain their complexity far from equilibrium, relentlessly fighting collapse and death. After all, “poised” on the brink of chaos, there is an obvious business definition for agility:

Responsiveness to signals in a market with imperfect information and imperfect competition.

This context necessitates process control that keeps identity and novelty in constant tension – even against our most brilliant ideas. Thus, our tactical principles for general preparedness, quick orientation, and powerful responsiveness will be rooted in the need to orient faster than the enemy system, our ideological competition. Only the working product of our efforts can provide a pragmatic judgment of the value we have created, so the ultimate measure of our success as a Disruptive Influence is the actual change in behavior we have caused.

Because individuals and interactions are inherently complex, adaptive, and difficult to predict in the reality of socioeconomic competition, we value knowing them directly, studying them and interpreting their position ourselves. We value this over relying on their predictability, likelihood of adherence to an agreed-upon process, or correct use of the best possible tool for any given job. Although we assume processes and tools taken at face value will deceive us into a false sense of stability, we also recognize that individuals and interactions cannot always be taken at face value either.

Because responsiveness, both in decisiveness of action in an unexpected situation and as adaptation over a long-term investment horizon, will consistently be awarded with asymmetric payoffs, we can only trust a plan to the extent it includes contingencies, delays commitment, and distributes control to the individual with the best understanding of the situation at the time a decision must be made.

Because compromise is the inevitable and unsavory outcome of “contract” negotiation, while creative endeavors in contradistinction rely on the energy of tension, cognitive dissonance, intra-organizational paradoxes, and conflicting interpretations, we invest our time and effort in social exchanges while delaying formalization. A contract relies on an external locus of control for its power and validity, whereas we must prioritize a social and socioeconomic view of the complex system we hope to lead into adaptation.

Because a socioeconomic “factor of production” is defined by its output, evaluated on how much more value “the whole” can add in excess of its “parts”, and because digital products are continuously created and maintained but never mass-produced, we take the tangible product of our endeavors as the only valid measure of its worth.  However good the product design looks on paper, however well-defined the future state is documented, only exchange in the marketplace can determine the economic value of the product we have actually created

Do Project Tasks go in a Scrum Product Backlog?

I get this question frequently when training agile and scrum teams:

Do Project Tasks Belong in a Scrum Product Backlog?

YES.

Since answers to this question I have seen in chatrooms are typically insufficiently argued as part of a crazed political debate full of comments taken out of context, this very pragmatic question deserves a bigger picture answer – because the need to ask the question is a symptom of a stagnating transformation.

A successful shift from stage-gate or waterfall development processes to agile, Scrum, or Kanban requires a fundamental change organization-wide: from maximizing ROI and shareholder value to maximizing Economic Value Creation and sustainable competitive advantage. If this shift does not occur, the improvements gained from agile practices will inevitably stagnate.

Jez Humble refers to this state as Water-Scrum-Fall, that unfortunate state where most agile and DevOps initiatives plateau.

Most often when I talk to development teams, Product Owners, and ScrumMasters, this is often blamed on a lack of executive buy-in.

I completely disagree.  

I have also blamed a manager or two for the imperfections in the agility of a company, so I can relate to this view. To show you why you might not even want executive sponsorship, let’s revisit the view of a corporation as a minimum viable superorganism.

Complex Adaptive Systems Leadership

A corporation is not a machine with various parts to replace or maintain in isolation, it is a superorganism. It is a biological phenomenon that is not sufficiently explained by social contract theory or through monetary theories of motivation. Judgments about this reality are very easily clouded. Unfortunately, once measurement and monetary incentives change the natural behavior of the superorganism, it is difficult to change back – making it easy to fallaciously claim this as proof of their effectiveness.

Quantum physicists have suggested that undisturbed systems in the universe naturally stay in multiple states simultaneously, unless someone intervenes with a measurement device. Then all states collapse, except the one being measured. Perhaps what you measure is what you get. More likely, what you measure is all you get. What you don’t (or can’t) measure is lost.  – H. T. Johnson, “Lean Dilemma”

So when you hear “We need more buy-in from management” this is absolutely incorrect.  It is even counter-productive!  Adaptations by a complex system, that disruptive creativity and innovation agile champions desire, can only occur through organic, emergent leadership – a tribal, heretical rebellion. Adaption to a new stimulus may have a focal point, a “leader” who organically builds up energy in a new direction – but this leadership is an emergent property the complex system. In contrast, formal leadership (“management”) is a crystallization of a complex system, an attempt to reinforce a desired “normal state” – a force that exists counter to emergent leadership and adaptation. By default, formal leaders at all levels of an organism are incented (through power, money, and Agency Dilemma) to maintain homeostasis – i.e. the status quo. Even if a formal leader becomes the emergent leader of adaptation, this will be odds with her formal leadership. Unless she is willing to risk the loss of formal leadership, she will dissolve her capacity for emergent leadership and resume promotion of homeostasis – no matter how much it dampens creativity, innovation, and sustainable competitive advantage.

Evolution of a superorganism through disruption – whether a lean or digital or agile “transformation” – cannot occur if any one piece of the system is optimized in isolation from the whole because any superorganism, as a complex adaptive system, will exert tremendous energy to maintain homeostasis. The larger the superorganism, the more likely that optimization of one function or team will result in a net loss of desired adaptation (whether the desirable “adaptation” is called innovation, process improvement, or “growth”).

So, when a formal leader blesses a piloting of lean and agile practices by a completely isolated team, this is the superorganism equivalent of a mother’s amniotic sac – the team can establish itself as a unique complex adaptive system while in isolation, fed by the resources of the maternal superorganism but shielded from the homeostatic processes of the parent system. The moment this new team is re-integrated into the larger system, continued adaptation is unlikely. The company attempts to spread the innovation and creativity culture they achieved but instead can only formalize a shift in a subset of practices.  These practice, outside the context of psychological safety, a well-formed collaborative team, flop. No single activity of the pilot team will have the same value implemented outside the context of the pilot team’s “bubble” that safeguarded it against the homeostatic forces of the superorganism!

But wait – what about that “net loss” in innovation, creativity, and efficiency I claimed?

In practice, a company that adopts an agile process (let’s say Scrum) as a change in behaviors isolated to the teams developing software causes the rest of the system to expend energy maintaining homeostasis, and even more energy wasted by agents accommodating these homeostatic forces so that the development teams can preserve their no-longer organic place in the system.

I think you know exactly what that looks like:

  1. Updating documentation processes without seeing them as “artifacts” that emerge from an adaptive process rather than social contracts that require formal sign-off.
  2. Replacing one tool with another, causing a new set of employee workarounds to occur.
  3. Increasing frequency of software releases without changing the size of organization commitments.
  4. New meeting names that don’t change communication patterns or the homeostatic, status quo, “normal” flow of information.
  5. Continuous backlog decomposition as a manual transfer of a large-batch investment into small-batch development items.
  6. Oops! Another manual transfer at the end –  of small batch engineering back into large-batch approval processes.
  7. Changing job titles without addressing diffusion of responsibility and the lack of psychological safety inherent in the culture of the system.
  8. More overhead and forced “transparency” than if nothing had changed, through extra meetings, reports, metrics, and analysis, due to the natural distrust between formal leadership and emergent leadership, and the lack of trust in information flow between the homeostatic processes and the aberrant nomenclature of the development teams.

In the middle of all this, a large organization grabs their Project Managers and their Business Analysts, or anyone cheap who is around and doesn’t have the “status” a Product Manager, Director, or VP, and switches around their responsibilities to call them “Product Owners” and “Scrum Masters”.

What a debacle.

The newly-minted Product Owner receives Project Plans full of important tasks and milestones and big nasty Use Case document and an even bigger, unapproachable set of Technical Specifications – and is told to manage what the team delivers with User Stories.

Now in the midst of all this, should the Product Owner include Project Tasks in the Product Backlog?  Or to get down to brass tacks, could a task ever be a Product Backlog Items?

Absolutely!

But not all of them.

Some “Technical” Tasks (specifically not User Stories) are still Product Backlog Items

Technical tasks that create demonstrable economic value that the organization can capture, a known cost of delay, but are completely invisible to the user STILL NEED TO BE PRIORITIZED relative to other potential Product Backlog Items.

This, of course, is why the question of if these belong in the backlog is sign that a systemic shift in thinking has not occurred. If you are optimizing for project ROI, then these tasks just don’t have the marketable, monetizable potential of each Use Case. If you have a systems view of optimizing the flow of economic value creation, these tasks are judged relative to any other potential investment. Economic investment is continuous, the economic value created can be judged continuously, delivery and value capture is continuous, and you can prioritize based Weighted Shortest Job First or another collaborative decision making process about the of Cost of Delay.

“Artifact” Tasks are an Agile Anti-Pattern

There is, however, another kind of project task in Water-Scrum-Fall that SHOULD NOT be in any development team’s backlog: artifact tasks. These are things like “Complete wireframe for new home page” and “Document Social Integration for PokemonGo”. No matter how you small-batch these tasks, these are not Product Backlog Items. These are not even artifacts. Artifacts are the tangible leftovers of the creativity and innovation of a strong agile software team. A documentation, design, or planning task is antithetical to economic value flow. It is a trap. A box you put your money in and bury. It takes all the value-add, throws it in a pile, and lets it sit there, unused, as it become gradually less valuable.

This mini-waterfall process – this outrageous, lean-agile anti-pattern – surfaces in three ways, all of which I whole-heartedly reject and will actively undermine the capacity of others to pursue it in hopes that my heretical tribal rebelliousness will gain emergent leadership support:

  1. Business Kanban and Program Increment Planning tasks that lock up all creativity and innovation prior to the development team passively receiving instructions (as you see in shoddy implementations of the Scaled Agile Framework)? FAIL! TRY AGAIN!
  2. Tasks for non-developer “members” of the development teams completed as Sprint Backlog Items separate from the User Stories, thereby formally dividing cross-functional collaboration and preserving us-them Guilds (whether in dual-track Scrum or within even the shortest sprint)? FAIL! TRY AGAIN!
  3. Sub-tasks that formally divide up User Stories into function-specific tasks to complete? FAIL! TRY AGAIN!

These are all agile anti-patterns that prioritize tools, social contracts, and “process” over collaboration, communication, relationships, and creativity. You will never disrupt your organization, and your organization will never disrupt your industry, sorry.

“Milestone” Tasks are a Continuous Delivery Anti-Pattern

Since we started this asking if the BA / PM as PO ought to put Project Plan tasks into the Scrum Product Backlog, I’d hate to leave out “milestones”. Now you may say, “Andrew, that’s ridiculous, no one would treat a dependency as Product Backlog Item!” Indeed, ridiculous. But that’s the ultimate sign of your Continuous Delivery anti-pattern. Truly optimizing the flow of economic value creation across the entire complex adaptive system would completely remove “milestones” and “dependencies”. If you can’t get rid of Project Plans completely, and continuously deliver and validate Finished Story Benefits for ALL work that the organization takes from identified pain to economic value capture, whatever you started pursuing in your agile, or digital, or lean, or devops transformation, you’ve plateaued as a company.

And this is the really the paradox that made the lengthy description of complex adaptive systems leadership necessary. This hurdle is NOT something that “Needs executive buy-in.” This is something that is accomplished through outright insurgency, tribal heresy, and fait accompli rebellion.

That’s because Continuous Delivery takes more than agile ceremonies and user stories. It takes developers who are proud of knowing business context. It takes refactoring that no one approved. It takes a team move to Git from Subversion without telling anyone. It takes a handful of people setting up a Continuous Integration server no matter how often the nay-sayers tell them it’s useless. Continuous Delivery is a change in engineering practices and development culture that tend to happen without formal leaders needing to approve anything.

It just takes the right people having enough pride in being BETTER that they draw a line in the sand and defiantly announce “THIS IS OUR CRAFT!”

A Heartfelt Epilogue: Real Creativity, Innovation, and Disruption is MESSY

Now listen, human-to-human, if all you know about “agile” comes from that one book you read, YouTube, or a two-day certification, I won’t be surprised you’re thinking, “Wait, Andrew, that’s nothing like agile! How do I report you! How do I get you stripped of all your certifications?” That’s great. That reaction means I hit a nerve. Fantastic! Contact me and let’s talk about taking agility to the next level.

Truth is, I don’t look to my four certifications, five training course, three conference, my blog, OR EVEN my five years of attending, speaking at, and hosting MeetUp’s on agile as the proof of my legitimacy on these topics. I measure my expertise in the number of experiments, including the major failures I have been through with my development teams. The reason is simple: complex adaptive system leadership is an emergent property that require deep entanglement and shared experiences in the trenches. And, as it turns out, I’ve been in the thick of every kind of good or bad lean or agile possibility, trained people in that context, debated ferociously about it in multiple companies, and I have compromised my values or experimented with teams to directly challenge every single principle your little YouTube summary glossed over.

If at this point you think some teacher let me down and it’s a real shame, I’ll be happy to give you a recommended reading list and YouTube list and introduce you personally to other thought leaders that dive, like I just did, into the MUD of how you actually achieve: creative innovation, strategic and operational agility, and lean, continuous delivery of disruptive economic value.

Either way, reach out so real dialogue can get started.

“Digital Transformation” Beyond the Hype

Living in the tech implementation space, the most exciting moment in a “Digital Transformation” for me is near the beginning of any project or initiative.  It’s the moment someone who is integral to operations finally opens the 5″ binder that has been sitting on their desk untouched; and finding the information contained in the binder is fundamental to all company revenue.  Or it’s the moment the battle book comes out from the sales VP and the ensuing conversation shows – to the collective surprise of the rest of the participants – there is no standardized pricing, and no tracking of how prices get negotiated.  Or it’s that moment I find a clipboard and start asking about the origin, purpose, and destination of each form.

That’s the juicy part.

On factory tours, in “working sessions” and project kickoffs, or detailing the business logic for an implementation, this is the moment my work is no longer just “make it prettier and online” and the conversation starts driving an actual transformation – of the workplace experience and overarching business model – using “digital” technology.

The reason this moment is so exciting for me happens to also the answer to the question I’ve heard at more than one barbecue from an older neighbor – “And what exactly are you transforming?”

I think that’s a great question in retrospect.

What we are actually transforming is information.

  • We take the information created purely for human consumption;
  • We make it easy for “computers” to read it efficiently instead of humans;
  • We use “computers” to present the information more quickly to more people.

It’s that simple. 

Pragmatically, that’s the process that takes the hard-to-maintain spreadsheets that become binders or clipboard papers and transforms them into intuitive digital interfaces (they are also “online and pretty”). By simplifying all of that socially complex and context-dependent information into a flat table a computer can understand, you become free to add all of the social and contextual perspective in multiple ways later (channel and audience specific) instead of just one way forever (in that binder).

Enterprise Toxic Waste

In a complex adaptive system of knowledge workers, the ability of a group to creatively adapt to an external stimulus becomes impossible once all of the organization’s energy is expended on maintenance of internal homeostasis. To the extent that leadership is an emergent property of the system – in which an individual organically focuses collective energy into new adaptation in response to an external stimulus – it can distribute the pressure to innovate across the entire organization.  When all potential energy is focused on individual self-protection, emergent leadership is stifled. The superorganism “behaves” exactly as any evolving species “behaves” – when conditions are favorable, individuals focus resources into reproduction, increasing the likelihood of variation and aggregate potential for adaptation as a species.  When conditions are unfavorable, resources are dedicated to individual self-preservation, reproduction is reduced, and the species is “culled” leaving only the adaptations that best fit the pressures of the current unfavorable context.  This ebb and flow of creativity and narrowing is seen within the organism as well: in favorable conditions, the cells work toward reproduction, maintaining the health of the system (the body) while in unfavorable conditions the individual cell maximizes its own self-preservation to the detriment of the body (cancer).

“Tech” – currently represented by software, apps, and the web, thrive on innovation and disruption.  The industry as well as organizations attempting to compete through innovation is driven by the desire to maintain a continuous state of innovation at the superorganism  level; instead, most superorganisms (companies, the enterprise) even in the software industry remain cancerous, slowed to a near-death state, presenting painful symptoms far removed from the root cause of dysfunction.

This wasted potential for innovation, sustainable competitive advantage, minimum viability, and adaptive survival is not the fault of any individual and is not strictly caused by the official mission or formal structure of the organization.  This is a cultural issue, not a policy issue.

The formal leaders of a complex system, the managers and executives who are synthetically, socio-contractually positioned to act as the official drivers of innovation (or “vision” or “strategy”) for the organization cannot bureaucratically force creativity and adaptation, as these must emerge organically from favorable conditions across the whole.  Often the formal leaders are charged with being the exclusive source of adaptive creativity despite the fact they are typically in the worst position possible far removed from the external stimulus – to be relied upon for the emergent leadership that drives innovative adaptation.  The inherent waste then is two-fold: the official manager is unlikely to consistently display emergent leadership while the presence of a formalized leader prevents others from organically emerging.  Whether the creative adaptation desired by a manager is valuable and likely to succeed or not, the manager must  force action against the system, as a toxin, a betrayal of the natural state of the system.  In response, the complex adaptive system protects itself against the likelihood of a failed adaptation through cancerous self-preservation of maladaptive patterns.

Unfortunately, if this continues in the context of increasing demand, the growth to supply it exacerbates the likelihood of failed formal leadership and the need for individual or self-preservation.  The waste only grows.  To counter the failure of fewer, more detached formal leaders, the existing formal leaders of many organizations continue to add formal layers in hopes that elevating “high-performers” to official power can mitigate the systemic failure to adapt properly.  This is problematic because the optimization of formal management further decreases the likelihood that any enmeshed individual could organically emerge to lead systems adaption – every individual is progressively more disconnected from the system as a whole.  Silos arise, stage-gate processes are crystallized, and creativity – without needing to be actively stifled – is now unlikely to impact the system as a whole.

Before we move on, promise me you understand:  lean does not mean layoffs.  Toyota’s dedication to the individual on the factory floor is central to its success.  If you try to mimic their process improvement, focus exclusively on eliminating waste, and then cut staff to save money, you’re doing it wrong.  That’s a huge leadership failure. Hacking off a portion of a complex adaptive system will direct any energy gained from increased efficiency toward self-protection.  It is never worth it.

Game Theory shows us that the best way to build sustainable competitive advantage is to invest in resources that create and maximize information asymmetry against our competitors.  On the other hand, we must also raise barriers to exit and increase switching costs for our scarcest resources, people. The more scarce, unique, and hard-to-steal your people are, the more defensible your unique value proposition and the higher your economic rents.  This requires a culture in which the individual has psychological safety in which to take prudent risks.  Trust – the kind that is earned through time in battle together – really trusting in peers, superiors, and subordinates is essential. The individual must be invested in and given the resources necessary for their pursuit of mastery, autonomy, and purpose.  Only then can teams organically self-organize around new forms of adaptation.

Inside that organization, you need the opposite conditions compared to the outward-facing competitive landscape in order to maintain margins and economic value captured.  Maximizing market information asymmetry requires close to perfect internal symmetry of knowledge – in other words, alignment.  Real alignment of understanding of the problem, the objective, and the acceptable risks in pursuit of a solution.  You need continuous throughput that maximizes value add and minimizes waste.  You need low barriers to meaning and purpose and high barriers to exit.  You need slack and creativity.  You need to encourage the tension and paradox and dissent that creates new ideas, while ensuring the organization as a whole is respect-based and disciplined about change.

In Lean we call this Minimum Viable Product. The “product” that must be minimally viable is not a product on the shelf that a consumer buys. The “product” is the sustainable business model that creates economic value that can be captured.   Whether there is one product for sale or hundreds, built by 15 people or 5,000, the minimum viable product is minimal if all consumers receive more economic value than their transaction cost at a price that is great than the cost of production; it is viable if there are enough consumers and enough demand to make the business model of production sustainable.

Seen in this way, the upgrading of any resource across the value stream to maximize minimum viable production should be considered as part of a single improvement roadmap, regardless of its handling by accounting “on the books” – whether it is an enhancement to a software product, brand recognition, acquisition of a competitor to gain market share, or training developers on a new programming language or delivery methodology.  In the end, all of these initiatives are the investment of capital for the purpose of economic value creation protected from competitive influences through creation and protection of unfair advantage.

This is critical – and why vanity metrics are so dangerous.  Even a very unhealthy, unsustainable company can create conditions of information asymmetry that protect its existence in the near-term, but touting a graph that shows increasing revenue, increasing company size, and increasing market share / number of customers does not paint a sufficient picture of the sustainability of the business model.  These numbers are a given. When they aren’t, companies love to find some other numbers that comfort them instead.

What a toxic, carcinogenic waste.

DevOps Athleticism

Let’s face it – being small makes it look easy to be nimble.  Look at your average kindergartener: they may not always be graceful, but their capacity for unexpected action or a rapid spontaneous change in direction at full speed is frequently mind-blowing (for each of mine, it was usually a sudden jump into the risk of oncoming traffic).

So it’s understandable for the established enterprise to look at the youth (and occasional hyperactivity) of startups – and small companies who never grew up – and feel a little fat, a little old, a little bit brittle.

That metaphor doesn’t need to end there, though, because there are also large companies maintaining a portfolio that balances finding new opportunities on the one hand and exploiting new opportunities on the other.  These are two very different operations, though, and companies find balance difficult.  Just like hyperactivity is internalized in the executive function of adults who had physically hyperactive childhoods, that rebellious startup creativity can survive unscathed within the mature organization. By doing so, you can simultaneously continue category-killing through innovation despite staying the course and reaping decades of fruits on already-mature markets and products.

Likewise, to extend the agility metaphor, life is full of athletes in the top quartile of height and body mass index. They top the BMI charts compared to average scrawny-but-chubby adults despite doing it with rather lean body composition.  They are practically outliers, and definitely don’t fit the “standards” set by statistical BMI.  More importantly these individuals put “nimbleness” to shame; and just look at those kindergarteners revere them. Look at the heroes of the NFL: agility doesn’t begin to describe their mastery of movement.  Look at star hockey players in the NHL: they move with the power of an elephant, the stamina of a gazelle, and the grace of a ballerina.  The stereotypical Hollywood karate master black belt may have a very thick, potbelly body-type, but the master needs very little movement, in just the right places at just the right time, to send an opponent flying.

So it’s simplistic at best to “think like the startups” or “be more agile”.  You cannot transplant a culture.  Size alone is not their advantage, strength alone is not their advantage, tenacity alone – as much we love a good underdog story – is not their advantage.  To emulate any ONE  attribute of the lean-agile startup on the rise is foolish.

Stop talking about enterprise at-scale agility like you’re trying to be that kindergartener veering into the street unexpectedly. 

It’s more than being lean, or gaining experience or agility. At scale you need to build repertoire of enterprise-grade DevOps Athleticism!  It’s one thing to have an impressive vertical jump but quite another to jump over a fence, hurdle over a tackling safety, or parkour up a building,

Training for Obstacles

For the support engineer team, kanban looks a lot like an Olympic marathon team.  You constrain WIP (focus/movement pattern), create a sustainable pace, and fuel as you go – you train for the long haul by (basically always) running for distance.  It may be fragile spaghetti code built over the decades, but you your crack team knows it inside out.  But that’s not the majority of your at-scale enterprise.  As you get further from a continuous flow of relatively similar requests and move toward innovation and greenfield disruption efforts, kanban and even scrum are going to fail unless you include the assumption of uncertainty and churn in your overarching process.

This is like the difference between a New York marathon versus Tough Mudder or another obstacle-rich competition.  If you don’t build your capacity for speed-strength and coordination against unexpected obstacles, you’re likely fall short. The long and short of it is, if you can count on a marathon, kanban your way to glory.  If unpredictable obstacles and risk-taking for glory are fundamental, stop whining and start training. Look for extra opportunities to beat down tough challenges instead insisting on a slow and steady pace.  Speed and sustainability need to be loosely coupled in a strong DevOps process.

Jumping the Fence

I can tell you from experience that maximizing raw strength in the barbell squat does not correlate to jumping higher.  If you need to jump higher to make a layup, you do things like box jumps.  If your really daring, leverage your box jump into jumping over a 3-4′ fence (or hurdle) from a standing position.  Raw strength on the one hand and sprint speed on the other don’t give you the actual agility, coordination, and explosive power you’d need.

Similarly, coordination of multiple teams is more complex than strengthening, quickening, or improving communication with each team individually.  Establishing a cadence of synchronization and opportunities for cross-pollination of ideas – even as you increase the independence of each team  

This extended metaphor has a great caveat – go find a 3’ tall picket fence, stand in front of it, and try to jump over.  Assuming you haven’t been practicing, I bet your body stops you.  The same is true of a healthy DevOps system – when you try to launch into a painful bout of stupidity, the developers stop you.  If you’re smart, you don’t force yourself into a giant failure.  Instead, you practice a bit and ramp up your agility to get your entire body confident you won’t end up in the hospital.

Throwing a Punch

You don’t throw a punch with your arm.  You throw it from the ground up, leveraging the perfect twisting launch of one square inch of fist powered by your entire body.  If you’re the square inch that gets to land the winning knock-out blow, don’t get cocky.  You’d be nothing without the support and power of the entire body.

5 Simple Rules for Real Agility 

There is a very wide spectrum from the mythical evil-waterfall-monolith to a perfectly lean and utterly agile continuous delivery of value. In fact, scratch that, it’s not really a spectrum. It’s not even a consultant’s two-by-two matrix. It’s a complex multivariate systems-view that is needed, and fighting religiously for absolutes doesn’t help improve any of the real trials and tribulations on the front lines.
Come on – Don’t try to enforce one-size-fits-all agile or lean or kanban. Instead, create your own adaptive center of excellence from any approaches & tactics, new or old that can provide insights into the variety of techniques that can be adopted for each situation.  

For example, a really well-formed support team could move to kanban and get rid of most of the scrum ceremonies. Likewise, not every multi-scrum-team product needs a cadence of Program Increment planning – but (be honest) some do.

The bigger the organization, the more important it is to be practical in your approach to change you’re passionate about. Self-check: Are you asking for a change that makes the organization easier to work in, better at serving the customer, or more sustainable as it grows? Great! Don’t let fundamentalism get in the way of the spirit of agility and the purpose of your organization.

….Especially if you are an enterprise that is “mid-transformation”.

In fact, rather than worrying about drastically changing to a new and elaborate process with all the answers (which will definitely FAIL), there are just a few underlying principles that will help evolve an enterprise toward lean agility:

1 – Each time you make a business decision, make one that makes it faster to validate your assumption than if you hadn’t made a decision at all.

Anytime you make a decision, make it easier to recover from it as an organization if you are wrong than if you had done nothing at all.

2 – Challenge the biggest assumption first, working to disprove one hypothesis at a time

3 – Each time you touch code, leave it simpler to understand and easier to change than if you hadn’t coded at all

4 – Create an environment of psychological safety for your people

5 – Do no harm to the user