What is Doctrine Anyway?

BB_LineLater this year, I’ll be sharing the stage at SDI Miami with Stephen Bungay, whose book, “The Art of Action,” has been influential in the Agile community. He’ll be continuing to expand on his thesis—that the Prussian General Staff identified an effective approach to organizing for collective action in the face of uncertainty—and presenting on “Blitzkrieg: Lessons in Organizational Agility & Strategy.” I’m looking forward to seeing how he relates the success of the German Army in the early years of World War II to the management challenges of today.

I plan to do something similar, but with a less familiar example. I’ll be highlighting the importance of rapid organizational learning by discussing the Allied offensive at Guadalcanal in late 1942. The series of naval battles triggered by that offensive led to revisions in the U.S. Navy’s doctrine—its approach to combat. Whereas Bungay will discuss the merits of the German Army’s doctrine, I’ll be presenting the importance of developing doctrinal agility: the ability to rapidly refine, adapt, and evolve doctrine.

So what is Doctrine?

In my forthcoming book on organizational learning in the U.S. Navy, I define doctrine this way:

Doctrine is the set of implicit and explicit assumptions that govern the behavior of a military force. It is what officers and sailors fall back on to guide their decisions when precise instructions are not available. It has a parallel to “culture” or “ethos” but greater specificity than either one.

Bungay (and many others) contend that the German Army’s doctrine was particularly effective because it created a common sense of what to do and how to do it, allowing large collections of individual soldiers to act in concert with minimal need for explicit instructions. I contend that the U.S. Navy’s doctrine was effective because it retained the ability to evolve and change in the face of new information. These are related concepts, but the difference is important.

Why Should I Care about Doctrine?

Whether we are aware of the process or not, doctrine influences how we make decisions. We’ve all experienced the influence of doctrine in our work. Some organizations tend to centralize decisions, perhaps in the hands of a senior engineer or manager. Those who fail to defer to them are stigmatized or punished, quickly creating a doctrine of centralized decision-making. Other organizations attempt to empower teams with the ability to collaboratively make decisions. When leaders—managers, senior engineers, scrum masters, etc.—reinforce this concept, the doctrine of empowered teams spreads. Many more examples exist. In most cases, organizational doctrines are implicit, but they exert a powerful influence.

Military forces explicitly create a doctrine based on their preferred approach. Drill, exercise, and repetition creates patterns—what Daniel Kahneman calls “heuristics”—that become the preferred approach to solving specific problems. There are two challenges in this. First, the heuristics must align with the organization’s goals and objectives. Second, the heuristics must not be so deeply embedded that they cannot change. The U.S. Navy was particularly adept at both seventy-five years ago.

Come to SDI Miami and I’ll explain why this was so, and what the implications are for modern organizations.

Looking Forward to Lean Kanban North America

This post first appeared on Excella Consulting’s Blog.

Next month I’ll be speaking at Lean Kanban North America. The last time I attended, in 2015, I was a finalist for the Brickell Key Award. I had been helping distributed teams align their work and increase their situational awareness by using Kanban. Jim Benson and I spoke about the positive aspects of that experience, but we spent more time on Kanban’s dark side. We argued it could become an oubliette—a claustrophobic dungeon—in certain circumstances. If you’re interested, you can see the video here. I really enjoyed the experience, and I’m excited to go back.

Kanban for your Brain

This year, I’m going to be focusing on something slightly different. One my favorite things about Kanban is the subtle shifts it triggers in our minds. It’s a huge relief for me when I can get things I need to do out of my head and onto my Personal Kanban. Once they’re there, I don’t have to focus on remembering them, and seeing them set out as a collection of options—work I can start when I feel it’s best—gives me an increased sense of control. I’ve seen the same thing happen for my daughter when she uses Kanban to help make sense of her homework.

Kanban offloads mental processing and reduces our cognitive burden. With a team, this dynamic becomes even more profound. A team Kanban becomes a shared view of their work. At the most basic level, this reduces everyone’s cognitive load, just like my Personal Kanban does for me. But effective Kanban systems will do much more than that. They will become a system of distributed cognition.

Kanban and Distributed Cognition

Distributed cognition doesn’t mean a distributed team. Distributed in this sense means that there is a broad cognitive—or sense-making—activity taking place that is greater than the sum of the individual parts. The interaction of the team and their board creates the potential for more effective and more rapid decision-making. This is especially true if the team has invested in customizing their board to incorporate details like classes of service, specific types of work, and defined capacity allocations. The increased amount of information allows the board to become a decision-support system. Everyone working with it knows what choices to make and what conversations to trigger. When a team gets to this level, it’s electrifying!

Historical Parallels

This isn’t the first time this sort of thing has happened. My favorite historical example is from the U.S. Navy’s experience in early World War II. During the confused night battles in the Solomon Island chain, task force commanders and ship captains couldn’t make sense of the situation around them. They had access to revolutionary new sources of information, like radar and very-high frequency radios, but there was no way to effectively understand all the details they provided.

The U.S. Navy had to create a system like Kanban, one that could model the current situation with meaningful symbols, offload the cognitive burden, and help align decision-making. Once that was in place, ship captains had much greater situational awareness. They began to operate as a team and collaborated more effectively. The results were revolutionary.

A good Kanban system will help your team in the same way. Come to Lean Kanban North America and I’ll explain how.

Becoming an Accredited Kanban Trainer

This post originally appeared on Excella Consulting’s Blog.

The Kanban Method is an empowering approach that helps individuals and teams harness their full potential. I’ve experienced its benefits repeatedly, both in my work and personal life. Last month, I increased my knowledge of Kanban by becoming an Accredited Kanban Trainer (AKT) through Lean Kanban University (LKU). It was a great experience, and I’m excited to be able to offer certified Kanban training at Excella.

Kanban offers an “alternative approach” to agility. People tend to assume this means it is a different “process” from Scrum, XP, or other Agile methods. That’s a misunderstanding. Kanban isn’t a process; it’s a method, a framework that helps manage work more effectively and catalyze ongoing improvements. Kanban integrates well with many other approaches—including Scrum and more traditional methods—and helps to improve them.

That’s because of the emphasis Kanban places on “starting where you are.” With Kanban, there is no canned solution. Instead, current roles and ways of working are respected. Teams start with visualizing their current way of working. This first step is critically important. Kanban applies Lean management principles to knowledge work. Lean management emerged from manufacturing, where work products—gears, drivetrains, lawnmowers, etc.—were visible. In knowledge work, like software, project management, and HR, we generate knowledge. This may ultimately appear as working software, a proposal, or a new policy, but the work that goes into it is invisible. This can make it very difficult to manage effectively.

Kanban addresses this challenge through visual representations of our work. We can see what is in progress and who is focused on it; we can see where it might be waiting, and we can anticipate the tasks we’ll need to take on next. Visualization also allows the next logical step: limiting the amount of work in progress. Just like traffic signals that restrict the entry of cars onto a busy highway, limiting work in progress improves overall flow. Because there is less work going on simultaneously, team members focus on the most important things and get them done faster, improving flow, responsiveness, and agility.

But the Kanban Method does more than create an effective flow of work. Getting to this point—where a team has an effective visualization that helps limit work in progress—is a collaborative exercise. Once a team achieves this level of understanding, they become empowered. They take responsibility for their process. The Kanban Method encourages them to make it more “fit for purpose,” more effective at meeting their needs and the needs of their customers and stakeholders.

The approach Kanban takes is an evolutionary one, where the best methods emerge from the work of a collaborative team. STATIK—the Systems Thinking Approach to Introducing Kanban—is a structured approach to improvement that helps the team understand what makes their system work well. How can it better meet their needs and the needs of their stakeholders? What kind of work do they do and where does it come from? What is their current capability and how well does it meet expectations? These questions drive a process of continual improvement that helps the team refine their Kanban system and make it better.

It can have a dramatic impact on how effectively work is done and how well the team meets expectations. Effective Kanban approaches are continually evolving to become increasingly “fit.” The Kanban Method provides an effective framework for this. If you’re interested in learning more about how you can apply these techniques to your team, please join us for one of our classes.

My Experience at Lean Agile Scotland

This post originally appeared on Excella Consulting’s Blog

Lean Agile Scotland was an excellent conference. I’ve struggled with how to condense all my positive experiences into a single blog post; this may have to be the first of many. Over just three days, I was able to create new connections, participate in enlightening sessions, and start a number of thought-provoking conversations.

These are a few subjects that I can’t stop thinking about.

Doctrine

My talk fell on the third day of the conference. I adapted it slightly so that I could build on some of the prior sessions. Simon Wardley brought up doctrine in his opening keynote and Will Evans touched on the same subject in his talk on strategy. Doctrine is akin to a culture or an ethos, but more specific; it’s the set of assumptions embedded within a team that informs their behavior. Doctrine is important because it helps to drive decision-making; with a coherent doctrine, team members can make the correct decision for a specific context in the absence of instructions or communication.

I explained why this is beneficial for Agile teams (because I’ve yet to come across one that hasn’t cited the need for “better communication” and “fewer meetings”) and then described how the U.S. Navy went about developing a more coherent doctrine in the early years of the twentieth century by using regular learning cycles, self-organization, and heuristics. I think it worked pretty well. The slides are here, and a video should be coming soon.

Wardley Maps

Simon Wardley’s keynote was very good. I’d seen Wardley Maps on the internet before but never delved deep enough to really understand what they were or how they could be used. Simon explained them in detail, giving some entertaining background on how he came up with them.

weeoo

Wardley Maps are a way to visualize a solution and the associated technologies. Two axes are used. The vertical represents where an item falls on the value chain, with “visible” or customer facing elements of it towards the top and “invisible” or internal aspects at the bottom. The horizontal axis reflects the level of “evolution” of the associated technologies. Evolution is usually represented in four categories: “genesis,” “custom build,” “product,” and “commodity/utility.” Each element of a solution can be mapped on these two axes and decisions can be made based on the current position and how those positions are likely to change. Technologies tend to progress along the horizontal axis, for example, from genesis to commodity/utility.

Teams and team types on a Wardley Map

That is straightforward enough, but what got me really excited was the idea that different types of approaches, with different types of teams, are more applicable to different areas of the map. Simon described three basic types of teams, “pioneers,” “settlers,” and “town planners.” Each of these is more applicable to different levels of technological evolution. For discovery, we want “pioneering” teams who are open to alternative paths. To exploit new technologies, “settlers” are more applicable, and “town planners” are best in the commodity space. Simon explains it here.

Optionality and Uncertainty

Chris Matts presented his own take on these ideas. He tied together Wardley Maps, Cynefin, and Crossing the Chasm in a series of slides that spoke to his belief that Lean Agile Scotland brings together a “community of needs.” He contrasted this with a “community of solutions.”  The main difference between the two can be expressed in one of his favorite ideas: optionality. In a community of needs, new options are created. The goal is an investigation and broader understanding through fostering increased connection and collaboration. This creates more options for each individual and for the community as a whole, fostering greater potential. For Chris, we are a bunch of “settlers.” In a community of solutions, answers are better defined; options are more constrained and context is less important.

Chris tying it all together

Chris and I are currently having a dialog about options and their relationship with constraints. I believe we broadly agree, but I think there are some important differences on how the two interrelate. Can options create new constraints? Can constraints create new options? I believe the answer to both questions is yes, but we need to work through them and explore it a bit more. I’m excited to have the option to do so, and I expect my learning will be the subject of another post.

Melissa Perri took these concepts and made them more immediately relevant to Agile teams in her excellent keynote on “The Build Trap.” She’s seen the problem of teams building, building, and building without having sufficient focus on real value. A key element of this is discomfort with uncertainty. It is difficult to admit that we don’t know exactly how to solve problems for our users. But once we do, we can experiment and learn so that we discover the best approach. Melissa confronted this challenge directly.

Melissa’s and Chris’s sessions tie together because they both force us to think about the opportunities that arise from the limits of our knowledge. That spirit, and the commitment to learn from each other to create new options, is why I think the conference was such a great experience. I can’t wait to go back.

Complexity in Action: Operating in a Complex World

This post originally appeared on Excella Consulting’s Blog.

In the previous posts in this series, I introduced Complex Adaptive Systems (CAS) and described some basic approaches for using complexity to improve the work of Agile teams. In this post, I’ll delve a bit deeper and explain how complexity can help trigger the mindset shift necessary to create an effective environment for Agile teams.

But first, it’s important to revisit the main characteristics of CAS:

  • Greater than the sum of their parts.
  • Sensitive to time.
  • Sensitive to context.
  • Emergent futures.[1]

Each of these has a bearing on the work of Agile teams.

Greater than the Sum of the Parts

Anyone who has been part of a good team has experienced this dynamic. Good teams become more than a collection of individuals. They create an environment that enhances the effectiveness of team members. They learn how to work together, to communicate seamlessly, and to enhance each other’s skills. Good teams become entities unto themselves; they are complex systems.

Although Agile emphasizes the need to develop cohesive, self-organizing teams, the importance of this is often underestimated. There is a lengthy history in modern management of treating individuals as “resources” and assuming that they can be moved from team to team without significant reductions in effectiveness. CAS theory illustrates how this idea rests on a false assumption. Teams cannot be reduced to their component pieces, taken apart, and reassembled. They need to be considered a whole with unique characteristics that are more than the sum of their components.

To be successful with Agile, we need to foster the development of good teams, create environments that allow them to flourish, and let them become effective at working together. Once they achieve that state, treat them as a team, not a collection of individuals. This means shifting the focus of management. Managers become responsible for creating the necessary environment; they shift from managing individuals to managing teams.

Sensitive to Time and Context

This work is aided by becoming familiar with how sensitive teams are to historical events and their current context. Just like CAS in general, Agile teams are a product of their pasts and current environmental influences. This has several important implications.

It is impossible to “rewind” the clock and return to a previous state in a complex system. Historical events and their impact become embedded in a team; they constrain future potential. Focus efforts like retrospectives on broadening everyone’s perspective and validating the diversity of views within the team; there will be no single “correct” view of the past. Acknowledging diverse perspectives will provide a solid foundation for future improvements and ensure they are informed by the experiences of the entire team.

Context exerts a similar influence. I have worked with dozens of Agile teams around the world, from Europe to Asia and North America. Each of those teams had a slightly different context—different team members, different products, different ways of working—and they all approached Agile slightly differently. To be most effective, I had to adjust my approach, and my message, to allow my efforts to resonate with them.

An effective environment for Agile teams needs to recognize this variability. Just as we cannot expect all individuals on a team to react and behave the same way, we cannot manage all teams the same way. What’s needed is a clear set of expectations—well-defined constraints—for how teams will be evaluated and managed. If those constraints are in the “sweet spot” then the teams will have the freedom to improve, grow, and self-organize, and the leaders of the organization will have enough visibility and control to develop the confidence they need. The key is to remember that the “sweet spot” will vary from one organization to another.

Emergent Futures

One of the most exciting aspects of Agile approaches is waiting until the “last responsible moment” to take action. It’s exciting because identifying the right moment can be a challenge, and because it allows us to defer commitment of energy and time until we have the latest (and best) information.

The future is unpredictable. We all know this. But in CAS, we assume the future will emerge, that unanticipated new ideas and opportunities will arise. By waiting until the “last responsible moment” we increase the probability that we will be able to take advantage of these when they do.

The challenge, of course, is that emergent futures are not predictable, and most organizations crave predictability as a means to reducing risk. From the perspective of CAS, this is quickly exposed as a paradox. If we invest in predictability to reduce risk, we inhibit our ability to defer commitment and seize emergent opportunities. The alternative is to reduce risk by minimizing unknowns. If we can go from starting work on a user story to delivering the associated functionality in two weeks, we keep risk very, very small. Agility offers new ways to reduce risk.

To make Agile work effectively, especially in an environment with multiple teams, a mindset shift is required. CAS theory helps us understand the nature of that shift and provides a new window into understanding why Agile approaches are so effective. In these four posts, I’ve barely scratched the surface. If you’d like to learn more about how to apply complexity in your organization, please contact me or one of the other coaches here at Excella.

[1] For a detailed examination of these ideas, see Embracing Complexity by Jean G. Boulton, Peter M. Allen, and Cliff Bowman.

What are Heuristics and How Can They Accelerate Decision-Making?

This post originally appeared on Excella Consulting’s Blog.

In the earlier posts in this series, I introduced Complex Adaptive Systems (CAS), and contrasted Scrum and Kanban from a CAS perspective. I also briefly touched on the idea of heuristics; in this post, I’ll expand on these ideas and explain why heuristics are advantageous for decision-making in complex systems like software development teams.

A heuristic is a guide that aids decision-making. It is not a set rule, but it is a rule of thumb. I use a simple set of heuristics at my local grocery store to accelerate my checkout process. If I have a basket of items, I will use the self-checkout. If I have a cart, I’ll look for the checkout line that has the least number of people in it. If two lines have the same number of people, I’ll choose the one with the fewest items. These guidelines are simple heuristics and we all use techniques like these, even if we’re not always aware we’re doing so.

Heuristics are powerful because they accelerate the process of making decisions. We don’t have to spend time assessing all the potential options, performing a cost-benefit analysis, and ranking alternatives. Instead, we employ a specific set of guidelines to quickly arrive at what we believe to be the best option.

Heuristics in Complex Systems

Why is this important and how does it relate to complex systems? In an earlier post, I noted how CAS are extremely sensitive to context. The specific ways in which the individuals in the system interact and the constraints that act upon them vary; the nature of these interactions also change over time, altering behavior within the system and its potential for change. This makes complex systems dynamic. To operate within them effectively, flexibility is needed.

Heuristics offer the necessary flexibility. Because heuristics are not set rules, they can be quickly tailored to specific contexts. I can adjust my grocery store heuristics based on circumstances. If I’ve got a bottle of wine in my basket, for example, I might opt for a checkout line over the self-checkout because I know that a cashier will be able to check my age and validate I’m over 21 faster than the attendant overseeing the self-checkout machines. If children are with me, I may look for the line with no candy, regardless of its length. Because I’m using heuristics, I remain sensitive to context and can tailor my decisions quickly and easily.

That’s the power of heuristics. They inform decisions without substituting for them. Heuristics enable human judgment by rapidly framing the problem and allowing our minds to focus on the specifics of the situation. This leads to quick decisions that factor in valuable contextual information without overly complicated and unnecessary rules.

Heuristics in Agile

What’s this got to do with Agile software development? Agile software teams make decisions every day. How can those teams ensure that these decisions happen rapidly and align with their overall goals? One way is to make sure they’re made collaboratively. If teams regularly talk about their work and the impediments they’re facing (like in the daily standup), then their collective knowledge and experience will be brought to bear. However, many decisions are made outside of those collaborative sessions. How can we ensure they’re made rapidly and reflect the team’s objectives?

Heuristics are the answer. By explicitly developing heuristics to guide their decisions, teams can make decisions more rapidly, ensure the outcomes align with their objectives, and leave room for individual judgment and creativity. An excellent heuristic at work in software development is the “rule of three,” a simple heuristic that suggests code can be copied twice, but should be refactored into a new procedure the third time it is used. Another common heuristic builds on the Agile principle emphasizing face-to-face conversation: whenever you have a question, ask it face-to-face; if that’s impossible, use a video conference; and if that’s not available, use the phone.

Try Them Out!

Explicitly defining heuristics can accelerate the decision-making in Agile teams. Because they are sensitive to context, heuristics can adapt to a variety of different circumstances; they won’t age and become obsolete like “agreements” or “rules.” Teams employing heuristics can make decisions more rapidly and be more confident that day-to-day decision-making aligns with their goals. By allowing team members to utilize their knowledge and skill, heuristics foster greater engagement and morale. They fit perfectly into a view of software development as a complex adaptive system.

Try defining some heuristics and see how they can improve the effectiveness of your team! Next in this series, I’ll write more about how you can improve the work of Agile teams by employing ideas from complexity.