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.