Essence and Problem Solving Blog

November 18, 2022

Is there really anything new with Cyber Resilient Engineering?

Filed under: Essence and Problem Solving — pemcmahon @ 7:15 pm
Tags: ,

July 20, 2022

An Essence Use Case that might take my job away!

Filed under: Essence and Problem Solving — pemcmahon @ 9:23 pm

In my last blog I discussed a number of Essence Use Cases. One that I didn’t mention, I just realized, might take my job away.  Let me explain.   

When I first became involved over ten years ago in the work that led to the Essence standard I had a hunch it could lead to something revolutionary.  But I didn’t have a clear idea what that revolution might ultimately look like. 

Today, people are finding new uses for Essence that few, if any, envisioned ten years ago.  One of those use cases relates to my own business.  Helping companies assess their own practices, determine where they have gaps or weaknesses, and then putting appropriate improvements in place has represented a large part of my independent consulting business over the last twenty years. 

Recently, while reviewing a course I developed on using Essence to help assess an organization’s cybersecurity weaknesses, it struck me that what I was actually doing in this course was teaching my client to do for themselves what I had been doing for them. 

It also struck me that if I was successful, my client wouldn’t need to keep bringing me back in the future and therefore this course might just take my job away. 

But after reflecting on this situation, I realized this was not anything to be concerned about because the service I had been providing to my clients has been evolving for years and would continue to evolve in the future.  Consultants, like any business, must continue to innovate and evolve to remain viable. 

A colleague in a US Defense company mentioned to me years ago that he was concerned that the work his company was heavily involved in at the time would soon disappear because he believed the commercial industry would soon take it over.  Who would have guessed thirty years ago that commercial companies today would be the leaders in space exploration? 

By teaching my clients to do what I do, and Essence has been a great facilitator of this education, it opens up new possibilities for my own learning and growth.

Furthermore, teaching your client to do for themselves what you, as a consultant, may be doing for them today builds trust, and trust is invaluable to everyone’s future business.

Following is a three-minute clip out of my recently released online course titled, “Certified Essence-In-Use for Effective Cybersecurity.” This clip is the part of the course I was reviewing that motivated this blog. 

 As always, feedback is encouraged. 

For more information about the Certified Essence-In-Use for Effective Cybersecurity Course, refer to

July 7, 2022

A common trait observed in ALL Essence Use Cases

I don’t like to use absolutes ( e.g. words like “ALL”)  because it’s too easy to find “one-off” situations that can prove absolute claims false. So, you could take this post as a challenge to give me a counter-example to my argument, since so far I haven’t found one.

Before I explain the common trait let me step back and talk a bit about the primary Essence Use Cases I have observed to date.  Ivar Jacobson recently stated that many companies are now adopting Essence in one way or another. What I find most interesting about this statement is that implicit in his comment is the fact that there isn’t just one way to use Essence.  New Essence Use Cases are today being found faster than ever.  Let me give you a few examples.

Playing games with Essence Cards:  We have known for a long time about the games that can be played with Essence Cards, such as the game to help teams assess where they are and where they need to focus their attention next on their project regardless of the method they are using.   Another game is using Scrum Essentials Cards ( to help teams who have already committed to Scrum, but are struggling  with their Scrum implementation. 

But now people are starting to develop their own games inspired by Essence. An example can be seen in this post ( by Joseph Pelrine where the “hot seat” game is described.

When I read this post I starting thinking about how this game could be used to stimulate a team to think about any aspect of their endeavor, such as a specific problem the team might be facing, or an area where they needed improvement.  Pelrine challenges his readers with the following question in his post:

“Can you think of other uses of or variations on this game?” 

More on this subject later.

Essentializing Practices:  Essentializing practices may be the best-known Essence Use Case.  Scott Ambler, creator of Disciplined Agile Delivery (DAD), wrote a blog titled “Disciplined Agile and Essence: Succeeding Together” ( ).  In this blog Ambler explains how he essentialized a database refactoring practice.  Ambler says that he wrote a 400+ page book on this subject describing in detail the practice.  Then he asks:

 “But what if you wanted to start with something simpler before jumping into the details?“

This comment caught my attention because I know most of my clients won’t read 400+ page books.   Ambler then says: 

“This is where Essence comes in.”

This got me thinking about my own experiences essentializing practices.  If you haven’t essentialized a practice before, one thing you will learn when you try it is that often it turns out to be more difficult than you first think.  This is because once you start discussing the practice with practice users, or with the practice author, you often find differing views on just what is essential. This is where the process of essentialization really gets interesting because deeper insights into the practice often emerge.

Pattern Cards to address specific weaknesses: Another use case that I have personally employed with clients is the use of pattern cards to address specific weaknesses in an organization. 

Jeff Sutherland, co-founder of Scrum, uses Essence pattern cards when he teaches Scrum.  Sutherland has said that 58% of Scrum implementations fail and that:

“Essence is the key to success with Scrum.” 

From my own experience I have found pattern cards are a great way to force a team to think about just what is essential, or just what you want your team to focus on for improvement.   When using pattern cards you have to figure out how to convey the information in a way that will fit in the limited space available on the card.  This need to fit words in a limited space is part of what forces you to get to the real essentials. 

One area where some of my clients are trying to improve and I have used pattern cards is cybersecurity.  These clients want to ensure the software product they produce is sufficiently cybersecure to meet the needs of their customers.  We use the pattern cards in these cases to remind the team of agreed to changes in their practices to meet their specific cybersecurity challenges. 

As I read about Pelrine’s “hot seat” game it occurred to me that one possible variation of this game would be to place a desired product characteristic, such as cybersecurity, in the “hot seat” to stimulate team discussion and then place selected checklists from the alphas (rather than the alphas themselves) around the “hot seat” item.  This would force the team to focus on the critical issues they need to focus on when playing the game.  By varying the game this way it becomes closer to what I actually do with my clients today when using Essence to help stimulate improvements in specific areas, such as cybersecurity. 

I recently release a new course ( where I share some of these experiences using Essence to help clients achieve what I refer to as “effective” Cybersecurity.  I call it “effective” cybersecurity because you can spend a whole lot of money today on cybersecurity and never get to the real issues your customer cares about.

Using the approach I describe in the course can help any team get focused on the things they need to be thinking about and taking action on related to key cybersecurity changes (or whatever else you want to put in your “hot seat”) for their specific situation.  And I highlight the words “specific situation” because the right answer for each organization or team is often different due to factors that surface during the Essence stimulated discussions.  

It is worth noting here that the same approach I use to solve client cybersecurity challenges can be applied to address any problem or desired improvement area.  

So, this brings us back to the question of just what is that common trait to all of these Essence use cases?

You have to think each time you play an Essence game because the situation you find yourself in can quickly change and what worked in the last game (or situation) might not in the next.  When you essentialize a practice you have to think about the fact that what is essential in one context might not be essential in a different context.  When you develop Essence pattern cards you have to think about what would be most valuable to your team given their specific situation and given the limited space available on the card. 

What’s the common trait in all these Essence use cases? 

When using Essence you simply can’t avoid the thinking part!

This may sound obvious, but it isn’t. One of the major problems we face today is humans just “going through the motions” of a practice or process. Root cause analysis of many recent cyber breaches has pointed this out again and again.

That is why Essence has often been referred to as a “thinking” framework, and I would add here that when looking at challenges such as cybersecurity in today’s world you often have to think differently from the way we thought in the past.    This is also why today Essence is flying higher than ever.  Essence keeps teams on their toes, keeps them open to new ways to think– never being satisfied with the status quo.  

It is somewhat of a paradox that by embodying the things that never change, the Essence framework provides exactly what team’s need to keep changing, keep moving, stay motivated, and always remaining one step ahead of the competition.

Comments, as always, are encouraged. 

To learn more about Essence refer to

To learn more about the referenced course, “Certified Essence-In-Use for Effective Cybersecurity” refer to

March 5, 2022

A Simple Trick to Prove Team Performance Improvement

A couple of weeks ago I participated in an Essence and Heart of Agile Meetup with Soledad Pinter from the Heart of Agile community and Ivar Jacobson. That meetup inspired me to create this video blog.

To view a recording of the Meetup:

Comments are encouraged, as always.

April 7, 2021

32 Questions and Answers from my recent ACM Tech Talk on Teaching our Next Generation of Software Practitioners in the Universities

Filed under: Essence and Problem Solving — pemcmahon @ 12:37 pm
Tags: ,

On March 25, 2021 I gave an ACM Tech Talk titled: An Industry Perspective on What We Should be Teaching our Next Generation of Software Practitioners in the Universities.

As of March 29, there were 1815 registrants for the talk, and 806 attendees, of which 570 attended live. More will be viewing the recording in the days ahead. If you haven’t registered and would like to view the recording, you can do so at the following URL:

At the conclusion of my presentation I answered a number of the participant questions, but we did not have time to answer all the questions so I agreed to answer more questions off-line.  Below you will find my answers to 32 of the questions received from participants. 

I have also conducted a Pareto analysis of the questions grouping them into the four categories to see where participant interest lies.   Refer to Figure 1.  

Figure 1: Pareto Analysis of Questions Received

The question numbers associated with each category follow:

Category 1: Essence and Practices

1, 3, 4, 23

Category 2: Value of Essence/Challenges to Essence

5, 8, 12, 13, 17, 18, 19, 21, 25, 26, 29, 30

Category 3: How to Teach Essence

2, 6, 7, 9, 10, 14, 20, 27, 31, 32

Category 4: General Essence Questions

11, 15, 16, 22, 24, 28

If you have further questions, or would like clarifications on any of my answers, please leave a comment and I will do my best to respond. 

Question 1: What is your position on Watts Humphrey’s Personal Software Process and Team Software Process as ways to developing a personal method?

Answer: I believe both PSP and TSP are very good processes, but keep in mind these are both processes, and Essence is not a process.  The five checklist items I referred to at the end of my presentation that are part of Essence are intended to help developers become better estimators and better at answering the question “when will you be done” which is a large part of what Watts was getting at in PSP with regard to learning to measure yourself in a disciplined way.  You can use the Essence checklists, if you use PSP or TSP, or any other process including Scrum, or a Waterfall variant. 

Question 2: What do you think universities should stop teaching to make time for teaching the material you suggested?

Answer: I answered this question at the end of my talk, but I will restate my answer here.  I don’t think we need to stop teaching anything to teach what I propose.  I am proposing the insertion of concrete examples/stories from real industry situations (I gave a number of these examples/stories in my talk) into each course in the University.  Then just change the way certain things are taught to make them a little more efficient, thus making time for the added stories/examples. 

Question 3: Agile methods have been a buzz for at least a decade. It seems that the buzz is fading and becoming “real”.  Critical views on agile i.e. Antipatterns and “survival guides” are popping up. Any comments on that shift?

Answer:  All methods (agile or traditional) have weaknesses.  It is to be expected with the popularity of agile methods that we would be seeing antipatterns and survival guides to try to address the common weaknesses people run into.  This is one motivator for Essence, which as I said in my presentation is NOT a method itself. It is a common ground of essentials that underlies all successful methods and, as such it can help us identify the weaknesses in any method including agile methods.  Many of the examples/stories are referred to in my talk are, in fact, anti-patterns that we often see in organizations regardless of the method they choose to use.

Question 4: Natural language may not be precise enough to express procedures; process logic.

Answer: What I am suggesting is not intended to replace teaching computer programming languages that do need to have precise syntax/logic.  What I am suggesting is adding stories that communicate the real kinds of situations that software developers are certain to face in industry, so they don’t get a big surprise when they leave the university.  These stories are best communicated with natural language.

Question 5: I don’t know about this. In many universities I have been in, the capstone project (senior design projects) has real stakeholders and mostly ambiguous requirements.

Answer: I know there are some universities where this is true, but, as I mentioned in my presentation, I have also heard university professors say their students don’t have real stakeholders and they don’t have ambiguous requirements.  It would be good to hear more of the stories and lessons from the universities that are already doing this and if they have received feedback that the students are better prepared because of these capstone projects. What I am suggesting is to supplement courses with these real stories which can support capstone projects if you have one, and at least give students who don’t have the benefit of participating in a capstone project some ideas of what they should expect when they leave the university.   

Question 6: What is the percentage of active practitioners teaching in universities in comparison to academics?

Answer:  This is a good question and I personally don’t know the answer. If anyone who reads this does have a reference to a good answer please provide feedback.  I do believe we should be encouraging more active practitioners to share their knowledge with students.  I address this further in a later question.

Question 7: Do you have any tips for balancing the limited time available in an academic term with the simulation of difficult stakeholders and late hardware?

Answer: This is exactly why I like telling students stories. I think they can understand the kinds of stories I shared in my presentation and it doesn’t take a lot of time to tell the story and then have a follow-on discussion related to the associated Essence Alpha and checklist (s).  Admittedly, this might not stick with the student to the same degree as actually having a real project with a real difficult stakeholder or some real ambiguous requirements they have to work through, but it is one way to deal with the time constraint of an academic term.

Question 8: How are NFRs such as performance and reliability captured in this framework? Students are seldom taught to be aware of these.

Answer: I answered this question at the end of my talk, but to reaffirm my answer.  Often students find non-functional requirements difficult to grasp.  This is a perfect example why we should use real stories from industry to explain what happens when non-functional requirements are not appropriately addressed.  There are many such well-known stories that could be shared especially in the area of performance, such as the Obamacare Website problems.  Telling stories is the best way I know to make the point stick short of actually having the time to conduct a real project.  Using the related Essence checklist can then serve as reinforcement and as a reminder once they leave the university and go into industry. 

Question 9: As an active undergraduate student, would Essence and root cause analysis be taught in conjuncture with something like operations and management course? Or would these concepts be taught in their own course?

Answer: It could be done either way, but what I am proposing is to spread this training across many courses with relevant examples to each course inserted.  Root cause analysis isn’t something that should be limited to just one course.  Students should learn this way to think and use it throughout their career wherever and whenever appropriate.

Question 10: Grand Canyon University hosts a tech advisory board session each semester – the topic of changing or unclear requirements has come up.  It is hard to teach to that scenario because education requires having clear expectations.  Do you think providing User Stories and Task lists meet the need for students?

Answer: I don’t believe User Stories and Task Lists are sufficient.  They provide one way, but the student should be taught that this is just one way and the company they end up working for may or may not use this approach.   I believe you can set clear expectations in the university by adding real world scenarios to class content with changing or unclear requirements, having classroom discussions on those scenarios, and then testing the students by asking them to describe the root cause of the problem discussed and possible solutions. 

Question 11: Is there a place we can find all of the checklists?

Answer: Yes. On the last slide of my presentation you will find how to access all the checklists from the SEMAT website.

Question 12: Do you think universities should teach students things that change every few years in the real world? (I’ll give you a hint. The answer is NO!)

Answer: I didn’t need the hint. –:😊) You are right. The answer is NO.  This is a major driver on why we developed Essence. That is to teach students what they can take with them and use for a lifetime in industry.  This is much more valuable content for the student.

Question 13: Why should universities teach things that change every few years?

Answer: See the answer to the previous question.

Question 14: When should we be introducing Essence into a curriculum? How do I teach this to my freshman students, many of whom have zero programming experience and may need very structured assignments?

Answer: As I said at the end of my presentation and as I said in my answer to question 2, I think Essence should be distributed throughout a Computer Science curriculum and taught in a “stealth” mode by actually using it through concrete examples where appropriate.  Thus, the freshman student might get a little introduction to it, and then learn more about it in other courses where other examples might be more appropriate.   If you have a course on software engineering methods that would be a good place to talk about Essence from a big picture perspective.  Also, if you have a course on software engineering management that would also be a good course to talk about the general idea of Essence from a perspective of assessing progress and locating trouble spots in your project.  If you have an ethics course this would be a good place to talk about the importance of getting all the team members and stakeholders in agreement with the ethical principles they will follow on the project… and so on…

Question 15: Is linking the architecture to the requirements part of the check list?

Answer: Essence doesn’t provide “ hard links” between architecture (or software system- the alpha that includes architecture checklists) and requirements (requirements alpha) although there is certainly a relationship. The essentials of architecture are addressed in the Software System Alpha, and we say that the Software System Alpha “fulfills” the intent of the Requirements Alpha.   We say it this way for the reason I explained in my talk related to the “Enough Addressed to be Acceptable”.  Sometimes you don’t need them all addressed to “fulfill” the intent, as I explained in the “Requirements are not always requirements” example. 

Question 16: Is linking requirements to business and engineering needs part of the checklist?

Answer:  As I mentioned in the previous answer, Essence doesn’t provide “hard links” between requirements and other areas, such as business and engineering needs.  The essentials underlying “needs” are addressed in the Opportunity Alpha and there certainly is a relationship between the “needs” and the Requirements.  We say the Opportunity helps to “focus” the Requirements.  The specifics of this relationship depend on the practice your organization decides to use for requirements gathering (e.g. user stories, use cases etc.).  The reason I am being careful with the word “link” is because Essence is independent of method or practice choice.  What we say in Essence needs to be true for any method or practice.  This is also why it is so useful to teach students.   

Question 17: Do you think this type of education will help minimize “imposter syndrome?”

Answer: I haven’t heard the phrase “imposter syndrome” before, but if it means one practice pretending to be new when it really is fundamentally the same as another known practice or method, the answer is Yes.  This was one of the goals underlying the development of Essence. That is, to provide a common ground from which to compare practices and identify real discriminators.  Therefore you can use Essence to determine if there are no real discriminators and a certain practice is thus effectively nothing new.

Question 18: Examples of things that change every few years are software development methodologies (SCRUM/Agile/Essence/XP).

Answer: I disagree with your putting Essence in this list. Essence is not a methodology.  The intent of Essence is not to be used as a method to develop software.  It is intended to be used together with whatever method your company has chosen and therefore it doesn’t change every few years even if the method your company is using changes or if technology or tools change. Again, this is a powerful motivator for learning and using Essence. It isn’t going to keep changing every few years.  There may be minor improvements over the years, but it will essentially remain pretty stable. 

Question 19: One issue I see in industrial software is office politics. For example, resistance to change. When bringing improvement to an existing process or a system, existing people who created the original system would perceive this as an implicit critique to them and would fiercely oppose any these changes or enhancements. How would this be taught to students?  Thanks.

Answer:  Good question. I answered this question at the end of my presentation.  But to emphasize the point I made – this is a primary reason why I use Essence in what I call “stealth mode” as I discussed in my presentation.  I don’t think we should start from the supposition that something needs to change in an organization because that is a setup for opposition, as you say.  The starting point should be observing whatever your organization is currently doing and understanding what is perceived by those in the organization as not working well.  Then we use Essence (in a stealth mode—just stimulating normal conversation) to help identify the root cause of the problem.  From there we can all discuss the possible solutions and reach agreement.  This approach I have found can help to diffuse any emotion around change by taking the time to look at and reach agreement on what needs to be done to help the organization be successful.

Question 20: Where do we get all the relevant stories? I have some industry experience from before joining my university, but my experience is not extensive enough to know many critical stories of how company’s decisions impacted the work with the clients.

Answer: This is a great question.  I have personally shared many stories from my own career (such as in this presentation) and stories that have been shared with me by my clients (also in books I have published—for example my “It’s All Upside Down…” book has many real stories as does my “Integrating CMMI and Agile…” book).  I often encourage those with industry experience to share their stories through publications and by giving talks.  One way is to invite industry personnel to come into your classroom and give talks on real experiences with a focus on the trouble spots or challenges faced.  You could then have your class discuss the stories shared afterwards and see if they can identify root causes of problems discussed and possible solutions using Essence Alphas and checklists to guide the discussion.

Question 21: Imposter syndrome is a feeling by entry-level programmers that they do not have the knowledge, skills, or experience to be successful.

Answer: Ok. I think I misinterpreted what this phrase means in a previous answer, but my answer is still Yes.  Telling stories can help minimize this syndrome among beginners because it will help them feel like they have been in these situations just by hearing the stories.

Question 22: I must admit, I do not fully understand the concept of requirements not being requirements yet. Any clarification would be helpful. Thank you.

Answer: I tried to explain this in the talk, but let me try again and see if I can simplify it. Often something is written as a requirement because the customer (or person writing the requirement) only knows one way to get their needs met. But what they are asking for isn’t really a requirement, but rather one way to achieve their real need which is something else more fundamental.  When they learn more about the capabilities of the system that has been developed they may find another way to meet their need and thus what they thought was a requirement doesn’t turn out to really be needed by the customer.   Hope this helps.  You can often find lots of examples of this when a system is given a new user interface with different ways to achieve a user goal. 

Question 23: Can you come back on the Scrum practices that are implemented, poorly and not at all? What are they in each category? Thanks

Answer: Thanks for asking this question.  It isn’t one set (or one category) that are always implemented poorly or not at all. It varies with each company. For example, some organizations who claim to be doing Scrum don’t actually do retrospectives at all, while, of course, many companies conduct very effective retrospectives.  Some organizations implement their daily standup poorly and so on… 

Question 24: So that means, checklists are not enough but we should also group them based on weight or priority? So that if the more weighted ones are not checked, you shall not pass.

Answer: This question is in relation to my story about the Senior experienced personnel and critical thinking.  The answer is Yes, but be careful how you implement this. Which checklists have more weight or more priority depends on the situation so please don’t think you can do this assessment of priority and weight just once for a given organization and say that is the way we use them in our company.  This is why you need to teach your developers how to think and make better decisions on a daily basis.  I have seen organizations who try to dictate these answers from the top and it does not work.  It actually will cause the use of Essence to fail.  It leads to just using the checklists in a “check-the-box” mentality which is not what we are looking for.  We want your people to learn to use the Essence checklists to help them make better decisions given their own context.  Essence can’t make the decision for them.  Essence doesn’t know your context and this is crucial for each decision.

Question 25: If we conclude, we can say that students can learn from these stories and instead of following the usual tradition of “learning by making mistakes”, they can learn from others’ mistakes.

Answer: Yes. That is what I am saying. I am not trying to say they won’t still make mistakes and learn. We all must be continual learners, but we can share what others have learned so our new developers don’t have to relearn what experience has already taught us.  That is a big advantage of using Essence.

Question 26: Thank you very much Mr McMahon, so so interesting, holistic thought useful in many knowledge areas to teach in the university.

Answer:  Thank you for the nice comment. Good to hear you find it useful.

Question 27: We have a whole mashup of degrees that could lead to programming careers: CS in Arts/Sciences College, CS in Engineering College, Computer Engineering, Software

Answer: Yes. And as I suggested, I believe using Essence together we concrete real stories could be integrated into all of these degrees to help the student have a better idea what they will face when they leave the university and go into industry.

Question 28: where are the cards downloaded from?

Answer: You can find the url on the last slide of my presentation.

Question 29: More than 99% of code in the world runs in embedded devices. I work in the specialised area of safety-critical embedded systems: railway signalling, medical devices, (semi-)autonomous cars, surgical robots, warehouse robots, etc.

A few years ago I gave a keynote talk at an IEEE conference (sorry, but I wasn’t invited to an ACM one) and found I had a room full largely of academics. I asked for a show of hands of how many worked in a department that taught the skills required for embedded programming. Very few hands went up — many of the people present thought that Java was a programming language! I then refined the request to those who taught the techniques of producing safety-critical embedded code. One hand remained up. The safety-critical area is growing very fast and we are desperate for new blood, yet we cannot get such people from the universities.

Answer:  The situation described is one of the motivators for Essence.  As I mentioned in my talk you won’t find specific principles and practices in Essence and this includes safety critical principles and practices.  This is because not all software development requires these specialized skills.  It is expected that organizations develop additional alphas and checklists extending the Essence kernel addressing the specific needs of their domain.  

Question 30: This is really important. There’s many “industry oriented universities” with short academic programs that are skipping essential engineering and mathematics courses in favor of only programming-oriented courses

Answer:  Yes.  This is a good point and again it is a motivator for Essence. Teach the core fundamentals that are relevant to all successful software development.  We are not saying, as mentioned in the previous answer related to safety-critical needs, that this is all that computer science students need to know.  But it does ensure they understand the essentials that should always exist for successful software development.

Question 31: Does Computing Ethics have a place in the Computer Science (and related) curricula? And if so, how big should that place be, i.e one off ethics course, integrated ethical/social considerations per each computing course, interdisciplinary collaborations (e.g. between Computer Science, Social Science, Law etc) for teaching ethics, etc ?

 Answer:  Absolutely yes.  I also mentioned this in my talk. Essence does not prescribe ethical principles, but it does remind teams that stakeholders and team members need to agree on the principles and practices they will follow and that includes ethical principles.  It is my view that one of the best ways to handle this is to integrate this discussion into appropriate courses with concrete stories/examples.  For example, a course on databases could have a discussion on privacy and the responsibilities of a database developer in regard to protection of personal information.  Similarly, a course in artificial intelligence could have examples/stories that discuss the potential consequences and responsibilities of the software developer related to controlling self-driving cars and so on..

Question 32: At Grand Canyon University, we look for ways to introduce experience in reading other people’s code and refactoring it without breaking previously working functionality. We know students usually build something from scratch and with their own bias on knowledge and skill. By expanding their code exposure, they are more successful when they enter the industry.

Answer:  This is a great way to help prepare students for what they will face in the University because more and more software developers are working on legacy code rather than developing new code.  I would also suggest this is another great application for Essence, as students can use Essence in assessing legacy software looking for root causes of potential problems and potential fixes to these problems.  The results of such an assessment could be class discussion item. 

February 28, 2021

Incremental Essentialization: A cost-effective and practical value of “Stealth Essence”

Filed under: Essence and Problem Solving — pemcmahon @ 9:09 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/podcast I explained a simple way to apply just the right amount of structure to fix a problem with—or improve—a culture by using the Essence Pattern to capture essentials.  But how do you go about finding exactly which essentials rest at the heart of your current problem? 

I have in previous publications and blogs discussed [1,2,3] why I use a stealth approach when applying Essence with clients.  Simply put, proving the value of Essence by using it to help solve an actual problem is often the most practical way to get a client onboard.  But there is another good reason to take this approach, as well. 

Many senior organizational leaders are simply not convinced that investing in essentializing all their existing practices will be worth the investment.  This is where the stealth approach can help because it can be used to uncover small opportunities leading to an incremental essentialization approach.  Using this approach you can prove out the value of essentialization to your client (or your manager) in a low-cost way.  Let me give you an actual example from one of my client case studies. 

In one of my recent books [4] I tell the story of a client, I refer to as NORO, where we allowed the development team to effectively discover their own best practices while working on an actual customer project.  I make the point in this story that this approach seems totally “upside down” from what many of us have been taught with regard to proving out a well-defined repeatable process before using it on a real client engagement. 

But as we learned at NORO, by allowing the team to discover what worked best for them, we achieved rapid buy-in of key practices by the full team.  The reason this worked was because we were careful to make continual and small incremental improvements.  This substantially reduced the risk related to any single practice change.   

After we had proven out the new behaviors (many related to testing practices), I then was asked by my client to document the new/modified practices that the team had proven worked effectively.  When I captured these practices, I used an essentialization approach ensuring that the behaviors that were “essential” for success were clearly highlighted for other team members to learn and follow in the future.

This approach that includes waiting to formally describe your practices until after you have proven they work may sound upside down, but it worked effectively at NORO.  And, most important, NORO didn’t need to commit a large budget to essentialize all their practices at the same time.  Rather, at NORO, we essentialized the highest priority practices that we knew would give the organization payback because we had already proven it on a real project. 

If your organization isn’t ready to commit to essentializing all your practices, consider taking the “stealth approach” to identifying incremental improvement opportunities.  Once you have identified the essential improvements needed and proven they work, convincing your senior leaders to commit the budget to further practice essentialization will become a much easier road to navigate. 

Feedback is encouraged. 

[1] General information on Essence,

[2] Essence-In-Use References

[3] Essence-In-Use Training Course,

[4] It’s All Upside Down, Story Two, NORO Case Study,

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

January 30, 2021

Teaching the software development life cycle to high school students: Don’t forget to include why they should care

Filed under: Essence and Problem Solving — pemcmahon @ 11:56 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, click on the link and scroll down to where you can select the podcast.   

Blog Text Starts Here:

I recently received the following challenge from a high school teacher. He said,

“The goal is to code the Software Development Life Cycle (SDLC) using the Essence language. The result should be easy to understand for anyone, especially those NOT exposed to Essence. The general idea is to Essentialize something like Figure 1. My target is 16 year old students, or people who just started programming on their own.”   

                                                                                        Figure 1 SDLC

Let me start by saying that when I was in high school I wasn’t a great student. One reason was because I didn’t see what good much of what I was being taught was, so I wasn’t motivated to learn.  I almost failed ninth grade algebra.  I had no idea what the x’s and y’s had to do with the real world I lived in.  It would have been nice if this had been explained to me back then, but it wasn’t.  I start with this story because it affects the way I approach any challenge related to teaching students anything.  You have to first give them a reason to care.

Given this background, let me share how I would tackle this challenge today.

I would start by explaining to the students what the diagram in Figure 1 isn’t intended to tell them and then explain at least one practical use of the diagram they might care about.   I would focus first on what this diagram isn’t intended for because knowing what isn’t intended may help eliminate common mistakes. 

I would do this by saying something like:

“First, please don’t try to read too much into this diagram. I am stressing this point first because historically reading these kinds of diagrams too literally has led many software endeavors down troubled paths.   Specifically, the figure is not meant to imply a strict ordering of the software development activities identified on the diagram, nor is it intended to say anything about how to go about conducting the software development activities highlighted.” 

Next, I would explain what the diagram is trying to communicate and I would give a practical example that demonstrates why software developers should care.

I would do this by saying something like:

“The Software Development Life Cycle (SDLC), as depicted in Figure 1, is a simplified way to represent software activities conducted by a team. A team includes all the software developers involved in a software endeavor, as well as at least a few potential users of the software who can represent the views of the wider user community.  The value of an SDLC is that it helps anyone see the big picture, but what you don’t see on this diagram are essentials for software development success that underlie each of the activities identified and that is what you should care most about if you want to be a successful software developer.”

I would then give a few examples of those essentials by saying something like:

“Examples of essentials for success include principles, values, key practices and constraints. An example of a “principle” is Rapid feedback which could mean your team agrees to work in short cycles that include constant team and user communication. An example of a “value” is Courage, which could mean your team agrees to go as fast as they can, while also having the courage to slow down and share with their teammates anything that bothers them that they can’t solve on their own.  An example of a “ key practice” could be to develop tests before developing the code. An example of a “constraint” could be an agreement that there will be only three team members available to complete the entire software system.” 

I would then explain that principles, values, key practices and constraints must be agreed to by all software developers on the team, the software user representatives, and anyone else who your team depends on for help.   And here I would add, just for emphasis, when we look back at troubled software endeavors we often find that the root of the trouble can be traced back to a failure to reach agreement—or to take serious that agreement– on at least one of these essentials for success. 

I would also explain that principles, values, key practices and constraints can– and often do–  change on each software development endeavor.  In other words, you can’t learn just one way to develop good software and expect that the exact same way will work on all your future software endeavors.  

At this point I would slow down and tell them that in the future when they look at this diagram I suggest they try to recall what I am about to say about the essentials underlying each of the 6 activities highlighted on the diagram.  I would then explain the diagram to them in the following way:

Activity 1: Planning Essentials

On all software endeavors there is always work to be done by the team.  To be successful that work must be sufficiently broken down so the team can estimate their effort and commit to a credible (believable) plan.  

Activity 2: Analysis Essentials

When breaking the work down questions will arise that must be investigated and decisions made related to building new software, buying existing software, or reusing parts of existing software. 

Activity 3: Design Essentials

When breaking the work down decisions must to be made regarding hardware platforms (e.g. the computer or smartphone the software will run on), technologies used (e.g. programming languages), and interfacing mechanisms(e.g. how the software will communicateoutside its platform, such as cloud services). 

Activity 4: Implementation Essentials

The system must be tested and demonstrated, first in small pieces, based on the agreed to credible plan.

Activity 5: Testing and Integration Essentials

The small tested and demonstrated pieces must be integrated (combined) together, based on the agreed to credible plan to make sure the system as a whole is fit-for-purpose.

Activity 6: Maintenance Essentials

After the system has been accepted by the users as fit-for-purpose, acceptable defect levels must be maintained and agreed service levels supported.  This means that all defects don’t necessarily have to be fixed, but the critical ones– in the eyes of the users and the team– must be adequately addressed.

I would then point out to the students that the six essentials, as just described, usually occur iteratively (repetitively) within feedback cycles.  The details of these feedback cycles depend on the way of working that must be agreed to by the team as well as those who use or can affect the software system.

Now, let me say a little more about the approach I have just suggested in this blog to explain the SDLC  to high school students. 

First, I chose my words carefully.  The description provided above focusing on essentials underlying each of the six activities can be referred to as an “essentialized” description of the SDLC.  Essentialized means it uses the Essence language to communicate essentials.  

Specifically, information provided on principles, values, key practices and constraints can be found in the Essence Stakeholder, Team and Way of Working Alphas.  When you hear the word “alpha” just think of the important things we work with and want to keep healthy for software success.   Other italicized words in this blog can be found in Essence checklists.  Consistent with the Essence language, the term software system as used in the above description includes both the software and the hardware required to run the software.  This is because software without hardware provides no value.  And value is critical because Essence is a practical framework. It is based on what experienced practitioners have found is essential for success. 

The description of an SDLC provided in this blog is an example of using Essence in “stealth mode.”  For more information on Essence and the rationale for using Essence in “stealth mode” refer to [ 1, 2, 3, 4].

I would like to end this blog by providing a little rationale for the approach I have suggested to teaching the SDLC to high school students.

Using an “essentialized” description to teach high school students the Software Development Lifecycle can help our next generation of software developers avoid common mistakes of the past, and help them maintain awareness of the most important things to pay attention to for success when developing software.

As a final point, you might be wondering why it matters exactly what words, or phrases, we use when talking about software development.  The simple answer is because words matter.  Words are how we communicate, but they can easily be misunderstood.  The words, and phrases used in the Essence language were carefully chosen with the goal to minimize miscommunication and misunderstanding, while highlighting the essentials for success.

Feedback is encouraged.

[1] For more information on the background, rationale, and thinking behind Essence refer to

[2] For more information on case studies and practical uses of the Essence framework refer to

[3] For more information on Essence and Essence in Use refer to

[4] For training in using Essence in stealth model and as a critical thinking tool refer to

January 3, 2021

Build a Better Scrum using Essence and the Heart of Agile

Filed under: Essence and Problem Solving — pemcmahon @ 3:46 am
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, click on the link and scroll down to where you can select the podcast.

Blog Text Starts Here:

Today, thousands of companies are conducting agile transformations and according to Forbes 77% of those transformations are Scrum [1].  Yet, despite its popularity, according to Jeff Sutherland, co-founder of Scrum, 58% of all Scrum implementations are late, over budget and have unhappy customers [2]. Given these sobering statistics, a natural question we must ask is:

How can we build a better Scrum increasing our chances of success?

At least part of the answer, according to Sutherland, can be found in the Essence framework [3]. Sutherland tells us he has conducted an exercise with thousands of people in hundreds of companies where the participant teams build their own Scrum using Essence Cards [4] and then the teams presents their Scrum to the other teams as in a science fair.

Sutherland says:

“These Essence Cards flush out what is Scrum, what people are doing with it and how it is working…and we now have extensive data showing which parts of Scrum are implemented well,  which are implemented poorly,  and which are implemented not at all…  And on the average we find that about a third are implemented well, a third poorly, and a third are not implemented at all…. Essence immediately flushes out where the problems are, and then the next question is how can we use Essence to fix it?” [2]  

As a simple example of how Essence can be used to fix these problems Sutherland tell us one common problem you have in a vendor/customer relationship is who is responsible for what… By laying the cards out on the table and asking what the customer is responsible for, what the vendor is responsible for, and what do they jointly have to work on together, success rate is significantly increased.

Sutherland is not the only leader in the Agile movement looking at ways to fix common problems with Agile teams.  Alistair Cockburn, one of the authors of the Agile Manifesto has observed similar issues with Scrum, stating:

Scrum is pretty good.  It has very few rules, but it doesn’t tell you if anything goes wrong how to fix it.”  [5]

Cockburn, who believes that Agile has become overly decorated, has started a new initiative referred to as the “Heart of Agile” (HOA) in which he focuses on just four words—Collaborate, Deliver, Reflect and Improve [6]  The focus of HOA seems to be on the human or emotional side of software development.  Cockburn told me:

“If you see me emphasizing the human component more and more it’s because my experiences show it affects success more than other things.” [7]

The importance of the human dimension in software development success is supported by my own experience and the experiences of others working as SEMAT [8] volunteers on the development of Essence. In one of our Essence working group meetings we heard:

“The reason Scrum works so well is because we have come a long way on the technical side; how to develop requirements, how to design, how to test.  But it is the team side where we have been lacking and where Scrum fills a big hole.” [7]

While Scrum has helped many teams become more successful in areas such as collaboration through practices including Daily Standups and Sprint Reviews, the HOA initiative seems to be poking at a deeper underlying human issue.  One place you can learn more about it is in the first five minutes of a talk Cockburn gave in 2019 at a Lean Conference in France. [9]   

He starts this talk by saying he wants to make one small correction related to Agile, based on what he heard others saying at the conference the day before.  He then says:

“…Others put their energy into processes and tools and documents and plans, whereas the ‘magic’ is actually the way people interact with each other…. The magic comes from the movement of ideas between minds…”

 He goes on to say that the value that many people leave off when they summarize Agile is the very first value of the Manifesto and it is the one he is most proud of

“Individuals and interactions over processes and tools”  [10]

What struck me listening to this talk wasn’t so much what was being said, but rather the implications to successful software development. I was certainly aware of the Agile Manifesto Values, but I hadn’t previously given a lot of thought to the consequences of not emphasizing the values when people try to communicate what is essential to Agile.  

In the Essence language, the Pattern construct is used to reflect Values.  As an example, in Scrum Essentials, the Scrum Values are captured on an Essence Pattern Card. [4] Refer to Figure 1.

Figure 1 Scrum Values Pattern Card   

Those values, as depicted on the card, are:

  • Commitment
  • Courage
  • Focus
  • Openness 
  • Respect 

Note particularly the words on the card preceding the five values:

Successful use of Scrum depends on people living the five Scrum values.

These values are clearly an essential element to the successful use of Scrum, but in my own experience– and I would bet in the experience of many of those involved in the poor Scrum implementations referred to by Sutherland that– the essential values are too often not implemented well.

Reviewing the essential values of agile caused me to reflect on the fact that values must be lived, not just written down. It also caused me to reflect on just what the heart of agile is. 

From the Heart of Agile website [6] we learn that HOA is actually a “community of ideas” and that:

“The community forming around the Heart of Agile is what is interesting these days. People exploring better ways to collaborate, to communicate, to probe, to learn, to reflect, and to have more fun at the same time as having more impact.“

It occurred to me while reading these words that the degree to which teams truly “live” their values often has a significant impact on the success of a software development effort.  This also caused me to reflect on just how HOA might work effectively with Essence and Scrum.  To aid this reflection I recalled something Ivar Jacobson, the primary visionary behind Essence, once said to me, and that is the fact that practices are not just static descriptions. They are what we do! They are alive! 

More specifically, Jacobson recently said:

”…it is high time for a new paradigm. Where practices can be explored, experimented with, adopted and adapted interactively, in the same space where teams plan and execute their work, and continuously inspect and adapt their working practices.” [11]

The value of Essence is that it provides a reference framework that gives users the freedom to compare, and mix practices and patterns to form the best solution for their specific situation. Thinking of Essence this way brings me back to Jeff Sutherland’s exercise and something we all can do, particularly anyone reading this blog who believes they can implement a better Scrum. 

We can all conduct our own ”Build a Better Scrum” exercise similar to the exercise Jeff Sutherland referred to.  If you are one of those organizations that may be implementing Scrum poorly, or failing with Scrum, I suggest you download your own set of Scrum Essential cards [4] and conduct your own Build a Better Scrum exercise.  And when conducting this exercise be sure to pay close attention to the values your team holds giving particular attention to not only the Scrum Essential Values, but also HOA patterns, such as the one that captures the first value of the Agile Manifesto. 

You can use the Heart of Agile along with Essence to help your team build a better Scrum by bringing back the focus on the real essentials—including the values– to successful software development. 

Comments are encouraged. 


[2] SIGSOFT Seminar, April, 2020,, Refer to 14, 26 and 28 minutes into presentation



[5], Refer to 38 minutes into presentation


[7], Refer to Epilogue and Chapter Five.

[8] SEMAT stands for Software Engineering Method and Theory. Refer to for more information.




Next Page »

Blog at