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
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.
As you may know from our Three Year Vision, Semat’s first step was to create a common ground for software engineering. This common ground would be manifested as a kernel of essential elements that are universal to all software development efforts, and a simple language describing methods, practices and the kernel elements. Both the kernel and the language should be widely accepted. Right now, Semat is in the process of completing the first step, which has resulted in the following:
- A submission, called “Essence — Kernel and Language for Software Engineering” to the OMG’s RFP (Request for Proposal) “A Foundation for the Agile Creation and Enactment of Software Engineering Methods“. Two other works have been submitted to OMG. The Semat results were very well received by OMG. The Semat submission will incorporate some ideas from the other two submissions into the new “Essence” submission. Semat will also incorporate ideas from the existing standard Spem.
- Semat will be presented at the International Conference of Software Engineering (ICSE 2012) in Zurich on June 6, 2012. This will happen in the “Refounding Software Engineering” session. It is Semat’s first international publication and more publications are on the way.
- A new book `The Essence of Software Engineering – Applying the Semat kernel’ is coming – now in peer review. The book’s objective is to put the kernel into a context. The book describes how the kernel can be used by the practitioners and how they can measure progress in an endeavor independent of which method they use. It also provides suggestions for how they can scale up, scale out or scale in their methods.
The Semat kernel is already being used on two academic project courses at KTH Royal Institute of Technology. On one project course, Mira Kajko-Mattsson is teaching the Semat kernel and evaluates its usefulness within software education. Using the kernel elements, her students continuously evaluate the progress and health of their projects. On the other KTH project course, Anders Sjögren uses the Essence book as a base for education in software engineering with extensive lab work. Moreover, two other universities use or plan to use the Semat approach when training their students. These are Peking University and Oslo University. Experiences on the use of the Semat kernel in education will be published on Semat’s website in the next couple of months.
Getting a widely agreed upon kernel is just the beginning. The kernel is a fundament that constitutes a critical milestone for moving forward in refounding software engineering. To be able to systematically work with practices and methods both in the industry and academia, more work needs to be done in form of creating products, creating practice market places, constructing supporting tools, revising software engineering curricula, doing research and writing books and papers.
Thanks to the kernel, our less experienced developers (and most of us belong to this group) will become professional much easier and much faster. Standing on the common ground, they will be able to learn from one another much better and move from one team to another much easier. Since we focus on you, the developers, and not the process engineers, the adoption of the Semet kernel is more of a pull than a push.
The Semat kernel stands on two important principles, which are ‘agile in everything we do’ and ‘separation of concerns’. For example, we value:
1) What helps the least experienced developers over what helps the experts?
2) What helps the practitioners over what helps the process engineers?
3) Method usage over method definition?
Of course, we must support the experts and process engineers as well, but not by having the practitioners to pay a price. And, of course, we can define methods, but most importantly, we have to make methods useful while we actually work in real endeavors.
Compared to earlier attempts, the Semat approach has several differentiators that make developers more motivated to work with methods. Maybe the most important one is that the whole approach is actionable. As already described in the Three Year Vision, the developers do not just use it for studying. They use it in their actual daily work when enacting their ways of working and when measuring their progress. part of the whole game. All this will help the industry. The education at a university level will become more fundamental, more systematic and effective. The research will become more disciplined and more useful to the software community.
In parallel with working on the proposal, a small team of people has been working on a new book ‘The Essence of Software Engineering – Applying the Semat kernel’. The authors are Ivar Jacobson, Pan Wei Ng, Paul Mc Mahon, Ian Spence, Svante Lidman. The book is now in its 3rd draft and about 30 people have reviewed it and given constructive feedback. We expect that the 4th draft will be widely published. If you are interested in reviewing and providing feedback, please send an email to firstname.lastname@example.org. A copy of the book will be sent to you asap.
– Ivar Jacobson and Mira Kajko-Mattsson