A new article has just been published that might be of interest to those following the work of SEMAT.
As always, comments are encouraged.
A new article has just been published that might be of interest to those following the work of SEMAT.
As always, comments are encouraged.
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:
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).
In a recent Google Tech Talk given by Ivar Jacobson and Ian Spence (https://www.youtube.com/watch?v=WNlERrVxYjs ) questions were raised regarding measured efficiencies when team’s use Essence versus control groups not using Essence. Capers Jones also recently asked me if I had any benchmark data showing the effect that SEMAT’s Essence Framework would have on productivity/quality factors (e.g. impact on work hours).
Although the new OMG Essence standard is only a few months old we are already starting to see hard evidence of the value of this framework. As an example, in a recent field study using Essence conducted at Carnegie-Mellon West ( http://works.bepress.com/cecile_peraire/31/ ) the following value of using the Essence framework was found:
“While most styles of Agile retrospectives tend to focus on known issues, Essence reflections tend to make unknown issues apparent by covering the project holistically and reminding participants of critical areas that might be overlooked. These differences make Essence reflections and Agile retrospectives complementary. This is illustrated by the following student quote:
‘Though the team was holding retrospectives every week already, having Essence discussions be a part of it allowed the team to touch on important aspects of the project; aspects which would otherwise be ignored’.”
What I find most interesting about this study is that the findings are not so much directly related to efficiencies gained, but rather related to improving the team’s understanding of unknown issues, or risks. This is the same observation that was made by a senior experienced engineer in a major USA DoD organization when first exposed to the Essence framework. One of the Essence framework’s primary strengths is that it can be used with any method to help an organization uncover risks early and take appropriate action before those risks do serious harm to your endeavor.
So how do you go about quantifying the value of Essence from a risk reduction perspective?
According to the Carnegie-Mellon Software Engineering Institute:
“Data indicate that 60-80% of the cost of software development is in rework”.
Rework is the result of not doing the task right the first time and is often caused by issues that were unknown at the time the work was originally done. Rework is preventable by reducing unknowns early, and it costs an organization in more than just labor hours. It costs in schedule delays, and lost customer confidence. It is therefore reasonable to conclude that anything we can do to reduce risk– such as using the Essence framework together with whatever your organization is doing today– can potentially reduce the cost of software development by 60-80%.
So, with such a great potential upside, what is the downside of using Essence?
Personally, I don’t see a downside for the following reason: Essence is not another method. It is not an alternative to what you are doing today. It is relatively inexpensive and easy for team’s to get started using the Essence framework in a way that complements their current approach.
To learn more about how the new Essence Framework can help your software development teams refer to: https://leanpub.com/15fundamentals or http://amzn.com/099045083X or take a look at the Google tech talk referred to above (https://www.youtube.com/watch?v=WNlERrVxYjs ).
Why not give Essence a try and let your software development team’s decide? What have you got to lose?
In last week’s blog I asked readers to consider providing feedback as to whether the software community needs a framework that fits the needs of the framework vision described in my 15 Fundamentals book. Tom Gilb replied by referring to his comprehensive handbook on “Competitive Engineering” (a book of about 450 pages). I have read a good deal of Tom’s book and find value in it.
I have also read much of Scott Ambler and Mark Lines’ “Disciplined Agile Delivery” book (about 550 pages), and I have read Barry Boehm, Rich Turner and their co-author’s recent book, “The Incremental Commitment Spiral Model” (about 240 pages), and going back a little further in time, I have read multiple times Watts Humphrey’s “A Discipline for Software Engineering” book (almost 800 pages). In all of these books I have found useful ideas and great value.
Right now I have two clients I am helping who have very different situations, but need similar help related to figuring out the right practices for their organization to keep them competitive in today’s rapidly changing and demanding world.
I, as a consultant, need to find the time to read books, like those mentioned, because I need to keep up with the latest thinking of the best thinkers in the field of software engineering so I can provide the best advice to my clients when asked.
In reading each of the books mentioned above I observed useful new ideas and/or innovative techniques, but I have also found certain ideas that I interpret as essentially similar to ideas I already know and understand. So in the interest of time-management– and getting the most value out of my “new book reading time”–I read books with a filter on.
My filter seeks out the strengths of each book in terms of what I perceive as new and potentially useful that I can add to my current knowledge base. I then make conscious mental notes allowing me to rapidly recall each new idea or innovative technique when I observe a client situation where the new idea could be of benefit.
This allows me at the right time as a consultant to stop and say to my client:
“Hey I think you should take a look at … [fill in one of those books, chapters, ideas/ innovate techniques here]… because I think this idea or technique could really benefit you given the problem I see that you are currently facing.”
Keeping up with the latest thinking of our best software engineering thinkers is something I must do because I am a software process professional and this is what keeps me competitive in my own business.
My clients come to me because they don’t have the time to do this themselves, and they don’t have the funding in today’s competitive world to keep their staff current on all the latest thinking in software engineering. I thus provide value they need that they don’t have inside their own organization. This keeps my business viable.
But what if there was a way for software practitioners— programmers, analysts, testers, managers—who are actually working on real software projects facing real challenges every day to quickly access and use the strengths and new ideas of these great software engineering thinker’s without having to read hundreds and hundreds of pages as I do to keep my business thriving?
While I personally look forward to reading great new books on new approaches to help with the challenges of software engineering, most real practitioners just don’t have the time to devote to this activity.
So– as I expressed in my response to Tom Gilb on my blog last week– what if we could find a way to make the strengths of Tom’s “Competitive Engineering” handbook more easily accessible to the practitioners who need help every day? And taking this idea a bit further, what if we could find a way to do the same for Scott Ambler, Barry Boehm, Watts Humphrey’s and all the other great software engineering thinkers work so that practitioner’s could quickly see and access the strengths of each, compare them, and then make logical decisions without needing to devote hundred’s of hours digesting hundred’s of pages of books?
Obviously, we would need to be careful how such a framework was implemented because any simplification of serious thought-provoking work could always be open for criticism. But on the other hand, we know as George Box has pointed out, “all models are wrong, some are useful.”
So do you think such a framework might be useful to the software engineering community?
What I am suggesting here may be a slightly different way to think about the current vision of SEMAT and the Essence framework, but in a sense this isn’t far from what SEMAT is trying to do.
The SEMAT community envisions an open marketplace of software aids (practices, patterns, methods, hints, and so on…) where software practitioners can easily see what is new, compare it to what they currently are using, and make effective and timely decisions that can help their software endeavors today based on their own specific circumstances.
I would love to hear what you think. Does the software engineering community need a framework that fits this vision?
In last week’s blog I explained how I whittled down a long list of possible titles for my latest book to the following top four choices:
Only one of the titles came close to meeting Peter Gordon’s rule of keeping the title to three words or less, and that was “The Essence of Improvement”. I liked this title for one main reason besides its length. I worked with Ivar Jacobson and our co-authors on the “The Essence of Software Engineering” book which focuses on the essentials—or common ground—that always exist across all software engineering efforts.
I was originally thinking when I started to write my latest book that I was going to distill “the essentials that are common across all improvement efforts”, and so the title “The Essence of Improvement” seemed perfect. But as the book evolved based on reviewer comments, discussions, and my personal analysis of past experiences working with multiple clients, it became clear that what I was talking about in this book was not common at all. In fact, the 15 fundamentals– while they seem simple on the surface— are rarely achieved or thought about in most organizations today.
There was also another problem with this title. While I have found value in these fundamentals in my own personal improvement efforts as discussed in the book (e.g. golf), the vast majority of the examples I provide relate to software development. So the simple “Essence of Improvement” title was reaching too far without sufficient research and proof into what it takes to improve and sustain improvements in other endeavors.
If you read my two blogs over the past few weeks about Practice Slices and Patterns you should have a good idea why “Better Decisions Through Better Practice With Patterns” would have been a great title for this book. The value of patterns is a key point that I highlight in this book, and I provide many pattern examples from my software development experiences both as a practitioner and as a coach.
As I researched the pattern idea I became increasingly excited when I found numerous examples of similar experiences to my own in areas that had nothing to do with software development. Examples include the idea of “thin slicing” discussed by Malcolm Gladwell in his book “Blink: The Power of Thinking Without Thinking”.
A second example was found In Daniel Kahneman’s book, “Thinking Fast and Slow”. In this book Kahneman explains how we can improve our quick–or intuitive– thinking by learning to recognize common situations rapidly. This idea fits perfectly with my own experiences in software development, especially when rapid decisions need to be made by software practitioners on a high pressure project when a deadline is approaching.
My favorite story that I convey in my book to explain the power of pattern recognition among athletes I borrowed from Jonah Lehrer’s book, “How We Decide.” This is the story about Tom Brady, Quarterback for the New England Patriots football team in the National Football League. In this story the reader learns how Tom prepares for football games which gives you an idea why he is such a great quarterback when the original scouting reports indicated he would never make it as a professional athlete.
The analogies between what Tom does, and what I have found software practitioners can do to help prepare for typical situations they face each day– especially on a high pressure software development project—may well be the most compelling part of my book. This also turned out for me to be the most rewarding part of my research and work in writing this book. For that reason this title was my own personal favorite. It was also Bill Fox’s favorite.
A late entrant into the list of possible titles was “A Framework Vision for Higher Performance in Software Development”. I liked this title because the framework vision, which I added just in the last few months of writing the book, turned out to be a major strength of the book based on comments from a number of my reviewers. It was exactly what was needed to help people understand why we need a framework like the Essence Framework. Creating this framework vision also helped me personally– as one of the volunteers who developed the Essence Framework—to step back and see more clearly the bigger picture and the need for a framework such as Essence.
The Essence framework is difficult for many people to understand when first exposed to it for a number of reasons. One reason is because it is not immediately evident to many people why we need this new framework, or what problem it is solving that other software frameworks have not been able to solve.
By presenting the framework vision in the book using very simple non-technical language it helps the reader to first understand what is needed and why we need it, before we talk about a specific solution.
If you take the time to read my book– whether you like the Essence framework or not– I would love to hear your feedback on whether you agree or disagree that the software community needs a framework that fits the needs of the framework vision as I describe it in my book.
But when the voting was done, the majority of my reviewers polled preferred the title that highlighted the 15 Fundamentals. What is it that resonates with the idea of the 15 fundamentals that I highlight in this book?
First, these fundamentals are not what many might expect to see in a book about fundamentals and software development. You will not see Requirements, Design, Programming, and Testing mentioned. This is because this is not a book about the fundamentals of developing software. It is a book about the fundamentals of performing at a high level and sustaining that performance even under difficult and often adverse conditions–which are not at all uncommon in today’s fast paced and competitive world– when developing software.
Second, in this book I am calling for a culture change in how we implement process improvement today in organizations. A key point I raise is the fact that the speed of change we are all witnessing in today’s world requires that we step back and take a serious look at the process we are using to help our people get better at what they do.
It is my contention that we need a far better way than what most organizations are doing today to empower our teams to take ownership for improving their own practices and their own personal performance.
The 15 fundamentals I present in this book are my way of helping you think a little outside the box about how you might help your own organization get started down this path. If you only take one or two ideas from my 15 fundamentals that can help you make even a few small changes in your organization that can start you down this road, then my ultimate goal in writing this book will have been achieved.
Love it or hate it, I would love to hear what you think.
When I asked Bill Fox, author of “5 Minutes to Process Improvement Success” (http://5minutespisuccess.com/ ) what he thought of my current working title of my latest book he didn’t answer. He just said, “the title of your book is so important. I think you should write down 100 possible titles, then pick the top ten, and then poll your reviewers to get their opinion.”
When he first suggested this I thought there was no way I could actually come up with 100 different possible titles, but within a couple of hours I had actually created a list of 102. The next part of whittling the list down to a top ten took longer. In my case the problem was compounded by a number of complicating factors.
First, Peter Gordon, my publisher from Addison-Wesley for my second and third book told me that a title ideally should be no more than three words. When I looked at my list of 102, less than 10 were three words or less and none of them were my favorites.
Second, Rachelle Gardner, a literary agent says, an author needs to do everything possible to come up with the best possible title because your title “sets the tone, … and hints at the style of the book… and draws the reader in….” (http://www.rachellegardner.com/about-rachelle/).
While Rachelle’s advice makes sense to me, what really complicated this issue was the fact that I had multiple goals in writing this book, and there was no way I could capture them all in a single title. Furthermore some of my reviewers were highlighting strengths of the book that weren’t even part of my original goals in writing it.
One of the lessons I have learned from writing this book is one should never be surprised if you don’t end up exactly where you set out to go when writing a book. It is as much a learning process as it is a way to communicate your ideas. This is especially the case when you have over twenty reviewers many willing to help guide your thinking. This also means you need to be open to hearing that the most valuable parts of your book may be different from what you had originally planned.
My original working title for the book when I started it four years ago, “How to Get Better at Anything” never even made the list of 102. And the working title I had for most of the second and third year of the book’s development as I wrote and rewrote draft after draft listening intently to my reviewer’s feedback, “Performance Improvement Simplified” made the top twenty, but missed the top ten.
The top three titles eventually were:
In the last few months of developing the book a fourth candidate title was also added:
In next week’s blog I will share which three titles could have been a great choice and why one of them turned out to miss the mark given where the book ended up. I will also share which title was my favorite, and why the eventual winner was selected.
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:
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: www.leanpub.com/15fundamentals or http://www.amazon.com/dp/099045083X/ref=cm_sw_su_dp
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.
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”.
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:
I just released a new book titled, “15 Fundamentals for Higher Performance in Software Development.” You can learn more about the book at www.amazon.com (paperback book or kindle store) or at www.leanpub.com/15fundamentals.
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 (www.semat.org) 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.
If you are facing questions related to which improvement model (or approach) makes the most sense to help your organization improve in today’s rapidly changing world, don’t think you are alone. To make this decision even more difficult when you start to look close at your options it is likely you will find that the best answer is not a single answer.
More and more organizations are using a multi-model approach today and for good reasons. As George Box once said, “all models are wrong, but some are useful.” Another way that I like to look at this is, “all models have weaknesses, but they each have their strengths”.
A few years back when I went through my Lean Six Sigma Black Belt certification I did so for multiple reasons. First, I did have a business reason as a few of my clients had recently been asking about Lean Six Sigma and were thinking of adopting this tool-kit as part of their overall corporate improvement strategy. But even before that motivator, many of my clients that I had helped achieve a CMMI Level 3 were agile organizations (e.g. Scrum houses). Now they were looking at taking the next step in their process improvement journey, and that meant becoming an organization that used their data more effectively to predict and improve. While the CMMI higher maturity practices (e.g. Level 4 and 5) can help here, the model is not strong in the “how-to” side of setting up a measurement system and monitoring data to help you predict and make effective improvement decisions. This is a strength of the Lean Six Sigma DMAIC methodology toolkit.
What I have found most surprising recently is how many of my Scrum clients are now trying to find better ways to get more value out of their retrospectives and many of them are interested in more quantitative measurement techniques to support their decisions.
At the recent SEPG/CMMI Conference in the Washington, D.C. area in May this year I presented one of my recent case studies of a client that was using CMMI Level 4 and 5 practices to help improve the effectiveness of their agile retrospectives.
The picture I hope you are getting is that Lean Six Sigma can help the CMMI, and the CMMI can help Agile approaches as well.
The new kid on the block is SEMAT’s Essence Framework, which was just recently adopted as a new Object Management Group Standard. Like Lean Six Sigma, CMMI, and Agile Retrospectives, the Essence Framework has its own strengths and weaknesses.
With my own clients I am introducing them to Essence gradually as I see areas where I believe it can help strengthen what they are already doing today. One of the strengths of the Essence Framework is that it is more for the practitioners than for the process improvement professionals. It is a framework that a team can start using quickly as an aid to help figure out where they are now and where they need to be focusing their attention in the near future. Teams can also use Essence to help get more value out of their retrospectives. Another area where teams can quickly get value out of the Essence Framework today is to use the Essence Competencies to self-assess ensuring they have the right skills on their team. These are areas where the CMMI, Lean Six Sigma, nor Scrum provides much help to a team, and therefore Essence can help to power each of these improvement models in these areas.
The long range vision of the SEMAT community, and the Essence Framework includes many other goals I have not discussed here including the vision for a practice library where practitioners can share and compare practices. Part of the SEMAT vision for the future is for all software practitioners to be taught the Essence Framework in the Universities so we all have an agreed to set of common terms and essentials as a starting point to aid communication regardless of which approach is chosen in a given organization. This will help new software practitioners get up to speed faster, and it will help organizations assess in a more consistent fashion where they might have gaps and overlaps in their processes/practices.
So similarly to how Lean Six Sigma can help the CMMI by helping with the how-to side of measurement, Essence can help whatever your organization is doing today by helping to engage practitioners in their own process/practice improvement.
Getting back to the initial question: How Do You Decide Which Improvement Model (or approach) Makes the Most Sense for Your Organization Today?
There is no single best model (or approach) to performance improvement, and I don’t see this changing in the near future. But the best approach does include conscious thought and it does require that practitioners take on greater ownership of their own personal, as well as their organization’s, performance.
Love it, or hate it, I’d like to hear your thoughts so your feedback is encouraged and welcome.