When Language Makes a Difference: 7 Agile Coaches Key Differentiations
Organizational change starts with expanding our vocabulary
Can We Change Things That We Can’t Name?
Imagine you go to a bar in which there is only one option on the menu: “drink”. How likely is it, that you’ll get what you’re looking for?
For most of us, there is an essential difference between a glass of beer and a Piña Colada. The more we care about something, the more we tend to differentiate between things within that domain. And the greater our expertise is, the larger the vocabulary we need in order to express the meaningful differences between things that might seem to be the same.
Recently I explored together with my fellow agile coaches at idealo the idea of key differentiations for agile coaches. This was inspired by my practice of nonviolent communication (NVC). Marshall Rosenberg, the creator of NVC used such key differentiations to describe the mindset he was teaching. A key differentiation is like a mental data-structure with which we make clear:
We came up with more than 30 key differentiations that make a difference in our work. Here are 7 of them, which I believe every organization should have in its vocabulary:
Complicated vs. Complex
Probably the most important differentiation. In complicated problems, there is a clear relationship between cause and effect. An expert can analyze the problem and find the right solution. An example of a complicated problem is “how to build a bridge?”. This is totally different than the domain of complex problems, where too many variables play a role and there is no clear relationship between cause and effect. An example of a complex problem is “how to reduce the number of car accidents in Berlin by 30%?”.
Agile methodologies were created to help deal with complex problems. They are quite useless in the context of complicated systems. The same goes for product discovery and design thinking.
Understanding whether the problem you’re facing is complicated or complex will determine the way you’ll go about dealing with it. For example, no expert can tell you which product strategy will make your organization successful, or which agile framework will work for your company. In the domain of complex problems, we need to accept the fact that no one has the right answers for us. We discover our answers by experimenting, learning as quickly and cheaply as possible, and adjusting according to our learnings in short iterations.
Dealing with complex problems as if they were complicated is the fast lane to failure
Wanna go deeper? Check out
- Frederic Laloux: a new way to think about change
- Dave Snowden: cynefin framework
- Niels Pfläging: Organize for complexity
Problem Space vs. Solution Space
When it comes to solving complex problems, it’s essential to first understand the problem before coming up with any solution ideas. It makes sense to explicitly separate the problem space (understanding the problem) from the solution space (deciding what to do). Actually, that is exactly what you do in a design sprint. Focusing only on the problem before trying to solve anything increases the chance that you’ll develop holistic and sustainable solutions.
As a facilitator, you can help a team by explicitly decoupling the problem space from the solution space and making sure different perspectives of the problem are explored before solution ideas are considered.
Consensus vs. Consent vs. Other Ways of Deciding
In terms of agility, one does not “simply make a decision”. There are many different methods of making a decision. They all have pros and cons. And some of them are more suitable than others for making fast decisions in a complex environment. If you don’t explicitly define which decision-making method will be used in which situation, you take the risk of decisions being too slow or not representative enough. It’s comparable to not deciding if you’ll go somewhere by foot, by car, or by plane.
The following decision-making methods are known to be fast and suitable for complexity:
- Frederic Laloux’s advice process
- Holacracy’s Integrative Decision Making process
- Systemisches Konsensieren (for the German speaker)
Wanna go deeper?
You also might want to check out this overview of various decision-making methods or use this app to help you choose the suitable decision masking process for your specific situation.
Push vs. Pull
According to Kanban, any system that doesn’t strictly maintain explicit WIP limits is working in push-mode. A system works in pull-mode if it only starts to work on new items when the WIP limits haven’t been reached. In push-mode additional work is assigned to already busy people. In pull-mode people start considering new work items when they delivered what they were working on. Why does this matter? because push systems are extremely wasteful while pull systems allow you to deliver in a more predictable way.
Minimizing the amount of work in process and using Pull instead of Push are effective counter-measures to multitasking and have a huge impact on the productivity of product development teams. — Stefan Willuda
Many problems related to (mis-)alignment or organizational busyness result from multitasking on the organizational level that is at the core of the common (and usually implicit) push-approach.
Interpretation vs. Model-Based Interpretation
As agile coaches, we make observations, i.e.:
- Team A and Team B have conflicting goals,
- decision regarding X took 5 weeks,
- the product owner is writing code.
When it comes to the question of why the things we observe happen, it’s tempting to interpret based on the first idea that pops up in our minds. While our gut feeling might be correct, there is value in using multiple mental models in order to interpret our observations:
- It’s easier for others to understand our interpretations when we explain the mental model behind them.
- Interpreting a single observation with multiple mental models allows us to gain more perspectives. It also acknowledges that all models have a narrow view of reality. We stop talking about “the truth” and become aware of various ways to interpret things.
Ideally, mental models are like pairs of glasses we can wear, that allow us to see reality in a certain way. Here are some examples of mental models. You might want to add them to your collection:
- Change management: Kotter’s 8-Step Cahnge model
- Conflict: Glasl’s model of conflict escalation
- Team dynamics: Kantor’s 4 player model (+ some other goodies about mental models in this article)
Group vs. Team vs. Other Constellations
If there’s no common goal, it’s not a team. In the context of organizations, coaches meet “teams” where no shared purpose exists. Having the vocabulary to differentiate between “groups”, “pseudo-teams” and “teams” will help you notice faster that something is off. You will not waste your time on team building and purpose workshops if you realize “the team” is actually a group.
First they need to have a common/shared goal and second, they need to truly need each other to reach that goal. — Stefan Lindbohm and Viktor Cessan
Wanna go deeper?
Stefan Lindbohm and Viktor Cessan: The first question to ask when building teams — is this really a team
Genesis vs. Commodity
This differentiation comes from Wardley maps. It describes how products and services our businesses are dependent on evolve over time and how to deal with that change:
When something is created for the first time it considered genesis. There is a lot of unclarity regarding how it works, how to use it, and what are the benefits of using it. This is the case with new technologies. You’re basically inventing the wheel. Over time there are some people who can custom build something using the new technology. It’s still very rare and requires expertise. After some more time, this technology or solution is turning into a common and standardized product. It’s more known, it’s easier to find and cheaper to buy. In the last step, it finally turns into a commodity. It’s produced efficiently in a highly standardized way by many providers.
Twenty years ago people used to hire an expert to build a customized static website for them. Nowadays there are many drag-and-drop solutions for building interactive websites which include an online shop for a minimal budget.
This is a big deal because organizations become slower than their competition whenever they try to custom build utilities that are already a commodity. Moreover, new commodity solutions allow you to create new products and services that were previously unimaginable.
Today’s services are tomorrow’s platforms — Marty Cagan
This is also true about agile. Ten years ago you needed an expert to introduce and facilitate retrospectives and other agile ceremonies. Since then, every developer who works in an agile context has experienced hundreds or even thousands of such ceremonies. There are tons of recipes for retrospectives online and templates in tools like miro that let you run a retro with minimal preparation. The work of agile coaches has to evolve accordingly. We need to be where our work makes a difference, and stay away from work that can be done by our clients.
Final Thoughts
Key differentiations allow us to explain our ideas precisely by discerning between words that people might otherwise use interchangeably. They also allow us to prevent misunderstandings about concepts and goals. I believe they come in handy when we want to onboard someone to our way of thinking. Can you come up with any other meaningful key differentiations for agile coaches? Please share them.
loving agile product development? Have a look at our vacancies.
