Improving Your Company's Culture
This is a chapter from my upcoming online book Simplifying SAFe? With FLEX: An Enhanced Approach to Achieving Business Agility. FLEX is Net Objectives' Lean-Agile approach to helping organizations improve at all levels. While FLEX stands on its own, this book explains how to use it to enhance while simplifying SAFe. Feedback is requested either here on a user group I've set up for the purpose. I am also leading an online workshop starting in mid-January on FLEX that will include how to use it with SAFe. You can see more on linkedin by going to the Table of Contents.
“Organizational culture eats strategy for breakfast and dinner.” Peter Drucker
Agile and culture
Agile is a mindset based on values and principles. Many agilists talk about being Agile instead of doing Agile. The challenge is what if your organization is not Agile? How does it become Agile? Changing people’s “being” is difficult. Part of an Agile culture is trust and respect. Wouldn’t any company, Agile or not, benefit from more trust and respect? The question isn’t if trust and respect is a good idea, it’s a question of how do you create it if the culture isn’t already demonstrating it.
Lean and culture
Lean is also based on trust and respect. But Lean also includes suggestions on how to create trust and respect – trust and respect come from people working well together on a common problem. Systems-thinking tells us that the eco-system people are in has a significant affect on their behavior and that if we improve the environment they are in they can work better together.
Jerry Sternin (author of The Power of Positive Deviance) says it this way – “It is easier to work your way into a new way of thinking than think your way into a new way of acting.”
Here is a slight paraphrase from Creating a Lean Culture: Tools to Sustain Lean Conversions by David Mann.
Culture is important, but changing it directly is not possible. Culture is no more likely a target than the air we breathe. It is not something to target for change. Culture is an idea arising from experience. That is, our idea of culture or a place or organization is a result of what we experience there. In this way a company’s culture is a result of how people collaborate with each other. Culture is critical and to change it you have to change your method of collaboration.
Focus on agreements, behaviors, specific expectations, tools and routines practices. Lean systems make this easier because they emphasize explicitly defined agreements and use tools to make the work and agreements visible.
Consider a few key phrases in these statements and see if they match your own experience.
Culture is an idea arising from experience. That is, our idea of culture or a place or organization is a result of what we experience there. In this way a company’s culture is a result of how people collaborate with each other.
Remember a place where you or an associate worked where fear was present. What caused that fear? There were likely management decisions, such as reprimands or public humiliations when someone made a mistake. The fear was almost certainly a result of how people responded to something.
Mann tells us, “Culture is critical and to change it you have to change your method of collaboration” and to collaborate with explicit agreements and visibility of work and workflow. Net Objectives has developed a method of collaboration that we call Guardrails which is the topic of the next chapter.
Management must change the system
“A bad system will beat a good person every time” – Edwards Deming.
“Only management can change the System” – Edwards Deming.
Perhaps in the Lean-Agile space of the modern age we should change this to “management must change the system to allow those doing the work to be able to self-organize to get their work done.” However you want to look at it, management plays a key role in creating the eco-system people work in. What Deming observed is still true today:
“A system must be managed. It will not manage itself. Left to themselves, components become selfish, competitive, independent profit centers, and thus destroy the system … The secret is cooperation between components toward the aim of the organization.”
This is not top-down management. It is what is called “Middle-Up-Down” and was presented by Ikujiro Nonaka in 1988 with his article Toward Middle-Up-Down Management: Accelerating Information Creation. Professor Nonaka was one of the co-authors of the New New Product Development Game in 1986 which inspired Scrum. In a nutshell this means that middle-management looks up to see the vision of the leaders of the organization. It then looks down to where the work is taking place and works with those doing the work to improve their ecosystem based on their needs.
People are inherently good; we don’t need to motivate them, we need to stop de-motivating them
If we trust and respect people management does not need to focus our attention on them. Instead, they can focus their attention on how their people can improve their work, learn faster, collaborate with others and be more creative. This clearly involves a cultural shift. The challenge is, that although culture is incredibly important, it is not something you can address directly. Instead, we must focus on the management system that helps to shift culture over time.
In other words, we want to shift from “what values we need to do Agile?” to “how do we learn to work together when trust and respect is not as high as we’d like it to be so that trust and respect will go up?” This is clearly a culture change.
The nature of resistance to change
We often hear that people resist change. But I’ve seen many cases where this is not true. Admittedly change is often inspired by impending doom, but when people can see a better way to get their job done they will usually adopt it. An insight into the nature of resistance to change comes from Margaret Wheatley and Myron Kellner-Rogers in A Simpler Way.
In practice, all systems do insist on exercising their own creativity. They never accept imposed solutions, predetermined designs, or well-articulated plans that have been generated somewhere else. Too often, we interpret their refusal as resistance. We say that people innately resist change. But the resistance we experience from others is not to change itself. It is to the particular process of change that believes in imposition rather than creation. It is the resistance of a living system to being treated as a non-living thing. It is an assertion of the system’s right to create. It is life insisting on its primary responsibility to create itself.
Another factor in change
We’ve all had the experience of wanting to make a change but being unable to sustain it. What gets in our way is not so much resistance as habit. An organization’s journey to improvement requires breaking old habits while adopting new ones. Some organizations will do better by making a big jump, others through a series of small steps. Neither one is correct, rather both depend upon the organization and its culture.
Making change
It would be great to transform an organization into a magically wonderful space. But it’s a great step forward if people can get their job done better. That would increase satisfaction and meaningfulness. And, of course, there’s no reason to stop there.
Different Agile frameworks and methods take different approaches to change. Scrum, and most of its derivatives (e.g., SAFe, LeSS, Scrum@Scale) insist on changeup front – roles, team organization and more. The Kanban Method suggests no change up front but to improve from where you are. These are two extreme camps: one requiring a certain starting point in order to work and the other saying any up-front change will result in resistance. Which is correct, or if a blend is correct, often depends upon the culture of the organization and how well they are currently working together.
Ignoring change or avoiding change are not the only two alternatives
At a conference years ago Don Reinertsen and I were watching from the back of the room together. At one point it was clear that there was a pattern of “this or that.” Don made a funny observation “these folks have been around 1s & 0s too long.” I had had the same feeling and laughed at his eloquence. We’re still doing that.
We look at Scrum as a thing and Kanban as a thing. Neither are “things” but rather are approaches to improvement. Scrum has the cross-functional team be sacrosanct while David Anderson says “visualization not reorganization.” There is power to both. Both are proxies to what we need to do – have effective collaboration. But it is not as simple as one or the other.
Consider the following changes advised by Scrum and its derivatives :
- Creating teams may not be the correct solution (see How successful pilots often hurt an organization’s transition to Agile)
- A cross-functional team may not be advisable (some people need to work on several teams, at least initially)
- The change in roles may have an adverse effect on the team
When considering whether to do Scrum or to follow another approach it is important to see how the teams involved view the change and how it affects other parts of the organization. But the alternative approach with the Kanban Method of avoiding all change up front may miss huge opportunities for improvement.
I find these two extremes (ignoring the effect of change and avoiding up-front change) to often either cause problems or miss early opportunities for improvement.Integrating the best of both with Lean-Thinking
We must remember that one-size does not fit all. In the question of how to move forward with change we must also recognize that there are practices outside of the team as well. In all organizations, the amount and clarity of what is being requested of the team often has a bigger impact on the team than anything else. When multiple teams are involved and need to work together it is often best to first see how they work together before determining the actual practices of the team.
We have found the best way to create business agility is to:
- Attend to the eco-system within which teams work
- Have explicit workflow between teams so that people can see what’s coming their way as well as the impact they are having on each other
- Have agreements (the Guardrails) so that it’s about promises made and kept and not how one feels
- Attend to the willingness and ability of the people involved to change
Practices that usually provide value include:
- Decreasing the batch size of work by attending to the core value needed
- Allow teams to pull work when they have capacity, or at least limit the amount of work hitting the team to match their overall capacity
- Attempt to create teams to the extent possible
These actions will make life easier for those doing the work. They will almost always embrace them.
Why teams often accept changes made by management
Consider that if management can make bad decisions that teams resist (like demanding more work than they can do) that they might like good decisions made by management that stop them from being overloaded. But are there other changes the teams will embrace? Absolutely. The predictive factor is if the changes make life easier for the teams while making their work effective the teams are likely to accept them. As an aside, undoing bad decisions is something management should be encouraged to do.
Summary
- Lean tells us to change the system and to have management drive from the viewpoint of meeting organizational needs while supporting people in being able to do their work better
- Culture can’t be changed directly since it a reflection of the system people are in. It is best changed by changing our methods of collaboration and the agreements we make with each other.
- Resistance is not to change but rather to imposed change that is not to people’s benefit
- Difficulty in learning new habits instead of falling back into old ones is often a bigger impediment to improvement than resistance
I will be leading an online course on FLEX beginning in mid-January. It will cover all of FLEX, including the content regarding SAFe in this book. It's the equivalent of a 4-day course for only $795. Message me if interested.
You said, “When development groups change how their development staff is organized, their current application architecture will work against them. ?Reorganizing often works against change because it creates new communication channels which may not work well with the current architecture." What happens when the current application architecture changes? ?Or is in the process of changing? ?How best to organize the teams?