I’d like to hear what others think on this topic.

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

Just as we are reaching the ten year anniversary of the signing of the Agile Manifesto, there seems to be a significant increase in agile disillusionment.  Last month in an article titled,  “Agile Development: What’s behind the backlash against Agile,” [1] we heard about the hundreds of pages that will show up if you do a Google search on “hate Agile”, “Agile sucks” and “Agile fails”.   The article highlights three reasons for the backlash:   

• Too little analysis being done to address Agile’s appropriateness to an  organization’s situation (people, culture, management structure, business needs, development processes and tools).
• Trying to force a strict Agile approach when it is not appropriate for every environment. 
• Misunderstanding Agile principles as a replacement for discipline.

At the Agile Development Practices West/Better Software Conference inLas Vegaslast month, Martin Fowler also addressed this backlash when he referred to the four values of the Manifesto saying those who signed it weren’t trying to say there wasn’t value in processes, tools, documentation and plans.  He said those of us who signed the Manifesto were just trying to counter a strong movement at the time that was taking the industry too far in the other direction.  The main point of his talk centered on the need for the software industry to get back to being guided by value. 

Recently I caught myself trying to push a client too far down the “pure Scrum” path.  They had tailored their Scrum approach and I was concerned their tailoring had gone too far leading them away from key values Scrum provided.   They were not maintaining a consistent length for each Sprint, and they were allowing new work to be introduced in the middle of a Sprint.  I argued, as a good ScrumMaster, that keeping the Sprints a consistent length helps the team accurately predict its velocity, and  allowing new work in the middle of a Sprint was part of the reason they were often in chaos as release dates approached. 

But they forcefully argued back that the reasons they operated as they did were due to issues outside their control. This was a military environment, and I heard, “when the commander changes the top priorities he doesn’t mean wait until the end of the current Sprint.”  And I heard, “when they give us new high priority work we have to figure out the best way to get it all done, and sometimes it doesn’t all fit in a standard size Sprint.”

I backed off recognizing they had figured out what worked best for them given their environment.  As I thought about what happened, I realized the truth behind something Ivar Jacobson recently said to me while we were working together on a Semat blog [2].  Ivar said,  each team involved in developing software has its own method and they only need enough help to know that the approach they are taking is sound. 

The Agile movement of the past ten years has helped us understand the importance of individuals and interactions, working software, customer collaboration, and responding to change.  The risk we now run is becoming too dogmatic in the implementation of our values without adequate consideration to the context of each endeavor.  Agile is not a license to eliminate analysis and discipline. 

Agile, like lean, is more a way of thinking than a specific methodology.  I view agile as a set of tools that can help each team find whatever way of working works best for their current situation.  An agile way of thinking shouldn’t stop at software, but should include interfacing disciplines, such as systems engineering and project management. 

In all my years of helping organizations increase their agility and discipline I have never seen a “pure agile” approach work for even a single team.  There are always some conditions (regulations, staff skill constraints etc.) that require some tailoring.

If you want to reduce the risk of your agile adoption, give your team the freedom and the help they need to figure out the best approach, and the right degree of agility, given their specific situation.  Don’t dictate answers.  Just make the goal clear, and let them know the options they have to get the job done.   

[1] http://searchsoftwarequality.techtarget.com/feature/Agile-development-Whats-behind-the-backlash-against-Agile?asrc=EM_NLN_14271590&track=NL-498&ad=839381

[2] Referenced Semat blog by Ivar Jacobson and Paul McMahon: http://sematblog.wordpress.com/

Some of you might be wondering what is going on with Semat (www.semat.org).  In October it was announced that part of the Semat work would move to the Object Management Group (OMG, http://www.omg.org/) to take advantage of their open, transparent governance model.  The move to the OMG is taking place as planned, and many of us who have been involved in Semat during 2010 are supporting that effort.  There has also been a team formed from the original Semat working group members that is moving forward in preparation to respond to the expected RFP from the OMG.  The RFP is anticipated to ask for a software engineering kernel and a supporting  kernel language. 

Part of our goal in supporting this effort is to break some of the heaviness that earlier OMG efforts have brought to the table.   As we work with the OMG we are insisting that the language and kernel must be lightweight and supporting an agile way of working. 

 The subject of the kernel and kernel language brings us to the purpose of this article.   When I spoke at the Rochester Institute of Technology (RIT) (http://www.gccis.rit.edu/how-semat-can-change-future-software-engineering-personal-reflection) on the subject of Semat last October,  at the conclusion of my talk one of the first questions I received from a software engineering professor related to why we needed a language to express software processes when the Software & Systems Process Engineering Meta-model Specification (SPEM) already existed. 

I answered this question by stating that Semat wasn’t trying to compete with SPEM, or any other previous software initiative.  Semat’s goals are different.   For example, a primary goal of Semat includes a kernel of widely agreed essential elements supporting the needs of industry, academia and practitioners.  Semat seeks to separate these essentials from the specific needs of each organization and project.  SPEM does not have such a kernel.  Semat also seeks a solution with a greater focus on enactment than past approaches.  This means the solution must do a much better job of supporting the practitioner’s day to day activities.   To fully understand the importance of this goal, you have to first understand the problem we face today in the Software Engineering community. 

The Problem The Software Engineering Community Faces Today

The traditional way often used to describe software processes or practices includes a flow diagram demonstrating a sequence of steps (activities), resulting in the production of  artifacts,  such as a software requirements specification, design document, a test plan, or a test procedure.   While these process/practice representations have historically been viewed as an acceptable way to achieve the intent as identified in many process improvement frameworks, such as the CMMI, too often today we still hear from the software practitioners in the trenches that these process descriptions don’t really help them with the real job they face each day. 

When you dig a little deeper asking more in depth questions about that real job they face each day, and you listen to those practitioners describe what their real job specifically entails, it isn’t hard to understand why these process descriptions fail to help people where they need help most. 

Digging a Little Deeper

While Semat seeks to separate essentials from specifics, the problem we face goes deeper.  Many organizations today need help figuring out what information really should be captured in their “specifics”.  They need to know what their people really need help with to get their job done effectively.   It has been my experience that this important subject too often gets glossed over.  We don’t pay enough attention to where practitioners make their biggest mistakes.  

For example, some may need help in estimating because they tend to be overly optimistic.  Some may need help assessing risks.  Some may need help in determining what to do when they run into a certain type of problem.   The reason this isn’t easily solved is because these examples I just provided may be issues in one organization, but in another organization the critical issues may be completely different. 

The key issues that need attention the most differ in different organizations, and they differ in the same organization over time.  When I asked Ivar Jacobson for his thoughts he said these are what we would call extension practices.   He also said that the difficulty is that you need to know these “small fragments beforehand.”  And he followed that thought by saying if you did have a way to find them beforehand, “it would be great if we could hang these fragments on some kind of hook.”

It is worth noting here that this problem is not unique to the Software Engineering Community.   As an example, similar findings are being discovered in today’s processes within the health industry.  The common thread is “knowledge work”, a term coined by Peter Drucker over 50 years ago in his book, “Landmarks of Tomorrow” (1957).  Knowledge work refers to “work done in the workers head, rather than with their hands” and there exist other initiatives underway, besides Semat,  to help address this problem.   As an example, refer to work in “Adaptive Case Management” . [1]

At this point I would like to step back and ask a question.  Could there be a better way to help software practitioners with the real issues they face each day on the job?  More specifically, is there a way to give the software practitioner the specific help they need right when they need it most?  Can we, as Ivar refers to, know these small fragments beforehand, and might it be possible to, in fact, “hang them on a hook” so practitioners could access them, right when they need them?  And I want to highlight here  specific and small because what we are hearing, particularly from industry, is that general  and heavyweight guidance, is not cutting it.  

So What Is Semat Trying To Do About This Problem?

Much has been written about what Semat is and isn’t trying to do.  But one of the more exciting ideas is that practices– in the Semat context– are all about what people do, not just descriptions of what we would like them to do.  This—in the words of Ivar Jacobson—turns the idea of a “practice” upside down.   This idea opens up great possibilities.  So lets explore what it could actually mean with respect to how our practices will exist in the future—beyond just simple descriptions–  and how they might help people with the real tasks they face each day.  

A Different Way To Think About Practices: Upside Down

Traditional process representations have been static and impersonal.  They focus on activities and artifacts, and while some do make an effort to identify roles, and skills, and responsibilities, the people side has been largely missed.  This is not anything new.  At the Semat Kickoff workshop in Zurich last March Larry Constantine told us he and Ed Yourdon knew they had missed the people side from their Structured Analysis work in the 1970’s.  And it has continued to be missed ever since, including much of the current process representations that are used today. 

But what if we actually did turn the way we viewed practices upside down?   In other words,   what if we switched the focus of practice from  “things” to people?  In particular, the people who must use software practices—the software practitioners.  Now, think about the possibilities.   

This is not a completely new idea, and it is one that I have already found has proven useful in my own consulting engagements over the past few years.   When I hear those familiar words from a client – “the company processes don’t help me do my job,”—I typically have done the following:

First, I dig deeper to find more specifics related to what that individual means.  I ask, “could you tell me a little more about your job?”  And as they explain their job, I keep digging by asking, “what are the tough issues you typically face each day where you need more help?” 

Usually, I find that people talk easily about their job and can give me all kinds of situations that come up that they must face where they need help, but their documented company process descriptions give them no help at all. 

After talking to a number of people in a given organization I often observe common patterns emerging from these discussions.  I then take the data from these interviews and produce a set of simple scenarios that represent these common repeating patterns in that organization.  The scenarios I develop often demonstrate multiple possible decisions and possible consequences of each choice.   You could think of these scenarios as extension practices specific to a given organization.  You could also think of these scenarios as including more of the “how to” implement the practice, whereas the practice itself often just focuses on telling you “what” you must do.  Viewing it this way you can begin to see how such scenarios can really help the practitioner because it is the “how to” that they need when they are in the trenches doing their day to day work.  We package these scenarios up and use them as part of the training material when we deploy the new processes in the organization. 

What I have found is that because the scenarios are real to that organization, people relate to them and find them more helpful than static process flows.  This became so popular in one of my client organizations that I was asked to build more scenarios and then make them available on–line through their intranet.   This allowed the software practitioners to access the scenarios “just-in-time” during the “heat of battle” of doing their job, to refresh themselves on their options, and potential consequences, when faced with a given situation.[2, 3]

This is a perfect example of what I believe Semat is trying to achieve when we say practices are what we do, not just descriptions of what we would like people to do.

It is also worth noting that Watts Humphrey has observed in his work a similar need for more “how to” guidance for the practitioner.  He has stated that when using the CMM/CMMI ® it helps with the “what” you must do, but doesn’t help enough with the “how” to do it.  [4]

How The Semat Kernel Language Can Help Solve The Problem

At RIT when I spoke about Semat last October to help people understand what the Semat kernel language was about I made the following analogy:   I stated that the Unified Modeling Language (UML) is a modeling language for software.   The Kernel Language will give us a way to express the way we work when we develop software.  But if  this language is to help people with the real issues they face each day on the job, it must be able to represent those issues that can help most, and be usable by software practitioners in the “heat of battle” of their job.  Earlier efforts have largely failed here.

So if  Semat is to be successful,  what would such a language look like?

First, because people need information quickly when they are in the heat of battle of their job, the language must be flexible and capable of providing just the information a software practitioner needs when they need it.  This ties into an idea that has been discussed on Semat and is part of the vision going forward—separation of concerns.

When our concerns are not appropriately separated supporting the needs of the individual we create frustration, inefficiency, and we reduce our competitiveness.   The software practitioner needs what they need, when they need it, and no more.  And when they need it, they must get it in a form that is usable.  This is not to say they don’t have responsibilities to interact with key stakeholders, but only to state they only need to know what they need to know.

How can this be achieved? 

I suggest that a similar idea that has already proven successful can work for practice representations as well—multiple views where each view focuses on a specific software practitioner role. 

Whenever we model– or represent what we do in some tangible way–  multiple views can be useful.  So why not represent our practices from the viewpoint of those who must use those practices making sure to only provide the information that person needs at that point in time?   And from my own experience with my clients, the more specific we can make these views and the more “how to” information we can provide, the better it becomes as an aid to help with the real issues faced each day.  

Now let me be clear here.  When I say “from the viewpoint of those who must use those practices” I mean software practitioners.  This includes developers, managers, and testers.  Each has their own viewpoint, with their own set of specific “how to” issues they commonly face each day.  

It must be understood that the scenarios that I have found helped my clients in the past were very specific to roles within a given organization, and the “how to” solutions were very specific to the culture and environment in that organization.  Therefore such scenarios  would never be part of the kernel or the kernel language itself.   That is, unless we as a software community can come to a common agreement that some of these are patterns that do indeed repeat across all software engineering efforts—at least at some level.   This is still part of the challenge Semat seeks to solve as we move forward.

 The specific scenarios unique to specific software practitioner roles in each organization would be developed by extending the kernel using the kernel language.  Through such real scenarios that are developed from the real experiences of the people in your organization– using the kernel and the kernel language– we could have communities of not just shared best practices, but shared “best practice scenarios”.   This could  make static practices a thing of the past.  Our software practices would come alive!   And the goal of a practice being what we do, not just what we would like people to do would be realized. 

How Semat Can Bring Real Improvements and Cost Savings

Everyone is looking for innovate approaches to save cost and improve performance, especially during economically challenging times.   Training is a critical element organizations need to provide to keep their workforce competent and remain competitive.   However, historically it has been expensive with training costs continuing to rise. 

Static process descriptions can never replace training, because they can never answer all the questions a software practitioner will have, nor can those descriptions provide the needed coaching and course corrections required when a software practitioner is faced with a new situation. 

This brings us back to the issue Ivar Jacobson raised.  The difficulty is finding those “small fragments beforehand.” 

It has been my experience that the best practitioners inside organizations usually know what the key specific issues are for their organization at any given time and they know “how-to” handle those issues when they arise.  But what they too often don’t have is an effective mechanism to communicate this critical knowledge to their fellow practitioners so they too know just what they  need to know when they need to know it. 

In the past efforts to capture this information have failed for multiple reasons, one being because we have failed to separate today’s critical issues from yesterday’s and we have failed to separate common essentials from “specifics”.  When we try to list in our practices all the possible issues that could possibly arise it overwhelms us and processes become unusable.  This is the lesson from past heavyweight process approaches that have failed and continue to fail in many organizations today. 

The key to the future is to learn to identify that “small” set of “specifics” that are critical in your particular organization right now.  Then find a way to express them in an easy to understand way using a common language that includes a common agreed to set of underlying essentials.  This is not to say ignore all else, as this would lead us back to chaos.   What must be understood is that this is a matter of appropriate emphasis. 

Organizations that survive in the future will be those who find innovative solutions to meet critical needs, such as learning  how to systematically handle their current critical issues and communicating in a timely way expectations to those who need to know throughout their organization.    By creating a language that can be used in real time by software practitioners in an environment where they can access “just-in-time” the information they need most when they need it, we can bring real improvements and cost savings to industry. 

We envision here an innovative Semat kernel and kernel language that is easy to use by practitioners with easily accessible “hooks” to just the specific and small fragments of information they need when they need it.  The organizations that survive in the future will be those who embrace such innovations helping them maintain high performance and a critical competitive edge.   

Where We Go From Here

The Semat team that is continuing outside of the OMG effort is currently looking at options to gain broader involvement of the software engineering community in 2011.   We want to get feedback from potential users on our kernel and planned kernel language.  One possible activity that could be occurring at selected industry sites is looking at an organization’s software practitioner common scenarios and “how to” solutions to see how they could potentially be brought to life in real time through the kernel language.   We are still considering our options, and we are interested in hearing your thoughts and ideas.   We are also interested in hearing from those in the community who are interested in becoming more involved in the exciting work of Semat.  Please provide  your thoughts and feedback through this blog site, or through  the Semat blog  (http://sematblog.wordpress.com/).  

Looking forward to hearing from you!

[1] “Mastering the Unpredictable: How Adaptive Case Management Will Revolutionize the Way That Knowledge Workers Get Things Done”

[2] For more information on services helping organizations develop scenarios for “just in time” training refer to  (www.pemsystems.com).  Follow the links to the “Training Products and Services” page. 

[3] For more information on Paul McMahon’s client cases from which he draws common patterns leading to the simple scenarios, refer to his book, “Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement,” Addison-Wesley, 2010 

[4] “Why Can’t We Manage Large Projects?”, Watts Humphrey, http://www.crosstalkonline.org/storage/issue-archives/2010/201007/201007-0-Issue.pdf

In Part II of the interview the questions focused on the challenges faced in bringing process maturity to an agile organization, what you can do to address resistance, and who would benefit most from my book.  For the complete Part II interview, refer to:

http://searchsoftwarequality.techtarget.com/tip/CMMI-and-Agile-integration-Part-2-Adding-CMMI-process-maturity-to-Agile-organizations

To see both editorial and customer reviews of the book refer to http://www.amazon.com/Integrating-CMMI-Agile-Development-Performance/dp/0321714105/ref=sr_1_1?ie=UTF8&s=books&qid=1291925961&sr=1-1

Tom is currently planning a number of research projects addressing issues related to Semat.  We started our discussion by reaffirming the fact that Semat is not trying to compete with other industry initiatives including ISO standards and the CMMI.  I pointed out to Tom that Semat seeks the essentials of software engineering—the common ground we can all agree to.  I emphasized that “it  has to be small—not hundreds of elements– maybe just twenty or so.”  Tom replied, “Good luck.  It’s not that easy.  You can capture a small number of elements and get people to agree to them, but that won’t provide real value.” 

If we had this conversation a few weeks earlier I probably wouldn’t have had a good reply, but in this case I was quick to respond with; “The real value doesn’t come from the essentials themselves, but rather from helping software practitioners recognize the conditions where they fail to apply them correctly, and the options they have in those situations.”   

I had been thinking about this in Milan where we demonstrated through the Architectural Spike how to translate Scrum into the Semat structure. At RIT I took this notion further motivating the need for Semat by comparing Scrum–arguably the most popular Agile Method– to TSP, a disciplined team software process developed by Watts Humphrey. 

Many believe Scrum and TSP rest at opposite extremes on the agile-discipline method continuum.  I told those in attendance—mostly software engineering students and RIT faculty– that what I was about to say was based on my experiences with clients and while some of it may be controversial, I suggested they focus less on my conclusions and more on the process I used.  My experience from helping clients who have used these approaches indicates they may actually have far more in common than most realize.  I identified nine critical practices both approaches shared. 

Both Scrum and TSP have large supporting camps and both have growing bodies of evidence to support their success.  However, not all projects that use these methods succeed, and when you look close at the projects that run into trouble the root causes often turn out to be, not what is different between these two approaches, but rather  “common ground” elements that too often get missed.   Let me explain this further.

In my book I have two relevant case studies I refer to as LACM and GEAR [1]. LACM developed one of the best approaches I have ever seen to integrate agility into their existing CMMI processes, but today they are experiencing unanticipated difficulties.  Their approach fundamentally was to remove non-essential detail that was getting in the way of their people getting their job done.  Eliminating the non-essentials from the process descriptions brings focus to critical business essentials.   In my book I refer to these critical essentials as the “must dos.”  I have never found an organization that—once they try it– doesn’t think this approach is on target. 

However, due to business decisions LACM has fallen away from their focus on the “must dos.”  During a recent evaluation it wasn’t difficult to connect current costly troubled projects to their repeating weakness of lost focus on critical essentials.  As a result key weaknesses previously identified that could have been corrected are surfacing again and costing the company not just dollars, but potential future business.    

GEAR is an R&D organization that is employing innovative process improvement approaches to rapidly achieve CMMI Level 3 in support of strategic business goals.  Streamlined “must do” processes, and appropriate guidelines have been produced and agreed to in the organization, but the process deployment phase isn’t going as smoothly as desired. 

While key stakeholders agreed to what every project   “must do” at GEAR, the problem is every project isn’t doing it.  The  power of “must dos” has been proven to work to achieve an appropriate balance of discipline and agility at a reasonable cost [2].  The “must do” approach is the same idea that Semat is trying to bring to the broader Software Engineering community through the concept of common ground, or the “essentials” of Software Engineering.[3]   Until organizations try it they often don’t appreciate how a focus on essentials differs from previous process approaches, nor are they able to reap the benefits.

I have been looking closer at why GEAR is struggling to follow its own agreed to common ground “must dos”, and my initial findings are very interesting.  In some cases people are reading more into common ground than intended.  One simple example, a program manager was interpreting the word “plan” as requiring a comprehensive formal document, which was never the intent.

How do we address such issues?  This is where coaching and guidance become critical to effective process deployment.    One myth that I highlight in my book is relevant here: 

Myth: If an organization is agile, it requires less process training. 

At RIT, in a side meeting, Dr. Jorge Diaz-Herrera, the Dean of the College of Computing and Information Sciences, referred to a recent article by David Parnas related to the lack of discipline in software development and our failure to apply what is known in the field today.  Parnas say, “Much of the fault lies with our teaching.  Computer science students are not taught to work in disciplined ways,”  and he adds, “Disciplined design is both teachable and doable.” [4] 

There seems to be a tendency to think that essential common ground elements are so fundamental that they don’t require training.  There is also a tendency to think that to provide real value we need to make things complicated.  But when we examine closely where projects get into trouble, the real value people need to help them get their job done may lie in separating the essentials from the detail, as opposed to clouding them in complicated facts.    

Today software development is not limited to the large software intensive projects that seem to garner much attention.  Software is being developed in small organizations, by research scientists, electrical engineers and others.  Software  development is by no means limited to those in computer science and software engineering fields. 

Parnas tells us, “Anyone who observes engineers at work knows that exercising due diligence requires a lot of ‘dog work’.  The dull, but essential, work begins in the design phase and continues through construction, testing, inspection, commissioning, and maintenance.”  [4]

There are essentials in software engineering, but we haven’t brought them to light as in other engineering disciplines.  Parnas tells us that, “Many of us preach about the importance of determining the requirements a software product must satisfy, but we do not show students how to organize their work so they can systematically produce a requirements specification that removes all user-visible choices from the province of the programmer.  Some of us advise students to avoid dull work by automating it, but do not explain that this does not relieve an engineer of the responsibility to be sure the work was done correctly.” 

When you bring process maturity to an agile organization you actually need more, not less, training.  This is because the documented processes cannot address every possible scenario, nor do we want them to because history has shown such detail can mask the essentials that are most important.  Explaining to your people the likely scenarios, and the options they have in common situations is where the real power of common ground can be found.  But it must be trained and guided, not hidden in long wordy documents.  This is why I claim that common ground is critical to the future of software engineering, but it is also why I claim it won’t be easily attained.

[1] Integrating CMMI and Agile Development: Case Studies and Proven Techniques For Faster Performance Improvement, Paul E. McMahon, Addison-Wesley, 2010

[2] Refer to BOND Case Study in Chapters 4 and 5 of [1]. 

[3] Refer to www.semat.org

[4] Risks of Undisciplined Development, David Parnas, Communications of the ACM, 10/2010 Vol 53 N

 This week I am preparing for the 3^rd Semat Workshop to be held in Milan, Italy September 29-October 1.  After the Milan Workshop I will be giving a series of presentations in Northeastern United States to help more people understand the potential of Semat. 

 The following planned talk is open to the public and I encourage anyone who has an interest in learning more about Semat to attend.  There will be an open question and answer period following my talk.   

 I will be speaking at the Golisano College Auditorium (building 70, 1400) at Rochester Institute of Technology (RIT) from 1:00PM to 2:30PM on Friday, October 22^nd in Rochester, New York.  

 Title of Talk:  How Semat Can Change the Future of Software Engineering: A Personal Reflection

 About the Talk:  In this presentation I will explain the goals of Semat, how Semat is trying to achieve these goals, and how Semat relates to other industry initiatives such as the SEI’s Capability Maturity Model Integration (CMMI), popular software methods, such as Agile Methods, and international standards such as ISO and SPICE. 

 Case study examples documented in my new book, “Integrating CMMI and Agile Development: Case Studies and Proven Techniques For Faster Performance Improvement,” will be referenced as proof key Semat goals are achievable, and can substantially reduce future software development costs. 

I will also  provide examples demonstrating why Semat is needed today, and how Semat can change how we prepare future software professionals for the challenges they will face.   

Hope to see you there!

When I first heard the term alpha being discussed within Semat working groups, I was unsure if it was essential to Semat.  Although the precise definition of an “alpha” is still evolving, I now believe it is inside this alpha concept where the greatest hidden potential value of Semat lies.   

To help explain one first needs to understand the idea of a Semat Universal, how the Universals are being developed on the Universals Track, and how “alphas”  can bring critical value beyond the simpler Universals. 

I am currently leading the Assessment Track of Semat supporting Watts Humphrey and I am participating actively on the Requirements Track, the Universals Track, and the Kernel Language track.  As of this writing in early July, 2010 we have developed about six Universals on the Universals Track.  You can think of a Universal as something that is essential to all software engineering efforts.  For a Universal to pass the test of being a Universal it must meet the following criteria:

• Universal/Essential;
• Relevant;
• Actionable;
• Assessible;
• Defined Precisely.

A fundamental goal of Semat is to find those elements that we all agree are indeed Universal so we can stop the continual reinvention that occurs when new fads or new software engineering methodologies arise.  But just finding those “universal” elements alone will not be enough to make the Semat initiative a success.

Semat will not provide a methodology.  It will provide a kernel that contains the agreed to Universals, a kernel language that will support users in “combining”  Universals in a well-defined way,  and precise agreed-to related definitions.  Another fundamental goal of Semat is to help users both define new practices and methods and compare existing practices and methods using the kernel to help them make more effective decisions related to their software engineering work.   

Nevertheless, if you look at the first few Universals that have been proposed by the Universals Track some interesting questions quickly arise.  Early example candidate universals include Software System, Team, Work, and External Stakeholders.  

One question that arises is: What is the value of defining these “universal”  things that to many seem obvious?  

To understand the answer to this question we need to discuss the concept of an “alpha”, how an “alpha” relates to Universals, and the added potential value alphas can provide.  Let’s start by looking a little closer at a candidate Universal.

A Candidate Universal

Software System is one of the candidate Universals being proposed by the Universal Track.  Its current proposed description is:

A software  system is a system made up of software, hardware and digital information that provides its primary value by the execution of the software.

The Software System candidate has been verified by the Universals track as meeting the Universal criteria identified above.

What Is An Alpha?

A currently proposed (but evolving) criteria to determine if something is an Alpha is the following:

• The candidate has a Name
• It has a set of associated or referenced work products
• It has a well-defined set of states
• It has a completion criteria
• Optionally, it contains sub-alphas

Verifying if a Universal is an Alpha Through an Example

As an example assume you are a potential Semat user who is using a Component Development methodology on your project.   It can easily be verified that the candidate universal “software system” is a potential “alpha” by using this criteria as follows:

• The candidate has a Name which is Software System
• It has a set of associated work products which could be your code, test cases, design artifacts, and requirements artifacts
• It has well-defined states which could be based on your specific project agreed to life cycle phases
• It has a well defined completion criteria which could be based on your specific project agreed to completion criteria for your specific work products
• It has sub-alphas.  Each individual component in your project architecture can also readily be seen to meet this criteria

Reasoning Process To Determine If a Universal Is an Alpha

We have verified that the Software System Universal is a candidate Alpha.   But are all Universals valid Alpha candidates?  Let’s consider another candidate Universal “Team”.  “Team” has also been proposed by the Universal track as a Universal.  Its current proposed description is: 

The set of people actively engaged in the development and delivery of a specific software system.

If you run through the criteria for an alpha with the “Team” Universal you could reach the conclusion that it is not a good candidate to be alpha.  This is because you could conclude that a team doesn’t have well-defined states.  But under further scrutiny this may turn out to be false.  Consider the following argument.

All Universals must be assessable.  This is part of the criteria to be a Universal.   How do we assess a team?  Current work on the Assessment track is starting to develop a conceptual map for each Universal to help us understand each Universal in the context of its relationships to its attributes and to organizational objectives.  With such a map we can then make intelligent decisions about what aspects of a team we should be assessing.  This work is still evolving, but an early conceptual map of the Universal “Team” is leading to an increased understanding of certain attributes of a team that many believe are essential to all successful software engineering endeavors.  Examples include what are currently being referred to as  “coordinated-ness” and “collective mind-ness”. 

As these discussions continue to unfold it is quite possible that we will see that teams do indeed move through “states”.  It is already well known and accepted that teams undergo phases commonly referred to as storming, forming and norming.  And we may find that phases or states exist related to the degrees of “coordinated-ness” and “collective mind-ness”.

While this example doesn’t demonstrate for certain weather the Universal “team” is an alpha, it does demonstrate a criteria and a thought process by which we can assess a Universal, and reach a judgment.  Why this is important will become evident in the following paragraphs. 

Not All Alphas Are Universals

So far we have been discussing Universals and how to reason to determine if they are alphas.  But could an Alpha exist that is not a Universal?  To answer this question we need to go back to our criteria for Universals and Alphas. 

To be a Universal, the candidate must be Essential on all Software Engineering efforts.  As we consider the specifics of any software engineering endeavor we need to tailor our practices to fit our environment.  This tailoring of practices leads us out of the world of Universals because the practices we modify/tailor are now specific to our project conditions and therefore will not apply universally.  But it doesn’t lead us out of the world of Alphas.  The criteria to be an alpha doesn’t include being essential on all software engineering efforts.  Alphas are not necessarily universal.  This is a critical point and one we will see is crucial to helping real software practitioners on real software engineering efforts.

Let me give an example of an Alpha that is not a Universal.  Consider the Software System Alpha.  Suppose our Semat User has  tailored their practices to address their  unique needs and we  have made some project-specific decisions on the form the software requirements artifact will take.  Because Software System is an Alpha it has a set of well-defined states.  But because it is also a Universal these states must also be “universal.”  

However, because we tailor/extend practices to address specific project needs we may also tailor/extend the states based on these specific decisions on the form chosen to reflect those software requirements.  Note that in doing so the extended/tailored version still meets the criteria for being an Alpha, but it is no longer a Universal.    

Why Should You Care?

At this point you may be asking why should I care about Alphas in the first place?  In other words, what is the value of the Alpha to the end Semat User? 

Part of the answer to this question lies in why I say the idea behind an alpha is not really new.  What I believe we are actually doing on Semat is defining precisely and institutionalizing a concept that has proven to be a critical success factor in multiple past software engineering endeavors.  Let me give you three examples to demonstrate this point.   

Example One: CMMI [1] Organizational Assets and Tailoring

Fundamental to the best practices within the CMMI model is the notion of a common organizational process asset library from which specific projects tailor their practices to the unique needs of each project.  This concept of establishing common process assets across an organization along with tailoring guidelines has proven to work for many organizations that are succeeding with their software engineering efforts today around the world.  The analogy I am drawing is that the Semat kernel can be likened to the Organizational common repository, and the tailoring rules can be likened to the kernel language which provides the rules for “combining”  universals (or tailoring) to form practices for each project’s needs. 

I have long advised organizations that want to be disciplined and agile to use a “tailoring up” approach when developing processes using the CMMI model as a guide.  This means keeping what I refer to as the “minimum must dos” at the common organizational level [2].  This is very much like the idea of the kernel which contains only the “essential” elements for all software engineering endeavors.   You tailor up from the minimum core set we all agree everyone “must do” regardless of project scale or constraints. 

Example Two: IBM/Rationale ClearQuest Tool

IBM/Rationale ClearQuest is a workflow tool that has “out of the box” defined states for the fundamental element referred to as an Activity within the tool.  A number of my clients use ClearQuest, but they don’t all use it the same way.  Most have tailored the tool adding their own states based on their specific project environment needs. This is not uncommon for tool vendors to provide tool capabilities that are very basic, but extendible for specific user conditions.

Example Three: Successful Software Reuse Organizations

While it is popular to point to software failures, today there exists many success stories of software organizations that have reached high levels of maturity producing quality software rapidly despite facing continual changing requirements and technology.  Many of these successful organizations have found ways to increase their productivity and competitiveness by automating parts of their software development through domain-specific solutions and tools which support more effective decisions by simplifying their most commonly occurring decisions.[3]  This automation was made possible through their identification of repeating patterns with well defined states within their specific domain.  For more details on two such examples see the referenced articles.[4]

Why Should You Care?

The answer to the question, “why should you care?”  is because the fundamental idea underlying “alpha” is a proven critical factor that has been observed in multiple successful organizations in the past.  These ideas work. They are not new. They have been proven over and over again in successful software engineering organizations. The alpha concept is a way for us to institutionalize these proven concepts within the broader software engineering domain—and this is really what is new and what Semat can do to provide real value to the software engineering community. 

What Does Alpha Provide Beyond Fundamental Universals?

 First, Universals by themselves are not very useful because they are agnostic. Alone, they are like nuts and bolts on the floor.  Stating that a team or a software system is a Universal is interesting, but alone it provides no unique added-value to help Semat users do their job more effectively.  This is partly because Universals are intentionally agnostic. Their value is found in the fact that they get us to that all important common ground from which we can begin to communicate more effectively to one another. This point should never be underestimated.  

However, being agnostic can be both good and bad.  It is good because it provides commonality, but it is not so good because it doesn’t provide enough value alone to help people do their job on real projects. To do this we must have a way to connect what Semat is producing to the real world that our users deal with every day. 

Consider again the following key elements within the criteria for an alpha:

• Associated work products
• Well defined set of states
• Completion criteria

The associated work products are specific to your project.  They are currently being referred to as “Betas”.  The well defined “set of states” still need to be worked on Semat and this is where one of our greatest challenges lie.  The completion criteria still needs to be worked on Semat.  What I hope the reader understands is that Semat is still in its infancy. It has great potential value, but we are only just starting. 

Four Specific Values of Alpha

Let me explain four specific values that Alpha can potentially bring to the real users of Semat. 

First, the Semat User doesn’t have to start from a blank sheet of paper on every new project defining their methodology.  Alphas can help us by saving us time and effort by allowing us to reuse from our past.  We no longer have to go back to ground zero on each new project.

Second, because the alphas (some of them, not all)  are also Universals, which are agnostic, they are not forcing us into any specific methodology.  A fundamental requirement of the Semat kernel is its support for new practices and methods, and extending existing ones. 

Third, this is not unproven theory. The concept has been proven with CMMI tailoring approaches, successful commercial tools, and in organizations that have achieve high levels of software reuse through automation.   The principles on which Semat has been founded have already been proven.  The added value the Semat initiative is bringing is to “abstract”  these principles so they can be applied across the wider full domain of software engineering, and alpha is critical to achieving that added-value.

Fourth, the alpha concept can help the Semat end user with one of the hardest problems of many past software engineering endeavors.  That is, measuring  our progress more accurately.  

How? The “base states” of the alphas that are part of the Universals will have “base measures” and we can reuse this history to make more accurate future estimates.  We have learned that progress cannot be measured solely by measuring work products.  History has proven this.  Using historical data from efforts with similar practices will help us estimate more accurately in the future, but please don’t mis-read this as a “silver-bullet.”  

Conclusion

Tailoring practices to the unique needs of each project will always be needed for effective and efficient software engineering.  But we can minimize the effort this takes by minimizing the reinvention.  This is fundamental to the goal of Semat.  Universals can provide the “common ground” necessary to get us to a starting point.  But this won’t get us where we ultimately need to go for Semat to succeed. 

For Semat to succeed we need to provide more value to the user that goes beyond the agnostic Universals to include agreed-to universal states that can help the User understand where they are.  This is not something that will be achieved easily.  We are only now beginning to find the Universals, and just beginning the discussions on which might be alphas, and what their “universal” states might be.   

Following is a currently proposed definition of an “alpha.”  It is worth pointing out that this definition is still evolving, as it is now being discussed on the Semat Kernel Language Track. Therefore it is likely to change before the initial release of the Semat product. 

“An alpha is an entity of a software organization ecosystem that reflects the team’s work.  Alphas have state that allows the team to track its progress, co-ordinate and plan its work, judge the effectiveness of its practices, and (most importantly) judge the effectiveness of its work.  An alpha is described by a set of work products. An alpha may consist of other alphas. An alpha is dynamic and its’ state evolves over time.”

I am not yet certain whether we will find useful Universals that are not “alphas.”  I believe you can measure anything. And anything of value should be measured.  Furthermore useful measures vary over time.  This would seem to imply that “useful universals” would have multiple states and therefore would be candidate alphas.  But this discussion will lead us to another critical issue Semat must face.  If the resultant product is too “heavyweight”  with “explicit measures” it will fall under its own weight.  It is balance we seek for Semat to succeed. 

Where the challenge ahead for semat lies is not so much on agreeing with the concept of alphas, but finding the alphas that are universal, and then finding their base states that are also essential to all software engineering endeavors.  This will be no easy task, but as Ivar Jacobson recently said, “nothing I ever did in my life that had any real value was easy.”  . 

Notes and References:

[1] CMMI refers to the Capability Maturity Model Integration which is a process improvement maturity model for the development of products and services developed by the Software Engineering Institute (SEI).

[2] Refer to WWW.PEMSystems.com and related book “Integrating CMMI and Agile Development: Case Studies and Proven Techniques For Faster Performance Improvement.” 

[3] Refer to  http://www.pemsystems.com/SEMAT_position_McMahon.pdf

[4] Refer to http://www.pemsystems.com/iitsec-4-2002.pdf , http://www.stsc.hill.af.mil/crosstalk/1995/03/Pattern.asp

The discussion I am referring to began when Bertrand Meyer stated:  “We don’t want just any theory.  We want a theory based on mathematics.”  Alistair Cockburn responded by raising concerns about a mathematical basis given the lack of precision in our current understanding of software engineering.  

 I personally found this discussion intriguing and after the meeting looked up the word theory in the dictionary.  The first definition I came to read:   “A coherent group of general propositions used as principles of explanation for a class of phenomenon.” 

This sounded like what I expected. But it was the second definition that gave me a better idea why some may fear a mathematical based theory.  It read:  “A proposed explanation whose status is still conjectural, in contrast to well established propositions that are regarded as reporting matters of actual fact.”   I wondered as I read it, if a valid “theory” could be just a guess?

This possibility may help explain why some fear theory and why it seems to stir up such heated debates.  If you read some of the recent views expressed on Semat by Fowler( http://martinfowler.com/bliki/Semat.html ) and Cockburn (http://alistair.cockburn.us/A+Detailed+Critique+of+the+SEMAT+Initiative) there is a sense of “been there, done that”, and “don’t want to go back and do it again.”  This is easy to understand.  It is also easy to understand why some believe that Semat will become just an academic exercise with little practical value to real software practitioners. 

I too spent a great deal of effort in the 1980’s and 90’s trying to apply the latest “theories” on software engineering in real project environments and like Cockburn and Fowler I too recall the frustration.  It is natural and right to not want to repeat the failures of our past. 

Nevertheless, in this case I don’t feel the same as Cockburn and Fowler and other critics of Semat.  Part of my reason can be found in the Semat vision statement which I have read multiple times.  If you read it carefully you will find it is not advocating the resurrection of the failed theories of the past.  Specifically it states that the results expected one year after the start include: “The identification of specific theories or theoretical areas that hold potential for Semat, backed by examples of their successful application to specific software engineering practices.”   I find a recognition in these words of what we know we don’t know which in turn can help us focus our attention on what is most important to learn next. 

Bertrand Meyer who I perceive as strongly on the side of a mathematical basis appeared to listen to Alistair’s concerns during that heated discussion on Day One in Zurich,  replying with (as best I can recall):  “We don’t want precision for precision sake.  Today weather forecasting is imprecise, but it is based on mathematics and it has proven useful.”  Bertrand also pointed out that in mathematics there exists a concept known as “sufficiently complete.”   

At this point I sensed that Alistair was listening.  He replied with (as best I can recall): “Ok.  I am learning something here.”  I also recall feeling at this point that I might be witnessing an historic moment as two great thinkers were listening and learning from each other. 

It was unfortunate that over the next two days more moments like this did not occur.  There were ups and downs as is to be expected in any serious and challenging endeavor.  I have previously written about why I felt the Scott Ambler led requirements brainstorming on Day Three was a high point of the workshop (http://paulemcmahon.wordpress.com/2010/04/12/semat-kickoff-meeting-in-zurich/), but I would now like to explain why my support for Semat has continued to steadily grow since the Zurich workshop. 

When I originally read the SEMAT position papers of the Zurich attendees a number of statements by Larry Constantine caught my eye.  One of those statements was:  “Ivar Jacobson is fond of quoting Kurt Lewin, the founder of social psychology, that nothing is so practical as a good theory.” 

When I read it I thought this statement seemed counter to my own view of theory.   I always viewed “theory” as something separate and disconnected from “proven practices.”  My own Zurich position paper was based on my own practical experience helping clients do their job, and when I wrote it I didn’t think about theory. 

If I see something that works with a client I like to share it with others.  But I have also recognized that because something works for one client it doesn’t mean it will work for another.  I am careful when making recommendations to clients letting them know the context in which I have observed certain practices succeed.  In other words, this is my way of communicating the fact that I don’t know just how universal my own experiences are. 

Finding a set of “universals” is a goal of  Semat.  Clearly this won’t be easy.  But what gives us hope is our years of collective experience.  Today we know why many software projects fail.  Larry Constantine in his position paper references the work he did with Ed Yourdon on structured design and pleads guilty to missing the human experience.  He states: “I am convinced that any theory of software engineering that does not take into account at it core the fact that software is specified by humans, to be understood by humans, to be modified and extended by humans, and ultimately be used by humans is fatally flawed.” 

The criticality of the human element is something the agile community has helped bring to our attention.  This is just one example demonstrating how our collective experience has grown and can be used in the future to help build a solid and practical theory of software engineering. 

As another example, I have shared many of my own experiences with clients in a recent book titled “Integrating CMMI and Agile Development: Case Studies and Proven Techniques for Faster Performance Improvement” (available August, 2010).   

And while I still don’t know how universal my own experiences are, there does exist compelling evidence that what we know today about why some software projects succeed and others fail may be more universal than we think.  Hillel Glazer, a Certified High Maturity CMMI Lead Appraiser said after reading my book: 

“Prior to reviewing the manuscript, I had never met Paul nor collaborated with him on engagements.  For us to have such similar experiences merely provides further evidence that Pareto was right: 80% of the problems can be explained by 20% of the issues.  The cases Paul describes can be easily relatable and extrapolated to many organizations.  Even if/when his studies don’t match a reader’s experience precisely, that doesn’t mean that they are not relevant or that there aren’t lessons to be learned and applied.”

During that heated debate on Day One in Zurich Richard Soley said:  “Maybe we should stop saying mathematical and just say measurable.”    I have a Bachelors and a Masters degree in Mathematics and when Richard made this statement I was both surprised and intrigued.  I enjoyed my years in school learning mathematics, but I have often told others how I felt I would have gained far more value if my professors could have related the Theorems and “Theories” we were learning to real world situations.  As strange as it may sound in all my formal years of mathematics education I had never recognized that mathematics was a way to help us describe in a numerical way the world we live in. 

 Again I was led back to the dictionary where I found that mathematics is:  “The science that treats of the measurement, properties and relations of quantities…”.  As a result I am finding that today I look at Theory, Mathematics, Measurement and “Proven Practices” differently.  I see them all in a much more connected way and a way that can help software practitioners in the future. 

As an example, while today I still may not be thinking much about “theory” when helping clients, I now recognize that a solid “practical theory” could become a valuable aid in the future to help check out my own experiences with the broader community.  This, in turn, could help my decisions become more effective for my clients.   On a related note, Larry Constantine also said in his position paper:  “…good theory is far more than practical because it also transcends and outlasts practice.  Practices change, but sound theory abides.”  These ideas have helped me learn and grow in my own understanding of how theory can help practice. 

These ideas have also led me to look differently at the work ahead of us on the Semat Assessment Track.  Measurement is a major topic the Semat Assessment Track will be discussing over the coming months.  I am helping Watts Humphrey lead this Track where our twelve month goal is:

“A set of metrics, sufficient to assess software practices, products, and people, and backed by evidence of successful application to some projects.”

This raises a number of questions.  For example, how precise and how rigorous should our metrics be?  As one point of possible discussion, in the book “How To Measure Anything” the author defines “measurement” as:  “A set of observations that reduce uncertainty where the result is expressed as a quantity.”

Today the software engineering community has amassed a plethora of valuable observations.  Part of our task in the Assessment Track could be to sort through what we know today to determine which measures show the greatest potential to help software engineering in the future.  Some proposed outcomes based on the brainstorming in Zurich that the Assessment Track will be discussing in the months ahead include:

• Explaining why successful projects succeed and failing projects fail and develop related measures to help
• Identifying where we need metrics based on what is useful and important to projects
• Considering “rules of thumb” to help derive sensible measures and these rules of thumb should be based on a “practical theory”

We are interested in hearing more opinions from the full software community.  If you are interested in participating on the SEMAT Assessment Track email Paul McMahon at pemcmahon@acm.org.

 I happen to agree with the author when she states:

“the software problem isn’t just their problem -it belongs to all of us.” 

 It is worth pointing out that the SEMAT effort reaches far beyond the handful of Signatories and the small group who met in Zurich. 

As stated in the report of the first SEMAT workshop in Zurich (http://www.semat.org/pub/Main/SematZurichMarch2010/Zurich_meeting_report.pdf ), authored by the troika (Ivar Jacobson, Bertrand Meyer, Richard Soley), the original five tracks remain with a new track added for Requirements, and:

“Track leaders are selecting members now and these members may come from the entire community not just from the signatories or the participants at the meeting. “

 There are currently over 1000 supporters of the SEMAT initiative.  Many of these supports are hard working software developers and managers with day jobs who clearly can represent the viewpoints of software practitioners.  One of the founders of the SEMAT initiative personally told me he doesn’t expect much of the SEMAT “heavy lifting” to come from the signatories, but rather from our over 1000 supporters and beyond who are facing the real problems everyday that the SEMAT initiative is intended to address. 

 Contrary to the referenced article above on “SEMAT and diversity,” I do not assume that the small group gathered in Zurich is “sufficiently diverse to solve the SEMAT problem.”  This is why we are reaching out to a much broader community. 

 If you read the report referenced above from the first SEMAT workshop in Zurich you will find that multiple track leaders have provided their email addresses as a contact point for those who are willing to help.  Watts Humphrey, who I am helping on the Assessment Track, told me that our challenge will not be figuring out what to do so much as  “getting people to agree and getting the resources to do it.”  We welcome those in the trenches–especially those who can represent the viewpoints of software practitioners– who have the time and willingness to help.