Transforming to an Agile Mindset, Part 1

“Martin’s Problem”

Once, over beers late into the evening in an old European pub not far from his office, an executive shared with me his personal Agile mindset transformation journey. It is an account that I have found representative of many when they begin to lead Business Agility transformation. But first, some background.

A few years ago, I had the privilege of helping convene a Learning Consortium for a cohort of companies that were each on their own Agile transformation journeys. They banded together to visit and learn from each other, and I observed and facilitated. The diverse cohort included a large manufacturer, Magna International (MGA); a large software company, Microsoft (MSFT); fast-growing software companies, Riot Games and Brillio; a large logistics company, CH Robinson (CHRW), a large telecom company, Ericsson (ERIC); and smaller innovative companies such as SolutionsIQ (now, part of Accenture), and agile42.

Though learning consortia had been operated over the years for other disciplines, as far as we knew this was the first one to focus on how companies are coping with adopting at scale new management practices that generally go under the umbrella name ‘Agile.” We made nine site visits in three countries, four US States, and one virtual visit. Afterward we gathered to draw up and publish our observations and conclusions. One of the conclusions everyone agreed upon was that regardless of how different the culture and operations were at the visited companies one thing was clear: When attempts were made to implement new practices, no benefits were observed unless they were accompanied by a supporting new mindset.

A universal feature of all the site visits was a recognition that achieving these benefits is dependent on the requisite leadership mindset. Where the management practices and methodologies were implemented without the requisite mindset, no benefits were observed.–Learning Consortium for the Creative Economy, 2015 Report (Denning, Goldstein, Pacanowsky)

Since then the topic of the “Agile Mindset” has become more and more prominent. Experienced Agile coaches and consultants have regularly observed that the greatest impediment to transforming organizations is transforming the mindsets of its members. It is easy to train Agile practices such as Scrum and get people started working in teams. It is even easier to install collaboration tools like Microsoft Teams and Jira. So that is what a lot of folks do, they do the easy stuff. And then they wonder why there are no benefits from the change efforts. Worse, in too many cases the organizations struggle more than before they attempted the change.

This is the first in a three-part series to focus on how to understand the Agile Mindset, how mindsets change, and how we might become better mindset change agents. This first part we will look at what mindsets are generally and explore the foundation of mindsets, our values. But first…

Meet Martin

“Martin” is an executive at a technology company who has been successful though the normal course of traditional management from business school and up through increasing responsibilities. By the time I met Martin he had P&L responsibility for leading strategic business units within a 100,000-employee international company.

Martin was given the assignment to transform one of his company’s units, this one of about 2,000 people, which is responsible for the design, engineering, deployment and support of a couple of mission critical products in their industry. Martin knew that so far only one other unit had been successful in making this transition to these new “Agile” ways of working, so he called up his peer leading that unit and said: “Send me the plan you followed for your Agile transformation.” To which he was told:” Sorry Martin, it does not work that way.”

“What do you mean it doesn’t work that way, tell me how you did it.” Martin demanded. Martin’s peer explained further, “It will not work like you think, and following what I did won’t help you either. But I tell you what I will do, I will send you the Agile coach who helped me.” Martin reluctantly agreed, and the coach showed up not long after Martin was transferred to his new unit. Naturally Martin felt pressure to immediately begin implementing the changes.

“Sorry, Martin, it does not work that way.”

Agilist Antipatterns

Martin went on to tell me over another beer late that night what the conversations were like between him and his Agile coach. They went something like this. Martin would suggest to the coach, “OK, so it seems we need to do this and this, to get this transformation going.” The coach would reply, “No Martin, you really don’t want to do that.” Martin didn’t give me details on the suggestions he was providing, however traditional managers in transformation situations like this have common themes. Sometimes agilist borrow the term “anti-patterns” which are applications of common solutions that seem to make sense at the time, but end up having bad consequences that outweigh any benefits.

I was reviewing an Agile project plan recently created by someone unskilled in Agile and saw one of these. It had to do with the metrics they recommend to measure the Agile team’s output. The plan suggested using team “velocity”. This is an anti-pattern well known to have bad consequences such as the team gaming the relative estimation process to increase their apparent velocity to be measured more favorably. Other consequences to misapplying the velocity metric usually include obfuscating the real information a team needs internally to help them stabilize and plan their work flow, impeding the team’s self-directed continuous improvement, and interfering with the team’s ability to prioritize using value versus effort.

After such conversations, Martin would take some time, learn some more and then come back to the coach try again: “OK, I think what you really mean is that we should do this, and this.” To which to coach would sometimes be compelled to reply, “Martin that is actually the last thing you want to do.” Martin went on suggesting all the traditional ways he knew to make a company change and improve he had relied upon for his entire career. Surely this Agile thing can’t be all that different.

And on it went, for eight long months with no change taking place except Martin just getting more frustrated. Until the time came for Martin to take his summer vacation.


On vacation Martin brought a couple of books on this new Agile management approach, one of the most influential he said was Steve Denning’s “Radical Management”. With some time to relax, read and think about the these last eight confusing and frustrating months, while sitting poolside with his book in hand, all at once the pieces started to come together in a new way. Martin had this kind of “aha” experience. Right there from vacation Martin called his coach and tried again, “OK, I think I am getting it. Are you saying we should do this and this?” to which the coach replied, “Martin, now you are starting to get it.” Excitedly Martin continued, “And after that something like this and this?” Gladly for Martin his coach replied, “That’s it, Martin. When you get back, now we can begin.”

Indeed, changing one’s perspective is not easy for anyone. Here we can see that a highly competent and successful executive who made a sustained effort while submitting to good coaching guidance, that it still took eight months for a new mindset to form sufficiently to start aligning decisions around the new mindset. That is a long time in today’s fast-paced technology world that some describe as if we are operating in “dog years” where every month is like seven — which makes Martin’s delay the equivalent of almost five years! Yet this unit had already had one failed attempt at an Agile transformation by a previous executive before Martin. Even with the delay, Martin was wise to wait until he underwent his own Agile mindset shift. Today his unit is a shining example of how to succeed with Agile. Though he reports it was not always easy, they are in a much more sustainable competitive position, while some others they once competed with are no longer even in existence.

What did Martin experience? And can anything be done to speed up a mindset shift?

Shifting Gears

First let’s consider what makes up a mindset. “Aha” experiences are fundamental shifts in the habits of the mind. An Agile mindset change requires the ability to shift one’s paradigm between traditional and Agile ways of being and doing. We know that a mindset can also be described as a paradigm, a worldview, or a perspective. Some of us have compared this Agile mindset shift to one of the best examples of paradigm shift in history: the Copernican revolution.

For many of us who are systems thinkers who have for example developed products, written code, led IT system implementations, or even led organizational change, I think it is helpful to consider a mindset as simply another system, the system and structure we use to think. I became fascinated with this area in college and studied epistemology, the philosophy of how we know what we know where we looked at the impact of worldviews.

World views are thinking systems that can be thought of as containing three types of components, 1) specific views of self, 2) convictions we hold, and 3) behavioral habits that emerge from these. Breaking it down further, we can see that our views of our self can be understood as a set of values that we believe and upon which we base our identity. The convictions we hold can be understood as a set of principles or guidelines we use to make decisions that support our values. And the practices we adopt help bring into the world the actions we choose.

A mindset is like other systems – in this case, a thinking system


Values, Principles and Practices

At the foundation are a collection of Values, upon which rest the Principles that align with those Values, and at the most malleable level are the Practices. When we are attempting to bring into an organization capabilities like Agile, all three areas need to be addressed in their own way. This kind of development falls under the theory and practice of transformative learning, which is distinct from of traditional education. For example, courses like my Managing the Radical Shift to Agile at the University of Chicago, or Agile training like the Certified ScrumMaster course that about 10,000 people attend per month, spend the first day to build an Agile mindset foundation before getting to the specifics of Agile practices like Scrum on day two.

That emphasis on the first day can be confusing since folks attend these types of courses are presuming they are going to learn the mechanics of Agile’s collaborative team ways, and the “sprints” that people in them conduct, and about the odd-sounding roles like “product owner” and “scrum master.” I had an executive for a large pharmaceutical company’s medical device unit in my last UofC course say at the course-end retrospective, “At first I didn’t understand why you spent almost the entire day-one reinforcing things like a focus on the customer. But then I began to see the whole context, and on the second day when we reviewed the practices like Scrum, they made sense to me, how the behaviors reinforce everything we covered that first day.”

I should note though, that it is not just the “aha’s” we need. No matter how great a course or experience is by itself, it will always be inadequate since we are creatures of habit and are want to spring back and do what we have always done. As we know from other examples in life, it is an ongoing process to integrate the new values, principle and behaviors into our lives and our organizations. This is where ongoing coaching and development are needed.

Focus, Respect, Openness, Courage and Commitment

Let’s dig deeper into each of these thinking system areas starting first at the foundational bottom of the pyramid with Values. For values I like to refer to the Five Scrum Values of Focus, Respect, Openness, Courage and Commitment. I use this particular order — FROCC — because it acts as a mnemonic that helps me remember them, like a Jedi’s cloak or “frock”.

For these purposes I define Values as what we use to express individual beliefs and opinions, what are desirable and positive for a person, group or organization, which is why they are tied to our identity, such as valuing knowledge, tradition, or passion. Whereas Principles help create the framework for decision making such as the Agile Manifesto’s four Guiding Statements and its Twelve Principles. (One of my student’s favorites Agile Principle to learn is “Simplicity–the art of maximizing the amount of work not done–is essential.”)

There are lots of values we can select from. Whether we intentionally chose our values, or over time merely absorbed and adopted them, consciously or unconsciously they underlie our principles and behaviors. In our enthusiasm for a particular set of values, or even in our “Agile chauvinism” we can fall into the trap of judging certain values that don’t align with our values as “bad.”

The other day I was introducing Agile to a large power utility company that operates consistently in traditionally managed ways. I came to the readout of the findings from my discovery and was describing one of values I observed consistently exhibited around the organization which I described as “West Coast Nice”. A director asked about that value, “Is that a good or a bad thing?” The important thing I explained about values is not typically that people exhibit “good” or “bad” values but that their values are or are not aligned with what they intend. In the case of this organization’s value around being “nice” in the form I was observing which is pleasant but cautious when communicating, nice acted as an inhibitor to openness and transparency, and therefore it does not support desirable Agile outcomes like quality and continuous improvement.

A Case of Conflicting Values, at Home

Consultant and author Larry Linne provides an example of aligning values from his personal life. He said it came time for planning Thanksgiving with his family and he mentioned to his wife that their daughter would not be able to be at Thanksgiving dinner this year because in her new role in the travel soccer league she had to be out of town for a tournament over Thanksgiving. Mrs. Linne was not happy with that and said, “Larry we have a value that our family is always together on holidays.” To which Larry says, “Well we have a value that our kids pursue excellence in all they do and that is why we encouraged our daughter to pursue travel soccer.” Larry points out that while both of those values are great, only one of them will be lived out that Thanksgiving. So, a Linne family conversation ensued as to which value would take precedence and be reinforced in their family going forward.

These are the types of conversations we need to be having all the time in our organizations, especially while going through transformation. Every organization has life stages, leadership changes, and changes from other dynamics such as technology and competition. I find it often the case, especially with entrepreneurial companies I have done growth coaching for, that the values that got you here are not the ones that will get you to where you want to go. See for example “Why Entrepreneurs Don’t Scale” for research on what values need to pivot as a company grows. For organizations to be successful, they need to be intentional about aligning and re-aligning their values with their desired outcomes.

In a traditionally managed firm the normative values might be things like Control, Accomplishment, Carefulness, Kindness, Significance, Perfection. All good values, however these values may not align and support Agility. The value of accomplishment (especially if individually oriented) could inhibit collaboration. Significance (especially with the behaviors that require a clear ROI from the start) may inhibit taking small, experimental steps (“Little Bets”) that are not yet known to lead to significant outcomes. Perfection may inhibit learning from low-fidelity prototypes and MVPs (minimally viable products). Like the Linne’s family Thanksgiving, an organization likely will need to intentionally choose and promote which values will align with the desired Agile future state.

Transformation by its nature means that the current-state organizational values are going to need to change in order to align with the new desired Agile state. We will need to make explicit both the current state and the desired state values. You might wonder, “I know how to change out an ERP system, but I don’t know how to change out a value system.” During Agile transformations I often recommend values-based exercises. Today’s skilled Agile coaches have found ways to make values visible, create conditions to reinforce behaviors that align with the desired Agile values, and extinguish behaviors that don’t align.

Get Out the Map

One example of a simple exercise to aid with this was brought to my attention by Henry Dittmer, an Agile experienced coach. This is for organizations that have developed enough capacity to have transparent conversations, good retrospectives and have a sustained desire to improve, yet are still in the midst of mindset and behavior change. Henry coaches they setup a wall with an area for each of the five Scrum values. On sticky notes team members are to write down any behaviors they notice that support or detract from one of the values. Behaviors are not opinions, they are the observations that describe what a movie camera could record such as “on Monday 7/18 our stand-up started at its scheduled 9:15 time, two team members arrived at 9:19.” Notice this statement does’t even include the word “late” because if we are using the model precisely we provide just data and save our judgments and associated emotions for another process. These data-driven observations would then be posted under a value such as “commitment” or “respect.” One color can be used for detracting behaviors, and another color for supporting behaviors. Over time teams can monitor progress and continue to improve in exhibiting the behaviors that reinforce the desired values.

One technique I developed to help with the Agile mindset values shift involves using a radar map for each team member to rate on a scale of one to five how well they feel their team is exhibiting each value. The team members submit these anonymously to one person who combines the graph for the whole team as a data-gathering exercise to prepare for their team’s retrospective. I have found it amazing how easy it is for teams to converge on the values they are strong and weak on, and then use that visibility to make decisions how to continue to incorporate more of the desired values.

These are just two such exercises off the top of my mind. There are no doubt many other ways we can make visible and align organizational Values to better facilitate mindset change and organizational transformation. And if you have some examples of ways you have approached this, please share yours in the comments below!

In Part Two we will explore in more detail the distinctions between Principles of thinking systems that are consistent with the Industrial Age, The Information Age and The Age of Agile, and reasons and ways we resist changing our mindset in “My Facilitation Problem.” And in Part Three we will explore why at the top of the pyramid model, Behaviors can vary so widely and yet still align with Agile Values and Principles.

Read Part Two, “My Facilitation Problem”

Read Part Three, “Microsoft’s Secret to Becoming the World’s Most Valuable Company”