This is the second chapter of the authors' own translation of the award winning book The Story of Tahini-Tahini: Process Improvement and Agile Methods with the MPS Model. Originally published in Portuguese and already in Spanish. This Chapter deals with Process Improvement and how to make it work.

1. Boria et al.
Chapter 2 1
CHAPTER 2 - A CONTINUOUS IMPROVEMENT METHOD
2.1 Process Improvement
In agreement with the current literature and our own personal experience, process improvement is the tool
through which organizations learn about themselves, what W. Edwards Deming calls “A system of profound
knowledge”. This road starts with an intuitive perception of the organization and takes it to build a quantitative
understanding of it through the analysis, improvement and stabilization of their behavior. Intermediate steps are
useful not only to improve business results but also as stepping stones in that lofty goal of excellence companies
pursue. Processes that have been agreed upon change when the parties involved so decide, whereas not following
process implies that there is no recognizable pattern of behavior that has been agreed upon by the stakeholders.
One anecdote has helped us show clearly the role of following processes in this grand scheme:
In a software development organization, Peter, one of the best programmers, was an ardent defender of
following process. He was able to convince his fellow team members that they should adopt processes in their job
to build not only final products but intermediate documentation that could be checked and reviewed for defects
and measuring progress. In particular, Peter’s processes allowed the team to state well-defined handoff points in
their life cycle with clearly expressed criteria for completion. In this manner quality was made more objective and
shared and tied to every product, intermediate or final. Projects in which Peter worked thrived, being far more
successful than the average and with great approval rates from the customers. It took some time, but finally the
upper echelons got wind of this young talent and he went from promotion to promotion until he reached the
coveted position of Technical Director of Software Development, with overview over the programming phases. In
conformity with his past behavior, he called a meeting with his colleagues, in which he showed the link between
his success, following processes and his current high status within the company. Given this, he expected everyone
to support his drive for process improvement, based on an agreed-upon process that will be defined by the
programmers themselves, based on their best practices, and to be changed as needed. Many heads moved in
acceptance, and after a short question and answer session, Peter closed the meeting. Paul, the oldest
programmer of the lot, and the one considered the programming ‘maverick’ by the rest, and a serious candidate to
the position Peter now held, waited until the room was cleared. He then slowly approached the lectern where
Peter was still organizing and collecting his slides (this is a very old story; slides then were printed and called
transparencies).
- “Peter, he said. “I am happy for you, but you already know that I don’t follow other people’s processes,
and I feel that trying to explain my processes to other people is a waste of my time and theirs. They are
useful to me and only me. Don’t take this personally, but I will continue to do what I have always done.’
- “I could not expect otherwise”, Peter said.
- “I am happy that you see it this way”, said Paul.
Satisfied, he picked up his notes and turned around towards the exit. Peter waited until he was nearly over
the threshold, and then shot this parting line:
- “However, do not fail. Don’t you ever fail. Those that follow processes can have problems, because
problems teach us where our processes need to be improved. But if you fail when not following our
processes, failure teaches us nothing and the full brunt of the responsibility will be yours. Don’t take this
personally, but I will continue to do what I have always done”.
To sum it up: if process is being followed, when something goes wrong, blame the process. If process is not
being followed, when something goes wrong, find the guilty party.
When processes are being followed it is simpler to identify defects and trace them to their original cause. In
some sense, following a process is like buying an insurance policy: one does not expect anything to go wrong, but
one does make a little investment to mitigate the effects of such a problem when it happens. We don’t want to
break a leg, but if we do it is nice to have an insurance company covering the costs. So it is with processes: In a
perfect world, where everyone has total recall, we would never make mistakes and natural language specifications
would have a unique meaning that never changes, following process might be a more debatable subject; they
would still be of great use to coordinate activities across different roles and phases, but with total recall the
processes would have much less to express.
Reality is far from this ideal world: we are fallible, we forget and we have multiple understanding of the same
natural language expressions. As a consequence, the only way an organization can learn is to capture how we work

2. Software Process Improvement with Agile Methods and Maturity Models
2 Capítulo 2
in our processes and thus understand them (through the data they generate). In this way we can continuously
improve them, to improve the quality of the products that stem from our processes.
As with many other things, not all processes are equally interesting to us. Some administrative processes are
usually well established and respond to policies, and people follow them, under the penalty of real sanctions or
loss of benefits. There also are processes that come from outside the organization. Neither of these is of interest to
us. Those processes we want to focus on and improve are processes that are linked to software development
within an organization. Even then, it is possible to get in other places more and better information on best
practices than what we are going to cover in this book. We will limit ourselves to exhibit the minimal behavior
required to organize projects that will result in good quality software.
Organizations that understand their processes quantitatively (and there is no other way to do it seriously) and
profit from this knowledge are said to be ‘mature’. A mature organization pursues its objectives with the aid of this
knowledge. It knows what its teams are capable of and makes no promises it cannot keep. The teams themselves
use this knowledge to go into development with confidence in their capabilities and their ability to fulfill their
commitments. Immature organizations, by contrast, sometimes abide by their commitments, but they often do
not. They are not really sure of their capacity and base their promises on their desire to win the customer. What
we will show in this book is a road to achieve excellence, maturing as an organization, using agile methods and
maturity models, which we will showcase using a made-up example drawn from our combined experience of over
sixty years as consultants.
We will follow a unique road, that of MPS-SW. As we will show later, in Chapter 4, since MPS-SW and CMMI-
DEV are related, following the MPS road ends in full compliance with CMMI practices. We are convinced that a
sequence of well-implemented actions to introduce the practices of the maturity models can not result in anything
but high maturity, and we will show how this is not a road that requires large documentation and overhead to
traverse. Maturity models share a common origin in stage theories (see Chapter 4 for more detail) and hence have
a well-defined set of attributes. One such attribute is that the states are well-defined and easy to identify
demonstrably. Our maturity models have such characteristic. They can be used to show the degree of advance that
an organization has achieved in terms of showing the ‘stage’ it is in. MPS has seven such stages, while CMMI has
five, yet they map to each other very nicely. Because the MPS has more levels (stages), that exactly match the
CMMI levels when taken in convenient groupings, and because the transition to one level in the CMMI to the next
(upwards) is defined even strongly in MPS, we can follow MPS as a guideline to excellence, without losing any
practice in the CMMI. Maturity models aim at the highest degree of excellence an organization can achieve but,
unlike quality norms, or best practices models, maturity models require the organization to develop, not to adopt.
The latter is a step in developing the organization. The organization adopts practices to develop its maturity.
Maturity models are organizational development models. Unlike norms, they should be interpreted, not heeded.
In the MPS, which we will delve into with more detail in Chapter 4 and in Appendix A where we compare it to
the CMMI and map them to each other, we find the inspiration to create a route from happenstance to full
comprehension. The organization starts adding a set of practices at a time, without pain and with much gain, and
climbs up the levels one by one, until they achieve the highest maturity possible. Unlike a norm, where all the
practices are adopted at once, in a maturity model adoption is piecemeal, and the levels guide the decision to
implement in a given order. Well planned, this adoption helps build efficient processes and ingrained quality in the
products. Each step has a payoff and together they make the organization stronger, faster, cheaper and better.
However, even when the MPS has fewer levels than the CMMI, it is still necessary to pick an order within the
practices of a given level. In implementing the practices, one has to consider the impact on the business; one has
to make a business case for its selection. However useful, maturity models only go so far; a more business rooted
process is in demand. As the reader can surmise, there is more than one way of doing this, many authors have
created or adapted solutions to the problem of identifying the first thing to fix or repair and then the next one
after that. These are known as improvement life cycles or improvement cycles, or wheels. They have many names
in the literature. For the time being, let us postpone their enumeration and selection, to present a decision process
that will help us choose amongst them. We will borrow a technique that is present in CMMI and MPS, dubbed by
the CMMI as Decision Analysis and Resolution, and by the MPS as Decision Management . Using the practices for it
as defined in the MPS, we will start by defining the problem at hand.
Problem: Even when at a high level of abstraction maturity levels help define the sequence of steps for an
organization to follow to achieve excellence, in each case it is necessary to focus on the business needs of the
organization going after improvements of their processes.

3. Boria et al.
Chapter 2 3
Desirable Attributes of a Solution: A solution must provide a mechanism to pursue continuous process
improvement that allows to identify successive steps in an improvement program and the resulting program
should have sufficient detail so that it is possible to execute without too much ambiguity, yet not so detailed that a
selection requires a long winded plan (this attribute we shall call CLARITY). It would also be better if it is part of a
method or theory that helps to understand and measure the overall impact of the solution selected, not just local
to the changed procedures. It must have components, or steps, that direct to the derived actions that will provide
for the analysis and measurement of systemic benefits (SYSTEMICITY). It must provide quick feedback to make it
possible to keep a good pace in the introduction of improvements, without interfering with the job at hand or the
personal development of employees (FEEDBACK). These desirable attributes will provide us with criteria under
which the relative merits of proposed solutions will be judged. Their relative weight is shown in Table 2.1, Selecting
Process Improvement Methods.
attribute weight
SYSTEMICITY 5
CLARITY 3
FEEDBACK 1
Table 2.1: Selecting Process Improvement Methods
Alternative Solutions: There are plenty of examples in the literature. We have chosen to restrict our set to
the following: Plan-Do-Check-Act [SHEWHART W., 1939], IDEAL [McFEELEY B.1996], Focus-Improve-Sustain-Honor
[ARTHUR, J., 2004], and Lean Simplified [ARTHUR, J., 2006]. They constitute a representative sample of the most
well-known and most frequently used methods. Plan-Do-Check-Act is obviously the grandparent of all, given its
date of introduction. IDEAL is well known to practitioners that use the CMMI. FISH is an evolution of PDCA, as is
Lean Simplified of the former, both coming from the same author.
Evaluation Methods: We will usually use a Pugh matrix [PUGH, S., 1981] to evaluate alternatives when we
have multiple attributes. Used by Pugh in General Motors and described by him in his book Total Design:
Integrated Methods for Successful Product Engineering [PUGH S. 1991], and described previously in an article of
his authorship [PUGH S. 1981], it is one of the methods most commonly used by engineers to compare options.
The matrix’s columns represent alternatives and its rows an attribute. Each row has its own relative weight. In
each cell at the intersection of a solution with an attribute the contribution towards the attribute by the particular
solution is assessed. A formula to calculate the overall value of solutions, based on the relative weight of each
attribute and the assessed contribution to each by the different solutions is used to determine the most valuable
solution. The formula is best defined before the solutions are assessed, to force as much objectivity as possible
into the process.
Evaluation Criteria: Each attribute has to have its own evaluation criteria. We have chosen to measure all
with a four point scale, from 3 (maximum) to 0 (minimum). The maximum value is therefore the best and our
overall evaluation criterion will result from the simple sum of the attribute value for each alternative times the
relative weight of the attribute.
CLARITY requires a balance. A procedure can either be too detailed or too vague. The best value is 3, for a
perfect balance that allows to unequivocally interpret it while not being overburdened by details. A value of 2 will
be assigned to an alternative that is either a little too vague or a little too verbose. A value of 1 is still more verbose
or less detailed, and a 0 is either far too nebulous or tediously detailed.
SYSTEMICITY we value with a 3 when the starting point of the analysis is the customer’s needs and the
method shows how to bring your attention to other components in the system that can be affected by the change.
A 2 is for us a method that is quite comprehensive on the systemic analysis but not altogether complete, there is
an overall alignment with the business goals but is not integral to the method. It is a 1 when there are some hints
as to how to analyze the impact systemically and a 0 when there is no step to guide you with this and it is very
difficult to connect with business goals.
FEEDBACK we say is a 3 when the method clearly parses the steps with evaluation of results, with crisp
criteria for success of each step; 2 when the criteria exists but there is no clear indication of where evaluation is
required; 1 if the criteria are suggested but not expressed, and 0 if there is no direct way to connect the steps in
the method to partial advancement.

4. Software Process Improvement with Agile Methods and Maturity Models
4 Capítulo 2
We now describe the four alternatives. As an exercise, try to value them yourself vis-à-vis the four attributes.
2.2 Plan-Do-Check-Act
Plan-Do-Check-Act (PDCA) was originally defined by [SHEWHART, 1939], but mostly spread and backed by
Deming on various ways
1
. Deming called this procedure base on the scientific method ‘Shewhart’s Cycle’. We will
often find it as ‘Deming’s Cycle’, one of the many consequences of the latter’s notoriety being larger than the
former’s. Towards the end of his career, Dr. Deming changed “Check” into “Study” to emphasize that that step is
more of analysis than it is of inspection.
One can be justified in considering Dr. Shewhart as the father of industrial quality. He was the first one to
introduce statistical control charts to manufacturing as a tool to understand the stability of a process attribute.
Given the early date of its publication, it is not easy to find the original material, but in the majority of references
on the use of his processes
2
the first step is to identify the problem and proceed to its analysis. There is no direct
mention of business goals, even when it is difficult to imagine Dr. Shewhart not considering them, from his other
publications. It can be that (once more) the method was taken out of context and in doing so part of its systemic
approach was lost. We now go over the steps in PDCA within its four phases.
PLAN Step 1: Identify the Problem. Activities: Select the problem to analyze, clearly define it and draft a
precise statement of it; set a measurable objective for the problem solving effort; establish a process for
coordinating with and getting approval from the top management.
PLAN Step 2: Analyze the Problem. Activities: Identify those processes that impact on the problem and
choose one; list the steps of the process as they are executed at the time of analysis; build a process map; validate
the process map; identify possible causes for the problem; collect and analyze data related to the problem; verify
or review the original problem statement; identify the root causes for the problem; collect additional data if it is
necessary to confirm and verify the root causes.
DO Step 3: Develop Solutions. Activities: Establish criteria to choose a solution; generate potential solutions
that address the problem’s root causes; pick a solution based on criteria; gain approval and support for the chosen
solution; plan to implement and roll out the solution.
DO Step 4: Implement the Solution. Activities: Implement the chosen solution in a pilot or test it in a lab
environment. If PDCA is being used as part of the overall organizational Process Improvement Plan, continue with
Step 6. Otherwise continue with Step 5.
CHECK Step 5: Evaluate Results. Activities: Collect data of the process behavior after the change; analyze it. If
the results are good enough, continue to Step 6. Otherwise, return to Step 1.
ACT Step 6: Standardize the Solution (& Capitalize New Opportunities). Activities: Identify system-wide
changes and training needs for a complete, successful roll-out; plan the diffusion of the change; plan, execute,
monitor and control the roll-out; actively seek new incremental opportunities to refine the new process; look for
other improvement opportunities.
There is a difference between this description and how the method is used in the field. Let start by observing
that the DAR process area in the CMMI (all constellations) and the MPS-SW’s equivalent, the Decision
Management process, have strong resemblance to the steps listed above. Therefore, there is little discussion about
the relevance of the method. Still, there is a tendency to go over the steps too quickly and implement them in any
given context without trying to fully comprehend it holistically as a method. If we focus on how it is habitually
used, PDCA has the following attributes: easy to use, easy to follow, yet it is possible to start looking for
improvements that have no business impacts, much in the way in which Six-Sigma programs degenerate into a
Black-Belt program with goals on the number of people trained and promoted to the next level, without a clear
overall sense of improvement. Optimizing locally does not imply a system improvement. This said, many of the
versions have references to a process developed by Deming to address process improvement, which gives a very
systemic version of the method, as well as a more defined link to business goals. As appraisers we tend to judge a
process for how it is used, not for what it is written, but this is impossible to do under the circumstances. Still, we
will have to judge PDCA for the modern interpretations of it.
1
Shewhart’s book on Statistical Process Control [SHEWHART W., 1939] was compiled by Deming and carried his preface.
2
See for example http://quality.enr.state.nc.us/tools/pdca.htm

5. Boria et al.
Chapter 2 5
PDCA is a solid method, but its age has made it so that several of the details that Shewhart found important
are seldom found in their current implementations. This does not imply that those details are useless, quite the
contrary, but as with many other papers
3
, folklore has taken over history. It is infrequent that PDCA is correctly
framed within an encompassing method, more often than not it is considered an iterative way to run a process
group. One should be aware that for Shewhart, and as a consequence for Deming too, there is a larger process
improvement process within which PDCA fits. Otherwise, its value is lost. Starting by step 1 without a clear
understanding what the business needs are will render it as an exercise in futility, or a game of chance.
When PDCA is embedded within a framework that has a focus on the Business goals and incorporates a
systemic approach it works perfectly. Changing anything from that framework, or failing to have a framework
within which PDCA works is courting failure. The risk is to produce change without benefit. Since change is
expensive and painful, this can breed a disaster. Let us now see how Mc. Feeley [McFEELEY, 1996] deals with the
problem, adding to a kernel of PDCA the necessary detail (in a somewhat excessive manner, to our taste).
2.3 The IDEAL Method
Due to the enormous influence Deming holds on process improvement, and as a consequence so does
Shewhart, continuously referenced by him, all methods that we will address in this Chapter are strongly influenced
by PDCA. Figura 2.1 shows a graphical depiction of the IDEAL method. It is described in five phases that correlate to
significant steps in process improvement initiatives. Since improvements are perceived as a continuous endeavor,
it is implied that after the fifth step the process continues. Mc. Feeley underscores that the borders between
phases are fuzzy. Moreover, he cautions not to create large projects out of this process. His recommendation is to
start many several short projects in parallel. However, it is usual that these fall aside unheeded. As a consequence,
organizations attempt to do too much, packaged into long-lasting projects that create too much resistance from
those that should adopt the changes.
Figura 2.1: The IDEAL Method [McFEELEY, 1996]
The first phase is adequately named ‘Initiating.’ It has three blocks in the graph that are not explicitly
mentioned in the process description. Instead, the Initiating phase is defined to have 10 tasks. These are described
in detail, even to the level of subtasks in some cases. The same clash is repeated in every phase. Once the
improvement infrastructure is in place, according to IDEAL, the Initiating Phase is completed. The link between
business goals and process improvement has been established, a reward system aligned with process
improvement is in place, and an initial plan, containing the communication plan, for process improvement is in
place.
3
Few people are aware that Royce’s lifecycle is not the waterfall, for which he often is credited, when in reality he lambasted it.
Wirth’s paper on Functional Decomposition actually addresses proving programs correct, not the structured techniques that
claim to derive from it. And there are many more examples in our field, albeit it is so young.

6. Software Process Improvement with Agile Methods and Maturity Models
6 Capítulo 2
What follows is the six tasks of ‘Diagnosing’. The gap between actual and required process performance is
assessed. A key observation here is that those performing the gap analysis should not focus on the processes as
described, but the processes as executed. Since the exit criteria of the Initiating Phase does not imply the entry
criteria of this phase it makes it difficult to make the connection clear. The collective exit criteria of all Initiating
tasks do imply the Entry Criteria for Diagnosing, so the omission is procedural and not a core bungle. Exit criteria
for this phase are that a Baseline Findings and Recommendation Report has been delivered to the Management
Steering Group funding the effort, and accepted. Also, that a draft of the SPI strategic action plan is initiated.
IDEAL’s third Phase is called ‘Establishing’, which some readers that never went past the graphic version of
IDEAL assign to the processes, but the intention is to establish the plan. It has been suggested that other names
that better describe the phase, such as Planning or Tasking, were rejected because they did not fit into a nice
acronym. This is the phase where priorities are set or reviewed, and where the teams that will take the definition
and diffusion of changes and improvements are conformed. It is to be noted that the method recommends that
the planning be done by the Management Steering Group, and not by the Process Improvement Group
4
. From the
point of view of Organizational Development no recommendation can be better than this one: The decision is
where the locus of power lies. Even then, the implementation is rarely done this way: the process group presents a
plan that is either approved, reviewed or ignored by the organization. Exit criteria for the phase is that: the rollout
strategy and plan is fully executed, or being executed; the proposed solution is packaged properly and turned over
to the SEPG; that long term support has been arranged for; and that the process improvement has begun to be
institutionalized in the line organization.
After Establishing comes ‘Acting,’ This is to us the most interesting phase of the five. Even granting the
method has many useful components, this one sticks out because the link to business is strongly underscored in
this phase. Improvements are identified, developed, rolled through the organization, and practiced. It is defined in
ten tasks, of which we will underscore a subtask of step 2, Develop Solutions: Analyze and Fix the Problem. We do
this because in many ways it resembles what we will explain as Lean later in this chapter. The resemblance comes
from focus on the pain and not on process per se. Processes are changed because the processes, as defined and
used, are too lax and hence defects are possible and go undetected. The process is mute on defects and delays
that should not be tolerated. Processes are changed to attack the root causes, even if it is the symptoms that we
feel. When the problem is solved it is because we found the root cause and built processes that preclude it from
happening and detect it early when it does. This phase’s exit criteria is that the deployment strategy and the plan
have been executed thoroughly, or are well into completion. It is expected that solutions that have been adopted
(or even just piloted) are well documented and are under the control of the process group. It is also clear how to
judge their performance and how to maintain them. Process improvement is at the very least beginning to be
institutionalized in the organization
5
. This phase addresses many small improvements run in parallel, under a
single strategic plan and multiple tactical plans
6
. In spite of this wise advise, most implementations of IDEAL run
into the same problem: the BPFC, or Big Plan For Change, that never concludes and is resisted by most. It reminds
us of the famous Seinfeld sketch where Newman phases out explaining how the letters keep coming, and coming,
and coming. In the world of IDEAL, request for changes are the letters. Some organizations never leave the
planning phase.
The final phase, which is also the one that kicks off a new iteration through the IDEAL loop, is called
‘Leveraging’. This invokes taking advantage of progress made to establish the playing field for the next round of
changes and improvements. If the IDEAL method falls into the deviations aforementioned, there is little to show
and the process improvement effort usually dies. Frequently solutions are chosen and defined but not
implemented, not even piloted: every project is too busy ‘doing real work’, or the process group is happily taking in
new requests without closing on the previous batch, until the implementation is a problem larger, in itself, than
the one it is trying to solve.
4
Your names could vary. For example, the Management Steering Group is often called Process Improvement Steering
Committee, while the Software Process Improvement Group is often called the Software Engineering Process Group. Some
people prefer software PIGs to software PEGs.
5
When we deal with the CMMI we will have a definition of institutionalization that does not always match what is intended by
the authors of IDEAL.
6
Strategically the roadmap deals with the sequence of improvements, tactically with the order of deployment of single changes
and the projects that they affect.

7. Boria et al.
Chapter 2 7
IDEAL is not a bad method, but it is so detailed that a thorough reading is only for the process improvement
inclined, and then not for all of us. It is embodied in 236 pages. Many people have attempted to implement IDEAL
without reading the small letter, with dire consequences
7
. Some of the most fundamental elements are lost when
a perusal is conducted as the only training to implement it
8
. We can enumerate the following: a strong link to the
business objectives, parallel implementation of improvements, and a systemic (multicausality, feedback loops and
delays included) view; all vital to establish a successful continuous improvement program. IDEAL’s best
contribution is shown in Figure 2.2. It is its vision on how to create and sustain a successful software process
improvement program. All is based in the business goals, without attention to them the program will be a fiasco.
There are four pillars too: Program Visibility, or else it will go away as expense; horizontal and vertical information
sharing; creating a knowledge repository, and maintaining a support network for all adopters. Only with all four
can the process improvement program tactical and strategic plan be successful.
Figure 2.2: IDEAL’s Vision on Process Improvement [McFEELEY, 1996]
2.4 Focus-Improve-Sustain-Honor
Focus-Improve-Sustain-Honor (FISH) [ARTHUR, 2004] is one of the many contributions made by this author to
process improvement. It is yet another variant of PDCA, this one emphasizing Six-Sigma
9
tools. Arthur’s FISH main
difference is that it is based upon data. Using existent data and a search similar to those proposed by the business
intelligence community is the basis of this method, instead of repeated defects or the gap from some paradigmatic
behavior. This, of course, does not run contrary to the principles in PDCA, but it does make a difference in
effectiveness and applicability, because in FISH it is imperative to start from data analysis.
FISH begins with Focus, based on the statistically proven fact that it is a few processes that are responsible for
the larger number of defects. Finding ‘The Defect Factory’ makes one focus on the processes where a change can
have the largest impact. Arthur quotes Pareto’s Law. He reasons that if 80% of defects are produced by 20% of the
7
If you are not comfortable with the statement that many people do not read the details before attempting an
implementation, we would like you to read the seminal paper by Dr. Royce, Managing the Development of Large Software
Systems [ROYCE, W., 1970]. It is after this paper that people accuse him (falsely) of backing the waterfall life cycle. In this
paper Dr. Royce points to the waterfall as a childish vision of development that is plagued with problems. So much for fame.
8
Naïve IDEAL implementations have a tendency to be run through a sequential plan that creates the perfect process from head
to toe before attempting any implementation, a sure way to create resistance and delay application.
9
Six Sigma is the name given to a management strategy originated in Motorola in 1986. It is documented in SPC and TQM in
Manufacturing and Services [TENNANT, G., 2001] and widely used worldwide. It attempts to improve a company’s results
by identifying and eliminating the cause of defects. It uses a variety of techniques, mostly statistical. The term was born
from statistical analysis of the frequency of defects in manufacturing. Maturity of a manufacturing process is measured in
parts without defect over the total number of parts manufactured. A Standard deviation  measures the variation away
from the mean value. A six sigma process produces 99.99966% of defect free parts. This was Motorola’s goal and hence it
gave its name to the tools applied in its pursue.

8. Software Process Improvement with Agile Methods and Maturity Models
8 Capítulo 2
processes we can predict that 64% of the defects are produced by 4% of the processes, by simple application of
the so-called 80-20 rule a second time around. It is then a very small number of processes that are responsible for
the majority of the defects. Hence, the focus.
The second phase, ‘Improve’, is where the found defect is eliminated by updating the processes that allow it
to happen or make it possible to happen. The process that introduced the defect into the product and the quality
assurance processes that let it go undetected are changed to prevent repetition of the problem. Possible solutions
are identified and tried in this phase. Maturity models like CMMI and MPS provide the tools to build processes that
lead to identification of root causes of problems. All along this book we will be using such tools including the steps
that follow, improving and diffusing the improvement throughout the organization
10
. Using root cause analysis is a
systematic approach to process improvement that can be found in multiple sources, not the least of which is
Fagan’s in-process inspection process. [GILB T. & GRAHAM D., 1994]. When used together with risk analysis and
management in a systems thinking framework it becomes a fundamental intellectual procedure that should always
be present in process improvement.
The third phase, ‘Sustain’, is where the improvement is to be consolidated and maintained. Arthur here
breaks with tradition in that he proposes using “profound knowledge” tools, as they were proposed by Shewhart
and supported by Deming. For starters, Arthur requests the use of the process map, using as simple as possible
tools. In all cases, when there are options, Arthur falls on the side of simplicity, saving time for thinking and using
the tool that has the better fit and the lower learning curve. In this case he suggests using flow charts, even when
other tools are available more powerful and equally popular
11
.
Arthur argues correctly that to be able to certify that the results have been attained it is necessary that the
process is stable. Otherwise, any result could be attributed to chance and comparisons would be impossible to
hold. Let us use a simple example, of a culinary recipe that is producing mixed results. When we perform our root
cause analysis we find that the cooks are giving certain steps in the recipe different interpretations. The author of
the recipe assumed, incorrectly, that the cooks had received culinary training and would have a homogeneous
interpretation of her instructions. We also find that the recipe has a mistake, in that the type o flour being
suggested is not correct. Let us say that by saying “flour” without specifying the type our cooks will always assume
white flour, when the recipe calls for a special kind of flour. Root cause analysis detects these defects in the recipe
(our process to do the cooking) and the changes are made to eliminate them from it. We now have a recipe that is
unambiguous and describes the right ingredients.
An inexperienced process group will declare success and move on to happy hour. The process now “should”
work. Jay Arthur (and the authors) beg to disagree. Our job in process improvement is not done until the execution
of the process is performing correctly under most circumstances (exceptional circumstances could happen that
might throw away the gains). When such an incomplete definition of the duties of the process group is taken there
is a chance that something was overlooked and the process is still not fixed. Only the execution of the process
repeated times under controlled circumstances can show that it is now fixed, by focusing in the output, not on the
written process.
It is because of this that ‘sustain’ implies measurement and analysis of the results, to compare them to the
expected results and conclude if the process has been fixed or not. This leads to the need to understand what,
when and how to measure. It is central to each process definition that key steps are identified and the way to
measure their outcome defined in the process itself. The need is recognized early in the maturity levels, but it is
only expressed completely as a requirement to be appraised in what is called “high maturity”, where identification
of key processes is mandatory. Understanding which are the key processes is a managers most valuable tool. For
example, if a large number of our projects overruns its deadlines, we should make changes to the processes to
avoid this happening. Measuring not just the end result, but intermediate results after some key steps are
executed is of the utmost importance. If we wait for the project to be over to measure deviations from the
deadlines it is too late to operate on them. Arthur jumps right in with 6tools that the CMMI only requires at
Maturity Level 4 and the MPS at Maturity Level B. To test the stability of the processes requires statistical tools
10
Root cause analysis also Works when the event being analyzed brings a positive outcome. When the outcome is negative the
change will intend to out root it, if it is positive, to understand how it happen to duplicate it elsewhere.
11
SADT diagrams, or IDEF0 in their international norm version, are more detailed and its use more spread. Also swim lanes in
flow charts have a lot of followers. One could possibly use Structured Analysis techniques or UML, as has been proposed in
the literature.

9. Boria et al.
Chapter 2 9
that are far from the reach of normal managers most of the time. This really complicates the understanding of the
results too when there is a paucity of data. If a given change is limited in its use it could take months to gather the
data that proves the change has had the requested effect
12
.
The last phase in FISH is ‘Honor’. Arthur here deals with the change management requirement that
commitment to change should be recognized and rewarded. Not all changes are improvements, but all
improvements are changes, so that building commitment to organizational change is a powerful way to deal with
transitions. A huge part of how organizations deal with transitions is embodied in the way they choose to reward
their personnel with regard to changes and improvements. One should remember that not all improvement
projects will be equally successful, especially when the program is young. Some might even have negative results,
but killing the messenger is not going to solve the problem. An organization should be able to recognize when it is
learning a new thing and value the effort.
2.5 Lean Simplified
Our last choice of method is Lean Simplified [ARTHUR, 2006]. Jay Arthur developed this method as an
extension to his FISH so that it could be easier to apply. In it he emphasizes the value chain from the customer’s
request to her satisfaction for the product delivered. He has reduced the statistical demand that comes with Lean
to help its adoption by many organizations. We will abbreviate it LS.
LS, as Jay Arthur explains in [ARTHUR, 2006] was developed for the manufacturing industries. However,
modifying or leaving aside what does not work for the software development industries, is a powerful method to
identify and solve problems within a continuous improvement framework. Here then is our version of LS as
adapted from the original version to be applied to software development. At the heart of LS lies production
speed
13
. Speed is not hurrying up to go as fast as one can. It requires respect for quality and avoiding interruptions.
It is not coming to work on weekends or staying late every night for two months before the deadline. Speed is
productivity serving the product. In today’s world where faster, cheaper, better has reached the level of now, free
and defect free [RODIN, 2010], it is imperative that software organizations respond with high quality and low costs
while turning the product on time all of the time.
Delays can no longer be justified. Software products can be unique and not repeatable, but the processes
through which we generate it are not. Each project, whether it is Agile or traditional, has the same phases and
activities. It is notable that very low maturity organizations have a great resistance to such concept. In those
organizations it is a sad contradiction that everyone knows that things have to change but they stick to their guns
in that there is no way to organize production that can be better than the anarchic process they follow. What is
really wanting is a serious effort to recognize their needs and start on a systematic hunt for their pain points.
According to Arthur, every organization has two factories. The main factory, the one that is shown to the
visitors and carries the organization day to day, is the one that designs, produces, sells, invoices and delivers the
product. This factory has an equation that can be expressed as Speed with Quality + Income = Benefits
14
. The
second factory is constantly fixing what the first factory does wrong. It fixes designs, builds, deliveries, as they are
seen to have defects. A fixes factory is often at least partly visible and can be controlled. Unfortunately many times
the fixes factory is hidden under the carpet and its impact on the product factory is not considered. The formula
for this fixes factory is Defects + Delays = Losses.
LS focuses in production speed. The relationship between steps in a process is fundamental. Steps and
activities that do not add value should be eliminated from the process. The first activity in LS is to map the ‘value
12
A surprising side effect is that when an organization is already very good, shaving off a small percentage of defects can be
considered a real improvement, but under the circumstances it could well be that to show it in statistical analysis could
demand years of reproducing the experiment.
13
Toyota invented lean production taking a hint from supermarkets in the USA, where product is added to shelves as the point
of replacement is reached and as fast as the customers are demanding it. This they dubbed a “pull” system. In a pull system
the preceding process needs to synchronize its speed to the process that consumes its products. To be able to identify the
need to produce more of a given part, the workers would place a card that would mark the place in which the producers
would have to at least match the speed of the consumer. The Japanese name for the card is Kanban. Today the card’s name
is also used to denote the method and some related tools, such as a Kanban board.
14
The role of margin in business is grossly underdeveloped in favor of other indicators such as market share. It is easy to pay for
market share with margins. The other way around is not possible. Stressing the margins in favor of market share is a recipe
for disaster.

10. Software Process Improvement with Agile Methods and Maturity Models
10 Capítulo 2
chain’, the sequence of activities that go from the reception of a customer’s request to the satisfaction (or lack
thereof) her needs
15
. Once again, the map has to be simple in construction and understanding, but not so
oversimplified that it is ambiguous. Besides, since it is a pull system where the output of an intermediate product
can force the activation of the previous process, and so on, this method is normally oriented to start from the
Voice of the Customer. Correctly done, this map shows how the organization generates value for the customer
and, in consequence, for itself.
Focus on Defects
In trying to reduce the “friction” that delays processes, Toyota discovered that there are many forms of waste
(“muda”).
1. Excess of production (in software, it can be gold plating, that is including code that was not requested
“just in case we might need it later”)
2. Excessive inventory (in software, processes that are not required by the output, such as excessive
testing of non-required functions, manuals that are excessive in detail and useless, et cetera)
3. Waiting (in software this happens when another role or personnel is busy or some particular
environment is not available, but often when the customer has to give approval to something)
4. Unnecessary movement of parts and product (in software this can happen if unnecessary approvals
and reviews push product around folders)
5. Unnecessary movement of people (typically in installing or deployment or in validation, sometimes in
the requirements phase)
6. Unnecessary processing (this can be related to unneeded iterations in software)
7. Defects that drive fixes and rework (no, really? In software? No need to elaborate)
When an organization works in short time periods and focuses on maintaining flexibility quality benefits and
the consequent customer satisfaction are easy to achieve. In the next Chapter we will elaborate on how a group of
software developers built several methods that build on such principles. The movement they founded is explained
in their site, the Agile Manifesto
16
and has forever changed our views on how to organize the software
development activities.
Going back to LS, it follows the value stream mapping with how to eliminate muda. This is known as the five
S. The five S are: Sort; Straighten; Shiner; Standardize; and Sustain. In what follows we give our own twist on what
each means in software development
17
. Sort stands for deciding what is useful and what is not and get rid of the
latter. This to us is what process improvement is. When it works, it is the teams that detect anomalies, missing
elements and redundancies in processes, asking for changes and suggesting them. If the Quality Assurance role is
correctly performed, as we will see later, it can be useful in detecting best practices and cross-pollinating across
teams. Straighten deals with having a place for each thing and keeping it under control. In software development
this falls under configuration management. We will elaborate on it further in another Chapter. To Shine has to do
with keep the area clear and clean so that problems can be immediately spotted. A clogged work area is a magnet
for problems. In software development it has to do with readability and ease of use of documents and code. We
will deal with this in several process areas that focus on how technical solution is developed, starting from
gathering requirements. Patterns and code standards are part of how to shine your work environment. In a sense,
configuration management should too make it possible to keep your work environment clean. Standardize is to
define policies, processes and procedures that help enforce the previous three Ss. Again, the process group with
support from upper management should be able to make this happen. Finally, Sustain is to achieve a stable flow of
work that sticks to the rules. In low maturity this is the role of quality assurance and the process group later, in
high maturity this is part of the culture itself.
Another surprising fact of LS is that demand has preeminence over production. The organization does not
produce what they think they can sell they produce what their customers demand from them. In our translation to
software development we can simply state the obvious, that is that it has always been this way. Now, it is possible
15
To hear and react is not to listen and satisfy.
16
http://www.agilemanifesto.org/
17
If you are interested in the original definitions in manufacture, these are useful sites to visit: http://es.wikipedia.org/wiki/5S ;
http://totalqualitymanagement.wordpress.com/category/management-of-process-quality/toyota-production-system-
management-of-process-quality/

11. Boria et al.
Chapter 2 11
to build unnecessary software. Think of the last time you used every function in your favorite spreadsheet program
in one month. However, there is a lesson here too: if it is not broken, do not fix it. As a process group we should
recognize the organization as our customer for process improvement. If they do not demand it, it is going to be a
hard sale. This is why LS is a pull system. We shall not push process improvement into people’s desks under
penalty of building some (serious) resistance. The typical abuse happens when an organization wants to “achieve a
level by year’s end”. The ensuing frenzy does not focus on development problems but on achieving the level as a
problem. It is rarely the case that the outcome is a better organization. When a process change is perceived as an
improvement that really solves a recognized problem, adoption is easy and the free time that the teams gain from
the change allows them to second more changes in the future.
LS has even more to offer, but we have covered above what is essential to understand the advantages and
disadvantages of the method. Our Pugh matrix for the four methods, according to us, is now thus:
attribute weight PDCA IDEAL FISH LS
SYSTEMICITY 5 1 3 3 3
CLARITY 4 1 1 2 3
FEEDBACK 3 2 1 1 3
sum 15 22 24 32
Table 2.2: Analysis of a Process Improvement Method
It is clear from the table that our inclination is to use LS. Of course, one can object to this decision, because all
the numbers in the table are arbitrary to a certain extent. In a decision with more impact on the business itself it
would be desirable that the punctuation system be more detailed and weighted to achieve more objectivity.
Since we are going to use LS in our analysis and our proposals for the organization that we have taken as our
study case it is convenient to underscore here some of the values and believes that are associated with LS.
1. An exact process will produce the exact results.
2. Developing personnel and suppliers adds value.
3. Continuous solving of root causes of problems conduces to organizational learning.
4. One piece flow increases productivity, earnings and quality.
5. Products do not like to stand in a line waiting for attention. Materials, parts and products are impatient.
6. The only thing that adds value in a process is the physical or informational transformation of the input
into something the customer wants.
7. Mistakes are an opportunity for learning.
8. Problem solving is 20% tools and 80% applying your intelligence.
In our process improvement approach many, if not all, of these values will come into play in what deals with
software development. We will not limit ourselves to applying an implementation of the MPS, we will try to
identify and solve the problems that plague the software industry.