Why is Complexity Useful?



Frogs are complex. I like frogs. From https://commons.wikimedia.org/wiki/File:Green-leopard-frog-in-swamp.jpg

Why is complexity useful? One of my colleagues recently challenged me to answer that question. I wasn’t sure how exactly to respond. I’ve become so accustomed to approaching situations with an eye towards complexity that it has become part of my mental fabric. I take its value as a given. I thought stepping back and reflecting on it might be valuable.

Complexity informs a lot of what I do. I use it to enhance my work with software teams; I try to apply it in my approach to historical analysis; and I find myself reflecting on the Cynefin framework when I’m confronted with a problem. I find it useful in all these situations.

Software teams are complex systems. They contain individuals who play different roles and have their own independent thoughts, desires, and motivations. Each team is unique. This makes it very difficult to develop a formulaic approach to helping them improve. There are, however, certain general concepts that I’ve found to be useful.

I accept Alicia Juarrero’s idea that we cannot cause innovation, but we can create an environment where it is more likely to occur. I try to create that kind of environment by encouraging team members to broaden their perspective on their own process and to momentarily step outside of it. I change the size and composition of working groups, run them through simulations, and impose short time boxes. Usually, these help foster a new shared frame that increases receptivity to potential improvements.

Those familiar with complexity will recognize that I’m altering constraints. I tailor the environment within which the team self-organizes. This triggers a change in perspective, allowing team members to look at their shared context in new ways. It is quite useful in generating ideas that are relevant and immediately applicable.

I also think about complexity when I’m doing historical analysis, but I approach it quite differently. Instead of manipulating constraints, I try to keep in mind the broad set of potential outcomes that were possible at a given moment in time. When looking into the past, we have a tendency to focus on known outcomes and ignore the possible alternatives. This leads to an unfortunate sense of inevitability, and we can easily fall victim to retrospective coherence—the belief that historical outcomes were largely predictable, for no other reason than because they occurred. Reality is far more complex.

If I keep the broader set of possibilities in mind when examining past decisions, I develop a deeper understanding of why certain choices were made, how they were justified, and what potential alternatives were considered. This provides a richer and more valuable narrative. If I can explain past decisions in context, then I there is more opportunity to draw out salient lessons for the future.

When approaching new decisions, I find myself often considering courses of action based on the Cynefin Framework. The framework itself is described in detail in the Cognitive Edge material. I have found it very useful for thinking about how best to approach a problem. It is especially useful in a group situation, with competing perspectives about how to proceed. Pausing for a moment to consider whether or not the problem is Complex or Complicated (rarely do discussions of Obvious problems last long) can be very valuable. In Chaotic situations, there’s a need to act right away, so pausing is better once the crisis has passed.

In see a use for complexity in all these situations. The more experience I gain with using it, the more I feel like complexity is “the way things are.” It’s less a tool and more of a model for seeing the world. I find it quite useful. I suspect you will as well.

Leadership Teams and Enabling Constraints

Michael Norton’s
Leadership Teams may be a smell” is a thought-provoking read. As I went through it, I found myself thinking of examples from my own experience that bear out his hypothesis. Here’s a summary of his idea:

Right now, I think of a leadership team as an organizational smell. Like a code smell, an organizational smell potentially indicates a deeper problem in the system. The smell itself, in this case the existence of a leadership team, is not technically a problem. A leadership team doesn’t prevent an organization from functioning. But the existence of a leadership team may indicate perceived weaknesses in the overall system. Maybe we’re attempting to compensate for these weaknesses by centralizing authority and decision making.

As I thought about the topic more deeply, I realized I didn’t fully agree. I don’t think a leadership team should be considered an organizational smell, but the attributes Michael Norton ascribes to them (centralized authority and decision-making) should be. I hope to build on his thinking.

Professional organizations are complex adaptive systems. They improve, adapt, and learn through constraints. Some constraints, like markets, act mostly from the outside; others are introduced internally. These two basic types of constraints interrelate and influence each other.

Beyond this categorization, there is another way to think of constraints. Some are “enabling” because they encourage creativity and self-organization. Enabling constraints help to channel activity and focus it. Examples abound in natural systems; the arteries of the circulatory system are one of the best; they channel nutrients to cells, allowing larger and more complex bodily structures. Arteries are analogous to the enabling constraints in a Kanban system, the work-in-progress limits and visual workflows, which help channel the delivery of value to customers.

Other constraints are imposed “top-down.” These constraints limit creativity and inhibit self-organization. They are generally human creations. Having to fill out a progress report every week, or mindlessly summarizing the day’s status to satisfy a Scrum Master are examples of top-down constraints.

The key organizational smell for me is not whether the leadership team exists, it is whether its members are using constraints well. Are they centralizing decision-making and imposing decisions? Or are they experimenting with structures and approaches that encourage teams to self-organize more effectively? Are they introducing top-down constraints that inhibit creativity? Or are they encouraging experimentation with enabling constraints?

I believe this holds even in the most challenging environments. If we consider the Cynefin Framework’s complex domain, for example, I agree with Norton that the optimal organizational design pattern is a decentralized network. There is value in having a mechanism in that network that watches for patterns and trends, so that positive experiments can be identified and exploited. This is what I would expect a leadership team to do and it can be done through effective use of constraints.


CIC on USS Independence

Fortunately, it is not just theory. This is the exact approach taken by the U.S. Navy’s Pacific Fleet in 1942. Existing shipboard information systems were being overwhelmed by new data coming from radars and radios, preventing effective decision-making in battle. Admiral Chester Nimitz, the fleet commander, recognized the problem, but refrained from imposing a solution. Instead, he and his staff introduced an enabling constraint; they ordered each ship of the fleet to develop their own solution. This triggered multiple parallel experiments throughout a large (fairly decentralized) network. The staff observed the results and selected the most successful experiments for future development, resulting in the revolutionary Combat Information Center (CIC).

To put it in terms of Cynefin, Nimitz and his staff successfully moved the problem of managing shipboard information from the Complex Domain to the Complicated one through the use of multiple parallel experiments and constraints. In doing so, they acted as an effective leadership team. I believe today’s leadership teams could have similar successes, so long as they keep the details of complexity in mind, and approach problems with an eye towards enabling constraints.






Constraints to Improve Flow

In my work with software teams, I often use traffic flow as an analogy. It is an extremely accessible way to describe the concepts of capacity, flow, and utilization. We all seem to have experienced traffic in one form or another and even the smallest localities have their share of traffic jams. Most people appreciate the value of the analogy immediately, which makes it easy to relate the use of metered on-ramps to work in progress (WIP) limits in a software system, an approach I like to take.


An officer acting as a constraint to improve overall flow. He was only moderately successful.

This familiar analogy can be extended. Recently, I’ve started realizing how constraints in traffic systems influence self-organization and flow. Some traffic constraints are obvious and common across geographies. We’ve all experienced lights at intersections, roundabouts (or traffic circles), stop signs, and yield signs. Some less obvious constraints, such as curbs, medians, and lane markers define the roadway. All of these together help to control the flow of traffic and make it easier for us to navigate to our destination.

Alicia Juarrero and others have broadened our understanding of complexity by emphasizing the impact constraints have on self-organization. She divides constraints into two major categories. Context-free constraints limit options, but lack contextual significance. It is often useful to think of these constraints as being imposed from above, or from another level of the system. Context-sensitive constraints, on the other hand, arise from within the system itself.

Within a traffic system or a software development process, both types of constraint can have an impact on flow. A stop sign is a good example of a context-free constraint. It controls flow by forcing vehicles to stop when they reach it. If the way is clear, then they can proceed; otherwise they wait. But the sign has no knowledge of the state of the system. You’re required to stop regardless of whether cars are approaching on the cross street.

A parallel in a software process might be a WIP limit on the “Development” column within a team’s Kanban. Although the choice of the particular value for the WIP limit is very sensitive to context, once it is chosen it acts like the stop sign, forcing work to wait until capacity is available regardless of the broader context.

Both the stop sign and the WIP limit can help improve overall flow. The stop sign exists to allow improved traffic flow along another axis, or to control flow through the intersection. The WIP limit prevents work from building up in Development, allowing more rapid feedback to that activity from downstream processes. These smooth out the flow in both systems.

Context-sensitive constraints also exist in traffic systems and software systems. These tend to be less obvious unless you’ve had a chance to immerse yourself in them. But even as a passenger, it quickly becomes apparent that the unwritten “rules of the road” are very different between India and Germany, or Italy and England. There are even subtle differences between Maryland and Virginia, where I tend to spend most of my time driving. This is because drivers in each of those locations have a specific set of expectations for how they believe they should behave in traffic. These expectations constrain their behavior, and they differ from place to place. Software teams have similar unwritten “rules” of behavior that influence their flow.

Together these context-free and context-sensitive constraints largely determine the overall flow of the system. Interesting relationships between the types of constraints can be seen. The German traffic system, for example, is relatively highly constrained by the “rules of the road.” German drivers go through an extensive certification process, giving them a strong common sense of how to behave on the roads. One result is that they tend to stay out of the passing lane unless they are passing. This context-sensitive constraint improves the flow of traffic on two-lane roads.

Contrast this with Virginia, where the use of the passing lane is far less disciplined. Drivers sit in it, inhibiting flow and triggering backups. To improve flow, traffic engineers end up adding new lanes. In effect, they’re substituting a context-free constraint (another lane) for a context-sensitive constraint (limited use of the passing lane) to achieve the same end (improved flow).

India is another good example. In Indian cities like Chennai, the “rules of the road” lead to the utilization of the entire expanse of the roadway. Lane markers are ignored and all spare capacity is utilized. This works well to fit lots of traffic into a confined space, but it can have a crippling impact on overall flow. Driving becomes a series of negotiations as each vehicle jockeys for just enough space to move forward.

To compensate for this, the city of Chennai has begun to introduce context-free constraints: large barriers have been installed along the sides and down the center of major roads. These limit the ability of traffic to enter and exit the roadway. They also prevent traffic travelling in one direction from flowing over into the oncoming lanes. Although some of my friends there might argue the point, I think they’ve improved flow.

Similar relationships between context-free and context-sensitive constraints exist in software systems. Some teams have developed a common understanding—a sense of how much work they can handle—and can do without WIP limits within their system. They maintain flow through their “rules of the road.” Other teams lack this capability and have sought to achieve the same end through WIP limits, a disciplined understanding of their velocity, or other means. 

Neither of these approaches is inherently more valuable. The key is understanding how the team is behaving today and determining how best to maintain an effective flow. If you regularly bog down and have variable flow, context-free constraints may be the best way to start. In other circumstances, working on team cohesion may be more effective. There are many approaches to that; I’ve found Lean Coffee to be an effective one. Informal conversations over coffee breaks are good too.

Unconferencing #NoEstimates

A little over a week ago, Paul Boos hosted the first Agile Dialogs Unconference. Our subject was inspired by the debate surrounding #NoEstimates. We hoped to get beyond some of the rhetoric and grapple with perspectives from both sides. I was hopeful that we would increase our overall understanding and generate some ideas for real improvements we could use with our teams. I think we achieved that goal.


A number of good ideas came out, and Paul has generated an accurate list. For me, there were three main lessons. The first is that when we debate #NoEstimates or #YesEstimates, we’re often talking about very different things. We paused several times in our discussions to ask ourselves what we really mean by “estimates.” There were some very diverse perspectives and we often needed to recalibrate. Differences in the definition of “estimates” influence how we approach the idea of #NoEstimates and what we think it means. Many of the arguments on Twitter seem to have their origin in these kinds of misunderstandings.

We were able to get past that in our dialog and draw out some valuable perspectives from both sides. From the #NoEstimates side, I think one of the most important lessons is that when we make an estimate—regardless of whether or not that is a traditional time estimate or one involving something more abstract like story points—we risk anchoring ourselves to a particular implementation approach. This may be fine.

But there are cases where it will lead us down an undesirable path and trigger rework or introduce technical debt. It can be difficult to avoid, as we often don’t realize the impacts of our assumptions until we have a chance to test them. Usually, that comes long after an estimate has been made. Teams that make estimates might want to keep this in mind.

Critics of #NoEstimates point out that estimates are often blamed for broader organizational dysfunctions. We discussed this at length and cited a number of examples from our own experience. Although estimates are a visible aspect of dysfunction (like when they’re used to transfer risk), that does not mean they are the cause. They may only be a surface symptom; discarding estimates may have no effect on these deeper issues and may only further complicate the problem. If you’re looking to discard estimates, you may want to investigate whether or not this applies to your environment.

As with many things, the benefit or harm of estimates appears to be very much dependent on context. By getting together and sharing our experiences, we helped broaden our perspectives and gain more understanding. I’m looking forward to more Agile Dialogs.

The Perils of “Obvious” Testing


The Cynefin Framework

Like many, I’ve been stunned by the VW Emissions Scandal. But I’ve also been fascinated. when I heard that software had been written to circumvent the EPA’s tests I immediately started wondering how it was done. I thought that would be an extremely complicated process, but that was because I failed to understand the nature of the testing.

As this article on the Washington Post points out, the EPA’s tests are very scripted. They follow a predictable and repeatable routine where speeds have to be kept within “two miles per hour of the required speed at any given moment.” With such a standardized approach, I immediately recognized how it would be comparatively simple to put the necessary monitors into the software to detect the start of such a test, adjust performance throughout, and guarantee a passing performance.

I’m glad the EPA quickly recognized that it needs to revise its testing approach. I hope that they take the deeper lesson from this experience and adjust their testing so that it is not “obvious.” I am deliberately using the term for the Cynefin Domain, because I think the sense-making framework can help us understand what happened and draw broader lessons for how to develop more effective tests.

The Obvious Cynefin Domain was previously called “simple.” It is tightly constrained; there are no degrees of freedom; and best practices can be developed and disseminated for dealing with problems in this space. This is an accurate description of the EPA’s testing approach and also applies to other forms of testing. It also helps explain what happened with the VW diesels, because when Obvious solutions fail, they do not fail mildly.

Instead, they tend to fail catastrophically by passing through the boundary into the Chaotic Domain. This shatters the existing dynamic. It is, I think, a perfect encapsulation of the VW Emissions Scandal; it was a catastrophic failure that undermined our faith in the automotive industry.

I have seen similar failures (on a much smaller scale) in software, where teams used scripted approaches to testing that failed to adequately model user behavior and expectations. The tests “passed,” but the user experience missed the mark. In these circumstances, the software “failed.” Some of these failures have been similarly catastrophic. How can we avoid similar types of failures in our own testing approaches?

One answer is to ensure that our tests are not so “obvious.” They must not be scripted and predictable. If they are, they invite “gaming” and will lead to failure as user expectations change (and they will, once they begin to use the software). Exploratory Testing is an excellent way to do this. Exploratory tests are not “obvious;” from a Cynefin perspective they are Complex, because the tester follows a “probe-sense-respond” paradigm as they work with the software. Assumptions about what it should and should not do are subordinated to learning what it actually does. This offers the potential for learning and discovery. Coupled with a rapid feedback cycle, it is a much better approach and will lead to better solutions.

Perhaps the EPA should consider something similar.  

Thoughts on Agile Coach Camp US

I attended Agile Coach Camp US last week. It was a wonderful experience and a great way to explore new ideas. Here are some of my personal highlights of the event.


Olaf Lewitz gave an excellent introduction to the concept of Temenos. It’s an approach that emphasizes creating space for effective conversations and mutual understanding so that we can become aware of our choices and take more deliberate (and positive) action in the future.

IMG_4302Olaf triggered a sharing exercise by asking us to tell stories from our lives where it felt difficult to say “no.” We began hesitantly, but soon we were relating our experiences, building on each other, and exposing how difficult it can be to turn down our friends, relatives, and colleagues.

While this was happening, we observed several things. The pace of the sharing accelerated. Sharing led to more sharing, more openness, and increased sense of connection with each other. As we discussed our experiences, I—and others as well—became more aware of options. Our choices to say “yes” or “no” were deliberate; we did not “have” to make them the way that we did.

That’s when I was struck by the power of the approach. Instead of drilling into why an event occurred or why a decision was made, we were being focused on options and future possibilities. We talked about our view of the past, but the analysis in my head did not dwell on the past; it was looking to the future. I felt that I had more choices than before. I felt that I could be more deliberate. It was a fascinating effect to observe.

It was made more powerful by the knowledge that the most successful retrospectives I’ve facilitated worked much the same way. I’ve always placed great emphasis on sharing diverse perspectives. I didn’t call these perspectives stories, but they worked similarly, and broadened our view of the past so that we become more aware of future options. From there, it is easier to make a deliberate choice about what to do in the future. I think I can make my approach even more effective with Temenos and want to learn more.

Remaining Curious

Sue Johnston led us through a fun conversation about the value of remaining curious as a coach. The most impressive aspect of this session was how we focused in on questions and questioning style. Questioning is an important aspect of curiosity, of course, but there are different ways to ask questions and we agreed that some are more effective than others.

IMG_4295One of the most interesting suggestions was to try to avoid the use of “why” questions. We ask “why” questions all the time; the “5 whys” is a well known technique. However, they can be very dangerous. “Why” questions can easily lead to blame. Consider the difference between these two questions:

Why did you do that?


What made it seem like that was a good idea?

These two are very different. The first question is framed in such a way that an individual (or a group) immediately feels responsible for doing something wrong (the “that”). Judgment is implicit. This will likely trigger hostility and/or fear. We risk shutting the conversation down.

The second question divorces the action (the “that”) from the individual or team. We operate from an assumption of best intentions and allow them to share their perspective. We remain open to the possibility that they know something we do not and that their choice might have been the best. This approach increases the potential for a broader level of shared understanding. The suggestion was that we should try to reframe “why” questions as “what” questions whenever possible.

Another valuable point was Sue’s introduction of the idea of the “arc” of a coaching conversation. This was presented as a series of different questions, each appropriate for a different moment in the arc.

  • In the beginning, we need to learn and so we ask, “What?”
  • Once we understand the situation better, we need to develop a better sense of the context and so we ask, “So What?”
  • With a sense of the context, we can move to helping draw out factors that may not be immediately obvious and so we ask, “What Else?”
  • Finally, to help someone understand what they can do with the knowledge gained, we ask “Now What?”

I thought this was an excellent little frame for thinking about coaching conversations that can help keep the focus on curiosity.

The Unprintable Work of Derek W. Wade

Derek ran a pair of sessions, both had great names that drew people in, but they’re inappropriate for a family blog.

In the first, we explored the power of venting frustrations in a positive way. We shared techniques we use to deal with frustration and affinitized them. Then we vented our frustrations, not as stories, but just as a word or phrase, going around the group several times. We had plenty of frustrations. Once we had a good list compiled, we shared a few stories and tried to relate them back to the brainstormed techniques. I think the best vision to come out was the concept of simultaneously drinking wine and juggling chainsaws. That gave us all a good laugh!

The second session explored techniques for dealing with leaders who seem resistant to change. We had all encountered people in powerful positions who appeared unwilling to support the improvement of their teams. Although it was not billed as such, the session was a great look into the dangers of fundamental attribution error. We spent a lot of time discussing how these individuals have their own valuable perspective and we need to gain a better understanding of it in order to communicate with them effectively.

Beneficial Conversations

In addition to the sessions, I had several really useful conversations which helped me see things in new ways.

Michael J. Tardiff and I IMG_4282had a fascinating exchange. We talked about infection and subversion as two different models for organizational change. We agreed that an infection model starts out localized and spreads once others see or hear about the value. With infection there is no inherent threat to existing power structures; an effective practice, like TDD, might spread this way. Subversion differs in that it deliberately seeks to undermine existing authority and is driven by interested parties. The two can be combined; they’re not mutually exclusive. But they have very different implications. Our talk got me thinking about the importance of accounting for power dynamics and vocabulary when we discuss organizational change.

Andrea Chiou reminded me of the value of creating a shared set of experiences for increasing empathy and accelerating understanding. The most effective workshops I’ve run all seem to have had some element of this, even if I didn’t intentionally create it.

Bryan Beecham explained his concept of “human refactoring” and used some very effective software code analogies to describe it. He believes we can use this approach to change our behavior and make better choices. I agree. I’m less confident in his goal to live for 200 years, but I wish him luck.

Weighing in on #NoEstimates


“… plans are useless, but planning is indispensable” – Dwight D. Eisenhower

I’m a big fan of the debates that have been triggered by #NoEstimates. It’s wonderful to have the dialog, even though many of us often end up talking past each other. I think the root of some of the misunderstanding rests in our assumptions about planning and how we think about risk.

I like the #NoEstimates concept because it challenges us to get away from the belief that we can accurately predict the future. Many of us gravitate towards the idea that if we could just estimate our tasks better, then we would become more predictable. This idea has a lot of appeal because, as professionals, we strongly believe we should be able to accurately assess how long our work will take.

And this is true, broadly speaking. We can get a rough sense of how long work will take. However, there will always be an element of uncertainty remaining, if not in the task itself, then in our environment or circumstances. I experienced a great example of this earlier this week when the power went out just as I was bringing a new printer online. The task duration grew exponentially because of this external block.

If uncertainty is unavoidable then how can we plan? This is the question that I think many discussions of #NoEstimates get hung up on. How should we plan?

Planning is beneficial. It can help us determine the right thing to work on and when to work on it; it can align the work of multiple teams (or multiple disciplines); it can give us a window into how effective we are at delivering value, and how often we do so; and it can ensure that everyone is working together, towards a common goal.

All these outcomes are possible, even in conditions of uncertainty, provided we make planning a recurring activity. If the future is unpredictable, then our plans are inherently flawed. We must revisit them periodically to update them as we learn more. Otherwise, their value decays rapidly with time.

I think an emphasis on planning, not plans, is a natural consequence of the #NoEstimates concept. However, it’s easy to conclude that #NoEstimates makes planning impossible or irrelevant, because how can we plan without any idea of how long a task will take?

The answer is that we can spend just enough time conceptualizing, categorizing, or breaking down the work to make the planning activity valuable. This can be done without estimating. Some teams I work with just get their stories “small enough;” others try to conceptualize them in terms of “units” of work. None of these teams believe they “estimate,” yet they plan effectively.

Closely tied to concerns about plans and planning is how we think about risk. Risk is inherent to what we do; it’s in the uncertainty of our predictions and in the new and innovative solutions we try to bring to customers. When we emphasize regular planning, we recognize this and provide a release valve—a way for risks to be rapidly identified and discussed as a team. This creates an environment where risk becomes a shared responsibility.

#NoEstimates reflects experience with a very different type of environment. Often when development groups are asked for an estimate, what’s really happening is that risk is being transferred. An estimate of two months triggers an expectation of delivery in two months. If there is no commitment to regularly revising this plan, then any uncertainty becomes the responsibility of the team that gave the estimate. Risk is not a shared responsibility; it’s been transferred exclusively to the team, and their estimate was the transfer mechanism.

Not surprisingly, many teams want to avoid this dynamic. Since the estimate was the mechanism that gave them responsibility for all the risk, #NoEstimates has great appeal. If it can trigger a recurring approach to planning, then the team will develop a healthier approach to managing risk and uncertainty.

For some more specifics on how this might work, check out this post from Paul Boos.

Nominated for Brickell Key

I'm a Brickell Key Award finalist I’ve been nominated for the Brickell Key Award! I’m tremendously excited about this. The award highlights excellence with Kanban, honoring people who have shown outstanding achievement, leadership, and contribution to the Kanban community. I’m also rather stunned.

I don’t think of myself as having shown outstanding leadership or achievement. I really value Kanban though, and I talk about it almost everywhere I go, so maybe there’s something to it.

What I appreciate most about Kanban is that it is a deliberate attempt to create a shared cognitive framework, a shared view of what we are doing. This makes it much easier to work together, cooperate, and collaborate towards a common end. I’ve seen it with the teams I work with, and I’ve also seen it in my own home.

We hear a great deal about the importance of culture and how Agile and Lean require a specific cultural mindset. In most organizations this requires cultural change. I have to agree with this. Although my work is generally considered “process improvement” a vast majority of my efforts focus on improving how teams work together and relate to each other; this improves their culture, or at least changes their perception of it. In many cases, my work would better be described as “cultural change” rather than “process change;” the two go hand in hand.

The wonderful thing about Kanban is that it gives us a tool to work on culture directly, without ever mentioning the concept. By providing a shared frame of reference, a Kanban creates a new cognitive framework. This can overcome existing biases and assumptions and help bring a team together. It’s a powerful constraint that can trigger changes in the way people work and relate to each other. Seeing a team move from infighting and division to collaborative self-organization in this way is a wonderful thing.

And it is disheartening to see it abused. A Kanban can be a wonderful tool, but it can also be a powerful mechanism for division and control. I’ve seen managers construct Kanban systems that enhanced their power and disenfranchised subordinates. It’s rare, but it can happen.

This hasn’t reduced my enthusiasm for it though. And I’m excited to share what I’ve learned and collaborate with others at Lean Kanban North America 2015 in June. I’m also excited that I might be honored with the Brickell Key Award.

If you’ve worked with me and want to put in a good word of support, please follow this link.

I Always See the Gorilla

Silver_back_gorilla_-_Gorilla_beringeiBy now most of you have probably seen one or more variants of the “Gorilla Video.” I’ll do my best not to spoil it in case you haven’t, as the experience can be quite illuminating. What I’ve always found most interesting about those videos is that I always see the gorilla, and in similar videos, I tend to notice more of the “changes” or the “hidden elements” than most.

As part of the LeanUX14 Conference I attended a Cynefin Workshop hosted by Dave Snowden. It was a wonderful experience and he provided an explanation for why most of us miss the gorilla. We normally take in a very small portion of what’s in front of us; 5% appears to be typical for those of us from a western background. We don’t “see” everything. We filter things out based on a system of pattern recognition, even if those things—like the gorilla—are right in front of us. In other words, we observe what we’ve been conditioned to see.

This thought sat fermenting in my head for a good while. It made perfect sense from a scientific and evolutionary perspective. What was it then about my own experience—my own conditioning—that made me more likely to observe more than my peers? I wasn’t ready to accept the idea that I was just unusual; I like to have explanations for things.

It wasn’t until Michael Cheveldave (a colleague of Snowden’s) was giving a presentation later in the conference that a potential explanation hit me. Michael was talking about the concept of Cynefin and its meaning as “place of multiple belongings.” He had a picture of a green valley in Western Canada up on the screen, and he said that although he travels many places, that place—that green valley—was his home.

I don’t have a place like that. My family moved around a lot when I was young. I can feel “at home” in the upper Midwest where I was born, in Indiana and Illinois, and in Virginia where I live now. Wild places, like the Boundary Waters of Northern Minnesota and the desert plateau of Utah, feel like home. London, Paris, and Munich feel as much like home as Washington, DC. In a similar way, the streets of Chennai always feel welcoming when I return to them.

Many places feel like “home” to me, but I have no place like Michael’s valley, no place that is definitively and absolutely home. When I realized that, I thought I had an explanation for why I see the gorilla.

We are conditioned by our surroundings. We learn what to expect. When we have a home, we adjust to it; we learn what we need to pay attention to and what we can safely ignore. I think my youth and my frequent movements conditioned me to expect new situations—new places, new things, new contexts. For me, being able to see and take in subtle variations meant the difference between a fun day at school and an unwanted bullying. I not only learned to pay attention but became conditioned to do so.

The important implication is that our environments—our management systems, our Kanban boards, and our tools—are conditioning us. Are yours triggering the kind of behavior you want to see? Are they enabling people? Are they fostering learned helplessness? What gorillas do you see? Which ones are you missing?

The Danger of Singular Attractors

A6M3_Munda_1943“Responding to Change over Following a Plan”

That phrase is one of my favorites from the Agile Manifesto. In mulling it over the other day—and thinking about how to explain its value to others—I felt that a historical example could help explain the dangers of adhering too strongly to a specific plan when circumstances change. Looking at how the Imperial Japanese Navy (IJN) approached the idea of “decisive battle” before and during World War Two is an excellent way of illustrating the value of “responding to change over following a plan.”

The Japanese planned for war assuming that an American Fleet would steam across the Pacific from its base in Hawaii. The fleet would recapture—or relieve, if Japanese attempts to capture them failed—the Philippine Islands and also seek bases from which war could be brought to the Japanese homeland, such as Okinawa or Formosa. The Japanese plan was to prevent this by engaging the American Fleet in a large naval action, crippling it, and ending its journey. Victory in this “decisive battle” was how the IJN expected to win the war.

This objective would be made easier by subjecting the American Fleet to attritional attacks as it moved west. Before the decisive battle, attacks by airplanes, submarines, and surface forces would reduce the strength of the American force, increasing the odds of victory in the decisive fleet action. Japanese light forces and submarines would attack from bases in the Marshall and Caroline Islands, granted to Japan in the aftermath of World War One. These islands sat astride the most direct route of advance across the Pacific, the one the Americans planned to take.

Japanese weapons, doctrine, tactics, and force structure reflected this emphasis on attritional attacks and decisive battle. They invested in powerful, long-ranged torpedoes, perfect for night attacks on enemy formations. Land-based and carrier planes were extremely long-ranged, so that they could attack at ranges from which the Americans could not respond. Ships were built with an emphasis on offensive action, and powerful for their size. Relatively little attention was devoted to survivability, maintainability, or logistics. The focus on decisive battle trumped other considerations.1

There were good reasons for the IJN to invest so heavily in this core assumption. It reflected their recent history, and the lessons they had drawn from prior wars. The Russo-Japanese War had ended in a decisive action, with the Russian Baltic Fleet steaming around the world to its destruction at Tsushima.2 The Sino-Japanese War had also featured a major fleet action, victory in which gave the Japanese command of the sea. This historical experience was augmented by Japanese interpretations of the writings of Alfred Thayer Mahan, one of the most influential thinkers on naval strategy of the late 19th Century. His theories had a significant influence on Japanese naval strategy leading up to World War Two.3 The result was that the IJN focused almost exclusively on the decisive battle and the attritional campaign leading up to it.

The daring attack on Pearl Harbor was the culmination of this thinking. In the years before the war, modifications to the basic plan had moved the anticipated location of the battle farther eastward and closer in time to the initiation of the war. The IJN’s quest for longer ranges and earlier action influenced its thinking strategically as well as tactically. But Pearl Harbor proved to be just the beginning.

In the language of complexity, the concept of the decisive battle became a “singular attractor” for the IJN. Plans, tactics, and doctrine gravitated towards it, to the exclusion of other potential alternatives. This singular focus began to blind the IJN to other possibilities; the leadership ignored “weak signals” that suggested different paths to victory.

This is the underlying reason why the Agile Manifesto places greater emphasis on “responding to change” than “following a plan.” When we follow a specific plan—when we emphasize its employment over alternatives—we risk creating a singular attractor that blinds us to alternatives. We focus on the plan; we invest ourselves in it; and we try to ensure that we conform to it. We do this even when other, more effective, options arise.

This focus on a specific plan can trigger all manner of problems, but the most insidious is that the more we invest in the plan, the more power we give it as a singular attractor. The more attached we become, the less responsive we are to alternatives that could allow us to achieve the same objective with less effort. We become willingly ignorant of the weak signals in the environment; we miss potential opportunities with more favorable outcomes.

This is what happened to the IJN. The faith it placed in the decisive battle was misplaced. American strategic mobility and industrial might permitted an advance on two fronts—through the South Pacific and across the Central Pacific. The Japanese lacked the forces to hold back both; their attempts to do so spread them too thin and left them vulnerable.

The investment in attritional tactics did not play out as hoped. Attritional combat injured the Japanese as much as the Americans. In mid-1944, when the opportunity arose for the decisive battle, the Japanese lacked the capability to execute their prewar plans. The result was shattering defeat at Philippine Sea and Leyte Gulf. With their prewar plans finally thwarted, the Japanese formally adopted kamikaze tactics.

Software teams that adhere to specific plans despite changing circumstances often adopt similar—but much less lethal—approaches, sacrificing themselves and the future of their applications in a fury of long hours and weekends. They, like the IJN before them, fall victim to an inordinate focus on a singular attractor. They are often no more successful, and the long-term harm done to morale and application architecture often bears a certain resemblance to the brave—but futile—kamikaze tactics of the Japanese.

1. Kaigun: Strategy, Tactics, and Technology in the Imperial Japanese Navy, 1887-1941, David C. Evans and Mark R. Peattie (Naval Institute Press, 1997) and Sunburst: The Rise of Japanese Naval Air Power, 1909-1941, Mark R. Peattie (Naval Institute Press, 2003)

2. Battle of Tsushima

3. From Mahan to Pearl Harbor: The Imperial Japanese Navy and the United States, Sadao Asada (Naval Institute Press, 2006)