chapter3and4.pdf
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 1/27
3.1 Module 1: Quality Values and Principles Best value is deeply satisfying
Module 1—Objectives Explain and discuss quality as both a value and an objective
Explain and discuss the dominance of quality over cost and schedule
Quality: Values, Principles, and Practices To begin, quality is a value; values are ideas we believe in and care about. Things of value are things for which we are willing to work and pay. Indeed, in another chapter, we will address the cost-of-value as a synonym for budget. And so it is with quality—it is that which we are willing to pay and invest to achieve and obtain. Though quality is a relentless goal of agile projects, most agree that quality is hard to de�ine —indeed, for many, quality is one of those things that we know when we see it.
Quality makes its appearance to customers with project outcomes; thus, we think of quality as an outcome objective. As such, quality as an outcome objective is quite different from cost, schedule, and other resources, the control of which are input objectives. Following the paradigm of the Agile Manifesto, agile practitioners put more weight on achieving quality outcomes than adhering to an input resource plan—cost and schedule, etc. In this sense, agile projects are dominated by the shift of allegiance from the input plan to making good on quality promises.
Quality is inextricably linked with price through value. When quality, as perceived by the customer or sponsor, meets or exceeds the price to be paid, the product certainly has economic value—hence, “I got my money’s worth.” If there is no better opportunity, such economic value may be a best value.
Other chapters address best value in more detail; but, suf�ice it to say that when customers draw deep satisfaction with the quality of the product, they also believe they have received the best value for their investment. And, the term customer is meant in the broad sense: executives, sponsors, users, and those who pay—whether internal or external. Throughout the text, we will build on the quality values given in Table 3.1 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#tab3-1) .
Every methodology includes principles labeled quality principles. Principles are the domain-speci�ic guidelines that point the way and set boundaries for behavior and action. Principles support values, but principles bring the action. Every project dashboard should advertise the principles that guide their speci�ic project and re�lect upon their organization. The list in Table 3.2 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#tab3-2) can be a part of every agile project.
Table 3.1 Quality values
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 2/27
Within every project and every methodology there are quality practices that put principles to work. Quality practices are the things that are actually done to deliver and improve quality. Practices are implementations of principles. There are many more than the most important few listed in Table 3.3 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#tab3-3) . Each of the quality dimensions—�itness to use, �itness to standard, �itness to cost, �itness to societal and global environment, and others—are achieved most easily when fully internalized by all the project participants.
Quality Values and Principles Are Planned into Agile Methods The discussion so far is the setup for actionable quality practices in agile projects. Values and principles such as respect for courtesy, timeliness, and accuracy of communications, are guidance for day-to-day activities. Tools and techniques such as customer-driven value and plan-do-check-act come from the legacy of Taylor, Deming, Juran, and Crosby, among others. It now remains to apply this quality inventory to agile projects.
Planning and Deployment Planning for quality is much like planning for the project itself:
Establish goals,
Conceive a strategy,
Adopt principles to guide action, and
De�ine practices.
Table 3.2 Universal quality principles for agile methods
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 3/27
Table 3.3 Quality practices
Ideally, the project’s quality goals and principles will:
Align with the quality elements of the balanced scorecard
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 4/27
Re�lect the values and principles of the organization as given in Tables 3.1 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#tab3-1) and 3.2 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#tab3-2)
Re�lect the principles of quality practices in projects as given in Table 3.3 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#tab3-3)
Respect the values and principles of the speci�ic methodology followed
Suggested quality goals are given in Table 3.4 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#tab3-4) .
Deployment of a quality regime is �irst and foremost a communications task to inform, train, and educate—and also to document principles, standards, benchmarks, and practices. Deployment drives internalization. What is meant by deployment and internalization is that while it is necessary to inform and educate, it is imperative for each project member to take matters to heart, in order to have an effective program, to treat the project principles as personal principles, and to make quality practices natural and routine.
Quality program deployment steps for agile projects are listed in Table 3.5 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#tab3-5) .
Scorecards for Quality In physical systems, quantitative quality metrics are numerical measures compared to a benchmark or control limit. This, we know, is de�ined process control. Among many similar objects, the actual measurements—usually slightly different from one object to another—will largely cluster around the nominal value.
Table 3.4 Quality goals
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 5/27
Table 3.5 Deployment elements for agile projects
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 6/27
Acceptance limits are established to separate the good objects from the bad. Numerical measurements are recorded on a scorecard that is often called a control chart because the measurements are plotted between the control limits as shown in Figure 3.1 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch55#�ig3-1) .
With intangible outcomes, physical parameters such as size and weight are not usually measured; instead, functionality and performance are measured. Because many defects are unforeseen consequences of interactions among system elements, the system’s latent chaos and entropy are unknown. Thus, the practical import is a near-real-time strategy to set quantitative defect limits empirically, meaning the quality standard is adapted to the observations of the actual situation. To gather empirical data, discriminating differences are observed and recorded.
At the unit test level, there are all manner of technical errors:1 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch75#ch03fn1) Syntax, spelling, de�initions, and others. At the integration and functional level, users �ind errors of logic—such as retrieving only a last name instead of a �irst and last from a database—and errors of performance, such as too much time taken to populate a data �ield. And there are other defect categories such as defects of conformance to standards, and missing or inappropriate features and functions.
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 7/27
Figure 3.1 Example control chart
To develop a quality performance scorecard, design entries for:
Error condition: The error condition is the unique problem observed, like retrieving only the last name rather than �irst and last.
Error condition frequency: Occurrences of unique errors are scored as a 1 or 0—at each observation instance, the error either occurred or did not occur. The total frequency count is simply the sum of the error scores.
Error condition probability: The ratio of the occurrences to the observations is the error condition probability.
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 8/27
Error impact: Impact is a judgmental factor about how much an error condition affects product effectiveness and customer satisfaction. Impact is often given as a qualitative (e.g., low, medium, or high) �igure of merit, or sometimes a number scale is applied—the higher the number, the lower the customer satisfaction will be.
Module 1—Discussion for Critical Thinking In your experience, is it more likely that quality will be dominant over cost and schedule, or not?
If your answer to the foregoing was yes, do you agree that management focus and priority has shifted to outcomes from a priority and focus of keeping to a planned cost and schedule?
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-cb… 9/27
3.2 Module 2: Thought Leaders and Agile Quality
Agile quality is built on the work of many of those that have thought much about quality
Module 2—Objectives Familiarize the reader with the most distinguished quality thought leaders
Make the connection between quality ideas and agile objectives
In this module we examine the impact on agile of the thought leaders on quality. In this module, three different ideas of quality are presented, each represented by a different thought leader:
1. Business ef�iciency (think of lean);
2. Product excellence (think of a product with no bugs); and
3. Fitness for use (think of customer satisfaction).
F. W. Taylor’s Lean Thinking Fredrick Winslow Taylor, more popularly known as F. W. Taylor, was one of the �irst to study business systematically. Unwittingly, he was the lean thinker of his day. According to Taylor, managers must acknowledge and accept this principle:
Managers have responsibilities to design ef�icient and effective processes and procedures.
Waste must be eliminated! It is not enough that the trains run effectively— they must run on time! Every action requires de�inition and a means to measure results.
Taylor came up with the original time and motion studies, perhaps one of the �irst attacks on non- value work. Peter Drucker, a management guru par excellence who coined the term knowledge worker, has ranked Taylor as one of the seminal thinkers of modern times.2 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch75#ch03fn2)
Taylor may have been the �irst lean thinker, but he was decidedly not agile-oriented regarding staff, which he thought of as interchangeable— according to job description, not individual talent. Taylor, more so than any of the other thinkers, was focused on business ef�iciency and not on making conditions right for innovation and customer in�luence.
Taylor believed that workers must be divided by skill and by role; quality is achieved by careful job design, handing off from one skillful person to another. Any residual errors are caught at the end by independent inspection. Taylor’s ideas made mass production of process results possible:
People, properly trained, were to be as interchangeable as standard mechanical parts
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 10/27
De�ined processes staffed with quali�ied people should be capable of consistently repeatable results
And Taylor ushered in quality control as an independent and external practice to catch anything the functional process did not detect and correct.
Kent Beck in Extreme Programming Explained3 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch75#ch03fn3) confronts the legacy of Taylor by noting that:
Taylorism lies latent in our business culture and unconsciously affects day-to-day activity
Taylor’s idea that quality is a responsibility external to the mainstream work
The idea of quality outside the mainstream should be worrisome to all of us. As this chapter will present, quality is an equal partner with scope, resources, and schedule. Quality, as they say, is built-in and job one.
A project management
tip
F. W. Taylor’s impact on agile projects
Fredrick Taylor was the �irst lean thinker.
Taylor was the �irst to study and quantify non-value work and put emphasis on eliminating wasteful and time-consuming processes, procedures, and environmental impediments.
In a similar vein, Steve McConnell, respected author of Code Complete, states that “the general principle of software quality is that improving quality reduces development costs….” and that “the best way to improve productivity is to reduce the time reworking….”4 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch75#ch03fn4)
Lean Practices for Quality Before World War I, Taylor was thinking lean. More recently, lean has come to mean a laser focus on making every practice value-added from the customer’s perspective. Lean also means smoothing the �low from one step to another so that unproductive idle time is minimized, reducing or eliminating batch queues, substituting real-time processes, and minimizing overhead set up time. And lean means deferring production decisions until just-in-time to avoid inventory buildup and premature commitments.5 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch75#ch03fn5)
But perhaps most important for the customer-developer relationship, and also as a centerpiece of lean and agile methods, is the concept of pull. Pull means that features and functions are pulled into the product design as a consequence of customer request rather than being pushed out by a developer’s whim.6 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch75#ch03fn6) Pull is the essence of the agile Kanban practices we discuss elsewhere in this book.
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 11/27
Pull and the concept of simplicity work in complementary ways. Simplicity is the avoidance of complex interactions, but it is also the avoidance of complexity caused by incorporating design before its time— before the customer states a need or sets a priority.
W. Edwards Deming and De�ined Process Control Deming introduced very practical ideas of process control as a means to limit variations in product quality. Today, it is called de�ined process control. Deming came at quality from the point of view of the product: make the product the same way each time and make it work within limits that are acceptable to the customer. The modern poster child for de�ined process control is Six Sigma. An explanation of Six Sigma is given in the Appendix at the end of this chapter.
Deming was in�luenced by the work of the process statistician Walter A. Shewhart, who is credited with identifying the fact that processes have two variables: assignable cause and chance cause.
Assignable cause is systemic and capable of being corrected and maintained to an economical minimum. Assignable cause is what agile teams address in the retrospective review after each review and each release.
Chance cause is randomly occurring in frequency and intensity, not always present in the process, and is mitigated by establishing performance limits for a given process. Agile handles chance cause two ways:
1. Only scheduling backlog for an iteration that is about 80% of the predictable throughput, thereby leaving “white space” for absorbing chance cause
2. Scheduling empty iterations as buffers to catch the over�low of debt that accumulates due to chance cause
A project management
tip
W. Edwards Deming’s impact on agile projects
Deming focused on eliminating unsatisfactory results before they reached the customer. In agile parlance, every object must pass its unit, functional, and system test.
The modern version of Deming and Shewhart is Six Sigma. Suf�ice it to say, however, that de�ined process control is not what agile is about. Agile stresses empirical process control, meaning that circumstances in the moment are drivers for process design and control limits. That said, there are elements of Six Sigma that are adaptable to agile methods.
A project management
tip
Six Sigma is supportive of agile
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 12/27
Six Sigma provides a very effective problem solving method (de�ine, measure, analyze, improve, control [DMAIC]), which enhances the plan-do-check-act (PDCA) cycle.
The principles of DMAIC are usable without invoking other aspects of Six Sigma.
Six Sigma brings understanding of the defect opportunity space, and promotes the idea of setting limits at the boundaries of customer satisfaction.
Many defects will never be known and others are not economical to �ix. All have the potential to contribute to the customer experience.
Joseph Juran Favors the Customer More in line with agile thinking, Juran began the shift of the quality effort—away from Deming’s product focus and toward a customer focus. He is known for his advocacy of the Juran trilogy: quality improvement, planning, and control.
Juran stressed the quality concept of �itness to use. He believed that meeting a speci�ication is a necessary condition, but insuf�icient without �itness to use—that is, honoring the customer’s idea of product value and utility. In other words, features are not valuable unless they are everyday useful.
Juran’s ideas are what agile practitioners think of as favoring customer value over following a plan.
Juran de�ined �ive parameters that make up �itness to use:
1. Quality of design, a judgmental parameter with grades of goodness
2. Conformance to standards and customary expectations of the market
3. Availability, a consequence of frequency of breakdown and rapidity of repair
4. Safety in use
5. Usability in a customer’s setting
Among tools, Juran popularized the Pareto chart, which he named after Italian economist Vilfredo Pareto who recognized the phenomenon of the 80-20 rule in his study of business activity.
The Pareto chart is a histogram arranged in descending order that shows distinct problems according to how frequently each occurs. One distinct problem might be a paper jam, and it might occur 100 times a quarter. The paper jam might be the most frequently occurring problem observed.
The 80-20 rule states that most histograms show that 80 percent of all problem occurrences are linked to only 20 percent of distinctly identi�ied problems.
So, if by example, 1000 occurrences are reported, and there are 80 distinct problems among the 1000, by the 80-20 rule, 800 of every 1000 occurrences are forecast to be attributable to 16 of 80 distinct problems.
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 13/27
A project management
tip
Joseph Juran’s impact on agile methods
Juran shifted quality toward a concern for the customer and away from the goodness of the product.
The agile interpretation of Juran is to value customer satisfaction over following a plan.
The concept of �itness for use, a synonym for customer satisfaction, was promoted by Juran as a quality management concept.
The Pareto chart helps to focus agile teams on the most important features and functions.
Philip Crosby: Zero Defects and Free Quality Philip Crosby came along a generation after Deming and Juran. Working in the aerospace and defense industry, Crosby became �ixed on pushing Deming’s ideas of assignable cause to the point of zero defects. He also authored the principle of doing it right the �irst time, known as DRIFT.
Crosby is best remembered for inventing the idea that quality is free! In his formulation, the cost of conformance is just the cost of doing business the right way. Thereby, the cost of quality is free; only the cost of nonconformance is an add-on.
A project management
tip
Crosby invents the idea that quality is free!
Agile teams understand and practice the DRIFT principle.
Although zero defects is laudable, agile methods look to the customer to put a priority on �ixing defects. Some defects are not economically repairable and will not be �ixed.
Module 2—Discussion for Critical Thinking In this module, three different ideas of quality are presented: business ef�iciency, product excellence, and �itness for use. This is similar to other business models that have a similar triangle. In the spirit of triangulation, which leg of the triangle would you make longer (dominant), and which gets the short end?
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 14/27
3.3 Module 3: Sampling for Quality Validation
You can’t measure and validate everything; yet everything must have “quality”
Module 3—Objectives Make the connection between accepted methods to sample and the need for quality
Sampling is an advanced topic for readers who are interested in additional quantitative quality measures. Most experienced project managers and developers (whether traditional or agile) understand that it is impossible to validate every quality consideration—there are just too many conditions and combinations.
Economic limitations
Schedule constraints
Undiscovered or unknowable defects hidden behind obscure functionality
Operational �lukes
Therefore, testing and veri�ication is led naturally to sampling.
Sampling Sampling shifts the mind-set from descriptive statistics, in which piles of data measurements describe actual conditions, to inference statistics. That is, a shift from big data that proves a condition or hypothesis, to an inferred conclusion, supported by much less than big data.
Thus, an inference is a conclusion that is assumed to be true based on observation and analysis of similar or closely related facts. Usually, an inference is accompanied by a statement of con�idence about how certain the assumed conclusion is.
In project terms, drawing an inference is a pretty big shift from measuring every outcome. Drawing an inference introduces the idea of trust me into the validation results, thereby adding complication when communicating with executives and sponsors. Nonetheless, inference statistics are common:
Opinion polls are an everyday example of inference statistics
The opinions of only a few thousand seem to represent those of many millions within a reasonable margin of error—in other words, with relatively high con�idence
In projects, the situation is much the same as in political polls. From a relatively small number of observations, validators infer those same results on a larger population that is too numerous to evaluate. For example, when testing database systems, there may only be the opportunity to validate a few thousand records out of tens of millions. But if the validation is designed correctly, then there can be con�idence that the remaining data population will have the same quality.
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 15/27
In most practical situations, it is possible to actually quantify the con�idence of the test results. Sampling is a big subject, but there are a number of simplifying assumptions and heuristics that make sampling a practical tool for day-to-day use, as shown in Table 3.6 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch67#tab3-6) .
Picking the sample size and understanding the con�idence limits is a subject for expert analysts. Suf�ice it to say that if the population is more than ten times that of the sample drawn from the population, and the error conditions are random occurrences distributed among all objects in the population, then many simpli�ications come into play to make sampling practical for projects.
Table 3.6 Simplifying ideas for sampling
Process Limits and Benchmarks Quality gets translated by some means, procedure, and policy of the enterprise into some attribute that is measureable. Process limits, sampling, and quality are dots to be connected. You can also add work-in- process limits to the mix. Quality objectives connect the dots. Accepting that everything can’t be economically or practically measured, samples are taken. But, what’s the benchmark for acceptable quality to which the sample is compared?
A benchmark is typically not a point on some scale—it’s a range de�ined by limits. The question is begged: when do the limits get de�ined? Traditionally, they are de�ined by analysis, and thus, become up-
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 16/27
front de�ined process limits. But, up-front top-down constraints are not appealing to agile practitioners, so the idea of empirical limits has come into projects.
De�ined limits are what are found on process control charts. De�ined limits, or sometimes de�ined process control is the quality idea promoted by Deming and made famous in recent times by the Six Sigma practice. De�ined limits presume advance knowledge of how it’s supposed to be and what a defect is. Presumably the nature of a defect has been tested in some way with customers so that there’s no question that a defect is unacceptable.
However, the agile issue is obvious: the product—at least during the project development period—is not tactically stationary, so the idea of �ixed and predictable limits is an antithesis. Consequently, we are led to empirical limits.
Empirical limits have a limits-on-the-�ly sort of �lavor, and indeed that’s the case. The quality limits are developed empirically as the requirements, stories, and use cases become project realities.
Quality Measures from Users Since most of the project outcomes we have been discussing end up in a user community, it is common to ask, “How do you like them?” The answers often come back as good-better-best, and sometimes ranked on a scale of 1-10. Some caution, however, that in the absence of objective standards for numerical ranks, the ranking is often no better than good-better-best. Subjectivity, however, affords �lexibility because all of the interpretation is driven strictly by the information given to us by our customers—another example of empirical analysis rather than �it to a de�ined standard.
Empirical analysis of subjective information bene�its from something as simple as a histogram or Pareto chart. A Pareto chart is a ranking tool, as shown in Figure 3.2 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch67#�ig3-2) .
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 17/27
Figure 3.2 Histogram for quality measures
Module 3—Discussion for Critical Thinking Sampling, rather than validating every outcome, is a risk. What if the customer receives that one defective unit, or stumbles onto that one bug left in the product? How does your organization approach such risk? Are you satis�ied with empirical control limits, or does your organization demand de�ined process control like that of Six Sigma?
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 18/27
4.1 Module 1: First Principles and Requisite Conditions Strategy, tactics, and environment
Module 1—Objectives Discuss and explain the principle of strategically stationary
Discuss and explain tactically iterative and emergent as an overlay to strategy
Hybrid Operating Principle Somewhat different from the agile principles we discussed in prior chapters, this operating principle is the foundation for a hybrid of agile and traditional methods that could co-exist in the same project.
Hybrid operating principle
Agile projects are simultaneously strategically stationary and tactically iterative and emergent
Strategically stationary means that:
Whenever and wherever you look, the project has the same strategic intent and predictable business outlook—traditional methods require this, but business planners do also
Strategic intent is what is expressed by the business for the opportunity and vision of the project
A strategically predictable business outlook is the outcome that is expected of the project— typically expressed as the mission, but also found on the business scorecard
Tactically iterative and emergent means that:
Flexibility is delegated to development teams to solve issues locally
Teams are empowered to respond to the �ine details of customer demand, while respecting strategic intent in all respects
Teams are expected to evolve processes in order to be lean, ef�icient, and frictionless in development.
Business Case and Project Charter As discussed in the chapter on the business case, the place you’ll �ind the strategic intent documented and discussed is, in fact, the business case. The strategic business scorecard—the scorecard of the differentiated future— will re�lect the impact of mission complete in the sense of the project’s impact on the business.
Correspondingly, the business case is mapped to the project charter, which includes the project scorecard. The project scorecard, with a shorter timeline than the business scorecard, will nonetheless
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 19/27
re�lect the strategic intent in the form of project metrics.
Figure 4.1 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch76#�ig4-1) illustrates these points. The business case always re�lects the optimism of the business, though, at times, it is somewhat fuzzy or without de�inite boundaries. The business case expresses the mission, opportunity, vision, and narrative as we’ve discussed in prior chapters. Thence, a mapping occurs:
From the business mission, the project discerns the project drivers
From business opportunity, the key milestones are derived
From the vision of the business leadership, we envision a responsive architecture
From the narrative given by the business comes the myriad of functionalities of the outcomes
Figure 4.1 Strategic mapping
Risk Response We see in Figure 4.1 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch76#�ig4-1) that the project charter always assumes some risk to project objectives, even if such risk is not explicit in the business case or runs counter to the optimism of the business case. So the question becomes: what is the arching risk response? Answer: be tactically emergent and iterative— which are exactly those qualities of agile methods that best address risk.
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 20/27
We de�ine an environment that can provide those qualities as an environment with these attributes:
Supportive of small teams with internal redundancy
Locally manageable at the team level—perhaps even rotating the management among team members
Supportive of proven protocols and lean practices
Supportive of instinctive actions, lean principles, and frictionless interplay among team members
Overlay Strategy with Tactics The upshot of a tactically emergent and iterative risk response is that we may �ind that actions in the moment are a seeming variance to the strategy—that is, the project plan. But, over time, we may take other actions that converge on the strategy. In effect, we overlay the strategy with tactical expediency at the moment.
Figure 4.2 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch76#�ig4-2) illustrates this idea of the interplay of tactics with strategy. What are these actions?
For the agile work stream, the most common tactical move is adjustment of the iteration backlog, the repository of stories or use cases that are the gist of requirements in the agile methodology.
And why are these actions taken?
Most commonly, because the customer/user sees a better way to achieve a functionality; they see an unnecessary story that can be dropped; or they have been given information about a requirement, heretofore unidenti�ied, that should be added to the backlog.
Another form of tactical maneuvering is the result of technical or functional debt—those small items which have been left behind on a punch list to be completed before the project ends. This debt may cause small changes which may seem to lead off the strategy, but more often they help to converge to the strategic intent.
Although this discussion is cast in the context of risk, the same applies as if we were talking about the dynamics of backlog management. No matter how one story or requirement might seem to lead us off course, in the long run, if we are faithful to the strategic intent, we will �ind our way back by subsequent adjustments in the backlog.
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 21/27
Figure 4.2 Overlay of strategy with tactics
Module 1—Discussion for Critical Thinking The two big ideas in this module are:
1. In the hybrid situation opposite ideas co-exist: to be stationary and to be emergent
2. No matter the strategy, there will always be tactical moves that are instinctive to the situation, as well as responsive to the customer demands on the backlog
What issues do you see in supporting these ideas as leader of the project of�ice?
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 22/27
4.2 Module 2: The Black Box, Interfaces, and Connectivity Yours, mine, and ours
Module 2—Objectives Discuss and explain the importance of open and stationary interfaces
Discuss and explain how the black box can still be emergent
Familiarize readers with extending these ideas to work stream and portfolios
The Black Box The black box is a metaphor for encapsulation in which the internal structure and details of a unit of architecture are hidden and unknown to the outside world. The only way to employ a black box is to communicate through its interface.
Its generality is useful across a broad range of system design: black boxes for mechanical devices and structure; black boxes for software units; and even black boxes for whole work streams or projects.
Architecture is Mapped The �irst use of the black box is to map or de�ine the architecture of the project outcome—whether service or product—as a number of black boxes with some kind of relationship between them. In many cases coming up with a good mapping is more art than science, and strikingly the mapping often re�lects the organizational biases of the enterprise.
Somewhat counter to the agile principle that suggests the best architecture emerges, we hold that the best architecture is the product of fore-thought. It is �irst an outcome of strategic intent; it is conceived top-down, only then to be re�ined with bottom-up mapping to a level of detail suf�icient to put a project charter in place.
Strategic Architecture Is the Product of Forethought
Partition by subsystems for near total isolation and independence (stand-alone model)
Partition by layers for ef�icient distribution of functions (Internet model)
Partition by application on a common foundation for application independence (smart phone model)
So, is the agile principle about good emergent architecture a nonstarter? No, indeed at a level lower than the strategic architecture, the tactical architecture can be expected to emerge and be responsive
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 23/27
according to the �ine detail of customer demand. Nonetheless, in the same way the point was made earlier, even tactical departures from the main architecture are made consistent with the larger architecture as respect for strategic intent.
Mapping continues from the business case to the project charter:
Vision and narrative map to top-level architecture and functionality, respectively
Architecture and functionality are allocated to work streams
The labor of work streams is done according to a local choice of methodology
It’s that latter idea that leads directly to a hybrid methodology to respond to the business case and project charter—provided the necessary conditions of our operating principle are in place, as we discussed.
Encapsulated Scope and Methodology Encapsulation is a powerful idea that enables these possibilities for a hybrid agile-traditional enterprise project:
Methodologies—agile and traditional—can be encapsulated and thus made noninterfering, but yet able to communicate through interfaces
Work streams can be encapsulated, communicating with other work streams at certain milestones and interfaces
Architecture components can be encapsulated to the interface level
Projects can be encapsulated within a portfolio, communicating with other projects at certain milestones and interfaces.
Two big encapsulation
ideas
1. Interfaces are all important for being able to communicate and interconnect from one encapsulated entity to another
2. Milestone planning is a necessary scheduling tool for ensuring the encapsulated functionality is ready for integration with other encapsulated entities
All of these encapsulation possibilities can be mapped to the black box paradigm given in Figure 4.3 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch80#�ig4-3) . The �irst thing noticed, and the most prominent visual, is that all details are hidden from the nonowners or teams not working in a speci�ic box. With this seeming privacy, local decisions, local processes, and local issues are contained and known only to a small cadre of informed individuals.
In that regard, we see immediately that encapsulated black boxes can be a bit territorial:
You have yours; I have mine
We each have a piece of the architecture
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 24/27
Although the internal details can vary and are largely my business and not yours, the open interface cannot change without engaging with change management
Figure 4.3 Encapsulated scope
The open side of the interface must be stationary and supportive of strategic intent
Thus, each black box team is compelled to stand behind the open side of the interface. To not do so breaks a pledge to the rest of the project to remain faithful to strategic intent.
Tactical Emergence and Iteration Other than holding the interface to the outside world open and stationary, the development team is otherwise free to design and develop the internal structure of the black box according to the backlog assigned to the black box.
First, let’s be sure we understand that when the details of the black box are made known to the team working on that entity, we then have a white box. For those that see the black box transparently, they are working on the white box solution.
Second, the most important rule is given thus:
Rule for tactical emergence and
iteration
The team is free to iterate and take advantage of an emergent backlog, and then refactor the white box solution, once the team has committed to the open and stationary interface.
Once the interface is de�ined, the team cannot then modify its functionality or attributes on the open side without coordination with every other black box team.
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 25/27
The white box
For every black box, there is a white box
The white box is simply the description or speci�ication of the internal structure and actions of the black box
The white box is the black box with the encapsulation stripped away
The white box is known only to the team that is responsible for the black box
From the project planning, when does the commitment to the interface functionality and other attributes occur? Answer: during the architecture de�inition and decomposition of the vision and narrative into functional architectural units.
So, given that the open side of the interfaces has been committed to by the various teams working on the black box, we turn to the idea that each interface of an active device, process, or component is itself active and is a function onto itself. Thus, in the context of integration of and communication between black boxes:
Units communicate by addressing themselves to the interface
Units pass parameter data or otherwise adhere to the interface structural demand
Units expect to receive data in return, or to have the black box act in some functional manner
Network of Boxes It remains, then, to consider how we go about communicating between and among the black boxes. There are three broad choices:
1. Dedicated point-to-point connections2 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch93#ch04fn2)
2. Shared connections over some type of network
3. Connections organized into, and governed by, rules of hierarchy
Certainly since the 1970s when layered protocols and the Ethernet topology came into general use, the network solution has been the topology of choice. By choosing a network as the means to communicate among black boxes, we must consider how to address ourselves to the interfaces. Essentially, we do these things:
Create an open, active network as part of the product, service, or program architecture
Apply layered protocols to achieve ubiquitous connectivity
Arrange the black boxes as nodes on the network (function at node architecture)
Apply application protocols, like �ile transfer protocols, as an overlay to the connectivity protocols
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 26/27
Network Attributes There are several attributes of the network that connects all the black boxes into a system, as shown in Figure 4.4 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch80#�ig4-4) :
Each node on the network is the interface to a black box, either a backbone bus topology3 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch93#ch04fn3) or somewhat like a mesh4 (http://content.thuzelearning.com/books/Goodpasture.7968.17/sections/ch93#ch04fn4) of functionality and physical units
The interface on the network side is open and stationary once the architecture has been set and agreed upon
Figure 4.4 Network of boxes
Protocols on the network are open and stationary, and in accord with the strategic intent
Connectivity is suf�iciently responsive that the intended purpose of the black box is not compromised by an under-performing network
The network is extendable to remote or virtual units
Network Operating System If the network is active, and not a sneaker net, there is, somewhere in the foundation of the system, a network manager which executes a network operating system (NOS). As in all operating systems, many services could be provided that depend on the environment of the product, system, project program, or unit:
Security services—to include authorization and authentication for the black box to be on the network, and to authenticate any agents that may operate on the network
Management services—to include load balancing, address maintenance, and error control
1/21/2020 Print
https://content.ashford.edu/print/Goodpasture.7968.17?sections=ch55,ch60,ch67,ch76,ch80&content=content&clientToken=37e7d055-023f-0228-c… 27/27
Reporting services—to include availability reports, error performance, user population and usage, and other management metrics
Network Extension Now applying the encapsulation concepts discussed above, the network is extendable to both program entities—like work streams and projects—and to various objects, both hardware and software. The programmatic extensions can be local or remote, real or virtual, and can even involve sneaker net between the program units. For successful extension to program units, it is necessary to coordinate and synchronize milestone planning, a subject we will take up in the next module.
Of course, one programmatic network idea, which can also be embedded in the project outcome—that is, the project or service—is work�low. There are many work�low solutions, to include smart service oriented architecture solutions as one variant that involves middle-layer functionalities and applications.
The extension of the network among objects, both hardware and software, is a familiar concept to most project teams. There are a myriad of materials on layered protocols and networking ideas at the physical level, so we will not extend this discussion further.
Module 2—Discussion for Critical Thinking If your project has a large hardware component such that integration of hardware and software is a major consideration, would you think the ideas in this section are still applicable, and ef�iciently applicable, as compared to other ways to go about integrating functionality?
