Essence and Problem Solving Blog

November 16, 2019

Let’s start a conversation on integrating Essence into day to day activities as a thinking framework and general problem-solving tool

I received a question on the title of last week’s blog– “The value of listening to people who think differently from yourself.

To clarify, if it wasn’t already clear to you, there are two distinct groups of people I was referring to.  First, are the SEMAT volunteers from around the world who shared their different perspectives based on their own experiences and culture.  The second group is the reviewers of my “Shy Boys” book who– as I explained in the blog– shared their own experiences and perspectives in helping me write a better book.

This week I would like to start a conversation (or get your feedback) on an idea I received from one of those book reviewers that really appeals to me, and I am particularly interested in hearing the thoughts from those of you who are in the education field.

This reviewer was a software developer in industry and had gone back to the university to teach software engineering to our next generation of software professionals.

Let me first give you some context for the reviewer’s comment.

In Chapter Fifteen of the book I refer to a discussion I had with Watts Humphrey shortly before his passing in 2010 and I state:

Part of training in how to act professionally includes how to listen, learn, improve and work collaboratively as a team member. These essential elements to software engineering success are found within the Essence framework Team Alpha checklists.”

This reviewer made the following related comment:

“Most Computer Science programs have a Software Engineering class, but the common issue is that the ideas are isolated within that particular class. In many programs, mine included, the software engineering class  is presented in the third year, after the basics are taught. You highlighted in this book the idea that you believed Watts wanted to make sure graduates had the proper attitude. One class in a computer science degree, as I learned over the years, doesn’t influence students enough to keep it present. I think we need to take a wholistic approach… We need a curriculum that integrates these ideas into the day to day activities without having to detail the activity in a text. While I was pleased that you and your colleagues produced a textbook, I think it might be more helpful to use “stealth mode” within the classroom environment. How to accomplish this could be your next book!”

 This comment got me thinking about how such a “wholistic approach” might be implemented in a university environment and one idea that occurred to me was to use Essence as a thinking framework to aid problem-solving in multiple computer science courses.

Just to provide a few examples where I think Essence could be integrated into existing courses, consider the fact that most computer science curriculums today have distinct courses in Cybersecurity, Computer Ethics, Artificial Intelligence/Machine Learning, and Software Requirements/Design/Testing.

Each of the computer science courses mentioned above provides its own unique perspective into critical challenges related to developing software.  Each of these perspectives brings its own set of common problems, or challenges, that students need to be exposed to, and learn how to go about dealing with in a professional way.

As a common ground for all software engineering endeavors, Essence could be used in each of these classes to demonstrate to students how to go about analyzing such challenges, identifying related root causes, and assessing options and consequences of possible decisions.

What I am suggesting could provide a path to achieving the “wholistic approach” my reviewer referred to by helping to teach our next generation of software practitioners what it means to act professionally when it comes to the common challenges they are likely to face when they enter industry.

One potential advantage to this idea is that it doesn’t require university professors to make major changes to their existing course curriculums as Essence is integrated into the existing course material as a tool that aids critical thinking and problem-solving.  This approach also can help students learn practical ways to use Essence to address common challenges they are likely to face in industry.

Another potential advantage to this idea ties back to one of the potential problems we are trying to solve with Essence as I state in Chapter One of my “Shy Boys” book.  That is, the fact that “there isn’t commonly accepted software engineering terminology so when new graduates come out of school with computer science degrees and go into industry they have a whole new set of terms to learn, and then if they change  jobs and move to another company they  have to relearn a whole new set again.”

By integrating Essence into multiple computer science courses as a thinking framework and general problem-solving tool we can continually reinforce the Essence standard terminology so it becomes the natural language of choice for new graduating computer science students as they enter industry.

I am interested in hearing your thoughts on this idea, particularly from those of you within the education field.

If you believe this idea might have merit, I am also interested in hearing about any specific problem scenarios you may be currently using, or thinking about using, in your course material.

We can then use such scenarios to continue this conversation by providing practical demonstrations of the power of Essence as an aid to critical thinking and problem-solving related to these timely computer science topics.

To be clear, what I am suggesting is not intended to replace a first course in Software Engineering using Essence, but rather to show how Essence can be effectively integrated into other common computer science courses as an aid to critical thinking and as a general problem-solving tool.

Looking forward to hearing your feedback and keeping this conversation going!

March 23, 2019

Critical thinking and Essence: Why every engineer and consultant should care

I work with a number of consulting companies.  Recently I was in a meeting with a member of one of those companies who was trying to explain a problem he was facing and was unsure how to solve.   He had attended a Milestone B review on a major US Department of Defense (DoD) program and was concerned with how his team was assessing the progress of the prime contractor.  For those unfamiliar, Milestone B is a key DoD decision point for approval to move forward with detailed engineering development.

He said that his team was using 150 checklists as the basis for assessing the contractor’s progress and because the contractor met 140 of the checklist-items they were declaring the review to be a success.  The problem was that one of the 10 checklist-items that wasn’t met was having a sound architecture that would solve the customer’s problem.

This person went on to explain that what made this situation even more troublesome was that all of the people on his review team were senior experienced consultants who should have known that NOT having a sound architecture at a Milestone B review was sufficient criteria in itself, regardless of how many other checklist-items they may have met,  to give the contractor a failing grade at the review.   He added that while his review team members were all experts in their specific engineering discipline, they all seemed to lack the ability to think critically.

Wikipedia refers to critical thinking as the analysis of facts to form a judgement.  It requires logical reasoning, research, curiosity and the ability to analyze and synthesize information gathered from observation and experience.

One effort that has been tackling the problem of helping people think critically is the Software Engineering Method and Theory (SEMAT) initiative through its Essence standard.  Essence provides a kernel of essentials common to all successful software engineering endeavors. Essence includes a set of essential checklists that can be used to support critical thinking.

While facts and checklists are important, as Wikipedia points out critical thinking requires more.  A colleague who works for a different consulting company told me, when I relayed this story to him, that the trouble he sees with too many consulting organizations is they assume they know the answer before they take the time to listen to and understand the problem the client would like solved.

To be an effective critical thinker you first need to be a good listener. You need to be curious enough to listen to and understand your client’s situation and to know where they need help.  Effective critical thinkers know how to use facts and checklists–not in a “check-the-box” mentality—but rather to guide a conversation and, when necessary, to expose poor reasoning by using experience.

When I coach teams in how to use Essence in a thinking capacity I emphasize the fact that while all the Essence checklists are essential, they don’t all have equal value and must be applied appropriately given the specific project context.  I also let the participants know that to use Essence in a thinking capacity requires an understanding of how to use it as a root cause analysis tool because if you don’t first understand the root of the problem you have little chance of finding a lasting solution that meets your client’s need.

All software practitioners should learn the essentials of software engineering, and all consultants should learn the essentials of listening to fully understand the circumstances before guiding.  This is fundamental to effective consulting and coaching.

A recent attendee at my Essence-In-Use training course commented that he felt the course should have been called “Consulting 101”.   I prefer to refer to it as “Coaching 101”, but regardless of whether you are a consultant, coach, or team member most of the essentials to project success never change.   You need facts, but facts aren’t enough for project success. We need to teach our next generation engineers the essentials of good engineering, but we also need to teach them the essentials of effective critical thinking and root cause analysis.

Essence is today being used increasingly in universities to teach our next generation software engineers the essentials of successful software engineering.  There is also an effort underway to explore modifying the Essence framework to support all engineering endeavors.

The next step is to teach all engineers and consultants how to use the Essence framework in a critical thinking and problem-solving capacity.   This will help consultants ensure they are solving the right problem for their clients, and it will help engineers ensure they are making the best decisions given their project context.

If you are interested in learning more about using the Essence framework in a critical thinking and problem-solving capacity refer to http://www.Essence-In-Use.com.

December 27, 2018

What does Essence and science fiction have in common?

One of the things I like most about Essence is how the alphas help you look at what is going on from multiple perspectives.  Often the root cause of a problem only becomes evident when you step back and look at the problem differently.

A few years ago I learned that Larry Constantine writes science fiction under the pen name Lior Samson.  I first met Larry at the SEMAT (semat.org)  kickoff meeting in Zurich in 2010.   Learning about this other side of Larry intrigued me and I investigated his work further and found he doesn’t write fantasy science fiction, but science fiction that makes you think about a common problem we all face a little differently.

I had started writing science fiction myself over twenty years ago,  but let it go when I started my own consulting business.  Larry’s story motivated me to revive my science fiction writing as I approached my retirement years.  Please note here that I am NOT planning on retiring, only taking up once again an old interest that I let go as I move into what some people might refer to as my “retirement years”.

I have just released my first science fiction book, and like Larry (or Lior) I now too have a pen name (Fred E. McMichaels), and my science fiction writing, like Larry’s, isn’t fantasy either.

Like Essence, my intent is to encourage my reader to look at common problems we all face a little differently.   I have, in fact, discovered that science fiction writing can be an avenue to problem-solving as it encourages people to open their minds to possibilities they might otherwise miss.

If you are interested in learning more about my new venture you can check out my new blog at fredemcmichaels.com and you can learn more about my first science fiction book below.

February 4, 2018

How Essence Makes Practitioners Better Software Estimators for a Lifetime

This is the fourth short video-blog (roughly 9 minutes) in my 2018 series on Essence and Software Engineering. As always feedback is encouraged.

 

January 27, 2018

How Essence Makes Practitioners Better Software Modelers for a Lifetime

This is the third short video-blog (roughly 8 minutes) in my 2018 series on Essence and Software Engineering. As always feedback is encouraged.

 

January 19, 2018

Things You Can Take with You For a Lifetime

This is the second short video-blog (roughly 7 minutes) in my 2018 series on Essence and Software Engineering. As always feedback is encouraged.

 

 

January 11, 2018

Motivation for Essence in 7 Minutes

Over the next few weeks I am planning a series of short videos on selected Essence and Software Engineering topics.  Following are a few tentatively planned topics:

  • Using Essence Alphas like the Dashboard in Your Car
  • Scrum and Essence: An Example of What Practitioners Can Take with them for Life
  • Examples Demonstrating How Essence Checklists Are Different from Traditional Checklists
  • Examples Demonstrating How Essence Checklists Help Teams Become Self-Empowered
  • Examples Demonstrating How Essence Activity Spaces Can be Used in Industry
  • How Essence Can Help Teams Determine if they have a Leadership or a Management Problem
  • Examples of a Team Using Essence as a Reasoning Tool to Solve Common Problems
  • A Case Study of a Team that used Essence to Help Them Discover an Innovative Solution To a Difficult Problem
  • Examples of a Team Using Essence Competencies to Determine if They Have a Skills Problem
  • A Skill Practitioners Can Take with Them for Life: Making More Accurate Estimates using Essence

I start off this series this week with a 7 minute video motivating Essence.  As always feedback is encouraged.

If you are interested in learning more about how Scrum and Essence are partnering, checkout the latest announcement on the SEMAT website (www.semat.org).

January 30, 2017

Avoiding two common software project troubled paths by “being agile” rather than “doing agile”

This week I want to talk to you about two common troubled project paths, and give you some simple tips to avoid both.

The first troubled path is putting too much effort into documentation. When you catch your project heading down this path stop and ask:

What is the driving need behind our documentation requirement?

Often there are two driving needs. First, your customer or senior management may be looking for some kind of assurance that the software team is doing the right things.  The second reason is to help users and maintainers once the software is deployed.

Unfortunately, traditional documentation isn’t very good at meeting either of these needs. It isn’t good at helping users and software maintainers because often it isn’t trusted to be kept up to date after delivery.  And, historically, documentation hasn’t been very useful to software teams at helping them create high quality software.

The second common trouble path is reacting to the first troubled path by declaring “we’re agile!” –and throwing out the essentials for high quality software along with the documentation.

Now, today, it is a fact that we are seeing more and more organizations trying to increase agility, but many of these same organizations are struggling to figure out how to “become agile” without jeopardizing essentials for success.  And in a moment I am going to explain more what I mean by that phrase “become agile” because I may not mean what you think.

But first, a little background. You may know that in previous blogs and publications I have talked about Essence.  Essence is a framework that captures essentials for high quality software in a simple way—and most important to today’s topic—those essentials are independent of the degree of agility you are driving for with your teams. Essence also includes a simple language to express practices on top of the essentials to give guidance to your teams.

Today I want to talk to you about three simple parts of an Essence practice and how these parts can help your teams find their right level of agility while not jeopardizing essentials for success and help you avoid both common troubled paths.

Those three parts are:

  • the purpose–or goal– of the practice;
  • the activities conducted as part of the practice;
  • the work products produced.

Activities in an Essence practice are what people actually do when carrying out a practice.  They can vary greatly in prescriptiveness. In other words, you can provide activities in your practice that just specify “what” people must do or you can be much more prescriptive specifying in detail the “how to” side of your practice activities.  Similarly, the degree of detail specified in a work product can vary greatly.

Now, let’s look at some examples from my “Upside Down” book.

In Story Two in Part I of my book you learn about a team that came up with an innovative approach to achieve the goal of their sprint review practice when they learned a key stakeholder could not attend the meeting. They actual got on an airplane and went to the client’s site to engage that customer and get their feedback.

The point I want to emphasize here is that the real goal of the sprint review practice wasn’t holding a meeting called a sprint review which is what too many teams get overly focused on when they blindly zero-in on following specified “how to” activities in highly prescriptive practices.

Stated differently, what we are seeing too often is teams falling into just “going through the motions” of prescribed activities. Other authors have referred to this as the difference between “being agile” and “doing agile”.   And, to be honest, I really didn’t understand this difference until I observed it in one of my own client organizations.

What you learn from that story I just referred to is how a team stays focused on the real goal and figures out a creative way to achieve that goal which is gaining the buy-in of key stakeholders—not holding a meeting called a sprint review.

In that same story you learn about a challenge the team faces with a tester having difficulty communicating with developers.  In this case, the team came up with an improved testing practice that included the activity of developers placing a note in the ticket to the tester.  The note in a ticket could be viewed as an example of a very lite work product—not a heavy documentthat helped the communication problem.

In this story it is important to understand that the goal of the testing practice wasn’t to create a note in a ticket.   The real goal was improving communication between developers and a tester. Placing a note in a ticket was just one possible activity that could help the team achieve the real goal of the practice.  And in this story you learn how the team understood that in certain situations if it made more sense to just get up from their workstation and go over and talk directly to the tester that was an option they could and should use.  This is a perfect example of “being agile” rather than “doing agile”.

What you learn from these stories is that where teams often get in trouble is when they start confusing the activity they conduct as part of a practice, or the work product they produce with the goal.  One simple way to help yourself is to keep asking yourself are we are getting too much into “doing agile” –  or just going through the motions of our rituals, such as sprint reviews even when the key people can’t attend?

Or are we “being agile” by keeping focused on the real goal and coming up with innovative solutions when necessary, such as finding creative ways to engage our stakeholders when they can’t make it to our sprint reviews, and getting up from our workstations and walking over to talk to a tester when their might be some risk of misunderstanding.

One caution here, if you decide to allow more choices in your team’s practice activities by making them less prescriptive– it is also highly encouraged that you provide clear limits to the activities, and coaching in these limits, so the team does not fall into chaos.

Always keep in mind that activities and work products are important parts of a practice, but they should never be confused with the goal of a practice.

When we see this confusion starting to happen it is often a sign that an organization is falling too much into the “doing agile.”

Use these simple practice tips when you are developing your practices and coaching your teams, and you might just find it easier than you think to avoid both common troubled project paths and find your right level of “being agile.”

January 26, 2017

Is Upside Down the key to Moving Forward?

Last week I promised in my next video and blog to explain two specific ways projects often get into trouble and give you some simple tips related to Essence that can help mitigate the risk of both.  I have had a busy week and so I am putting off that video and blog, but it will still be coming soon!

This week I was interviewed by Bill Fox from Container13; Exploring Forward-Thinking Workplaces

https://container13.com/exploring-forward-thinking-workplaces/

Bill asked me some very interesting questions.  One thing I loved about this interview was that I was able to tie in a strategy that may seem “upside down” that is used by the coaches of the 2016 Little League Baseball World Series Champions from Endwell, NY– which is just 6 miles from where I live.

Check out the interview at

https://container13.com/is-upside-down-the-key/

I’ll try to get back on track soon!

January 15, 2017

A Key Value of Essence Related to Troubled Projects

I have been involved in the development of Essence since 2010 along with many other volunteers from around the world representing industry, academia and research.  And I have spoken on the subject of Essence at numerous universities and in many organizations including many of my own client organizations.  And the reaction I often get—to be frank—has been mixed.

Some people immediately see the potential value and react with comments like:

“Wow! I wish I knew about Essence when we were planning our last project.”

While others react with comments like:

“I don’t get it?” or

 “Why do we need it?” or

 “What’s so great about capturing what we’ve known for years?”

 Although it has taken me some time to figure it out, I now understand at least part of the reason why people react differently when first introduced to Essence.  The reason is because each person views Essence through the lens of their own experiences and perspective.  As an example, I can view my own clients as falling into two distinct types each with their own distinct experiences and perspective.

One type includes successful organizations with happy customers. These organizations have great people with proven track records of creating high quality software and meeting their cost, schedule and performance commitments within reasonable tolerances.  They come to me for coaching because they want to keep aware of the latest thinking and innovations in software development.  They do this because they know they have to keep getting better if they are to stay ahead of the competition.

The second type includes those who seek my coaching because their projects are in trouble.  Many in this group aren’t meeting their commitments and their customers aren’t happy and many don’t even know how they got into the mess they’re in.

Interestingly, it’s the first type who often respond when introduced to Essence with questions like,

“Why do we need it?” or

“What’s so great about capturing what we’ve known for years?”

 While the second type often respond with comments like,

 “I wish you were here and had told us about Essence when we were starting this project!”

When I help troubled projects I have found Essence to be an incredibly useful tool to help communicate to key organizational and project team leaders in a simple way where they went off course, and how to get back onto a healthy path.

This is a key value of Essence specifically related to troubled projects— it is a tool that can help you quickly pinpoint a problem area, and then drill down into that problem area, locating precisely what needs to be done, and then communicate the critical information to the people who need to know to get the project back on course.

I like to use a sports analogy to help explain this key value of Essence:

Most of us don’t appreciate a good referee in a well-played sporting event because we are focused on the game and the great performance of the players in the game.  But when the trouble starts, that is when the value of a good referee is recognized and appreciated by most of us.

What is interesting about this—and the parallel back to software– is that people who have only experienced successful software development efforts often don’t appreciate the value Essence can bring to– not only troubled projects– but to all projects, even the successful ones.  To help my successful clients understand this I like to ask them to think about the following:

Even though you are successful today, how confident are you that your next project will be as successful as your last?  And even for your current successful projects, how confident are you that the success you are currently experiencing will continue tomorrow?

 The point is that on all projects— successful or troubled—there is always risk of new circumstances and new challenges that can jeopardize future success.

 So what are you doing to mitigate that risk today?

While Essence clearly has proven itself in helping troubled projects today, its greatest value may actually lie in helping to mitigate the risk all software projects face of loss of essential software engineering activities that we now know exist and have captured in the simple Essence tool.

In my next video and blog I will explain two specific ways projects often get into trouble and a specific feature of Essence that can help mitigate the risk of both.

Next Page »

Create a free website or blog at WordPress.com.