Improving Your Company’s Culture

Organizational culture eats strategy for breakfast and dinner. Peter Drucker

Agile and culture

Agile is intended to create a new culture.  Many agilists talk about being Agile instead of doing Agile. The challenge is that it is difficult to change one’s being.  While trust and respect is a key value of Agile, it should be a key value for every approach. 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 takes a different view than the striving for trust and respect that many agilists undertake. Lean’s attitude about culture has three main tenets:

  1. Take a systems-thinking approach.
  2. Management must change the system.
  3. People are inherently good; we don’t need to motivate them, we need to stop de-motivating them.

Take a systems-thinking approach

Systems thinking is considering a system to be an interrelated and interdependent set of parts which is defined by its boundaries and is more than the sum of its parts (subsystems). Changing one part of the system affects other parts and the whole system, with predictable patterns of behavior. Positive growth and adaptation of a system depend upon how well the system is adjusted with its environment, and systems often exist to accomplish a common purpose (a work function) that also aids in the maintenance of the system or the operations may result in system failure. The goal of systems thinking is systematically discovering a system’s dynamics, constraints, conditions and elucidating principles (purpose, measure, methods, tools, etc.) that can be discerned and applied to systems at every level of nesting, and in every field for achieving an optimized end state through various means.

Management must change the system

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 change the system.” However you want to look at it, management plays a key role in creating the eco-system people work in. This is particularly true as Deming observes what 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.”

The bottom line is, as Deming observes,

“A bad system will beat a good person every time.”

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. Ironically 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

Ironically, if we trust and respect people we do not need to focus our attention on them. Instead, we focus our attention on how they 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?  This is clearly a culture change. As Jerry Sternin (author of The Power of Positive Deviance) observed,

It is easier to work your way into a new way of thinking than think your way into a new way of working.

Culture is air; the management system is earth

Here is a 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.

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, pre-determined 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 upon the organization and its culture.

Summary

  • Lean tells us to change the system and to have management drive from the viewpoint of meeting organizatioal needs while supporting people in being able to do their work better
  • Culture can’t be changed directly but can best be changed by changing our methods of collaboration and the agreements we make with each other
  • Reistance is not to change but rather to imposed change.
  • Learning new habits instead of fallilng back into old ones is often a bigger impediment to improvement than resistance

Making change

It would be great to transform an organization into a magically wonderful space. But to be candid, I’d be happy if people could just get their job done. That’d great satisfaction and meaningfulness. After that is accomplished, keep undertaking your journey. Unfortunately, in the real world that’s not an option.

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. The Kanban Method suggests no change up front.  These are two extreme camps: one requiring a certain starting point (and thereby often requiring up-front change in order to follow its approach) and the other saying any up-front change will result in resistance by the development teams.  Neither position is sufficient. Neither applies most of the time. Your approach should always be determined by the situation you are in… not by whatever approach you are most comfortable with.

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. As a side note, The Kanban method is not the same as Kanban as used by many outside of Lean Kanban University of which I was a co-founder but am not active anymore. See Demystifying Kanban for more.

Conway’s law tells us “organizations which design systems are constrained to produce designs which are copies of the communication structures of these organizations.” My corollary is that “When development groups change how their development staff are organized, their current application architecture will work against them.” Reorganizing often works against change because it creates new problems. 

Scrum, and all of its derivatives, require cross-functional teams to implement it.  However, in many cases, this is either not advisable or can be somewhat traumatic.  When Scrum is imposed, such as when a C-level person says, “we’re doing Scrum” expect resistance. In any event:

  1. It may not be the team part of the value stream that is the real problem (so Scrum doesn’t always address the true challenge that needs addressing)
  2. Creating teams may not be the correct solution (see How successful pilots often hurt an organization’s transition to Agile)
  3. A cross-functional team may not be advisable (some people need to work on several teams, at least initially)
  4. 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.

The alternative approach with the Kanban Method is to avoid all change until the value stream has been mapped, WIP limits have been put in place, cycle times measured and possibly more.  The idea here is that all up-front change will be resisted.  I find these two extremes (ignoring the effect of change and avoiding up-front change) to usually either cause problems or miss early opportunities for improvement (not to mention often causing framework tunnel vision).  The Relationship Between Visualization and Reorganization (an earlier chapter in this book) provides insights into these two approaches.

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 any size organization the amount, size and clarity of the requirements given 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 first best to see how they work together before determining the actual practices of the team – which should be determined by the team in any event.

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:

  1. Decreasing the batch size of work by attending to the core value needed
  2. 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
  3. 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

In the cases above, it is easy to see that teams will like management changes 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.

I also question the notion that management can’t make decisions without the teams approval. Many companies have adopted ineffective methods (waterfall) or organizational structures (splitting up developers and testers).  Undoing bad decisions is something management should be encouraged to do.