FullSizeRender

CMMI, ITIL, Six Sigma, Agile, waterfall, software development life cycle and eXtreme Programming . . .what do all of these terms have in common?  They are models.  In a perfect world, models are abstractions that we find useful to explain the world around us.  Models work by rendering complex ideas more simply.  For example, both a road map and picture rendered in Google Earth are models.  Two very different types of models: an abstraction of a set roads, buildings, parks and plants that exhibit can provide more information than rendering.  Real life is complex, Google Earth is less complex and the road maps are the least complex.  Simplifying a concept to a point allows understanding, while too much simplification renders the concept as a pale reflection.  Oversimplification can lead to misunderstandings or misconceptions, for example the conception that Agile methods are undisciplined or that waterfall methods are bureaucratic.  Both of these are misconceptions (individual implementations are another story).  According to Kenji Haranabe, software development is a form of communication game.  Communication requires that groups understand a concept so that it can be implemented.  Communication and understanding requires finding a level where common understanding based on common words can occur.  Words provide the simplification of real life into a form of model.

Unfortunately it is difficult to determine when enough simplification is enough.  Oversimplification of ideas can allow trouble to creep in.  Oversimplification can water down a concept to the point that it can not provide useful information to be used operationally.  An example of a very simple model is the five maturity levels commonly connected to the CMMI.  The maturity levels build awareness, but provide little operational information.  I do not know how many times I have heard people talk about an individual maturity level as if the name given to that level was all you needed to know about a maturity level.   The less simplified version with process areas, goals and practices provides substantial operational information.  ‘Operationalizing’ an overly simplified model will yield unanticipated results and that is not what we want from a model.  I once built a model of the battleship Missouri that had horrible directions (directions are a model of a model), I used three firecrackers to remodel the thing I ended up with (which was not a very good model).

Models abound in the world of information technology.  If we don’t have a model for it, we at least have TLA (three letter acronym) for it and are working on a model that will incorporate it.  The models that have lasting power provide structure, discipline and control.  They’re also used as a tool to guide work (tightly or loosely depends on the organization) and as a scaffold to define improvements in a structured manner.  Models are powerful; molding, bending and guiding legions of IT practitioners.  The dark side of this power is that the choice of models can be definitional statement for a group or organization.  Selecting a model can elicit all of the passions of politics or religion.  Just consider the emotions you feel when describing Six Sigma, CMMI, eXtreme Programming, waterfall or Agile.  One of those words will probably be a hot button.  The power of models can become seductive and entrenched so as to reduce your ability to change and adapt as circumstances demand.  A model is never a goal!  Define what your expectations are for the model or models that you are you using in business terms.  Examples of goals I would expect are of increased customer satisfaction, improved quality or faster time-to-market, rather than attaining CMMI Maturity Level 2 or implementing daily builds.  Know what you want to accomplish then integrate the models and tactics to achieve those goals.  Do not let the tool be the goal.

Models are powerful, useful tools to ensure understanding, they provide structure and discipline.  Perform a health check.  Questions to ask about the models in your organization begin with:

  1. Is there is a deep enough understanding of the model being used? – With knowledge comes the background to operationalize the model.
  2. What are your expectations of value from the model? – Knowing what you want from a model helps ensure that the model does not become the goal and that you retain the ability to be flexible.

There are many other questions you can ask on your heath check, however if you can’t answer these questions well stop and reassess, re-evaluate, re-train and re-plan your effort.

CMMI, ITIL, Six Sigma, Agile, waterfall, software development life cycle and eXtreme Programming. . . powerful tools or a straight jacket. Which is it for you?

The TMMi is comprised of eight primary components, similar to a pile of Legos.

The TMMi is comprised of eight primary components, similar to a pile of Legos.

The Test Maturity Model Integration (TMMi®) provides a framework to describe the requirements and environment for testing in the complex environment of most IT organizations.  The TMMi, like the CMMI® and ITIL®, describes a wide swath of the IT landscape.  Each model might cover part of the landscape, but not the entirely of the products and services delivered by a typical IT department. The TMMi has addressed the problem of describing part of the environment by being complementary with the CMMI (mainly the CMMI for Development). Part of being complementary is content (testing) and part is structure.

The TMMi is comprised of eight primary components, similar to a pile of Legos that are assembled into process areas define levels of maturity.  When putting the parts together some of the parts are needed, some of the parts are recommended but others can be substituted, and some of the components are there to provide explanation or elaboration on how the model works.  The model uses three terms to capture this concept:

  • Required Component:  This component must be visibly implemented.
  • Expected Component:  This component describes how the concept is typically implemented but alternatives are acceptable.
  • Informative Component:  These components provide explanation or elaboration on practices in the model.

The eight components of the TMMi are:

  1. Maturity Levels – Maturity levels are used to capture and convey a general sense of the capability of the organization. The TMMi model has five levels (Initial, Managed, Defined, Measured, Optimization).  An organization that is classified as Initial is considered to be less capable than one that is classified as Managed.
  2. Process Areas – A process area defines a set of practices required to support a part of the testing eco-system.  Process areas include Test Environment, Non-Functional Testing and Product Quality Evaluation to name just three.  Each maturity level, with the exception of “Initial,” is defined by a number of process areas.
  3. Specific Goals – Each process area has one or more specific goals that define the unique behavioral characteristics that the process area is attempting to generate. A process area is considered satisfied when the goal is satisfied. For example the first goal in the Test Planning process area is “Perform a Product Risk Assessment.”  (This is a Required Component.)
  4. Specific Practices – The specific practices express a path that, if taken (and done well), will satisfy a specific goal.  These activities are important to reach the specific goal, but there may be other means of attaining the goal.  (This is an Expected Component.)
  5. Example Work Products – This component elaborates on the types of deliverables that are typically seen when the specific practices are implemented.  For example, work products for the Test Planning Process Area might include a risk analysis and a test plan.  These work products indicate how others have implemented the specific practices, but not how you must implement them. (This is an Informative Component of the model)
  6. Sub-practices – Sub-practices described the tasks that are generally needed to satisfy a specific practice (think of this as a form of a work breakdown structure). These components of the model provide support for interpreting and implementing the model. (Sub-tasks are an Informative Component of the model.)
  7. Generic Goals – These goals are represent organizational goals that are common for each process area.  For example, have a policy, provide resources and identify responsibilities are three generic goals.  There are 12 generic goals (10 at Level 2 and 2 at Level 3).  Satisfying the generic goals is required to institutionalize model usage.  (The generic goals are Required Components of the model.)
  8. Generic Practices – The generic practices express a path that, if taken (and done well), will satisfy a generic goal.  These activities are important to reach the generic goal but there may be other means of attaining the goal.  (This is an Expected Component).

The structure of the TMMi is very similar to the CMMI. Once I irritated the instructor of a class I took on the TMMi by pointing that out.  That similarity makes understanding the structure of the TMMi significantly easier for those have previous exposure to CMMI.  The complementary nature of the two models ensures that a TMMi implementation can not only co-exist, but also support and extend each other.  We apply the CMMI for Development covering development functions and the TMMi to augment the verification and validation functions within IT.

Development and testing are intertwined!

Development and testing are intertwined!

“All models are wrong, but some are useful.”  – George E. P. Box

IT has many useful models for addressing the complexity of developing, delivering and running software.  Well known models include the Capability Maturity Model Integration (CMMI®), the Information Technology Infrastructure Library (ITIL®) and the Test Maturity Model Integration (TMMi®) to name a few.

Testing is a mechanism for affecting product quality.  The definition is of quality is varied, ranging from precise (Crosby – “Conformance to requirements”) to meta-physical (Juran – “Quality is an attitude or state of mind”).  Without a standard model of testing that codifies a definition, it is difficult to determine whether testing is affecting quality in a positive manner.  The TMMi is an independent test maturity model. It  is a reference model representing an abstract framework of interlinked concepts based on expert opinions. The Wikipedia definition suggests that reference model can be used as a communication vehicle for ideas and concepts among the members of the model’s community. The use of a model as a tool to define the boundaries of a community also amplifies its usefulness as a communication tool as it defines the language the community uses to describe itself.   The TMMi is a reference model of testing for the testing community defining the boundaries of testing, the language of testing and a path for process improvement and assessment.

Many developers (and development managers) think of testing as a group of activities that occur at the end of coding. This flies in the face of software engineering practice since the 1980s and the Agile tenant of integrating testing into the entire development process. The TMMi model explicitly details a framework in which testing is not an event or gate that has to be hurdled, but rather a set of activities that stretch across the development lifecycle (waterfall, iterative or Agile). A model provides a framework of the activities and processes that need to be addressed rather merely laying out a set of milestones or  events that need to be followed explicitly.  The TMMi model extends the boundary of testing to entire development process.

The TMMi model lays out a set five maturity levels and sixteen process areas ranging from test environment to defect prevention.  The model is has a similar feel to the classic CMMI model. Since the model provides a set of definitions and a language to talk about testing and how it integrates into development, it provides the mechanism for members of the testing community to communicate more effectively.

The TMMi, through its framework of maturity levels, process areas, practices and sub-practices, lays out best practices for testing that should be considered when developing testing practices.  Like other reference models, the TMMi provides a framework but does not prescribe how any project or organization should do any of the practices or sub-practices.  By not prescribing how practices are to be implemented, the TMMi can be used in any organization that includes testing.  A framework that is neutral to lean, Agile or waterfall practices that points that communicates best practices provides a tool to identify and pursue process improvement is a tool that can be molded by managers and practitioners to make testing more efficient and effective.

CMMI, ITIL, Six Sigma, agile, waterfall, software development life cycle and extreme programming . . .what do all of these terms have in common?  They are models.  In a perfect world, models are abstractions that we find useful to explain the world around us.  Models work by rendering complex ideas more simply.  For example, both a road map and picture rendered in Google Earth are models.  Two very different types of models:   an abstraction of a set roads, buildings, parks and plants that exhibit can provide more information than rendering.  Real life is complex, Google Earth is less complex and the road maps are the least complex.  Simplifying a concept to a point allows understanding while too much simplification renders the concept as a pale reflection.  Oversimplification can lead to misunderstandings or misconceptions, for example the conception that agile methods are undisciplined or that waterfall methods are bureaucratic.  Both of these are misconceptions (individual implementations are another story).  According to Kenji Haranabe, software development is a form of communication game.  Communication requires that groups understand a concept so that it can be implemented.  Communication and understanding requires finding a level where common understanding based on common words can occur.  Words provide the simplification of real life into a form of model.  Unfortunately it is difficult to determine when enough simplification is enough.  Oversimplification of ideas can create scenarios where trouble can creep in.  Oversimplification can water down a concept to the point that it can not provide useful information to be used operationally.  An example of a very simple model is the five maturity levels commonly connected to the CMMI.  The maturity levels build awareness but provide little operational information.  I do not know how many times I have heard people talk about an individual maturity level as if the name given to that level was all you needed to know about a maturity level.   The less simplified version with process areas, goals and practices provides substantial operational information.  ‘Operationalizing’ an overly simplified model will yield unanticipated results and that is not what we want from a model.  I once built a model of the battleship Missouri that had horrible directions (directions are a model of a model), I used three firecrackers to remodel the thing I ended up with (which was not a very good model).

Models abound in the world of information technology.  If we don’t have a model for it t we at least have TLA (three letter acronym) for it and are working on a model that will incorporate it.  The models that have lasting power provide structure, discipline and control.  They’re also used as a tool to guide work (tightly or loosely depends on the organization) and as a scaffold to define improvements in a structured manner.  Models are powerful; molding, bending and guiding legions of IT practitioners.  The dark side of this power is that the choice of models can be definitional statement for a group or organization.  Selecting a model can elicit all of the passions of politics or religion.  Just consider the emotions you feel when describing Six Sigma, CMMI, eXtreme Programming, waterfall or agile.  One of those words will probably be a hot button.  The power of models can become seductive and entrenched so as to reduce your ability to change and adapt as circumstances demand.  A model is never a goal!  Define what your expectations are for the model or models that you are you using in business terms.  Examples of goals I would expect are of increased customer satisfaction, improved quality or faster time-to-market rather than attaining CMMI Maturity Level 2 or implementing daily builds.  Know what you want to accomplish then integrate the models and tactics to achieve those goals.  Do not let the tool be the goal.

Models are powerful, useful tools to ensure understanding, they provide structure and discipline.  Perform a health check.  Questions to ask about the models in your organization begin with:

  1. Is there is a deep enough understanding of the model being used? – With knowledge comes the background to operationalize the model.
  2. What are your expectations of value from the model? – Knowing what you want from a model helps ensure that the model does not become the goal and that you retain the ability to be flexible.

There are many other questions you can ask on your heath check however if you can’t answer these questions well stop and reassess, re-evaluate, re-train and re-plan your effort.

CMMI, ITIL, Six Sigma, agile, waterfall, software development life cycle and extreme programming. . . powerful tools or a straight jacket which is it for you?