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.

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.

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 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.