fedora 12 · understanding the existing process and how well it performs, the dmedi measure tends...

16
1 Fedora 12 Six Sigma in Fedora Possible application of Six Sigma within Fedora John McDonough Copyright © 2009 John J. McDonough Copyright © 2009 John J. McDonough. The text of and illustrations in this document are licensed by Red Hat under a Creative Commons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanation of CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The original authors of this document, and Red Hat, designate the Fedora Project as the "Attribution Party" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute this document or an adaptation of it, you must provide the URL for the original version. Red Hat, as the licensor of this document, waives the right to enforce, and agrees not to assert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law. Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, the Infinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United States and other countries. For guidelines on the permitted uses of the Fedora trademarks, refer to https:// fedoraproject.org/wiki/Legal:Trademark_guidelines. Linux® is the registered trademark of Linus Torvalds in the United States and other countries. All other trademarks are the property of their respective owners. Abstract This article briefly describes Six Sigma, especially Design for Six Sigma, and how it may be applied within Fedora, especially with respect to understanding what does Fedora mean and what should it mean. 1. Introduction .................................................................................................................................. 2

Upload: dangthuan

Post on 21-Jun-2018

212 views

Category:

Documents


0 download

TRANSCRIPT

1

Fedora 12Six Sigma in Fedora

Possible application of Six Sigma within Fedora

John McDonoughCopyright © 2009 John J. McDonough

Copyright © 2009 John J. McDonough.

The text of and illustrations in this document are licensed by Red Hat under a CreativeCommons Attribution–Share Alike 3.0 Unported license ("CC-BY-SA"). An explanationof CC-BY-SA is available at http://creativecommons.org/licenses/by-sa/3.0/. The originalauthors of this document, and Red Hat, designate the Fedora Project as the "AttributionParty" for purposes of CC-BY-SA. In accordance with CC-BY-SA, if you distribute thisdocument or an adaptation of it, you must provide the URL for the original version.

Red Hat, as the licensor of this document, waives the right to enforce, and agrees not toassert, Section 4d of CC-BY-SA to the fullest extent permitted by applicable law.

Red Hat, Red Hat Enterprise Linux, the Shadowman logo, JBoss, MetaMatrix, Fedora, theInfinity Logo, and RHCE are trademarks of Red Hat, Inc., registered in the United Statesand other countries.

For guidelines on the permitted uses of the Fedora trademarks, refer to https://fedoraproject.org/wiki/Legal:Trademark_guidelines.

Linux® is the registered trademark of Linus Torvalds in the United States and othercountries.

All other trademarks are the property of their respective owners.

AbstractThis article briefly describes Six Sigma, especially Design for Six Sigma, and how it maybe applied within Fedora, especially with respect to understanding what does Fedoramean and what should it mean.

1. Introduction .................................................................................................................................. 2

Six Sigma in Fedora

2

2. What is Six Sigma ........................................................................................................................ 22.1. DMAIC .............................................................................................................................. 32.2. DFSS ................................................................................................................................ 42.3. Transparency and Storyboards ........................................................................................... 42.4. Deliverables ....................................................................................................................... 72.5. Tools ................................................................................................................................. 8

3. Market Positioning ........................................................................................................................ 83.1. Understanding Competitors ................................................................................................ 83.2. Customer Analysis ........................................................................................................... 103.3. Voice of the Customer ..................................................................................................... 113.4. Prioritizing the Requirements ............................................................................................ 133.5. Positioning Our Product ................................................................................................... 14

4. What is Fedora ........................................................................................................................... 15

A. Revision History 16

1. IntroductionSix Sigma techniques have been used throughout industry for a number of years. Although Six Sigmatechniques made their initial mark on manufacturing, they have been far more effective when applied to"transactional" projects, especially software.

Six Sigma is highly focused on data based decision making, and especially in the case of productdevelopment, has demonstrated powerful tools around understanding the customer base, how it issegmented, and how to best serve that base by the deployment of capabilities.

Inasmuch as the Fedora Project is attempting to understand its positioning within the larger open sourceecosystem, it seems an appropriate time to raise the possibility of applying these tools to that effort.

2. What is Six SigmaSix Sigma is a set of project methodologies. There are separate methodologies for improvement and from-scratch development. Six Sigma actually recognizes three sets of methodologies:• MET or Most Effective Technology projects. Where the improvement needed is small and the

techniques needed are known, the project is simply performed in the traditional way. These aresometimes referred to as JDI or "Just Do It" projects. Six Sigma does not address these projectsdirectly, but simply recognizes that there are times when a rigorous approach is not warranted.

• DMAIC or Six Sigma Improvement Projects. In this case we need a substantial improvement, and theremay be enough complexities that the solution is not obvious. For DMAIC projects, however, we believethat our current way of doing business can be modified to achieve our objectives. While the way forwardis not totally unknown, it requires some study.

• DFSS projects. These are either build from scratch or dramatic improvement projects when we think ourcurrent methods require rewriting from scratch. DFSS is often used in product development, and as aconsequence, focuses more heavily on understanding the market, the customer base, their needs andtheir wants.

DMAIC

3

Six Sigma is all about measurement, and the amount of improvement needed is often spoken of in"sigmas", or the number of standard deviations some metric needs to be moved. DMAIC projects aregenerally undertaken when the degree of improvement desired is around one sigma. Some smallfraction of that typically leads to a MET project, while a several sigma improvement typically requiresa DFSS project. In some organizations, a dollar value is applied to help. In one organization this writerworked, DMAIC projects were expected to return about a quarter of a million dollars, DFSS projectsmillions, although DMAIC projects would frequently discover that they could return far more than initiallyanticipated.

In many ways, Six Sigma is nothing more than organized common sense. At a high level, themethodologies seem obvious (although we often realize that we can see that common sense more oftenin the breach!) Within a large corporation, Six Sigma often incorporates a lot of mystique and mumbo-jumbo, but this is typically about changing the corporate culture. As a data-based methodology, Six Sigmacan be threatening to managers who are accustomed to making arbitrary decisions. The prospect of beingruled by the data appears to many to be a threat to their authority. A lot of the mystique around Six Sigmais about deflecting this problem.

2.1. DMAICThe DMAIC process is the Six Sigma improvement methodology. There are 5 stages, which this writerlikes to explain in the following simple terms:• Define - Let's all agree on what we want to do

• Measure - Be sure we understand what success smells like

• Analyze - Understand what knobs we have to turn

• Improve - Decide which knob we are going to turn

• Control - Make sure that knob stays turned

Of course, we speak of "knobs" in the figurative sense. Even in manufacturing applications rarely are thechanges we need to make physical knobs. Instead they are various process or technique changes.

While the DMAIC steps may seem like common sense, they are often ignored in more traditional projects;particularly the first and last steps. How often have you seen the same project repeated every few years,because nobody thought to consider how to keep the process from reverting back to its old ways. Andhow many projects have you seen where the project is almost complete and a stakeholder says "That'snot what we were trying to do". By formalizing these steps Six Sigma attempts to elude these pitfalls.

Each step along the way the project is driven by the data. This is a major difference between Six Sigmaand traditional projects. Project leaders are skilled in experimental design and analysis of results. Theyare trained to refuse to be seduced by "apparent" trends and "common knowledge". Every step must bejustified by defensible data.

Of course, in the real world, collecting data is expensive and time consuming, and we can't always affordto get all the data we would like. Nevertheless, the Black Belt must find data he can use, even if it is notperfect. And he has the tools to evaluate the quality of that data.

Six Sigma in Fedora

4

2.2. DFSSDFSS or Design for Six Sigma projects are those where the expectation is that something new will have tobe designed. There are a few "flavors" of DFSS, but really, they differ only in the marketing. The DMADVflavor emphasizes the commonality with DMAIC. The DMEDI flavor tries to highlight the creative aspect.The IDOV flavor emphasizes the front-end loading of the technique. In reality, the flavors are almostidentical; the difference are in what aspect the proponents want to market. This writer was brought up inthe DMEDI school, so we will discuss that.

DMEDI, like DMAIC, has five steps, and they are quite similar in objective, although the actual activitiesperformed may be quite different.• Define - as in DMAIC, let's all agree what we are going to do

• Measure - again, what does success smell like. But where the DMAIC Measure is generally aboutunderstanding the existing process and how well it performs, the DMEDI Measure tends to be abouta very deep understanding of the customer. This is where the market is segmented, where marketingstudies are performed, and also where functional options are understood.

• Analyze - as in DMAIC, we are trying to understand our options, but in DMEDI we are trying to balanceour functional options to the needs of our various constituencies. This can be a fairly technical andcomplex process.

• Explore - here we really do the detailed design, and we typically use tools that are common to theparticular domain. The main difference here is that since we have a "DFSS Scorecard" that wedeveloped in Analyze, we have some metric to help us decide between design options.

• Implement - sounds simple, go make it happen. But in implement we are also putting in place metricsthat allow us to track how successful we were in achieving our goals.

2.3. Transparency and StoryboardsSix Sigma works because a number of things that have been done before, especially in quality efforts likeTQM, are combined in a particularly effective way. One of the key Six Sigma components that is oftenunderplayed is the incredible degree of transparency.

In the open source community we tend to think of ourselves as models of transparency, but the Six Sigmaapproach goes beyond our level. Not only are all stakeholders given an opportunity to participate indecisions, but decisions MUST be data based, and the Black Belt is required to clarify the thought processvisually. This means that not only are all significant decisions open, they are understandable.

A key way the decision process is detailed is through the storyboard. For each part of the process theBlack Belt builds a storyboard that visually shows step by step how certain decisions or metrics werereached. The following few images show parts of a storyboard for a project to deliver video into thecommand vehicle for emergency responders:

Transparency and Storyboards

5

Figure 1. Storyboard page showing overview of process

Six Sigma in Fedora

6

Figure 2. Storyboard page summarizing specific study

Deliverables

7

Figure 3. Storyboard page showing resulting decision process

Of course a complete storyboard involves a dozen or two slides, and interestingly, rarely are theypresented as slides. More often they are printed and posted on a board that reviewers can review,sometimes in a "gallery walk" setting.

Complete storyboards for some non-proprietary projects may be viewed at http://www.is-sixsigma.com/index.shtml?ID=3.

2.4. DeliverablesAlthough the overall steps in a Six Sigma project look fairly similar to the traditional SDLC, the emphasison deliverables is quite different. Six Sigma provides a very rich set of tools, each roughly equivalentto a typical software development deliverable. However, in Six Sigma, these tools are merely tools.Although reviewers will often look for specific tools for specific purposes, most tools are really optional.The "Deliverables" are really quite few, and for the most part are specific metrics. For example, the maindeliverable from the Measure phase of a DMAIC project is the CCR, or Critical Customer Requirement.Although there may be more than one, typically the CCR would consist of a target value for a specificmeasurement. In DFSS, of course, there tend to be more, but there is a clear distinction betweenrequirements, which tend to be exposed during Measure, and critical requirements, which are the maindeliverable from Measure.

Six Sigma in Fedora

8

2.5. ToolsThe Black Belt is the project manager in Six Sigma, although in some programs he may be relieved ofadministrative duties such as project scheduling and tracking so he may focus on the process. The BlackBelt is trained in hundreds of tools, and applies them as needed for a specific project. Although manytools can be effective on their own, they tend to be more effective when they are applied with a clearunderstanding of their context.

Often when one hears about Six Sigma one hears about statistics, and many of the Black Belt's toolstend to be statistical. However, there is much emphasis on understanding the "Voice of the Customer","Human Change Management", and many other "soft" areas which are equally important in guaranteeinga project's success.

For our purposes, the tools around new product development, especially understanding customer needsand wants and market positioning are key. In this short note we cannot even list the total toolset at theBlack Belt's disposal. We will head directly to the Measure deliverables of understanding where we wantto position ourselves in the market.

3. Market PositioningKey to understanding what any product needs to look like, including Fedora, is deciding where we want toposition ourselves in the market. There are two components to the market, customers and competitors. Tomake rational decisions, we need to understand both components.

3.1. Understanding CompetitorsTo understand the market landscape we need to understand the players inhabiting that market. While wemay not think of other distributions as "competitors" in the true sense, we do need to understand them asif they were. Even if we decide that we want to be a clone of Ubuntu, we need to understand what thatmeans. More likely, we imagine things that differentiate us. If we want to exploit those differences, weneed to understand how some parts of the market are served.

The competitor analysis can be quite complex, involving market research firms and expensive evaluation,or it can be quite simple. Simply writing down what we know can be very valuable. Enhancing that bysimply visiting websites and further validating where these competitors see themselves can be veryhelpful. But simply writing down our findings helps to clarify our understanding:

Understanding Competitors

9

Figure 4. Competitor Analysis

This approach can be quite simple; list the competitors, note what characterizes them, especiallytheir differences, then do a little digging to help understand how each competitor addresses specificcharacteristics.

A table of data, however, can be difficult to digest. One may see some trends, but it is always usefulto make the data visual. One way to do this is with a corner model. A few (3-5) key characteristics areidentified, a polygon with that number of vertices is drawn, and corresponding polygons outlining whereeach competitor fits on that spectrum is drawn.

Six Sigma in Fedora

10

Figure 5. Corner Model of Competitors

This simple technique often highlights differences that might not be evident from the table, and perhapsmore importantly, clearly shows underserved market components. In the model above, it is obvious thatno competitor focuses on the business process reengineering segment.

Clearly, this approach is simple and inexpensive. Depending on the project, far more detailed andexpensive analyses might be warranted, but the approach must be matched to the needs and resourcesof the project.

3.2. Customer AnalysisThe other side of the market coin is, of course, the customers. They may be customers in the true sense,clients, stakeholders, or other consumers of the product. But to rationally make market positioningdecisions, we need to understand them and their needs.

The first step in understanding the customers is understanding how the market is segmented. Again,this can be simple or complex or anywhere between. Very likely we have some idea of the differentconstituencies. Again, writing them down is important, but we also want to write down what differentiatesthem.

Voice of the Customer

11

Figure 6. Market Segmentation

In the above figure, which was part of a website design, the intent was to identify market segments thatshould be addressed. Green Belts were identified as not having much influence, and thus were ratedlower. And while executives may have much influence, they are unlikely to get their data from websites.The visual presentation makes this decision very transparent.

3.3. Voice of the CustomerOnce we understand the segmentation of the customers, we next need to identify what matters to them.This is quite similar to traditional requirements elicitation. However, we again use a few tools, some ofwhich are commonly found in software development, to help focus the process.

The first step is documenting what we want to know. For this we use an Information Inventory. TheInformation Inventory outlines key questions, how important they are, where we may find that data, andhow credible it is.

Six Sigma in Fedora

12

Figure 7. Information Inventory

Notice that, although stakeholder interviews are the traditional way to collect requirements, we don't wantto overlook other avenues. Research on the web, through suppliers catalogs, even the library are otherways in which information can be gathered.

Having decided what we want to know, and who the stakeholders are, we can now begin the informationcollection. We can use the Information Inventory to drive stakeholder interviews, but we collect the data ina Stakeholder Voice Table.

Prioritizing the Requirements

13

Figure 8. Stakeholder Voice Table

The stakeholder voice table not only includes what the customer wants, but also why. Often we canmisunderstand a customer statement. By exploring why and how the feature will be used, and makingsure we capture specific stakeholder quotes, we reduce the possibility that we will misunderstand somestatement.

3.4. Prioritizing the RequirementsOnce we have a collection of stakeholder needs and wants, we need to assign some weight to each.Depending on the number of stakeholders and the level of detail in our information inventory, we may endup with hundreds or thousands of "requirements". Simply attempting to assign some number to such amass of data quickly becomes meaningless, so some level of consolidation is required.

The first step is to affinitize the stakeholder statements to identify significant themes. This can be doneusing any of a number of affinitization tools. Ideally, of course, the stakeholders would be involved in thisprocess, but often that is simply untenable, and the project team, or a subset, needs to perform this task.However, the more diverse the group performing the affinitization the better.

Six Sigma in Fedora

14

Figure 9. Prioritization

There are many ways to assign priorities, but to make the assignment objective is difficult. If thereare few players, individual agendas tend to dominate the process. Even when there are a significantnumber of participants, stakeholders can't help but try to game the system to align the results with theirpreconceptions.

To reduce this tendency, a tool called the Analytic Hierarchy Process is often used. This essentiallyinvolves comparing all pairs of requirements. Obviously, this can be time consuming if there are manyrequirements, so aggressive affinitization beforehand is a prerequisite. Again, the level of participation andconsolidation needs to be driven by the project's needs and resources.

3.5. Positioning Our ProductNow that we have an assessment of the market we can proceed to understand these relationships.The tool typically used for this is Quality Function Deployment, sometimes called the "House of Quality"because of the similarity of the diagram to a house.

What is Fedora

15

Figure 10. Quality Function Deployment

The affinitized requirements are placed on the left, along with their relative weights as determined throughthe AHP. Along the right, we estimate how well our chief competitors meet these requirements, and arealistic assessment of where we would like to be with respect to each of these needs.

The customer needs may or may not map directly into components we can identify. Clearly measurablecomponents that are placed along the top (box 5). These may have been gained through affinitizationor a traditional functional decomposition. Within the relationship matrix, we identify how strongly each ofthe functions maps to the stakeholder needs. Based on that we can now calculate the importance of thevarious functions, and rank their importance. The top of the diagram, or "roof", provides a way to identifysynergies or conflicts that may indicate that special attention is needed to specific functions.

4. What is FedoraBy understanding the ecosystem in which we operate in an objective, quantitative fashion, we will be in afar better position do decide what Fedora is, or perhaps more importantly, what we want it to be. And byusing the Six Sigma philosophy of making all decisions visual, we will be much better positioned to explainwhat we have discovered.

Six Sigma in Fedora

16

A. Revision HistoryRevision 1.0 2009-11-06 John McDonough [email protected]

Initial Version