Risk #4 is the about quality from the project management perspective — going a little deeper from the “Seven Risks in Software Development”.

Kent Beck (with Cynthia Andres) in “Extreme Programming Explained (Embrace Change)” [2nd edition] states

“This model (managing projects using speed, quality, and price) doesn’t work well in practice.  Time and costs are generally set outside by the project.  That leaves quality as the only variable you can manipulate.  Lowering the quality of your work doesn’t eliminate work, it just shifts it later so delays are not clearly your responsibility  … The variable left out of this model is scope.”  (page 92)

From this model Beck describes and also thinking about the Project Management iron-triangle of scope, schedule, and budget, there are 4 levers:

  1. Scope
  2. Schedule
  3. Budget
  4. Quality (can be a silent lever)

And as Beck stated above – two of those levers (schedule and budget) are often frozen or given to the Project Manager as non-negotiable.

So beware!   When Scope, Schedule, and Budget are all frozen and there is not enough time to complete all the scope (common), then quality will suffer and you will probably find out later, after the software releases.  Actually, to be more accurate, your customers will discover and tell you about the product defect(s) after the release.

Beck also states “Defects destroy the trust …” (page 97)

  1. Trust of the customer and stakeholders (obvious)
  2. Trust within the team (not as obvious)
    1. Manager’s trust of true project progress
    2. Team members trusting each other

Beck (one more time):  “Here is the dilemma in software development:  (released) defects are expensive, but eliminating (preventing) defects is also expensive” (page 97)

What can we do about this?  Measure quality and then start actions designed to prevent defects like …

  1. Frequent testing (e.g., smaller testing batches, automated tests)
  2. Pair programming (to reduce both design and execution errors)
  3. TDD – Test-Driven Development (think about the test conditions before writing code.  A powerful technique!)

About measurements:  listen to the great advise from Troy Magennis on the Agile for Humans podcast [hosted by Ryan Ripely] .  A balanced metrics approach for software development.  Measuring not only quality, but …

  1. Throughput
  2. Predictability
  3. Responsiveness
  4. Quality

Magennis advises us to use a set of metrics that will offset each other – “anticorrelated measurements”.

Example:  if we focus a team on improving throughput, and only measure throughput, what happens to quality (or predictability for that matter)?

The four take aways are

  1. Quality can be a silent lever, leading to escaped defects (i.e., post-release defects).
  2. Poor quality erodes trust.
  3. Measure quality to drive improvements.
  4. Use a balance metrics approach, so one metric does not dominate the product or team, which can lead to gaming of the system or lead to the myopic pursuit of a single metric at the expense of the bigger organization.