Matthias Eiford: Thank you so much. I am sharing my screen now—I hope you can all see that. Okay, fantastic.
Hello and welcome, everyone, to this learning session. Thank you for the introduction, Denise. My name is Matthias Eiford, and I'm very happy to see all of you here today. Thank you for spending your lunch or evening with us, whatever it might be.
Since you are here, it seems there isn’t much of a need to try to impress you with my credentials at this point. But just to give you some quick context—I’m a coach and delivery lead at Excella, an agile technology and consulting company headquartered in the DC area. If you’ve attended any agile conferences or coach camps in North America over the past few years, chances are you’ve come across a session by one of our coaches or scrum masters. I am fortunate to work with some truly awesome people, and we are heavily involved in the agile community.
Personally, I’ve been at this for about 20 years, starting with hardcore quantitative quality work, then moving into software, then agile, and for the past few years, bringing all of that together through the lens of complexity and Kinevin.
On the slide, you’ll also see my contact info—feel free to connect with me on LinkedIn, email, or Twitter if you’d like to continue the conversation after today.
Setting Expectations
Before we get started, I hope you noticed that the subtitle of this session is “Why Agility Allows Us to Thrive in an Unpredictable World”, not “How.” We will get into some of the “how,” but I want to set expectations that this session will also contain a good amount of conceptual discussion. In my observation, this is actually a big part of the problem the agile community is increasingly facing—we're not always seeing the results we're being told to expect, and people are questioning agile and agility.
To me, agile is a mental model—a mindset. It’s about the way we do things, not just how to do things. But between corporate pressures to implement it quickly, daily overload, and the frameworks everyone wants to sell us, we often get so caught up in doing agile that there’s not much time left for reflecting on it.
As a community, despite our best efforts, we may have maneuvered ourselves into a corner where we’re permanently stuck executing the same things over and over—kind of like being stuck at the “Shu” level of Shu-Ha-Ri. It’s easy to get caught up in just implementing agile practices and demonstrating results while constantly arguing against inertia, constraints, and pushback.
So, I invite you to look at the next 85 minutes as an opportunity to take a step back, connect some dots, and make sense of things together by going back to the “why” of agility—to borrow a famous slogan.
Participant Poll
I’d love to learn a bit more about all of you and your contexts. We have a quick poll—Matt, could you pull up Poll 1, please?
If everyone could check the appropriate boxes quickly, we’ll get an idea of where people are coming from. Don’t overthink it—we’re just trying to get a rough sense.
Seeing a few responses trickling in... Okay, we’ll give it a few more seconds. We’re at 19 out of 26. Let’s see... okay, we’re at 21. Fantastic, thank you. That’s probably good enough. Now, let’s share the results.
Great—this is actually an interesting distribution. We do have people from IT—just barely the majority—but we also have a lot of business, non-IT, and participants from other domains. Exposure to Kinevin—some are applying it in their work, which is great, while others are more at the starting point. Lots of familiarity with agility, though some people are just beginning. Fantastic! This gives me a good starting point.
Introducing Kinevin
I just mentioned the constant battles we find ourselves in. The Kinevin framework, conceived by Dave Snowden in 1999, helps us make sense of these battles by identifying different problem contexts. It actually predates the Agile Manifesto by a couple of years and describes four problem domains, plus a fifth domain in the middle, which we’ll get to later.
Let’s start with a quick walkthrough of Kinevin.
The first domain is the Clear domain (previously called Obvious). This is the nice, stable corner of the universe where things are predictable. If we define what we want to achieve, there is a clear best way to get there, and we can repeat that process reliably. Think about making fries at your favorite fast-food restaurant—this is the realm of best practices and standard operating procedures. This is sometimes referred to as the context of known knowns.
Next is the Complicated domain, where we have multiple good options and need analysis or expert knowledge to determine the best one. This is the realm of good practices, where reliable cause-and-effect relationships exist but require effort to uncover. Engineering, science, and business rules typically fall into this category—contexts of known unknowns.
Both Clear and Complicated domains are part of what Snowden calls ordered systems.
Then we have the Complex domain, where inputs interact in unpredictable ways, and cause-and-effect relationships can only be seen after the fact. This is where markets, consumer behaviors, policies, and organizations operate. We are dealing with unknown unknowns, where outcomes vary, and past success does not guarantee future results.
Finally, the Chaotic domain is where everything is messy, random, and often urgent. If the Complex domain is foggy, the Chaotic domain is a full-blown dumpster fire. Here, we must act first, then make sense of things and respond.
In reality, problems rarely fall neatly into a single domain. Even in Clear problems, humans introduce unpredictability, and Complex problems contain elements that may be straightforward or solvable with analysis.
Complexity and the Agile Connection
For the rest of this session, we’ll focus mostly on the ordered (Clear and Complicated) and Complex domains, because that’s where our daily reality unfolds—and where the biggest tensions exist.
One key difference between these domains is predictability. In the ordered domains, we navigate a mostly predictable environment where we know what will happen when we take specific actions. On the left, in the Complex and Chaotic domains, unpredictability reigns. Doing the same thing twice may yield different results because of hidden inputs and unknown relationships.
Agile operates within the Complex domain. The iterative loops of Scrum’s inspect and adapt cycle, Kanban’s continuous improvement, and even Deming’s PDCA loop all align with the principle of probe, sense, respond. Agile is designed to work safely and effectively in complexity.
At its core, agility isn’t just about delivering software or following frameworks—it’s a response to uncertainty, change, and unpredictability.
Breakout Discussion
Now, let’s move into a breakout discussion. Think of an example where your organization has an unrealistic expectation of predictability. Consider what drives this—are there constraints, incentives, or cultural factors? Do the affected people have the authority to make changes? If so, what could be done?
We’ll give you a minute to reflect, then Matt will place you into breakout rooms for discussion.