I have just posted a blog about a different way to think about the SEMAT vision and the Essence Framework. 


 I would love to hear what you think.  


I have just posted my second blog of a planned series on topics in my new book.  This blog is titled: “Practice Slices and Patterns: A Better Way to Deploy Process Improvements”.   

Practice slices and patterns is a way to engage your practitioners in their own practice improvement which is a major goal of SEMAT and the Essence Framework.


You can also view a Youtube  video about practice slices and patterns at:


I am very interested in hearing feedback and stimulating discussion on the idea of practice slices and patterns.   

For those who may be interested, the new book I referred to in my blog on July 3 that includes discussions on the Essence framework is now available.  You can learn more about the book at www.amazon.com (paperback book or kindle store) or at www.leanpub.com/15fundamentals.

The book’s title is: 15 Fundamentals for Higher Performance in Software Development

You can also get some background information on how the Essence part of the book evolved at www.paulemcmahon.wordpress.com  in my blog dated July 17 and titled: Turning a Weakness into a Major Strength In My New Book “15 Fundamentals…”  

With the recent news release of the OMG Board of Directors adoption of the new Essence standard, and with the recent call for action for worldwide SEMAT adoption more people are now asking where can they learn more about how Essence can help.

Speaking as one who has been involved since the initial kickoff meeting in Zurich in 2010, one of the great things I have observed about the SEMAT initiative is how so many people coming from different backgrounds and different perspectives have been able to work together sharing ideas and learning from each other.

I believe it is our differing backgrounds and perspectives that have helped to make the Essence standard a sound kernel that will aid in the development of a solid theory going forward.

I also believe that to keep the momentum going we need more people writing about real experiences using Essence, or, if they haven’t used Essence, writing about real experiences where they can demonstrate how this new standard can help to solve the real problems that software practitioners face every day on the job.

This is an area I have been pursuing myself working on a book along these lines over the past few years. Many of the SEMAT volunteers have helped me along the way as reviewers of this work.  The book is now complete and will be available soon.

If you are interested in learning more about the book, or would like to be notified when the book is published visit the following URL (www.leanpub.com/15Fundamentals). You can even download a free Sample PDF of the book now that includes Scott Ambler’s foreword.  I would love to hear your feedback.

This past April I was asked to speak to a group of Computer Science students at Binghamton University, State University of New York, a school rich in a tradition of great software and systems engineering thinkers. In 1971, when I was working on my Masters degree at the same school, Jerry Weinberg (who was a professor of computer systems at the same school at the same time) published his book, “An Introduction to General Systems Thinking.” The book was reprinted twenty five years later on its silver anniversary and what intrigued me about this book when it first came out, and still intrigues me today is how it focuses on how humans think and solve real problems.

Fast forward to this past April, 2014. I find myself speaking to Binghamton University Computer Science students eager to understand the challenges they will soon face when they move into the world of industry and software development. Like I did in Medellin, Columbia last November, I decided to start by explaining a problem that the software engineering community faces today. I wanted to prepare them (and hopefully not scare them) for the real challenges they would soon face.

After the first 28 minutes of my talk, I then went on to explain how the new OMG standard, Essence, could help the software engineering community solve the problem I had been talking about.

Some of the topics that I address in this talk include:

Part I: The Problem We Face: Setting the Stage for Essence (28 minutes)

The Theory of Performance Improvement
Where We Go Wrong in Implementing the Theory
Insights into Two Types of Real Pain Points that Hurt Organizations
A Final Key Observation About Where We Go Wrong (before getting into Essence)

Part II: Essence: Helping to Solve the Problem (42 minutes)

What is Essence: “A Thinking Framework”
Key Elements inside Essence
Examples of how Essence Checklists Are Different
Representing Practices in Essence, and Why You Would Want to Do This
Explaining Common Practitioner Frustrations and How Essence Can Help
An Example of a Team Using Essence Activity Spaces to Self-Assess
Essence Competencies
An Example Scenario Courtesy of the Essence User Guide Volunteers
What if the Team Can’t Meet a Checklist Item?

At the conclusion of the presentation I came back to a few key points I made in Part I about two types of pain points that keep organizations from achieving and sustaining high performance and I reinforced a key related point about Essence.

This also brings me back to Jerry Weinberg. A great deal has changed in the last 40 years, but some things never change. In the end it is still about humans, how they think and how they solve real problems they face each day on the job.

My final point that I make in Part II of my talk to the students is about how Essence relates to critical thinking. Some of the challenges software developers face in today’s world are certainly different from those that Jerry was thinking about when he wrote his book in 1971, but the need for critical thinking in a world that is moving faster and faster has never been greater.

You can find both parts of my talk at Binghamton University on YouTube. Just google, “Paul E McMahon YouTube” and you should find the two videos;
“Part I: The Problem We Face: Setting the Stage for Essence” (28 minutes)
“Part II: Essence: Helping to Solve the Problem” (42 minutes)

Let’s keep this important conversation going. Love it or hate it, we want to hear what you think. Please provide your feedback through my blog (http://paulemcmahon.wordpress.com/ , the SEMAT blog (http://sematblog.wordpress.com/ , or the Linkedin SEMAT group.

Looking forward to hearing your thoughts.

In Medellin a few weeks ago in a workshop held following my keynote address at the Latin American Workshop on Software Engineering and Knowledge Engineering (JIISIC)  one of the first questions I received was: 

                        How does SEMAT relate to SWEBOK?   

I answered by focusing on the fact that Essence is small.  It contains only the essentials required on all successful software engineering endeavors and it includes no practices. SWEBOK, on the other hand, is large and covers many best software engineering practices. 

This past week I decided to go back and refresh my understanding of SWEBOK.   Part of my motivation was based on the question I received in Medellin, but I was also motivated because recently there has been some criticism of Essence (the first product of the SEMAT community) because of its lack of emphasis on software engineering architecture and testing practices. 

What immediately struck me in the preface to the  SWEBOK guide (2004 Edition) was the phrase:

“the emphasis of the guide is placed on the construction of useful software artifacts.”    

SWEBOK focuses on best practices in software engineering knowledge areas including requirements, design, construction, testing, maintenance, configuration management, software management, process, tools, methods, and quality.   Clearly these are all essential areas software engineering practitioners should know.   

SWEBOK, like SEMAT,  intentionally does not address rapidly changing technologies such as programming languages.  SEMAT, however, unlike SWEBOK, has intentionally  not focused on the construction side of software artifacts. 

So why did the SEMAT volunteers make this choice?

While constructing useful software artifacts is clearly an essential competency all software practitioners need to know, experience has shown that a project’s true progress and health cannot be measured by work products (or artifacts) alone.  It is the essentials of project success that transcend the work products themselves, such as ultimate stakeholder satisfaction,  where SEMAT places its focus. 

As an example, a key goal of the Essence kernel is to guide practitioners in asking the right questions that can help their team focus on what is most important right now leading to ultimate endeavor success.   While all software practitioners need appropriate skills in producing useful software artifacts, they also need appropriate skills in making critical on the job decisions related to the progress and health of their overall endeavor.  When you look at it this way, SEMAT and SWEBOK just might make a  perfect marriage. 

by Paul E. McMahon

There has been quite a bit of discussion recently about why we need SEMAT, or more specifically the Essence kernel which is the first product of the SEMAT community.

This past week I gave a keynote address at the Latin American Workshop on Software Engineering and Knowledge Engineering (JIISIC) held at the University de Medellin, in Medellin, Columbia– a great city to visit and a great University full of friendly bright students eager to learn.

Because I view the question above as a key challenge the SEMAT community must address, I decided to focus my Medellin presentation specifically on this topic.

But before I tell you more about what happened in Medellin, let me tell you a little more about the challenge SEMAT faces. The goal of SEMAT has always been to produce a common ground kernel that we all can agree is essential to all software engineering endeavors. But many people– including some of SEMAT’s own volunteers– have recently questioned how the Essence kernel is any better than Scrum, or the CMMI, or any other method an organization chooses to use.

A few months ago Capers Jones was asking questions related to comparing the SEMAT approach with other well known methods, and in the workshop held after my presentation in Medellin last week one of the first questions I received was about how SEMAT compared to SWEBOK, The Software Engineering Body of Knowledge.

In Medellin I decided to take a different approach to explain what Essence is, and why you should care. For the first twenty minutes I didn’t talk about SEMAT or Essence at all. Rather I talked about the problem the software community faces today as I have observed many organizations spending literally millions of dollars each year on process improvement efforts that too often fall short of their goals.

In my presentation in Medellin I provided a number of common patterns I have observed that can help us understand why many organizations, regardless of their chosen approach to improve– Scrum, CMMI, Lean, Lean Six Sigma, RUP…– fail to gain and sustain the improvements they seek.

I challenged what many of us have been taught and what many organizations continue to do today related to collecting large data samples before acting on improvements. And I gave examples of a much simpler and faster way to determine where the real pain points are in an organization.

Once you know where the pain is the next step is to figure out how to resolve it in a lasting way.

And this is where I explained what Essence offers that can help any organization have a much better chance of achieving their improvement goals in a way that is lasting, and they can continue to build on in the future.

It is natural for people to want to compare anything that is new to what came before. It is also natural to resist change as change is frequently viewed as risky. But as I explained in Medellin, the Essence approach is not about adding risk to whatever you do today, or changing whatever approach you use today.

In Medellin I gave specific examples demonstrating why the way the CMMI is used today in many organizations fails to help real practitioners with the real common difficult situations they face each day on the job.

And I gave specific examples showing how key checklists within the Essence kernel lead teams to ask the deeper questions that are needed to guide them to the right decisions that need to be made now to keep their software endeavors on a path to success with satisfied stakeholders.

Essence is not in competition with any method or improvement approach. It can help your team implement whatever approach you choose by helping them ask the right questions leading to better choices based on where their team is now and where they need to go next.

Essence doesn’t add risk. Rather it can help your team reduce the risk of failing to achieve a successful outcome and it can do it independent of whatever way of working you have chosen.

The SEMAT community will continue to face questions related to comparing Essence with other approaches and we will need to gather measures to demonstrate the value of the Essence approach. But the comparisons– I suggest– should not be Scrum versus Essence, or CMMI versus Essence, or RUP versus Essence. But rather they should be Scrum versus (Scrum + Essence), or CMMI versus (CMMI + Essence), or RUP versus (RUP + Essence).

Essence is not in competition with any existing practice or method. It is agnostic to your chosen approach and can be implemented by your team today without changing what you are currently doing. It is more about helping you do what you are already doing so you can keep doing it even better in the future.


Get every new post delivered to your Inbox.

Join 50 other followers