Not having the right mindset is a core obstacle or impediment when it comes to introducing or sustaining agile in any work environment. To fully understand the issue at hand, it makes sense to investigate the innocent word “we” in “We don’t have the right mindset” - because more often than not, this statement is meant to indicate that “We, as a company/business line/department” don’t have the right mindset, whereas “we, as a team”, or even “me, as an individual” actually do have the right mindset. It’s very uncommon to find a team or an individual that freely admits that, while others do possess the right mindset, their own mindset is just not right for Agile.
Or, in other words: The right mindset is something that is lacking in others, not in me.
The topic of a right mindset can be a sensitive one, acting as a red flag to certain people, mainly for the following two reasons:
- People who are quick to point out that others are lacking an agile mindset have a hard time providing a definition of what the characteristics of the “right” mindset is. In essence, they claim they “know it when they see it”, which makes it impossible to argue about.
- The argument about having the right or wrong mindset often drifts into the territory of the True Scotsman Fallacy, which, according to Wikipedia, goes like this:
Person A: “No Scotsman puts sugar on his porridge.”
Person B: “But my uncle Angus is a Scotsman and he puts sugar on his porridge.”
Person A: “But no true Scotsman puts sugar on his porridge.”
– Wikipedia: No true Scotsman
It seems that the “right mindset” is an elusive beast which you know when you see it, but only if you already have it, but which you can’t otherwise pin down, measure or test.
Building an Agile Mindset
If we want to talk about mindsets, we need to have a common understanding what a mindset is - both in general terms and in the context of agility. An elusive definition that seems to change whenever we look at it just won’t do. Therefore, the upcoming sections will deal with defining what a mindset is, and then build a definition of an Agile mindset on top of it. With that definition under our belts, it will be easier for us to argue about its role in the context of Software Development.
Results, Behavior, Assumptions and Values
Let’s start at the end, at the results any mindset produces, because that is what we see in co-workers and what we believe is the result of their mindset: The result. On a high level, the result of any company is an exchange of payment for service.
- Payment ultimately translates into money, but it can be something else instead. Another form of payment are, for example, data. In the context of Lean Startup, it’s not uncommon that the first revisions of a product cost more money than they generate, but during these revisions, a lot of data are collected and processed, to help making future iterations better and thus generating more money in the long run.
- Service can be a piece of software that a company delivers, or a website, or even the right to use a certain piece of software for a specific period of time.
From the customer perspective, the results are good if they feel they are getting the same or more value for the payment they delivered, and for the supplier, the results are good if the value they are getting through the customer’s payment is higher than or equal to the service they provided. Even though it sounds like a paradox, it’s possible for both parties to get more value than they paid for: In an early phase of a product driven by the principles of Lean Startup, a company might give away a valuable service for free, generating satisfied customers, while collecting a lot of data which is valuable for them, so both parties can win.
Let’s dive a bit deeper into the payment part. As stated above, the results are good from the customer’s perspective if the payment outweighs the expenses. It needs to be stated that the expenses by a company are more than simply the transferred goods or services. This is a fact that is often overlooked in the software industry, but well-known in other industries: If you deliver a real, physical thing, the customer does not only pay the thing itself, but, for example, it’s wrapping and the maintenance and care of the machine which does the wrapping, and even reserves to buy a new machine should this one break.
For the software industry, this means that we should define results as good not only if the customer is happy and the performance of the team is good, but also if the individual well-being among the engineers is good, and the working relationships within the team are good. You can’t argue that the results of a company is good if it comes at the expense of the people producing it, the same way as you can’t argue that results are good if all your machines are overloaded and never maintained: Both scenarios make for individual happy customers, but are not sustainable for long.
Results Are Produced by Behavior
Going one step back, we can see that results are ultimately driven by behavior. In simplistic terms, we can say that doing or not doing something creates a result. This is true on any organizational level: A team can express a certain behavior, much like an individual can express a certain behavior - an insight that seems trivial at this point, but is of consequence later on.
Since we define a good result not only as high-quality output, but also as positive and sustainable circumstances under which the output has been produced, it follows that multiple facets of behavior contribute to good results - not only behavior that directly produces something, like engineering a certain solution, but also behavior that impacts the well-being of the involved individuals. This is why team events or company parties also contribute to the positive results of that company.
Behavior Is Driven by Assumptions
What drives the behavior, both on the organizational and individual level, is a
set of assumptions that we have. The most straightforward assumption to name is
that we work on a specific part of the product because we assume it’s important.
We test our software because we assume that we make mistakes which would be
delivered to the customer without testing.
Less straightforward, but equally important assumptions are that we withhold information during a meeting because we assume we would be attacked, humiliated, or both, because of it. This frequently happens in the light of a deadline, where things simply have to be delivered and the stakes are high. As we will see later, specific mindsets create an environment where it is not safe to point out risks or flaws in the light of a high-stakes discussion, so people withdraw, because they (often rightfully) assume that they would have to face negative consequences otherwise.
Assumptions Are Influenced by Values
A big part of what actually shapes assumptions are values. For example, a lot of people value acting rational in a professional context. This value can then shape the assumption that an emotional reaction is a sign of a lack of self-control, leading to a distant behavior towards colleagues who openly express their emotions. Another very common assumption is that it’s generally better to win than to lose, which can shape the assumption that many, if not all, situations are actually about either winning or losing, and not about something else (like finding a common solution that works for everyone).
A Mindset Is the Sum of Values and Assumptions
Let’s put everything we have discussed so far in the right order: values that we hold dear influence and shape our assumptions. Both of these drive our behavior, which, in turn, produces our results. The sum of values and assumptions is what we define as a mindset. With this definition at hand, we can now proceed to define an agile mindset as certain values and assumptions, and a non-agile mindset as another set of values and assumptions.
Before we do that, however, let’s circle back to the trivial insight we generated above: Results are produced by individuals, teams, business lines and companies, and these results are obviously driven by the behavior of individuals, teams, business lines and companies. It’s important to note, in addition, that the behavior of groups is driven by the mindset - values and assumptions - of that group, which are not necessarily the values and assumptions held by everyone in that group. In the same way as there is collective intelligence in any group, there is also a group mindset which drives the behavior of the group.
The Agile Mindset
There is much to say about the agile mindset, many assumptions and values that form it, but there is one pair of value and assumption that eclipses everything else. It’s like this pair is the sun, and every other value or assumption is a planet circling that sun. Without that core part firmly in place, an organization, team or individual will struggle more with Agile than others, regardless of all the other qualities we will discuss later.
Valuing Learning above everything else, and assuming that we can always get better at how we do things form the fundamental base of any agile mindset. Agile methodologies are firmly set on the concept of validated learning. Typically, we set a goal, set a metric which represents the goal, try something out, inspect the results and adapt our approach. It’s important to note that we need both the value and the assumption for an agile mindset:
The assumption that we can always get better at how we do things absolves us from plateauing with our performance. If we assume that we are never done, and that we haven’t delivered our best work yet drives us forward. Without that assumption, Kanban teams will rarely find things to improve on, and Scrum retros will be over quickly, stating that there is “nothing to improve”. We should start proactively looking for ways to get better, even if the environment in which we are moving is less than ideal. We stop looking for others to make us better, and instead start looking for strategies to take matters into our own hands.
The focus on learning gives our drive structure and purpose, and helps us to put first things first. Without valuing to learn, we might be afraid of trying out new things lest they fail, with this learning mindset, we expect failures and treat them as learning experiences to get better with the next try.
Working together as an agile team requires a great deal of learning. First, we need to learn to work together. We are all different from one another, with different strengths and weaknesses, some of which only come out in stressful situations. How we deal with those when push comes to shove is something that any team needs to learn. Once it has mastered that, they need to move on to learning how to create happy, satisfied customers. Here, the key assumption needs to be that we do not know already what they want, even if they outright tell us, but that there is always something to learn, and always a way to deliver better software faster. The learning mindset automatically leads us to the fundamentals of Agility - so ultimately, it’s the mindset that came first, not Agility.
For example, valuing individuals and interactions over processes and tools reflects the fact that a process ideally represents the best way of working together based on historical learnings, but that it’s the individuals which are interacting with one another who do the actual work, and who can learn and improve above and beyond any given process. Collaborating with customers with the aid of working software is the most efficient way to learn what the customer wants - since we acknowledge that there is a better way to do things, we might as well face this fact head on and try to uncover this as soon as possible, rather than sticking to the plan until it catches up with the reality.
This key ingredient to an Agile Mindset is what Carol Dweck calls a “Growth Mindset” in her best selling book “Mindset”.
Learning Alone Is Not Enough, It Needs to Be Mutual
A Growth Mindset with the focus on learning is valuable, but it makes only half of a truly agile mindset. The other half is similar, yet not the same, and is best described in “The Skilled Facilitator” by Robert Schwarz, who calls it the “Mutual Learning Mindset”.
The key point is that a person with an Agile Mindset does not only seeks personal growth and learning, but sees any team discussion as a mutual learning experience. Meetings become learning groups where all participants learn as much as they can about the problem and its possible solutions. Post-Mortems turn from finger-pointing and blaming into learning how, where and why the team failed, and how, where and when they can do something to prevent the same mistake in the future.
In his book and on his website, Schwarz defines five values and five assumptions, which drive eight behaviors.
The list of assumptions reads like a guideline for successful meetings in any context:
- I have information and so do other people
- People may disagree with me and still have pure motives
- I may be contributing to the problem
- Each of us sees things others don’t
- Differences are opportunities for learning
(List taken from here)
To fully answer the question about an agile mindset, we need to understand what a mindset is and how it impacts us. A Mindset is the combination of assumptions and values which drive our behaviors, which in turn produce our results - individually, as a team and as a company.
An Agile Mindset revolves around learning: The foundation is the assumption that most things in life are learning opportunities, and mistakes and failures provide us with data to do better in the future.
This does not only apply to us and ourselves - an Agile Mindset is about mutual learning, which turns every team interaction into a common learning experience.