Apr 19, 2017
How to grow an “and” mindset
The relationship between an agile mindset and tools
Agile is not Scrum. Agile is not XP either. Agile is not Lean, or SAFe or Kanban or JIRA or Confluence or TDD or pair programming. Those are all processes, frameworks, tools, or techniques. They certainly help a team to be more agile, but in itself it is by no means proof that you are agile.
Or, to quote Steve Denning in a post on the same topic (a recommended read for those new to agile and the experienced agile evangilists):
“As the Agile Manifesto itself said, individuals and interactions are valued more than tools and processes. Without the Agile mindset, tools and processes achieve little.”
Agile is a mindset — not a tool, process or methodology — described by four core values. Yet, all the certifications currently out there focus mainly on teaching the things of agile — the tools, the processes and the techniques associated with agility.
This brings up the question of what to teach first? The mindset, or the things? Without the tools, you can’t teach the mindset, and without the mindset, the tools have little value. So now what?
The chicken or the egg
The chicken and egg question has had me thinking about it for years, even decades. It’s one of those puzzles that I really wish I could solve, yet the answer keeps eluding me. As soon as I convince myself that it’s the one, the other starts reminding me of their role and their importance, and the cycle starts all over again.
But what if it’s the wrong way to look at it? What if it’s not the one or the other that is more important, or first?
What if it’s the relationship between the two — the and, rather than the or — dynamic that is important, rather than what comes first? When you look at the yin and yang symbol, it’s kind of like the chicken and the egg. It’s a continuous cycle with the one growing into the other. It never stops. Each egg needs a chicken, and a chicken comes from an egg. The one is necessary for the other to exist. Not more important than the other.
What if that is how to look at with an agile mindset? Our focus is on either the one or the other at a time, yet we need both in order to be agile. The one can not be excluded at the cost of the other, they need to co-exist as a balanced entity with the one supporting the other.
Like looking at an object from different angles, you get a more complete picture than only judging it by the one aspect that is right in front of you. Knowing what an object looks like (outside) and how it works (inside) gives you a better understanding than only looking at one aspect.
3 Techniques to practice an “and” mindset
An “and” mindset is at the heart of agile and can be applied to everything, from the different roles that need to be included for a story to be considered done, or gathering requirements.
In fact, any issue you might have in your team where there is blame involved, calls for a practice of a more inclusive mentality. Here are three techniques to help you get started:
Forced Analogy
Based on the idea that we learn by linking, looking for how things are similar to something we already are familiar with, the Forced Analogy game is a fast and creative way to not only solve a problem but also practice an “and” mindset.
De Bono’s 6 Thinking Hats
The father of creativity and lateral thinking Edward de Bono created, in his words, “…a simple, yet effective parallel thinking process that helps people be more productive, focused, and mindfully involved.”
By systematically working through all the different thinking modes, the team learns to include different thinking into their decision making. Here’s how it works.
The facilitator presents the chosen problem for which a solution is required to the team. Explain the 6 Thinking Hats briefly describing the focus of each color.
Choose a color hat and each person in the team now metaphorically puts on this hat, only thinking with the focus of the mindset associated with that color. Set a timer for 7 minutes and each person contributes their “white hat thoughts”.
Once the timer expires, take off this hat and put on a new color hat, repeating the exercise.
Play around with different roles to replace the hats. For example, the requirements team are generally associated with a yellow, positive mindset, whereas testers are more associated with a black, what-can-go-wrong mindset, and a developer usually wears a white, facts-only more realistic hat.
A different perspective
Finally, a quick exercise, this technique aims to open teams up to the possibility that there might be a different, valid, perspective other than their own.
Take a random photo or picture and ask each person in the group to write down briefly how they interpret the image without speaking to the anyone. Think about where the people are, how they are feeling, why, and what they are doing there.
In pairs, turn to each other and discuss your interpretation, validating where necessary. As the listener, try to look for validity in their story and understanding how they got to it.
After the exercise take some time to reflect on the similarities and the differences between the various viewpoints, and how more than one story could possibly be valid for the same image.
An Open Mind
The key take-away is to show that an or point of view is a limited viewpoint. Whereas an and point of view allows for more possibilities.
That is the essence of an agile mindset — it’s an open mind looking for similarities and how two parts can complement each other, rather than the differences.
An agile mind is open to different perspectives. There is not a right or a wrong. There is only more information.
With this mindset, suddenly it’s not an us-vs-them competition of who is right or the winner, but rather a win-win complementary relationship between different skill-sets. The more perspectives, the better your view.
Suddenly, it becomes a coherent partnership with diverse skill-sets working together to create a better end product. The designer focuses on the aesthetics, the developer on the functionality, and the tester serves as the insurance policy ensuring that the requirements are met.
All, ultimately contribute to the same outcome, namely value to the customers.
“The whole is greater than the sum of its parts” — Aristotle
