Your SlideShare is downloading. ×
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Maturity Models and agile chap 02
Upcoming SlideShare
Loading in...5
×

Thanks for flagging this SlideShare!

Oops! An error has occurred.

×
Saving this for later? Get the SlideShare app to save on your phone or tablet. Read anywhere, anytime – even offline.
Text the download link to your phone
Standard text messaging rates apply

Maturity Models and agile chap 02

163

Published on

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 …

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.

Published in: Software, Technology, Business
0 Comments
0 Likes
Statistics
Notes
  • Be the first to comment

  • Be the first to like this

No Downloads
Views
Total Views
163
On Slideshare
0
From Embeds
0
Number of Embeds
0
Actions
Shares
0
Downloads
5
Comments
0
Likes
0
Embeds 0
No embeds

Report content
Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
No notes for slide

Transcript

  • 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.

×