Essence and Problem Solving Blog

January 19, 2015

New Video on Practical Ways Teams Can Use Essence and New Published Paper on Essence

A few weeks ago I shared a You Tube video providing highlights of Part I of a talk on Essence (44 minutes) I gave at Binghamton University in November, 2014 to a group of Computer Science students.  Highlights from Part II of that talk are now available where you can learn practical ways software teams can use Essence including games they can play to help assess where they are, how to conduct a root cause analysis to isolate a problem, and how to use patterns to improve their performance.

Highlights of the talk can be found at:

The Part II highlights are 30 minutes in length and at the front of this video you can find where in the video the following 13 topics can be found:

  1. Assessment Poker
  2. Case Study Results Carnegie Mellon West
  3. Root Cause Analysis Example
  4. How Essence Differs from Lean Six Sigma
  5. Examples Using Activity Spaces
  6. Using Essence Competencies
  7. Another Example Using Activity Spaces
  8. Where Can Essence Help Most?
  9. Practice Slices and Patterns
  10.  Two types of information practitioners need
  11.  Examples of Patterns
  12.  A Closing Thought
  13.  How Students Are Using Essence at Binghamton University

I also have a new published paper on Essence titled,

A “Thinking Framework” to Power Software Development Team Performance, appearing in Crosstalk, The Journal of Defense Software Engineering in the Jan/Feb, 2015 edition.

December 27, 2014

Essence: What’s New and Different?

In November of this year, 2014, I gave a talk on Essence at Binghamton University to a group of Computer Science students.  You can catch the highlights of Part I of the talk on YouTube.  This is a great video to watch if you want to learn what is new and different about Essence, the new software engineering Object Management Group (OMG) standard intended specifically for software practitioners.  If you don’t have time to watch the complete Part I– which is about 44 minutes– you can find a cross-reference at the end of the video to where in the video you can find the following 23 key topics:

  1. What is Essence?
  2. The Difference Between Scrum and Essence.
  3. What Does Essence Contain?
  4. Why Did We Create the Strange Alpha Word?
  5. What is Different About Essence?
  6. The Essence CARD Deck.
  7. An Example Demonstrating How Essence is NOT Waterfall.
  8. A Question About Essence Versus Scrum.
  9. How Essence Can Power Whatever Approach Your Team is Already Using.
  10. About the Problem We Are Trying To Solve With Essence.
  11. How Does a Team Use the Essence Model?
  12. How Essence Checklists Are Different.
  13. How Do Teams Apply the Essence Checklists?
  14. On the Importance of Knowing When You Are Done.
  15. A Question on How a Team Can Fall Back.
  16. On the Order You Address States, and Decisions on Checklists that May Not Apply.
  17. An Example of a Team Deciding if a Checklist is Applicable to them.
  18. On Activity Spaces.
  19. Competencies Within Essence.
  20. How to Figure Out if You Have a Leadership or a Management Competency Issue.
  21. What if a Team Can’t Meet a Checklist Item?
  22. Why Isn’t Risk an Alpha?
  23. Why is Hardware included in the Definition of the Software System Alpha?

As always, your comments and feedback are encouraged.

July 17, 2014

Turning a Weakness into a Major Strength In My New Book “15 Fundamentals…”

I just released a new book titled, “15 Fundamentals for Higher Performance in Software Development.”  You can learn more about the book at (paperback book or kindle store) or at

In this, my first of a planned series of blogs about the book, I want to share some background information about how the book evolved and how I was able to turn a weakness into a major strength of the book.

If you have been following my blogs over the past few years you probably know I have been involved since 2010 in the SEMAT (  initiative.  SEMAT, just last month, achieve a major milestone with the Object Management Group formally adopting the Essence Specification as an OMG standard.

When I started to write my just released new book close to 4 years ago I did not plan for it to include any discussion on SEMAT or Essence.  My intent was to describe a problem that the software development community faces that I felt needed to be discussed more openly.  You can learn more about the problem at:

But as I moved forward in writing the book in parallel with my work on SEMAT I started seeing more and more areas where SEMAT’s Essence framework could help to solve the problem I was talking about in the book.

At first I was unsure how to address this because I did not want to disrupt my  planned flow of the book, so I decided to interject sidebars in the book explaining how Essence could help to solve the problem I was describing.

I had twenty-one reviewers of this book who reviewed multiple versions over the last three years. Only eight of those reviewers had any knowledge of SEMAT/Essence before reviewing the book.  Unfortunately, many of my reviewers gave me negative feedback on the new sidebars with comments such as:

“I find the sidebars distracting,”

“I don’t get this Essence thing,” and

 “The alpha idea makes my head spin”. 

Multiple reviewers suggested that I break the book into two books – taking all the Essence material out of the first book, having a second book just about Essence. Clearly these sidebars had  become a weakness of the book that I would need to overcome.

One reviewer who was a real practitioner and knew nothing about SEMAT or Essence suggested that I take all the  SEMAT/Essence specific material out of the first two parts of the book (first 12 chapters/ about 150 pages), and replace the sidebars with a more general “framework vision” that explained in simpler terms what was needed to solve the problem I was talking about.

He suggested that I use no “process-freaky” words in the sidebars.  This was a project manager in a large US Defense Company who is a very practical oriented manager.  He then said I should keep the Essence framework discussion in the book, but present it late in the book showing how it meets the requirements of the framework vision and how it can help to solve the problem I had discussed in the first two parts of the book.

This is the path I took, and most of my reviewers not only agreed with this approach, but some even went so far as to say they thought the new framework vision was now one of the major strengths of the book.  It was particularly good to hear that the reviewers were able to easily grasp the vision and agree with it, as it now was being presented in the new way.  I now think of this framework vision presented in Parts I and II of the book as the requirements and Essence, as presented in Part III of the book, as an example of one way to implement those requirements.

One reason I wanted to share this story with you is because in Part III of the book where I do talk about Essence I do so from the perspective of how it can help to solve a major problem the software community faces today.

As it turned out, taking this approach achieved another goal as well. Whenever I have spoken at  Universities or Conferences in the past about Essence, there always seemed to be at least a few people who would ask:

“Why do we need Essence?” 


“What problem is Essence going to solve that the other aids we have today like Scrum, CMMI and Lean Six Sigma don’t already handle?” 

By presenting the framework from the perspective of how it can solve a real problem the software community faces, answering those common questions becomes much easier.

This leads us to an important question.

Why is it so difficult for many people to grasp the value of the Essence framework when first presented to them?

Some have observed that it could be because Essence requires a paradigm shift not unlike what was needed when object oriented design was first introduced in the software community.  I would love to hear your thoughts related to this question.

You can learn more about how Essence can help to solve the problem that I talk about in the first two parts of the book at:

In future blogs I intend to share more about how this book evolved including a story related to how the book achieved its final title which was based on a  polling of many of my reviewers after I had literally written down more than 100 possible titles.  I will also share the top 4 candidate titles, and I will tell you why they all would have been great choices, and I will tell you now my initial personal favorite was not the final choice.

The book is available in ebook and paperback format from  It is also available in multiple ebook formats from, and


November 23, 2011

What Does Lean Six Sigma and Semat Have in Common?

I recently went through an intensive ten week training course followed by a five hour examination to achieve my Lean Six Sigma Black Belt Certification.  Why I decided to invest the time to achieve this certification might not be why you think.   To help explain I need to first talk about another initiative I have blogged about in the past– Semat (

I have been involved in the Semat initiative for almost two years.  Because all of us working on Semat are volunteers our progress has at times been slower than what we would like, but it is currently on the upswing.   For those who haven’t been following Semat closely,  we are building a kernel– or what we refer to as the “common ground”– for software engineering.  We realize we will only succeed if what we produce achieves wide acceptance.  Our current focus is on preparing our response to the OMG FACESEM RFP (A Foundation for the Agile Creation and Enactment of Software Engineering Methods).

Some have questioned the value of spending time on the Semat initiative.   As an example, I recently heard from a colleague who works for a largeUSdefense company that their OMG representative questioned the value of Semat because they didn’t see any “beef” in what we are doing.  If you attended our kernel working group meeting last Sunday you might understand this comment.  Last Sunday we initiated a high level review of our first seven kernel elements (Opportunity, Stakeholders, Requirements, Software System, Team, Work,  and Way of Working).

Small Semat sub-teams have been working  on descriptions, states and checklists for each of our kernel elements.  We are now stepping back and looking for consistency across these descriptions, and part of this effort includes building a small, but commonly agreed to, glossary.  One goal is for these kernel elements to be easily understood and to use a consistent vocabulary.  We plan to take our work out to the broader community to get more feedback.  This is critically important to ensure wide acceptance.

Just to give you an example from last Sunday’s discussion–  It was observed that in our initial kernel descriptions many words that were used seemed to by synonyms of others.  One example we discussed were the three terms– problem, obstacle and issue.  After lengthy discussion it was agreed that the way these terms were being used in our kernel description documents that  they were essentially intended to mean the same thing.  During this discussion it was also pointed out that the word issue, and problem often had a specific meaning inside certain organizations.

One of our goals is to try wherever possible to avoid terms that may carry certain baggage or lead to misunderstanding.   In this case we chose the term obstacle and initiated an effort to remove the terms issue and problem replacing them where it made sense with our preferred new glossary entry obstacle.   What we are doing should not be viewed as trying to ban words within Software Engineering.  We anticipate that specific organizations and specific software engineering segments will extend the kernel and its glossary to fit their needs.

What we seek is not to limit, but rather to provide a  small common ground starting point that we can all agree to.  To keep this small and consistent we spend an incredible amount of time in our working groups looking for things to throw out of the kernel, including words that that don’t add value or words that serve to confuse rather than clarify.  As a result, our goal could be viewed as eliminating “beef” that fails to stand up to our criterion of being universal to all software engineering efforts.

Now I can understand how some might question if it is really worth the effort to spend so much time worrying about these common everyday words we use.  Some might ask, isn’t our real goal to write high quality software?

The answer is yes, our goal is to write high quality software.  But those of us who have been working with software for a long time  have learned that the most direct path to high quality software requires that we first know our goal, second we must  know what must be done to achieve that goal, and third we must know how we will measure ourselves to determine if we have succeeded.

We have learned that not hitting our goal too often results from unclear objectives and conflicting stakeholder needs and expectations.  One way to help us address this frequent trouble spot is through a simple common language and small glossary of terms we can all agree to as a starting point.

I know it may sound trite, but when software efforts fail it still often comes down to the same issues it came down to 40 years ago — miscommunication of requirements and miscommunication of stakeholder expectations.

So what does all this have to do with why I invested time in becoming a certified Lean Six Sigma Black Belt?   Lean Six Sigma emphasizes the importance of first understanding where the pain is, or stated differently; What is the real problem we need to solve?  It second focuses on understanding the customer needs and how to translate those needs into critical to quality requirements which can me measured.  It next focuses on quick-wins and getting rid of waste.  To do this we make sure we understand each step of the process and how to distinguish value added steps from non-value-added steps specifically in the eyes of the customer.

Lean techniques drives an organization to look hard inside their operation not just at how to fix defects once they occur, but how to keep them from occurring in the first place.  Lean Six Sigma teaches us to look hard at our personal work habits, like cleaning up our work area making it easier to find what we need when we need it.   Last Sunday our Semat volunteers spent a good deal of time cleaning up the language we use to express what we do.  We are looking to eliminate non-value-added effort wherever it exists.  We are working to make it easier to communicate accurately the first time.

I didn’t decide to become a certified Lean Six Sigma Black Belt because I wanted to learn a new fad.  I did it because I wanted to learn something old that we all know, but too often forget.  Start by simplifying what you do.  Eliminate waste wherever you find it.  Eliminate anything that doesn’t contribute directly to your goal.  Where is the “beef” you ask?  Quality is not measured by how much beef we have.  It is measured by how much lean we have and whether our customers are delighted with the value they receive from our products and services.

Paul E. McMahon
Principal, PEM Systems

Author: Integrating CMMI and Agile Development

Certified Lean Six Sigma Black Belt

Phone: 607-798-7740

Email: PEMcMahon@ACM.ORG

Create a free website or blog at