Category Archives: Process Improvement

Many articles at Tyner Blain focus on improving the software development process. These articles can address improvement of any aspect of the process, and often overlap with other categories in the site.

Agile Estimation, Prediction, and Commitment

Your boss wants a commitment.  You want to offer a prediction.  Agile, you say, only allows you to estimate and predict – not to commit.  “Horse-hockey!” your boss exclaims, “I want one throat to choke, and it will be yours if you don’t make a commitment and meet it.”  There’s a way to keep yourself off the corporate gallows – estimate, predict, and commit – using agile principles.

This is an article about agile product management and release planning.

Continue reading Agile Estimation, Prediction, and Commitment

Hidden Business Rule Example

Little girl hiding by covering her face

A business process is not just a sequence of steps.  A business process is a series of decisions and actions.  Some decisions are obvious and can be actively managed.  Some decisions are hidden, and until you discover them, you can’t manage or improve them.  Here is a real-world example of the discovery of a hidden enterprise decision.

Continue reading Hidden Business Rule Example

Smart Enough Systems – Interview With James Taylor

James Taylor

Today we recorded an interview with James Taylor, co-author of Smart (Enough) Systems, How To Deliver Competitive Advantage by Automating Hidden Decisions. This book, written by James Taylor with Neil Raden comes out on Jun 29th (2007), and is available for pre-order from Amazon today. Our interview covers many of the topics in their book, with a focus on the ideas inside and the benefits you can get from applying them, in just under an hour.

Continue reading Smart Enough Systems – Interview With James Taylor

CMMI and RMM One Minute Survey

timed test

Please take one minute to answer the following two questions, because people need to know how their process maturity compares with everyone else. You’ll be answering two easy questions –

  • What is your CMMI level?
  • What is your RMM level?


We just completed a series of six articles about CMMI levels and RMM levels. We discussed how the two frameworks can be connected, and explored the reasons for trying to reach the next level on either scale.

Question 1


Question 2


Thanks for taking the survey, and if you have any thoughts about the results, just comment here.

CMMI Levels and RMM Level 5 – Integrated Requirements

Book 5 in a stack of 5 books


In our introduction to mapping RMM levels to CMMI levels, we presented background info on CMMI, introduced the IBM article on RMM levels, and posted an initial mapping structure. In this article, we will look at the definition of RMM level 5. We also look at the mapping from RMM level 5 to various CMMI levels.

CMMI to RMM Mapping

(larger version)

In the previous article in the series, we looked at how RMM level 4 – traced requirements processes map to CMMI levels.

RMM Level 5 – Integrated Requirements

In RMM level 4 we discussed the benefits of establishing traceability within the scope of the requirements realm. This traceability helped us with tracking the impact of changes and validation of requirements, and it helped us with reporting and management functions that improved our insight and lessened our efforts.

RMM level 5 extends this traceability concept beyond the requirements realm. We can extend tracing into development, testing and documentation, as well as project management.

Delivery Scheduling

Each delivery of our software includes a set amount of functionality. We prefer using a timebox approach for planning those deliveries. We also suggest using use cases as the “pieces” of functionality that are delivered. We also have proposed an approach to managing changes to the delivery schedule. This overall process is a form of integration of requirements, and is dependent upon having organized, structured, traced requirements. It also requires us to create linkages between implementation elements/effort and the requirements that are supported.

Quality Assurance

There are two elements of integration between QA and requirements. The first is in defining test cases based on use cases. Each use case drives the creation of one or more test cases that are used to validate that the delivered software meets the requirements.

The second element is in tracking and management of bugs. We have a triage process for determining how to address bugs. Those bugs can come from anywhere – and sometimes they come from incorrect requirements. Establishing relationships between requirements and bugs allows us to manage the defect resolution process more effectively.


When we write documentation, our goal is to have the reader know how to accomplish something that they want to do. When we develop software, we define the things that users will be able to do. It only makes sense to structure documentation around use cases.

Mapping CMMI Levels to RMM Level 5

In our diagram, we show the following mappings for RMM level 5:

  • CMMI level 0 – No Entry
  • CMMI level 1 – No Entry
  • CMMI level 2 – No Entry
  • CMMI level 3 – Requirements Should Be Integrated
  • CMMI level 4 – Requirements Should Be Integrated
  • CMMI level 5 – Requirements Should Be Integrated

For CMMI Level 0 through CMMI Level 2 – when our process is unmanaged, and unstructured, integration doesn’t matter. Requirements management software will not solve our problems.

For CMMI Level 3 through CMMI Level 5 – Being able to quantify the performance of our process, and improve our process based on that feedback both require an element of instrumentation and insight into our techniques and tools. Attempting to do that meaningfully without additional structure and traceability will provide limited benefit. If we’re investing this level of effort in our requirements process, we should extend it to include our overal software development process by integrating to other systems.

From a CMMI Level Perspective

The previous analysis basically looked at the “RMM level 5″ column in our grid, and inspected the relative decisions for each “CMMI level” row. Now we will look at it by reviewing the CMMI levels, and seeing how they map to the RMM level.

A quick review of the same chart (so you don’t have to scroll up and down):

CMMI to RMM Mapping
(larger version)

At CMMI level 1 through CMMI level 3, we don’t address integration with other systems. We want to focus on getting a cohesive and powerful requirements management process in place before we look at integrating it to our other processes.

At CMMI levels 4 and 5 we are measuring and improving on our process. We require traceability as a key component to our quantified analysis and instrumentation. We should be extending that traceability beyond the requirements realm to maximize the value of what we are doing.


  • RMM level 5 specifies that requirements documents are organized, structured, and traceable – both to each other and to other systems.
  • Once we reach a company-standard process (CMMI level 3) we should be at RMM level 5, but we must have reached RMM level 2.
  • RMM level 5 is never required to achieve any of the CMMI levels – but it is valuable and encouraged.

Don’t forget to take our One Minute Survey on CMMI and RMM Levels.