Why Not to Focus on a Company’s Culture

September 27, 2007 — Posted by Al Shalloway

I am reading Creating A Lean Culture: Tools To Sustain Lean Conversionsby David Mann. Fantastic book. Here is a quote that has helped me quite a bit already:

Annual reports proudly refer to company culture as an invaluable
asset, and so on.

Should a company target its culture in its efforts to transform its
production process and all the positions - high and low - associated
with it? It is tempting to answer: Yes! But, that would be a mistake.

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 of a place or organization
is a result of what we experience there. In this way, a company's
culture is a result of its management system. The premise of this
book is that culture is critical, and to change it, you have to
change your management system.

So, focus on your management system, on targets you can see, such as
leader's behavior, specific expectations, tools, and routine
practices. Lean production systems make this easier, because they
emphasize explicitly defined processes and use visual controls.

This reminds me of a Scrum Gathering I was at a few years ago. This one had dealt particularly with trust. Most of the participants had bemoaned throughout the conference the difficulty of working with teams when trust didn't exist. We were all in the dilemma of – how to get Scrum to work without trust, but getting trust into a culture was difficult and time consuming. At the end of the event we had everyone in a circle giving their final comments to the event. This circle talk mirrored the lack of trust in organizations and the difficulties we all faced. It was clear everyone felt this lack of trust was just part of many company's culture and that culture was difficult to change.

When my turn came to give my final words I half-jokingly said we (meaning my company not the community) needed to find better customers (those who had established trust already and wanted to implement Scrum). However, as I thought about this, I realized these were few and far between.

I summed up the situation:

  • A cornerstone of Scrum is trust on the team
  • Most companies do not have a culture of trust
  • It will take a long time to get this trust
  • This implies it will take a long time to be able to implement Scrum

No wonder people were depressed! J

Anyway, when I'm in situations like this, I like to take the attitude on one of our t-shirts – "I feel so much better since I gave up hope!" In this case, the hope was to find a group that had trust. The back of our t-shirt says "Now that I have no hope I'd better take action."

So I asked myself – what can I do to move Scrum forward even without trust? I guess my Lean background of focusing on systems gave me the impetus. OK, so let's say we have a team that doesn't trust each other or management but we do the following:

  1. Get them co-located
  2. Get them working on one project
  3. Build software in stages
  4. Hold daily standup meetings
  5. Have someone available (the ScrumMaster) that will help them remove impediments in their way
  6. Have either the customers more available to them or have someone fill the role of the Product Owner so the team can get guidance on what is needed

It'd be better if they trusted each other, but if they just changed these actions would we get improvement? I was sure they would (and we've done this on dozens of teams since so now I know they would). Would their better results perhaps build trust? I hoped so (ok, so I guess I didn't totally give up hope). And experience has now shown that it did.

Looking back I now see that I was manifesting Mann's suggestion. I worked on the teams' actions and shifted their culture. I didn't focus on culture because, although incredibly important, it wasn't something I could deal with directly.

This also points out another long ranting concept I've had (a "long ranting concept" is a concept I've been ranting about for a long time). The concept? That understanding principles will help you follow practices. That is, in the past I did something I intuitively thought would be a good thing (focusing on action, not culture). But I had never brought this concept to my consciousness. I wonder how many times in the past I missed the opportunity for action that might have assisted transitioning a team or company because I was too focused on the culture?

Author: 

Share this:

About the author | Al Shalloway

Al Shalloway is the founder and CEO of Net Objectives. With over 40 years of experience, Alan is an industry thought leader in Lean, Kanban, product portfolio management, Scrum and agile design.


Comments

Alan,

I think you almost have this fully groked :).

The culture IS the collective behaivor. Belief and philosophy follow behaivor, and if you don't buy that just look at Stockholm syndrome. Better yet, look at the tendancy for really good developers to go bad in a culture bereft of good software development practices.

It is easier to trend toward entropy and many a good young developer loses his way in a cube farm without support for good behaivors.

In this case you did indeed focus in the culture. The 6 items you named become the culture.

A focus on behaivor is a focus on culture. Any other mechanism you hear to influence culture is a mere platitude.

Share This Blog

Free Email Updates!

Sign up for free email updates from
Net Objectives Thoughts Blog

Blog Authors

Al Shalloway
Business, Operations, Process, Sales, Design Patterns and Object-Oriented Analysis & Design, Personal Development, Agile, Lean-Agile, Kanban, Scrum, Scrumban, XP
Cory Foy
Change Management, Innovation Games, Team Agility, Transitioning to Agile
Jim Trott
Business and Strategy Development, Analysis and Design Methods, Change Management, Knowledge Management, Lean Implementation, Team Agility, Transitioning to Agile, Workflow, Technical Writing, Certifications, Coaching, Mentoring, Online Training, Professional Development, Agile, Lean-Agile, Kanban
Ken Pugh
Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Professional Development, Agile, Lean-Agile, Scrum
Scott Bain
Analysis and Design Methods, Transitioning to Agile, Design Patterns and Object-Oriented Analysis & Design, Software Design, Design Patterns, Technical Writing, TDD, ATDD, Coaching, Mentoring, Online Training, Professional Development, Agile