Essence and Problem Solving Blog

February 11, 2021

How do you fix a problem with–or improve– a culture?

Filed under: Essence and Problem Solving — pemcmahon @ 5:45 pm
Tags: ,

If you would like to read this blog, scroll down to where it says “Blog Text Starts Here.” If you would like to listen to the podcast version of this blog, click on the link and scroll down to where you can select the podcast.

Blog Text Starts Here

A colleague recommended I listen to a recent podcast with Alistair Cockburn [1]

where he says,

“The people who write about methodology don’t know how to talk about culture… so they describe the thing that’s easy to describe which is structure… With Heart of Agile I took away all the structural things.  I only talk about the cultural things; the behavioral things...” 

He goes on to talk about his Spotify Case Study where his client had a problem with dependencies.  Dependencies can be anything one developer needs from someone else to complete a task.  Cockburn gave them a “structural” solution which was to use a central person to manage a spreadsheet which identifies who needs what, from whom do they need it, and a “need by” date. Then they have a meeting every Monday and update the spreadsheet.  But soon after they started to use his solution, one of the Spotify people said:

“I don’t understand why I am sending this information to a central person.  How about if I need something from some person I just let him know what I need and then every Monday we don’t need to have a big meeting.”  

As it turns out the problem Spotify had soon was gone and Cockburn says, 

“My whole consulting went away because I was selling structure and they turned it into culture.”

Listening to this story cause me to wonder:

How do you fix a problem with—or improve– a culture?

Suppose there is something in your culture that is causing trouble in your organization.  How do you go about fixing it?

This reminded me of one of my own client cases which I will now share.

This particular case is a client I started working with many years ago (and still work with today) where we thought they had a problem related to risk management because they weren’t documenting their risks and holding periodic risk meetings to determine mitigation strategies.  Rather than just tell the organization that they needed to establish a more disciplined risk management approach, I asked a few people in the organization what they do when they have a risk.  The common answer was:

“As soon as I know I have a risk I am in the doorway of my manager’s office strategizing a mitigation approach.”

I have always said that a consultant needs to listen to the client first and take the time to observe what is going on because the best solution often depends on multiple factors and often those factors are related to the organization’s culture [2]. 

In this case, what I realized was that while this organization didn’t have a defined risk management process, they virtually lived and breathed risk management. It was engrained in the culture of the organization and it worked.   

So rather than recommend that they change their risk management approach, I recommended that they just recognize what was going on in the organization and train others in the approach.  We even referred to the expected practice in the training as “Doorway Risk Management.”  [3]

This is how we took an effective cultural practice and improved it by sharing it with others in the organization.  We did add a small degree of “structure” to the organization’s risk management culture.  But we were careful not to add any unnecessary, or non-value-added, activities.  

Another point I would like to make in regard to culture is that, while I agree a cultural solution is better than a forced “structural” solution, sometimes a small amount of structure can help fix a culture that has certain weaknesses. 

As an example, going back to Cockburn’s Spotify Case Study, in my experience while the solution Spotify came up with for managing dependencies was an optimal solution since they didn’t need to add the overhead of a Monday meeting, in many organizations that have similar dependency problems, all the personnel cannot be counted on to just provide what is needed to a teammate by a certain date.

Sometimes you need a degree of a “forcing function” (or structure) to ensure priorities are agreed to and accepted.  In these cases the Monday meeting may not be required for all dependencies, but you still may need a short meeting with a few key people for a period of time while the new desired behavior is still being learned.

Robert Martin, in his Foreword to our first “Essence of Software Engineering” book [4], says:

“Software is both a craft and a science, both a work of passion and a work of principle. Writing good software requires both wild flights of imagination and creativity, as well as the hard reality of engineering tradeoffs. Software, like any other worthwhile human endeavor, is a hybrid between the left and the right brain.”

I think there is something in these words that we can apply to the structure versus culture debate.  I believe quality software development requires both culture and structure.  They can and should work effectively together.  I have a practical idea on how to make this happen.  It requires us all to agree that just the right amount of structure at just the right time could be the most practical path to improve a culture– or resolve a known cultural weakness. 

I plan to continue this discussion in my next blog diving deeper into the challenge of applying just the right amount of structure to fix a problem with–or improve– a culture. 

As always, comments are encouraged. 

 [1] https://agilpodden.podbean.com/e/83-agile-manifesto-with-alistair-cockburn/

[2] Certified Essence-In-Use Practitioner Training, https://leanpub.com/c/essence

[3] Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement, (Chapter Four, Doorway Risk Management),  Addison-Wesley, 2011

[4] The Essence of Software Engineering: Applying the SEMAT Kernel, (Foreword, Robert Martin), Addison-Wesley, 2013

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

Blog at WordPress.com.

%d bloggers like this: