CMMI and Agile Blog

January 8, 2017

Helping Coaches Everywhere

In my last blog I highlighted how far a team can go to solve challenges on their own when given just a few simple principles and a clear goal.  But this doesn’t mean that teams don’t need coaching, tips, best practices and a structure that provides clear limits to how the team operates. This leads to the subject of this blog.

Besides the upside down principles, I also highlight in Part I of the book 18 coaching tips.  If you are wondering if a book that highlights coaching tips is for you, it is.  I believe everyone should view themselves as a coach.  But a big challenge most organizations face is how to communicate the right coaching tips to project personnel who need it, right when they need it.

Let me step back here, and tell you a little about my background.

I’ve been involved in the software business for over 40 years—the first 20 years as a software practitioner and the last 20 years as an independent consultant/coach.  And during the second half of my career as a coach I have often been called in to assist troubled projects.  One observation I have made about these troubled projects is that most of them fall into one or more of a surprisingly small set of common patterns.  But more importantly, when that pattern is detected in a timely manner, it’s usually not that difficult to steer the project back onto a healthy course. I’ve discussed this in previous writings and blogs. But this leads to an interesting question:

Wouldn’t it be great if there was an easy way to capture these common patterns and share them with coaches everywhere so more coaches could steer their project teams when needed keeping them on course?

This was my motivator for including a Part II in my book where I have framed the highlighted principles and coaching tips that have emerged from my stories in Part I within a framework called Essence.

If you have not heard of Essence yet, you have probably heard of the foundation from which it evolved, which I also explain in Part II of the book. I also explain with examples in Part II how Essence provides a simple and easy-to-use medium to communicate any organization’s practices, tips, principles, and checklists even among non-technical stakeholders.  This last point about stakeholders is particularly important. 

This is because when you read Part I you will learn how stakeholder issues related to understanding and knowing how to carry out project responsibilities is a repeating theme throughout many of my stories.  But, more importantly, it’s a repeating theme within many of those troubled projects I referred to.   

In my next Youtube and blog I share a personal story specifically related to troubled projects that can help you understand a key value of Essence that took me quite a while to fully comprehend and appreciate.

January 19, 2015

New Video on Practical Ways Teams Can Use Essence and New Published Paper on Essence

A few weeks ago I shared a You Tube video providing highlights of Part I of a talk on Essence (44 minutes) I gave at Binghamton University in November, 2014 to a group of Computer Science students.  Highlights from Part II of that talk are now available where you can learn practical ways software teams can use Essence including games they can play to help assess where they are, how to conduct a root cause analysis to isolate a problem, and how to use patterns to improve their performance.

Highlights of the talk can be found at:

The Part II highlights are 30 minutes in length and at the front of this video you can find where in the video the following 13 topics can be found:

  1. Assessment Poker
  2. Case Study Results Carnegie Mellon West
  3. Root Cause Analysis Example
  4. How Essence Differs from Lean Six Sigma
  5. Examples Using Activity Spaces
  6. Using Essence Competencies
  7. Another Example Using Activity Spaces
  8. Where Can Essence Help Most?
  9. Practice Slices and Patterns
  10.  Two types of information practitioners need
  11.  Examples of Patterns
  12.  A Closing Thought
  13.  How Students Are Using Essence at Binghamton University

I also have a new published paper on Essence titled,

A “Thinking Framework” to Power Software Development Team Performance, appearing in Crosstalk, The Journal of Defense Software Engineering in the Jan/Feb, 2015 edition.

December 27, 2014

Essence: What’s New and Different?

In November of this year, 2014, I gave a talk on Essence at Binghamton University to a group of Computer Science students.  You can catch the highlights of Part I of the talk on YouTube.  This is a great video to watch if you want to learn what is new and different about Essence, the new software engineering Object Management Group (OMG) standard intended specifically for software practitioners.  If you don’t have time to watch the complete Part I– which is about 44 minutes– you can find a cross-reference at the end of the video to where in the video you can find the following 23 key topics:

  1. What is Essence?
  2. The Difference Between Scrum and Essence.
  3. What Does Essence Contain?
  4. Why Did We Create the Strange Alpha Word?
  5. What is Different About Essence?
  6. The Essence CARD Deck.
  7. An Example Demonstrating How Essence is NOT Waterfall.
  8. A Question About Essence Versus Scrum.
  9. How Essence Can Power Whatever Approach Your Team is Already Using.
  10. About the Problem We Are Trying To Solve With Essence.
  11. How Does a Team Use the Essence Model?
  12. How Essence Checklists Are Different.
  13. How Do Teams Apply the Essence Checklists?
  14. On the Importance of Knowing When You Are Done.
  15. A Question on How a Team Can Fall Back.
  16. On the Order You Address States, and Decisions on Checklists that May Not Apply.
  17. An Example of a Team Deciding if a Checklist is Applicable to them.
  18. On Activity Spaces.
  19. Competencies Within Essence.
  20. How to Figure Out if You Have a Leadership or a Management Competency Issue.
  21. What if a Team Can’t Meet a Checklist Item?
  22. Why Isn’t Risk an Alpha?
  23. Why is Hardware included in the Definition of the Software System Alpha?

As always, your comments and feedback are encouraged.

November 27, 2014

Using Essence to Help Your Team Stay Fit, and Your Organization Find its Right Level of Governance

Some have raised the question:

Is the Essence Kernel ( ) just the essentials for all software endeavors? 

At a recent Essence user guide meeting this subject was discussed when Barry Myburgh raised the issue that some of the alpha state checklists might never be achieved by some teams.

He gave an example of a team with about ten developers he had been working with that never committed to when they would get the work done.  They had goals, but the team members had no idea if their goals were achievable.  He said they were incentivized to achieve the goals so as the deadline drew near the team worked hard, often late into the night, to get the job done.  When I listened to Barry describe his experience it resonated with my own experiences with many of my clients.

Examples of alpha state checklists teams might never achieve include:

Work Alpha, Under Control state:

  • Tasks are consistently completed on time and within estimates
  • Estimates are revised to reflect the team’s performance

Team Alpha, Performing state:

  • The team consistently meets its commitments
  • Wasted work, and the potential for wasted work are continuously eliminated

Some teams may never get to certain states such as Work Under Control because they don’t revise their estimates to reflect team performance. Rather they keep striving for goals that may be beyond their reach.   Ian Spence pointed out in our user guide meeting that some alpha state checklists are aspirational and are getting more at the health of an endeavor.  But when some people hear aspirational it can raise concerns.

Winifred Menezes, another Essence volunteer, pointed out one concern by asking—

What if a team is discussing their health and status and realize that they haven’t met a checklist item, wouldn’t there be a temptation to say, ”Oh, that item is only aspirational so we’re good and on track.”

Winifred raises a good point.  By calling some of the checklists aspirational are we making it easy for teams to decide these checklists are not essential and therefore require little attention?  Will this in fact dilute the value of the Essence framework as a guide to what is essential on all software endeavors? Will it cause organizations that are considering the adoption of Essence to lose confidence in Essence as an aid to help them find their right level of governance?

Toward the end of our user guide meeting Barry Myburgh after listening to the discussion said he had previously thought that on every software endeavor you needed to get through all of the alpha states because they were all essential to all software endeavors, but he now realized that was not the case.  Barry went on to draw an analogy.  He said when you use Essence it is like putting your team on a fitness program.  When a team uses Essence it brings an awareness of areas where they may have gotten out of shape, and can help motivate their team to improve in the future.

I personally like this analogy.  It reminds me of one of my Scrum clients who recently used a similar analogy by saying their team had gotten out of shape and they needed to go back to the gym.   They were doing this by giving the team some remedial training in best Scrum practices, and some additional coaching.  We heard a similar message from Cecile Peraire, another Essence volunteer, and a professor at Carnegie Mellon West where they have been conducting field studies using Essence with students.   In one of those studies a student indicated that using Essence Reflection Meetings reminded the team to think about points that otherwise would have been missed (  Similarly, when I was writing my latest book ( I thought what I was describing were fundamentals that most teams followed, but then I realized what I was actually describing was what it means to develop a high performance capability.

The concern that some teams may dismiss checklists that are viewed as aspirational is a valid one.  A simple way to answer this concern is to point out that we all need coaches at times to help remind us of our responsibilities—and to remind us when it’s time to head back to gym– if we want to stay fit.  But this simple answer may sound too glib to some, and this reaction is understandable.

At a deeper level this subject is dealing with the more fundamental issues related to trust in a team to self-manage itself versus the need for organizational governance to ensure required practices are adhered to.  Part of what the SEMAT initiative is trying to address through the Essence framework relates to helping organizations find the right balance between these two critical needs, while also helping teams stay focused on the real goal.

I would like to hear your thoughts on this subject.

September 16, 2014

How do you keep your audience engaged when they don’t understand your language?

In August, 2014 (this year) I faced this challenge when speaking at the Latin American Software Engineering Symposium (LASES) in Barranquilla, Columbia. The night before the talk Dr. Carlos Zapata and I came up with an idea that not only worked, but also generated more questions than I ever imagined.

The title of my talk was: Essence: A Practitioner and Team Performance Perspective.

Take a look at this video to see how we pulled this off.  Below the link to the video find a sampling of the questions I received and how you can locate them quickly in the video.

Following is a sampling of the questions I received during the talk:

  1. Why are there only 7 alphas in the Essence kernel?
  2. How long will the SEMAT community work on Essence?
  3. Why don’t we see practices represented on the kernel?
  4. What is the vision for how companies will represent their practices using Essence?
  5. Will there be more disciplines added to Essence?
  6. How is the kernel changed, and what changes are coming?
  7. What criteria was used in selecting Essence checklists?
  8. What is your vision for the future of Essence?
  9. How would you sell Essence to companies?
  10. Where are we headed with practices on top of the Essence kernel?
  11. What is the definition of practice from the point of view of the Essence kernel?
  12. How will practices be captured in the Essence framework?

If you don’t have time to watch the entire video, jump to the end of the video where you will find, along with the 12 questions above, 30 more key questions/concrete examples listed and a reference to where you can find them quickly in the video (minutes and seconds into the video).

July 31, 2014

Viewing Software Practitioners as the Customer for Your Organizational Practices: More Motivation for Practice Slices and Patterns

In last week’s blog I talked about the idea of deploying process improvements through what I referred to as practice slices and patterns.  I motivated this idea through an analogy to how we build and deploy large complex systems.  Today I want to provide another analogy to further motivate this idea. 

Today, a popular approach to describe and communicate requirements for software systems is User Stories.   A form that is often used for these stories is: 

“As a… [insert here your user role],

I want to… [insert here what you want from the system],

so that… [insert here why you wants this]”. 

This form of capturing requirements is more appealing for many software practitioners today than the traditional “shall statement” approach, but why do you think this is the case?

One reason, I believe, is because it is more personal.  It helps to put the reader of the story in the shoes of the user of the system.   In this way it communicates more effectively the real goal of the system from the perspective of that user.   The “why you wants this” is important because when we understand why a user wants something it can open up other possibilities not envisioned by the user potentially leading to a more effective solution.  

With User Stories the intent is to keep the written information to a minimum using it to stimulate a conversation where the details are fleshed out over a number of iterations.  Part of the reason this works is because it is a way to circumvent the ambiguities of written language.  Many would argue today that this approach has helped us develop software that is more responsive to user needs and has helped us reduce waste by creating fewer features that are never used. 

Now, let’s jump to the problem of developing and deploying useful practices for software developers.  The analogy I want to employ now is for you to think about your software practitioners as the customers for your organizational practices.

How often do we hear software practitioners say:

“My company processes don’t really help me with the real problems I face each day.” 

This is a common refrain that I hear over and over in organizations that have developed processes the traditional way.  So why does this happen?   Could it be the same problem that we have traditionally had with satisfying customers of our software systems?  Wouldn’t it make sense to engage our software practitioners in a similar way asking them to share their personal stories so we better understand what they want and why they want it?  

This is what we are essentially doing when we deploy our practices using practice slices and patterns.  We are developing user stories first from the software practitioner perspective.   The user story allows us to abstract the essentials of common software practitioner scenarios.  It helps us place ourselves in the shoes of our practitioners by asking them as software practitioners what do you want, and why do you want it?

 When I have discussions with software practitioners in my client organizations I listen to their stories.  I listen for their biggest pain points that they need help with now and when I abstract out the essentials often I hear feedback such as:

“As a software practitioner, I want more guidance in what I should do when I don’t understand a requirement, so I can build the best software to meet my customer’s needs.”


“As a software practitioner, I want to know what to do when my testing is taking too long, and I am getting pressure from my manager to finish.”


“As a software practitioner, I want more help in how to  handle a design risk, when the alternative designs are going to extend the schedule and I am getting pressure to finish on time.” 

Also, keep in mind that the guidance we give in response to these stories is best if it doesn’t come from an outside consultant or an internal process engineer, but rather from the expert practitioners in your own organization.  This is why we involve the experts inside client organizations in the discussions eliciting the options proven to work in the past within each organization, and also eliciting the consequences of common poor decisions.  When we add in the options and consequences based on how our experts would handle these situations we now have the patterns to use in training the less experienced personnel in the organization.

Of course the three stories listed above are not all a software practitioner needs.  But if it makes sense to deliver software in small increments, listening to the customer’s feedback before delivering the next increment, shouldn’t we be doing the same when delivering our practice improvements to our software practitioners?  

In other words, start with the first three stories your practitioners communicate to you because those are mostly likely the ones that are hurting their performance, and your organization’s performance, the most.    

This is what we are doing when we deliver process improvements with practice slices and patterns.   We are implementing process improvement in an agile and iterative way, and we believe everyone should be implementing their improvements this way regardless of what your practices and methods look like – agile, waterfall, or something else. 

Once you get started down this path you should also be asking a few other question to your practitioners at regular intervals, such as:

  • Do the practice slices and patterns we have already deployed help you?
  • What are the next most important user stories that you need help with? 

If a pattern previously deployed isn’t helping, change it in the next iteration, or delete it. In this way you keep your practice aids lean and of high quality always helping your team. 

You can build a library of practice aids in this way, based on continual conversations with your practitioners, providing assurance that you are giving your practitioners what they need most.  In this way you are also transferring the most current knowledge of your experienced people to your less experienced people raising the overall competency of your people. 

For more tips and pattern examples refer to the book, “15 Fundamentals for Higher Performance in Software Development” available at: or


July 24, 2014

Practice Slices and Patterns: A Better Way to Deploy Process Improvements


I want to share an idea with you that I believe is a better way to deploy process improvements that I call “Practice Slices and Patterns”.   Using practice slices and patterns is a way to engage your software practitioners in their own practice improvement which is a key goal of the SEMAT initiative, the Essence framework and today’s popular agile methods.

You can view a video about practice slices and patterns on YouTube:

First, people trump process. In other words a highly competent team will usually outperform a less competent team regardless of their practices and tools.  I don’t mean to bash practices and tools. My point is that ultimately the reason why most companies invest in process improvement is because they want to raise the competency of their people. They know in the long run that is what really counts.

So think about what it would mean to your competitive situation if you could raise the competency of your people faster than your competition.  Practice slices and patterns is one way to do this.

An analogy to aid understanding

Let me give an analogy to aid understanding.  We’ve known for a long time that the best way to build a complex software system is to break the problem down into small chunks and build and deploy those small chunks incrementally in small slices.   This approach works because it gets product into the hands of customers faster where those same customers can provide rapid feedback ensuring the development team is on the right track.

So if it makes sense to build and deploy our software systems incrementally in small slices, why wouldn’t it make sense to build and deploy the practices we want our practitioners to follow incrementally in small slices?


I will explain more about what I mean by practice slices and patterns in a moment, but to help motivate the idea let me first step back and talk about what’s wrong with how many organizations deploy practices today.

Our practices should provide useful information related to how we want our people to operate.  But people face all kinds of different situations each day on the job and so our practices can’t possibly tell practitioners what to do in each situation.

In fact, this is the mistake many organizations have made in the past.  That is, they try to define in detail what they want their people to do in every possible situation.  This has led in some organizations to practices (or processes) that are so heavyweight that they are not usable by human beings.  Other organizations have gone to the other extreme making their practices (processes) so light as to become trivial and of minimal or no value.

What practitioners really need falls in between these two extremes.  Processes need to be light enough to be usable, but they also need to contain enough value to help practitioners where they need help the most.   An example is helping them find the answers to those tough questions that often need to be asked, and helping them with the trade-offs related to how much effort to put into certain tasks once they decide the task needs to be done.

This is where practice slices and patterns can help.

So just what is a “practice slice”?

A practice slice is one or more related scenarios that commonly happen in a particular context.

What is a pattern?

A pattern is an abstraction of a practice slice that removes inessential details to ease recollection, and adds the options and consequences that can help the practitioner with the tradeoffs.  Patterns can help your people make better decisions.

An example:

Basic Scenario:  You and your team are driving toward a deadline, and your requirements are not clear and you can’t get your customer to work with you.

Related Scenario: You are still driving toward that deadline, your requirements are still not clear, but now you also realize your design approach may have a risk and the only alternative design is going to extend the schedule.

Another related Scenario: You are closing in on that deadline, but now you realize you don’t have all the data you need to fully test before release?

A practice slice could be just the basic scenario, or it could be the basic scenario together with one or both related scenarios.

You might discuss these common situations with your team and come up with various options that have proven to work for you in past similar situations.

A pattern is then just a simple way to capture the essentials of these scenarios along with the options and consequences you know have worked in the past and can therefore help you make better decisions in the future when faced with similar situations.

The Best Patterns to Aid Decision-making and Performance

When developing patterns to aid team decision-making what is most important is to not pick just any common scenarios.  For many common situations that happen everyday practitioners don’t need extra help.   So you want to pick the ones where people most often fall into making poor decisions, so the pattern becomes useful during the actual execution of their daily job.

With a number of my clients we used practice slices and patterns and these ideas really work.

Proven to work

First, we examined the common scenarios their practitioners were facing each day on the job.  Then we prioritized them and selected a small set that had a tendency to hurt their performance the most.

We then abstracted out a small set of patterns that included the options and consequences of related decisions.  Then we trained the people in the patterns, and we gave them simple checklists they could take back to use as reminders on the job.

Raising the competency of your inexperienced people faster

The experienced people in your organization know how to handle most of these common scenarios, and some falsely believe that we can’t speed up the learning process for the inexperienced people.   Let me explain why this is not the case.

First, to help you understand, there are a couple of books I like to recommend related to this subject.   One is “How We Decide” by Jonah Lehrer, and the other is “Thinking Fast and Slow” by Dan Kahneman.  Both of these books help us understand that we all can get better at decision-making even when we need to make decisions fast under pressure.

Both of these books explain how we can improve our quick thinking by learning to recognize common situations (scenarios) faster, and by keeping aware of our options and consequences and which ones work best under which specific conditions.

What we are talking about with practice slices and patterns is a way to deploy process improvements faster and more effectively ensuring we are focusing on the most important areas where practitioners need help today.

Practice slices and patterns is a proven effective way to share what your experienced people already know with your less experienced people helping you raise the competency of your people faster.

If this idea makes sense to you, you can learn more about the approach and find examples of many patterns in the book, “15 Fundamentals for Higher Performance in Software Development”.

( or

You can then use the examples in the book as they are, or use them to help identify your own scenarios that are hurting your team’s performance.  Then you can create your own patterns that make the most sense for your team.

I’d love to hear what you think about practice slices and patterns. Please share your feedback by commenting on this blog or through your favorite social media site.

You can also learn more about why I wrote the 15 Fundamentals book at:


July 17, 2014

Turning a Weakness into a Major Strength In My New Book “15 Fundamentals…”

I just released a new book titled, “15 Fundamentals for Higher Performance in Software Development.”  You can learn more about the book at (paperback book or kindle store) or at

In this, my first of a planned series of blogs about the book, I want to share some background information about how the book evolved and how I was able to turn a weakness into a major strength of the book.

If you have been following my blogs over the past few years you probably know I have been involved since 2010 in the SEMAT (  initiative.  SEMAT, just last month, achieve a major milestone with the Object Management Group formally adopting the Essence Specification as an OMG standard.

When I started to write my just released new book close to 4 years ago I did not plan for it to include any discussion on SEMAT or Essence.  My intent was to describe a problem that the software development community faces that I felt needed to be discussed more openly.  You can learn more about the problem at:

But as I moved forward in writing the book in parallel with my work on SEMAT I started seeing more and more areas where SEMAT’s Essence framework could help to solve the problem I was talking about in the book.

At first I was unsure how to address this because I did not want to disrupt my  planned flow of the book, so I decided to interject sidebars in the book explaining how Essence could help to solve the problem I was describing.

I had twenty-one reviewers of this book who reviewed multiple versions over the last three years. Only eight of those reviewers had any knowledge of SEMAT/Essence before reviewing the book.  Unfortunately, many of my reviewers gave me negative feedback on the new sidebars with comments such as:

“I find the sidebars distracting,”

“I don’t get this Essence thing,” and

 “The alpha idea makes my head spin”. 

Multiple reviewers suggested that I break the book into two books – taking all the Essence material out of the first book, having a second book just about Essence. Clearly these sidebars had  become a weakness of the book that I would need to overcome.

One reviewer who was a real practitioner and knew nothing about SEMAT or Essence suggested that I take all the  SEMAT/Essence specific material out of the first two parts of the book (first 12 chapters/ about 150 pages), and replace the sidebars with a more general “framework vision” that explained in simpler terms what was needed to solve the problem I was talking about.

He suggested that I use no “process-freaky” words in the sidebars.  This was a project manager in a large US Defense Company who is a very practical oriented manager.  He then said I should keep the Essence framework discussion in the book, but present it late in the book showing how it meets the requirements of the framework vision and how it can help to solve the problem I had discussed in the first two parts of the book.

This is the path I took, and most of my reviewers not only agreed with this approach, but some even went so far as to say they thought the new framework vision was now one of the major strengths of the book.  It was particularly good to hear that the reviewers were able to easily grasp the vision and agree with it, as it now was being presented in the new way.  I now think of this framework vision presented in Parts I and II of the book as the requirements and Essence, as presented in Part III of the book, as an example of one way to implement those requirements.

One reason I wanted to share this story with you is because in Part III of the book where I do talk about Essence I do so from the perspective of how it can help to solve a major problem the software community faces today.

As it turned out, taking this approach achieved another goal as well. Whenever I have spoken at  Universities or Conferences in the past about Essence, there always seemed to be at least a few people who would ask:

“Why do we need Essence?” 


“What problem is Essence going to solve that the other aids we have today like Scrum, CMMI and Lean Six Sigma don’t already handle?” 

By presenting the framework from the perspective of how it can solve a real problem the software community faces, answering those common questions becomes much easier.

This leads us to an important question.

Why is it so difficult for many people to grasp the value of the Essence framework when first presented to them?

Some have observed that it could be because Essence requires a paradigm shift not unlike what was needed when object oriented design was first introduced in the software community.  I would love to hear your thoughts related to this question.

You can learn more about how Essence can help to solve the problem that I talk about in the first two parts of the book at:

In future blogs I intend to share more about how this book evolved including a story related to how the book achieved its final title which was based on a  polling of many of my reviewers after I had literally written down more than 100 possible titles.  I will also share the top 4 candidate titles, and I will tell you why they all would have been great choices, and I will tell you now my initial personal favorite was not the final choice.

The book is available in ebook and paperback format from  It is also available in multiple ebook formats from, and


Create a free website or blog at