Efficient product quality design

---

I'm borrowing shamelessly from an essay by D. Miessler about efficiency in security design for user products by generalizing to the quality -- in the broadest sense -- of a product. That is to say: quality as evaluated by a user (quality is in the eye of the beholder, as it were)

And, I might observe that the principle explained below corresponds closely with the Agile idea of "enough, but not more than enough"

The Efficient Quality Principle

1. The quality baseline of an offering or system faces continuous downward pressure [i.e. less quality demanded] coming from customer excitement about, or reliance on, the offering in question.

2. The baseline for an offering’s quality will be set at the point at which people will not stop using the offering because it’s quality is not pristine.

3. The better the offering is, the lower the quality baseline can be without losing customers.

In other words, the way we know something has the “right” amount of quality built in is when people just keep using it. People use these offerings or systems because the value they provide massively outweighs the quality lapses  in user's minds.

The moment enough people stop using something due to quality being too bad, the baseline goes up. And not before.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

quality Assurance is free; QC is not

---

Philip Crosby is credited with the idea that "Quality is Free", and he made some money on the book by the same title ... still available from e-book sellers.

When I first heard that phrase -- around the time Crosby's book came out -- my thought was: If so, what is that line item in my budgeted WBS for quality planning and QC? It's not $0 for sure. So how is "quality free". Admittedly, TQM was everywhere at that same time (*)

Actually, the idea here is quality Assurance vs. quality control. The former is "free", perhaps even a profit center; the latter is always a cost, sometimes bolted on at the end.

Characterizing QA as a profit center has these business ideas embedded:

• There is a direct cost for some QA activities, to be sure, but other aspects of QA as an assurance strategy is a mindset that informs PM planning and execution
• There are attributable savings from QA -- taken holistically -- in the form of cost, schedule, and scope assurance that expectations will be met.

QA as a mindset

Perhaps QA should be written qA to emphasize that it's assurance we're after, in the context of "doing good; avoiding evil" of course!

The PM is always seeking  mission assurance. 

And the mission? 

The PM's mission is to meet sponsor expectations by returning a quality product or service in return for the sponsor's resources invested with the PM, taking calculated risks to do so. 

It's a balance sheet idea: sponsor investment balanced by resource transference into product + the baseline cost of risk (mostly the baseline cost of planned mitigation)

Two ideas inform "Assurance"

There are two ideas here to keep in mind at the same time: 

The first is that quality has these actionable artifacts :

• Measurables that validate environmentally fit; functionally, effectively, and efficiently operable; safe and secure (**)
• Value attained that is a multiple of cost (the whole is worth more than the parts; utility is >1)
• Mission objectives of timeliness and scope that are achieved

And the second is that "assurance" embodies some ideas from risk management and some ideas from sampling theory

• Schedule assurance by smart use (read: PM management) of slack to protect the critical path (some ideas on how to do this are embodied in "Critical Chain Theory" formulated by Goldratt
  
• Cost-Value assurance by built-in reserves and attention to value earned by a dollar spent
  
• Performance-to-scope sampling in real-time -- at a sampling frequency that's "inside the performance (work-package) timeline" -- to trap issues and correct deficiencies early when they cost the least, and make agile tactical data-driven decisions that assure strategic accomplishment.

Assurance is free:

Protect the critical path: manage slack by buffering for uncertainties at the critical milestones; have a bias toward "earliest start" rather than waiting; resource the CP before others
Mitigate uncertainties, in part, by allocating budget reserves to underwrite probabilistic event-impacts.
Stay ahead of unfolding events by sampling, measuring, and analyzing frequently enough to be inside the work-package timeline.

------------------- 

(*) Total Quality Management was a movement and a concept that quality ideas and expectations had to be well understood throughout the organization. That is: there had to be a consistent "deployment" from executive to doer of what was expected and also of what was to be done.

TQM audits were conducted to verify deployment (I was an auditor for a year or so).
After a while, the TQM moniker and a lot of the bureaucratic overhead faded away, but the overall concept is valid: everyone should think and do quality practices in a (culturally) consistent manner.

(**) There are a lot of ideas embedded in "effectiveness". Some go to reliable, predictable, non-chaotic performance; high availability achieved by long mean-time-to-fail and quick mean-time-to-repair; long term support after sale or delivery. 

Other ideas of effectiveness are financial: cost-effectiveness which means "good" utility for operating dollars.

---

Like this blog? You'll like my books also! Buy them at any online book retailer!

The V&V thing ....

---

Have you thought much about this? Two of the conceptual conundrums of the hybrid agile-conventional methodology are:

1. How do you verify that which is incomplete and
2. How do you validate the efficacy of that which is yet to be conceived?

Verification and validation (V-and-V) are traditionally held to be very important project practices that to some may be difficult to map directly into the Agile domain, to wit:

• Validation: Each requirement is validated for it’s business usefulness, in effect its efficacy toward project objectives.
  Validation is usually not later than the last step in gathering and organizing requirements.
  (Of course, in Agile methods, it's allowed to change the requirements book on the fly according to customer feedback about interim results, so there may not be a well defined "last step".)
  
  
• Verification: When development (construction) is complete, and when integration of all constructed requirements is complete, the roll is called to ensure that every validated requirement is present and accounted for. (See above re the changing book on requirements)
  

Validation
Placed into an Agile context, validation is applied both to the project backlog and to the iteration backlog, since changes are anticipated to occur.

Validation is typically first applied at the story or use case level, validating with conversation among the interested and sponsoring parties that the functionality proposed is valid for the purpose.

 

One can imagine validating against external rules and regulations, perhaps internal standards, and of course validating against the business case.

Verification
Verification is generally a practice at any level of construction and itegration, verifying that which was approved and prioritized in the backlog(s) is, in fact, found in outcomes. And, if not, any differences are logged as technical or functional debt.

Depending on the project paradigm, V-and-V can be carried into integration tests and customer acceptance tests, again testing against various benchmarks and standards for validity, and verifying that everything delivered at the iteration level got integrated at the deliverable product level.

Is this an issue?

Is importing a really old idea of V&V into the Agile domain an issue? It could be. 

V&V is systematic accountability, and many resist being held accountable to a planned narrative. 

 

Accountability requires estimating as a prerequisite, and we know where that debate is going (Disclosure: I'm an estimator!)

The remedy: change the name; press on. Agilists have any number of alternate names for V&V, but at the end of the day, being accountable for efficacy and completeness is part and parcel to competent participation in the project domain.

---

Buy them at any online book retailer!

Tradeoff vs corruption

---

How do you know when you've crossed the line from making trade-offs to fomenting corruption?

That's not a question asked very often in the is space, and not usually asked in polite company.

Nonetheless, it happens.

And, what is "it"?

"It" is making decisions about doing 'this' or 'that' that are a violation of accepted norms wherein the outcomes have an inappropriate personal benefit, rather than a decision among legitimate alternatives where the personal benefit is non-existent or indifferent to the outcome. 

 

Corrupting decisions take many forms: There may be a financial benefit, like a stock option that gets out of negative territory; there may be a job benefit insofar as the decision comports with the business narrative; or there could be a 'traitor in our midst' problem.

Sovereignty

They say that in a republican democracy (small 'r', small 'd') that the people are sovereign and that political power is simply a delegation from the sovereign -- such a delegation intended to benefit the sovereign (the people at large). Political corruption is then using that gifted and delegated power to work against the interests of the sovereign to one's own benefit. 

How does that work in a project? Who is the sovereign? What is corruption in the project sense?

You could say the owners and shareholders are sovereign. You could say that customers are sovereign and that all business value is a delegation from customers. 

• To work against the customer's interest (or owners and share holders) with false claims and hidden quality shortcomings is committing corruption. 
• To work for a compromise that is beneficial to customers and business alike is making trade-offs.

 

Enough!

---

Buy them at any online book retailer!

Feeling the pressure

---

" [The concern my some is] that with all good intentions, some project managers might start cutting corners. It's easily done. Don't be fooled by the trappings. ....

This sort of success comes with a lot of pressure. There are deadlines, penalties, [finances], and [executive changes]. [PMs] are stuck in the middle. Priorities can become murky.

It would be natural for some to feel the pressure and choose speed over quality" 

Louise Penny, novelist

I'm sure you can tell from the brackets that I took the excerpt from one of Ms Penny's crime novels, but nonetheless her character's words probably ring all too true to many readers. One wonders if she is writing about the false engineering found in the diesel car industry or the calamitous decision-making in the aviation industry of late.

Risk assessment and confirmation bias

I put it down to executive-level risk assessments. Looking the other way or deliberately hiding is always the path to trouble. There is a political adage that might apply: the coverup is always worse than the underlying transgression.

Even if that is understood, the pressure of the moment is often telling. One sign: the stressed PM is looking everywhere for confirmation .... and making themselves susceptible to confirmation bias. It is likely they will hear what they want to hear.

It's like a bad email

Most people handle email (and social media) poorly, sending email (or media) when they are mad or when they think no one else will find out. Never make an important decision when mad, and always assume what you write will appear on the front page.

The same is for the high-risk assessments. Unless life itself hangs in the balance, there is time to consider the consequences more thoughtfully. Take that time.

---

Buy them at any online book retailer!

F.W. Taylor: should we care?

---

How many project managers are still laboring with the aftermath of Fredrick Winslow Taylor, more popularly known as F.W. Taylor?

Taylor Who?
You might ask: Who was Taylor?
Good question
F.W. Taylor was one of the first to study business systematically -- an original "operations research" guy. He brought 'Taylorism" into the business culture in the years leading up to World War I. By 1915, his ideas were considered quite advanced.

But, here's news you can use: much of what he divined is still around and affecting projects! Read on ....

Taylorism, so called
Taylor set about to invent "scientific management", a revolutionary movement that proposed the reduction of waste through the careful study of work.

Taylor came up with the original 'time-and-motion' studies, perhaps one of the first attacks on non-value work.

Peter Drucker, a management guru par excellence who coined the term 'knowledge worker', has ranked Taylor, along with Darwin and Freud, as one of the seminal thinkers of modern times. ["Frederick Taylor, Early Century Management Consultant", The Wall Street Journal Bookshelf, June 13, 1997 pg. A1].

Ooops, what about Agile?
The essence of Taylorism is an antithesis to agile principles but nonetheless instructive.

Counter to what we know today, Taylor believed that workers are not capable of understanding the underlying principles and science of their work; they need to be instructed step-by-step what to do and how to do it; and nothing is left to chance or decision. Rigid enforcement is required.

Managers have a role
However off-base that idea, Taylor was close to the mark with his doctrine about value-adding work. According to Taylor, managers must accept that they have responsibilities to design efficient and effective process and procedures.

Waste must be eliminated!
Every action requires definition and a means to measure results.

OMG! Not a popular guy
Taylor was not well like by workers and it's not hard to see why. But Taylor's ideas and practises brought great efficiencies and profitability while providing customers with products of predictability of quality.

Do it once, right
I like what Steve McConnell says about quality and the software relationship. Building off Taylor's ideas of 'do it once right', though he does not mention Mr. Taylor, McConnell, author of the respected book "Code Complete" states the " general principle of software quality is .. that improving quality reduces development costs .... the best way to improve productivity is to reduce the time reworking..."

Beck gets it right
Kent Beck, writing in his book "Extreme Programming Explained - Second Edition" has a pretty strong idea about the legacy of Taylorism and its lingering effects on the knowledge industry.

He says of Taylor that he brought a social structure we continue to unconsciously apply, and warns against the message that Taylorism implies: workers are interchangeable; workers only work hard enough to not be noticed; quality is an external responsibility

---

Buy them at any online book retailer!

Agile and Plan-Do-Check-Act

---

This is not as stuffy as it sounds:

Plan-Do Check-Act --

• Plan-do-check-act (PDCA) envisions planning--just enough, and gasp! perhaps an estimate as well--for what is to be done, then doing it—that is the plan-do.
• Next, measure results—measuring is the check activity (did someone say: accountability?)—and
• Then act on the measurement results. To act in the PDCA sense means to reflect upon lessons learned and provide feedback for corrective actions to the next iteration of the plan.

Seems intuitive, of course, but in its written form, perhaps only 70 years old (only!) W. Edwards Deming gets most of the credit. Deming--working in Japan and else where in the mid-20th century--introduced very practical ideas of process control as a means to limit variations in product quality.

And, who's not all about product quality?

Deming was a product guy; he came at product 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. But, developing software is not a repetitive cycle (make it the same way each time) although processes are repetitive and they can be somewhat the same quality each time.

The modern poster child for defined process control is Six Sigma, but let's not go there; let's go to Agile

Agile Thinking

Ken Schwaber—a leading SCRUM methodologist—objecting to defined process control, puts it this way, “[defined process control] is based on processes that work only because their degree of imprecision is acceptable… When defined process control cannot be achieved because of the complexity of the intermediate activities; something called empirical process control has to be employed.”

In Schwaber’s view, software is too complex to expect defects to be contained within predefined error limits. Empirical control is the answer; empirical control is derived from observed facts, adapted to the situation, and not determined by preplanned limits from previous projects.

Edwards Deming's impact on agile projects
A project management tip: Deming introduced the PDCA cycle, which is can be wholly embraced by agile teams
• The cycle really applies to all agile iterations. The plan-do is equivalent to the planning session followed by development, test, and integration.
• Especially relevant is the check-act that provides measurement and feedback for continuous improvement.
• Deming focused on eliminating unsatisfactory results before they reached the customer. In agile parlance, every object must pass its unit, functional, and system test, and be acceptable to the customer's idea of quality in the large sense: function, accuracy, available, and appealing

Read my contribution to the Flashblog

Confucius simplified

---

Some of you read my recent posting on data quality and integrity, the discussion of which is anchored by a statement attributed to Confucius

Fair enough

But, the "publish" button was hardly pushed when this rolls in from herdingcats. I call it Confucius simplified:

If you make [a] serious allegation or claim and don't have serious evidence, no one is going to take you seriously

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Information quality; information integrity

---

In the early 21st century when the 4th edition to the PMBOK was being designed for publication in the first decade, there was debate about adding "data quality" to Chapter 11, Risk Management. The idea behind data quality being to evaluate risk in the presence of not only uncertainty, but also to look at the impact of making risk-informed decisions in the presence of lousy data.

I'm extending "data" to "information" for this discussion. The working difference being that information is multiple data elements integrated, and that data integrated data set integrated with context.

And, also think of information in the large sense. With all that, I offer this bit of insight from Confucius:

“If names are not correct then statements do not accord with facts.

And when statements and facts do not accord, then business cannot be properly executed.
When business is not properly executed, order and harmony do not flourish.
When order and harmony do not flourish, then justice becomes arbitrary.
And when justice becomes arbitrary, people do not know how to move hand or foot.

Hence whatever a wise man states he can always define, and what he so defines he can always carry into practice; for the wise man will on no account have anything remiss in his definitions.’

Confucius, Lúnyŭ† (Analects), xiii:3 (Chinese, early fifth century BC)2”

“Empires of the Word.”(*)
 Nicholas Ostler 

My favorite
So, Confucius might have been a good member of the Chapter 11 team, but for his age. I think he said it all about data quality, data integrity, and indeed business integrity in the largest sense of the word when he said:

"And when statements and facts do not accord, then business cannot be properly executed."

_______________________

(*) If you love language or history, then "Empires of the Word" is a good read on the history of language

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Flocking to quality

---

Ever wonder how you know you're impressing people; doing a good job; producing a good project outcome?

Watch the flocks

"People know quality and flock to it"

David brooks

No flocks? Hmmm, that sucks. Assessments are needed; perhaps even root-cause analysis, etc
Here's the important point:

If people are not flocking, it's not their fault. If they don't get it, it's your job to fix it so they do. The heavy lift is yours!

---

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Quality drivers -- four big ideas

---

On slideshare, you can check out a paper I wrote on four big ideas that drive quality, particularly in agile methods.  Here are the points, summarized for the blog:

1. The Focus should be on Customers: Perhaps this is an obvious idea that is on everybody's list, but actually it is the Deming v Juran debate.

• Deming was a product guy--make it right, and make it the right way.  
• Juran was a customer guy--make it fit customer need.  

 Of course, there really shouldn't be a debate; Deming and Juran were both right, but in the end, customers, in the broad sense of the word, pay all the bills!  Customers can only be the ultimate focus because without customer buy-in to the quality of the outcomes, all is for naught.
2. Continuous improvement is a project imperative: There can be no substitute for a learning organization, and that includes project, even short ones.  Every team, group, and enterprise should be a unit in transformation, continually improving performance, capability, and capacity. Plan-do-check-act is nearly sixty years old, but actually it's still relevant, especially the check-act thing.  Take a moment to reflect on what you've done or are going--that's check; and then act to apply learning for improvement.

3. Total participation involves everyone: There is a place for the loner, the eccentric, and the individual contributor, but in general, the best outcomes involve the synergy of everyone contributing.  This may be a little harder with virtual settings, but it borrows a page from the wisdom of the crowds as well as recognizing that every individual can make a contribution, so every individual should make a contribution toward improvement.

4. Societal networking is flattening: Social networking may sound like a new idea, but it's been around since the onset of human groups; just the technology has changed.  What is new, or at least revisited, is the way social networking has flattened the hierarchy.  Now, there's no excuse for misunderstanding the spirit and the letter of the customer's needs: just ask!

Wav 4 four big ideas that drive agile quality

View more documents from John Goodpasture.

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Process: Reflection, refinement, tuning,

---

Any process that does not have provisions for its own refinement will eventually fail or be abandoned*

- W. R. Corcoran

Corcoran is probably correct --- but how would we know? There are a lot of processes out there, many have been around forever, many oldies still effective. But, I take his point: change, adapt, or fade away to either obsolescence or irrelevance.

Of course, naturally changing demographics takes care of a lot of this somewhat automatically. New organizations, people new to organizations, and young people without the baggage of experience all tend to reinvent.

And, why not? The wheels of today are far superior to the wheels of ancient times. Can you imagine taking your chariot in to have the wheels balanced? Not likely. Perhaps the wheel does need reinvention from time to time.

Of course, we digress: reinvention is not exactly refinement, which suggests tuning on the margins. Refinement is more about lessons learned, feedback, TQM metrics, and the like, all aimed at weeding out the ineffective.

Of course, if you are locked into some kind of maturity model or ISO certification, refinement is no small matter, as changes must find their way into documentation, training, deployment, and so on.

Nonetheless, I get it: change, adapt, or fade away to either obsolescence or irrelevance.

---

Quoted by Glen Alleman from "The Phoenix Handbook: The Ultimate Event Evaluation Manual for Finding Profit Improvement in Adverse Events, Nuclear Safety Review Concepts, 19 October 1997."



---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Our man Juran

---

Agile people may have had their first real quality thinker and champion almost 70 years ago with Joseph Juran (should I say three score and 10 years ago?)

More in line with Agile thinking, Juran began the quality shift away from W. Edwards Deming’s product focus and toward a customer focus. He -- Juran -- is known for his advocacy of the Juran trilogy:

• Quality improvement,
• Planning, and
• Control.

But, here comes the Agile part:
Juran stressed the quality concept of fitness for use. He believed that meeting a specification is a necessary condition, but insufficient without fitness to use—that is, honoring the customer’s idea of product value and utility. In a word, 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 defined five parameters that make up fitness to use:

1. Quality of design, a judgmental parameter with grades of goodness
2. Conformance to standards and customary expectations of the market
3. Safety in use
4. Usability in a customer’s setting
5. Availability, a consequence of frequency of breakdown and rapidity of  repair

Among tools, Juran popularized the Pareto chart, which he named after Italian economist Vilfredo Pareto. Pareto recognized the phenomenon of the 80-20 rule in his study of business activity, though the chart etc came from Juran

 

 

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Customer success

---

Is there anything more to say than this about making your customer successful?

If the customer is not satisfied, he may not want to pay for our efforts. If the customer is not successful, he may not be able to pay. If he is not more successful than he al¬ready was, why should he pay?

Niels Malotaux

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

About quality

---

Everybody writes about quality these days. Agile is all about quality (in the sense of satisfying customer need). Manufacturing is all about quality (certainly in the sense of price and value), and we hear constantly about environmental quality (the trade between jobs and life quality, the latest being in the U.S. the "war on coal"; See also: Beijing air pollution).

So, it's no surprise that the early Navy nuclear program had quality at its core (no pun intended) since a quality issue would put the "diesel admirals" in charge. Thus, Admiral Rickover's words (never one to back off a fight with his fellow admirals), as quoted on Critical Uncertainties.

Quality must be considered as embracing all factors which contribute to reliable and safe operation. What is needed is an atmosphere, a subtle attitude, an uncompromising insistence on excellence, as well as a healthy pessimism in technical matters, a pessimism which offsets the normal human tendency to expect that everything will come out right and that no accident can be foreseen — and forestalled — before it happens

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

The Quality --- Agile thing

---

"... the definition of “quality” is always political and emotional, because it always involves a series of decisions about whose opinions count, and how much they count relative to one another."

Gerald M. Weinberg

Writing in "Crosstalk", July/August 2014:

"Agile and the Definition of Quality"

Weinberg's article in "Crosstalk" is very incisive. Of course it should be. He's been around software and writing about software for several decades, Agile being only the latest to catch his interest.

Here's a few wits about quality from Weinberg -- stuff to think about

“Zero defects is high quality”
-to a user such as a surgeon whose work would be disturbed by those defects
-to a manager who would be criticized for those defects

 “Lots of features is high quality”

-to users whose work can use those features—if they  know about them

-to marketers who believe that features sell products.

“Elegant coding is high quality”
-to developers who place a high value on the opinions of their peers
-to professors of computer science who enjoy elegance

“High performance is high quality”

-to users whose work taxes the capacity of their machines

-to salespeople who have to submit their products 

to benchmarks

“Low development cost is high quality”
-to customers who wish to buy thousands of copies of  the software
-to project managers who are on tight budgets

“Rapid development is high quality”

-to users whose work is waiting for the software

-to marketers who want to colonize a market before the competitors can get in

“User-friendliness is high quality”
-to users who spend 8 hours a day sitting in front of a screen using the software
-to users who can’t remember interface details from one use to the next

---

Bookmark this on Delicious

Read in the library at Square Peg Consulting about these books I've written
Buy them at any online book retailer!

Read my contribution to the Flashblog

Stage Gates and Agile

---

One of my Agile Project Management students asked me about stage gates and agile. My first response was this:

• Agile is not a gated methodology, primarily because scope is viewed as emergent, and thus the idea of pre-determined gate criteria is inconsistent with progressive elaboration and emergence.
• Agile does embrace structured releases; you could put a criteria around a release and use it as a gate for scope to be delivered
• Re budget: agile is effectively 'zero base' at every release, if not at every iteration. You can call the question at these points of demarcation.
  
• Agile is a "best value" methodology, meaning: deliver the 'most' and 'best' that the budget will allow, wherein 'most' and 'best' is a value judgement of the customer/user.
• Of course, every agile project should begin with a business case which morphs into a project charter. Thus, the epic narrative (the vision narrative) is told first in the business case, and retold in more project jargon in the charter. Thence, there are planning sessions to get the general scope and subordinate narratives so that an idea of best value can be formed.

But, DSDM is one agile method, among others, that is more oriented to a gated process than say, SCRUM. To see how this could work, take a look at this presentation:

And, you can follow-up with this:

Dynamic Systems Development, DSDM from John Goodpasture

 

---

Bookmark this on Delicious

SCRUM + Nine

---

In a paper supported by Microsoft and NC State University, we learn about SCRUM practices by three teams, and about nine practices that these teams applied as agumentation to SCRUM. The great thing about this paper is that it is well supported by metrics and a mountain of cited references, so not as "populist" as others

To begin, the Microsoft authors describe SCRUM this way:

The Scrum methodology is an agile software development process that works as a project management wrapper around existing engineering practices to iteratively and incrementally develop software.

I like that description: "project management wrapper", since, unlike XP and other agile methodologies, SCRUM is almost exclusively a set of loosely coupled PM practices.

That said, we read on to learn about three teams, A, B, and C. We learn that story points live! Microsoftees like them (and so does Jeff Sutherland):

The Microsoft teams felt the use of Planning Poker enabled their team to have relatively low estimation error from the beginning of the project. Figure 1 [below] depicts the estimation error for Team A (the middle line) relative to the cone of uncertainty (the outer lines). The cone of uncertainty is a concept introduced by [Barry] Boehm and made prominent more recently by [Steve] McConnell  based upon the idea that uncertainty decreases significantly as one obtains new knowledge as the project progresses.Team A’s estimation accuracy was relatively low starting from the first iteration. The team attributes their accuracy to the use of the Planning Poker practice.

And, what about the other 8 practices? The ones cited are:

1. Continuous integration (CI) with Visual Studio (a Microsoft product)
2. Unit TDD using using the NUnit or JUnit frameworks
3. Quality gates, defined as 1 or 0 on predefined 'done' criteria
4. Source control, again with Visual Studio
5. Code coverage by test scripts followed the Microsoft Engineering Excellence recommendation of having 80% unit test coverage
6. Peer reviews
7. Static analysis of team metrics
8. Documentation in XML

And what conclusion is drawn?

The three teams were compared to a benchmark, 10 defects/line of code. Two of the three teams did substantially better than the benchmark (2 and 5) and one team did substantially worse (21). The latter team is reported (in the paper) to have scrimped on testing. Thus, we get this wise conclusion:

These results further back up our assertion on the importance of the engineering practices followed with Scrum (in this case more extensive testing) rather than the Scrum process itself.

Wow! That's a biggie: design-development-test practices matter more than the PM wrapper! We should all bear this in mind as we go about debating wrappers.

And, one more, about representation and availability in another situation:

...our results are only valid in the context of these three teams and the results may not generalize beyond these three teams.

And, last, what about errors in cause and effect?

There could have been factors regarding expertise in the code base, which could have also contributed to these results. But considering the magnitude of improvement 250%, there would still have to be an improvement associated with Scrum even after taking into account any improvement due to experience acquisition.

And, need I mention this gem?

---

Bookmark this on Delicious

A quality model

I was skimming through a blog about safety and security in software systems when my attention was drawn to a reference to the ISO/IEC 9126 quality model.

The interesting thing about this model is that it's ubiquitous: there's nothing inherently software-centric about the model, though it was written with software in mind.  In fact, it's a pretty good checklist for anyone (and everyone) interested in delivering good quality to their beneficiaries.

Have a look:

Functionality - A set of attributes that bear on the existence of a set of functions and their specified properties. The functions are those that satisfy stated or implied needs.

• Suitability
• Accuracy
• Interoperability
• Security
• Functionality Compliance

Reliability - A set of attributes that bear on the capability of software to maintain its level of performance under stated conditions for a stated period of time.

• Maturity
• Fault Tolerance
• Recoverability
• Reliability Compliance

Usability - A set of attributes that bear on the effort needed for use, and on the individual assessment of such use, by a stated or implied set of users.

• Understandability
• Learnability
• Operability
• Attractiveness
• Usability Compliance

Efficiency - A set of attributes that bear on the relationship between the level of performance of the software and the amount of resources used, under stated conditions.

• Time Behaviour
• Resource Utilisation
• Efficiency Compliance

Maintainability - A set of attributes that bear on the effort needed to make specified modifications.

• Analyzability
• Changeability
• Stability
• Testability
• Maintainability Compliance

Portability - A set of attributes that bear on the ability of software to be transferred from one environment to another.

• Adaptability
• Installability
• Co-Existence
• Replaceability
• Portability Compliance

 Bookmark this on Delicious  

Are you on LinkedIn?    Share this article with your network by clicking on the link.

A quality correction

I wrote a blog on quality last month, and in the course of doing so, I made a quality blunder, herein corrected:

The reference to the blog that triggered my thought was incorrect. So, if you were trying to find it, take a look at Luis Coehlo's blog at "ah-ha-moments.com"

 Bookmark this on Delicious