Understanding What Culture Is and Why It’s So Difficult to Change for Enterprise Agility
Have you ever started working at an organization, trying to implement enterprise agility, and been told, “This is how we do things here”? Maybe you made a mistake, and a colleague or supervisor said, “This is not how we work.”
Now imagine if you responded, “Well, maybe we should change how we do things.” How do you think that would be received by your coworkers? It’s a safe bet most people working with you would find that attitude jarring, bordering on hostile.
That’s what culture is — shared, deeply ingrained assumptions and beliefs that control the thoughts and behaviors of individuals in a group. Culture is at the very core of what makes a particular organization unique. The managers, business analysts, and project managers have all accepted that these practices (often referred to as success patterns) are the way to succeed in the organization. Fortunately, although these assumptions, beliefs, and success patterns are deeply ingrained, they’re also learned, so they can be unlearned and replaced. But it’s not easy.
Many organizations start by trying to scratch and claw their way through the agile practices, changing the way a few teams work. All their effort goes into implementing specific agile practices, such as standing up during meetings and creating new user stories, but these practices only scratch the surface; they don’t change the thinking and behaviors required to stimulate innovation and achieve continuous competitive advantage.
Understanding why culture is so entrenched
In his book Organizational Culture and Leadership, Edgar Schein presents culture as three levels of stacked assumptions:
- Artifacts: Subtle expressions of values, such as the organization’s dress code, workspace, hours, posters, and even its perks, such as flextime or free coffee.
- Espoused values: The organization’s values, as expressed in its mission statement, vision statement, and goals. These values reflect the way the organization wants to be perceived.
- Underlying beliefs: The thoughts, feelings, perceptions, and beliefs that employees share without explicitly talking about them. For example, everyone in the organization may value creativity and innovation over predictability or the organization may have an unspoken bias against women in leadership positions.
You can usually sense an organization’s culture when you first step into its office space. A high-tech business in Silicon Valley has a vastly different feel from that of a top law firm in Chicago. The tech business is likely to have large, shared workspaces. You’ll probably see bicycles in the hallways, toys on desks, and people walking around in jeans. At the law firm, on the other hand, you’ll likely see orderly desks, people in suits, large windows overlooking the city, and a tone that’s more “professional.”
Schein groups assumptions into three levels to shed light on why culture is so entrenched and how challenging it can be to change an organization’s culture. The most deeply rooted beliefs may be buried under layers of everyday assumptions. An organization can’t change its culture simply by revising its mission statement or putting a new organizational framework in place. Changing culture involves changing deeply engrained mindsets.
Avoiding the common mistake of trying to make agile fit your organization
Do not try and bend the spoon. That’s impossible. Instead … only try to realize the truth. There is no spoon … it is not the spoon that bends, it is only yourself.
—Spoon Boy in The Matrix
When large organizations start an agile transformation they often try to bend agile to fit their reality instead of changing their organization to fit agile. Here’s an example:
In many organizations, management defines the product and hands the developers a detailed list of work requirements. The idea is that the more detailed the list of requirements, the more likely the customer will be satisfied with the result. In agile, on the other hand, the developer may start with a user story that describes what the user needs; for example, “As a shopper, I want to avoid having to wait in line to check out.” The developer is given the creative freedom to come up with a solution.
However, when some companies embark on their agile transformation, they write user stories that read more like work requirements, which completely eliminates the main benefit of the user story.
In this example, the organization adopted the agile practice of user stories, but it changed that practice to conform with the organization’s culture (a need to be told what to do). Instead of bending to the spoon, they bent the spoon.
As you educate and train people in your organization, spend time both on training people what to do and on explaining the reasons why they’re being instructed to do things a certain way. When people understand the why behind the what, they’re more likely to “get it.” Otherwise, they’ll just go through the motions. For example, if people understand that user stories are supposed to give the developer more creative freedom, they’re less likely to write user stories that read like requirements.