Essence and Problem Solving Blog

February 21, 2021

Essence Patterns: A simple way to apply just the right amount of structure to fix a problem with– or improve– a culture

Filed under: Essence and Problem Solving — pemcmahon @ 7:30 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

In my last blog I explained how you can fix a problem with—or improving – a culture and I gave a client case study that demonstrated how applying just the right amount of structure can improve a culture without adding unnecessary overhead.

In this blog I want to dive deeper into this subject showing you a simple way you can apply just the right amount of structure using an Essence pattern. So, let’s get into it…

People become engaged in their own improvement when they hear stories from peers. Over time I have noticed repeating patterns to the stories I hear and I often share these stories (without attribution) with clients facing similar challenges. I refer to these repeating patterns as “thinking patterns” because they can help teams effectively think-through their own challenges.

When the SEMAT [1] volunteers were developing the Essence checklists [2] I shared many of these stories and the other volunteers shared their own stories.  This was the genesis for many of the checklists that today are in the Essence standard [3].  

Today I use Essence checklists, along with Essence Patterns (discussed below) to communicate the “essence” of common stories relevant to a problem my client may be facing, along with proven solutions.  

In many cases the “essence” of both the problem and solution to these common situations is found to be rooted in culture.         

As an example, going back to Alistair Cockburn’s Spotify Case Study discussed in my previous blog [4], the solution Spotify came up with for managing dependencies was an optimal solution for their organization because it didn’t add the overhead of a Monday meeting and it utilized the existing Spotify culture to solve the problem.  

Similarly, the solution we came up with for my client with the Risk Management challenge (also discussed in the previous referred to blog) was optimal because we didn’t need to change what was already working well in the organization.  We just needed to rely on the existing culture and train more of the organization in the approach, which we referred to as “Doorway Risk Management.”

Nevertheless, all personnel in most organizations cannot be counted on to always provide what is needed to a teammate by a required date, as was the situation in the Spotify Case.  And in my own client case we could not count on everyone in the organization applying the “Doorway Risk Management” process just because that had become the culture for part of the organization. 

To fully implement this proven approach across my client’s organization we added a number of checklists to a one-page guidelines document and shared it broadly across the organization through focused coaching sessions. 

One way to capture this kind of solution to a problem and share it across an organization is through the Essence Pattern.  You can think of an Essence pattern as anything that can help teams conduct a practice more effectively, such as a collection of checklist items. 

You can also think of these checklist items as a set of  “essential reminders.”  As an example, refer to Figure 1 for the Scrum Values Pattern which reminds teams that the successful use of Scrum depends on people living the five Scrum values.

  Figure 1 Scrum Values Pattern

As another example, consider Cockburn’s Spotify Case Study.  In this case, we could have a Collaboration pattern that captures key checklist items, or “reminders” of things to think about to help manage dependencies.  Refer to Figure 2 for an example of an Essence pattern that could be used to capture key checklist reminders related to the Spotify Dependencies Case. 

                 Figure 2 Possible Spotify Collaboration Pattern to Manage Dependencies

It is also worth noting that there could be many more patterns collected under groups, including Collaboration, Deliver, Reflect and Improve as highlighted within the Heart of Agile initiative [5].  

In my own Essence training [6] I share a number of common patterns that I have observed, or my clients have shared with me, along with collections of related Essence checklist items to help teams think-through their own similar challenges leading to the best solution for their situation.

We now know the critical importance of culture to the success of any endeavor.  Many of the most common problems we see with software development teams (or any team for that matter) aren’t easily solved by simple structural fixes alone. 

Nevertheless, using Essence patterns can provide a simple and practical way to add just the right amount of structure to remind teams of essentials to fix a problem with—or improve—a culture. 

As always, comments are encouraged.

[1] SEMAT stands for Software Engineering Method and Theory. For more information refer to

[2] For more information on the Essence checklists refer to

[3] Essence checklists are part of the Object Management Group (OMG) Essence standard. For more information about Essence refer to



[6] Certified Essence-In-Use Practitioner Training,

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. 


[2] Certified Essence-In-Use Practitioner Training,

[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

Create a free website or blog at