CMMI and Agile Blog

November 23, 2011

What Does Lean Six Sigma and Semat Have in Common?

I recently went through an intensive ten week training course followed by a five hour examination to achieve my Lean Six Sigma Black Belt Certification.  Why I decided to invest the time to achieve this certification might not be why you think.   To help explain I need to first talk about another initiative I have blogged about in the past– Semat (www.semat.org).

I have been involved in the Semat initiative for almost two years.  Because all of us working on Semat are volunteers our progress has at times been slower than what we would like, but it is currently on the upswing.   For those who haven’t been following Semat closely,  we are building a kernel– or what we refer to as the “common ground”– for software engineering.  We realize we will only succeed if what we produce achieves wide acceptance.  Our current focus is on preparing our response to the OMG FACESEM RFP (A Foundation for the Agile Creation and Enactment of Software Engineering Methods).  http://www.semat.org/pub/Main/WebHome/Foundation_for_SE_Methods_RFP_ad-11-06-26.pdf.

Some have questioned the value of spending time on the Semat initiative.   As an example, I recently heard from a colleague who works for a largeUSdefense company that their OMG representative questioned the value of Semat because they didn’t see any “beef” in what we are doing.  If you attended our kernel working group meeting last Sunday you might understand this comment.  Last Sunday we initiated a high level review of our first seven kernel elements (Opportunity, Stakeholders, Requirements, Software System, Team, Work,  and Way of Working).

Small Semat sub-teams have been working  on descriptions, states and checklists for each of our kernel elements.  We are now stepping back and looking for consistency across these descriptions, and part of this effort includes building a small, but commonly agreed to, glossary.  One goal is for these kernel elements to be easily understood and to use a consistent vocabulary.  We plan to take our work out to the broader community to get more feedback.  This is critically important to ensure wide acceptance.

Just to give you an example from last Sunday’s discussion–  It was observed that in our initial kernel descriptions many words that were used seemed to by synonyms of others.  One example we discussed were the three terms– problem, obstacle and issue.  After lengthy discussion it was agreed that the way these terms were being used in our kernel description documents that  they were essentially intended to mean the same thing.  During this discussion it was also pointed out that the word issue, and problem often had a specific meaning inside certain organizations.

One of our goals is to try wherever possible to avoid terms that may carry certain baggage or lead to misunderstanding.   In this case we chose the term obstacle and initiated an effort to remove the terms issue and problem replacing them where it made sense with our preferred new glossary entry obstacle.   What we are doing should not be viewed as trying to ban words within Software Engineering.  We anticipate that specific organizations and specific software engineering segments will extend the kernel and its glossary to fit their needs.

What we seek is not to limit, but rather to provide a  small common ground starting point that we can all agree to.  To keep this small and consistent we spend an incredible amount of time in our working groups looking for things to throw out of the kernel, including words that that don’t add value or words that serve to confuse rather than clarify.  As a result, our goal could be viewed as eliminating “beef” that fails to stand up to our criterion of being universal to all software engineering efforts.

Now I can understand how some might question if it is really worth the effort to spend so much time worrying about these common everyday words we use.  Some might ask, isn’t our real goal to write high quality software?

The answer is yes, our goal is to write high quality software.  But those of us who have been working with software for a long time  have learned that the most direct path to high quality software requires that we first know our goal, second we must  know what must be done to achieve that goal, and third we must know how we will measure ourselves to determine if we have succeeded.

We have learned that not hitting our goal too often results from unclear objectives and conflicting stakeholder needs and expectations.  One way to help us address this frequent trouble spot is through a simple common language and small glossary of terms we can all agree to as a starting point.

I know it may sound trite, but when software efforts fail it still often comes down to the same issues it came down to 40 years ago — miscommunication of requirements and miscommunication of stakeholder expectations.

So what does all this have to do with why I invested time in becoming a certified Lean Six Sigma Black Belt?   Lean Six Sigma emphasizes the importance of first understanding where the pain is, or stated differently; What is the real problem we need to solve?  It second focuses on understanding the customer needs and how to translate those needs into critical to quality requirements which can me measured.  It next focuses on quick-wins and getting rid of waste.  To do this we make sure we understand each step of the process and how to distinguish value added steps from non-value-added steps specifically in the eyes of the customer.

Lean techniques drives an organization to look hard inside their operation not just at how to fix defects once they occur, but how to keep them from occurring in the first place.  Lean Six Sigma teaches us to look hard at our personal work habits, like cleaning up our work area making it easier to find what we need when we need it.   Last Sunday our Semat volunteers spent a good deal of time cleaning up the language we use to express what we do.  We are looking to eliminate non-value-added effort wherever it exists.  We are working to make it easier to communicate accurately the first time.

I didn’t decide to become a certified Lean Six Sigma Black Belt because I wanted to learn a new fad.  I did it because I wanted to learn something old that we all know, but too often forget.  Start by simplifying what you do.  Eliminate waste wherever you find it.  Eliminate anything that doesn’t contribute directly to your goal.  Where is the “beef” you ask?  Quality is not measured by how much beef we have.  It is measured by how much lean we have and whether our customers are delighted with the value they receive from our products and services.

Paul E. McMahon
Principal, PEM Systems

Author: Integrating CMMI and Agile Development

Certified Lean Six Sigma Black Belt

Phone: 607-798-7740
Web: WWW.PEMSystems.com

Email: PEMcMahon@ACM.ORG

Advertisements

Leave a Comment »

No comments yet.

RSS feed for comments on this post. TrackBack URI

Leave a Reply

Fill in your details below or click an icon to log in:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out / Change )

Twitter picture

You are commenting using your Twitter account. Log Out / Change )

Facebook photo

You are commenting using your Facebook account. Log Out / Change )

Google+ photo

You are commenting using your Google+ account. Log Out / Change )

Connecting to %s

Create a free website or blog at WordPress.com.

%d bloggers like this: