Quality and Productivity
yields competitive position
“Folklore has it that quality and production are incompatible: that you can’t have both. A plant manager will usually tell you that it is either or. In his experience, if he pushes quality he falls behind in production. If he pushes production, his quality suffers. This will be his experience when he knows not what quality is nor how to achieve it.”
— W. Edwards Deming
Less Re-work
There’s a simple reason why maintaining high quality results in greater productivity: less re-work. Time spent on stories returned from testing is time that might have been spent on new work. It is not a question of badgering developers to be more careful, and writing more test cases is not the only answer. Much of what determines quality is out of the developer’s hand, for example, defects resulting conflicts in specifications from different components being developed in parallel.
Improve quality, you automatically build in productivity.
— W. Edwards Deming
Quality Assurance
Software QA is often considered to be synonymous with testing, with tests consisting of proof of compliance with requirements. This is a very narrow conception, compared to how the term is used in manufacturing, for example. Practices that prevent the recurrence of defects is more consistent to the conception of QA I’m after here. For example, ensuring that all stories coming out of work meet an agreed upon Definition of Done (DOD) is a Quality Assurance practice. What testers are doing is actually quality verification.
If we establish a DOD that gets largely ignored, it doesn’t help. Do we have items in the DOD which are irrelevant to some of the work, thereby encouraging team members to skip over items? Is it too detailed, making people doubt if the time going into it are worth it? Are there items that are appropriate to done, but at a different stage than where the checklist is? Understanding DOD as a Quality Assurance practice, we need to work to keep in relevant.
Quality Assurance is what we’re doing when we curate the practices that define our workflow. Technical practices generally don’t become habitual just because we say that we value quality. Each practice area requires discussion for refinement and review for changing circumstances. The care and feeding of the practice is what keeps it alive until it becomes second nature. Picking practices in response to some crisis and then not following through is worse than doing nothing at all.
Observation of the Process
Quality Assurance starts with observation of the process: to try to understand the work better and identify where inefficiencies are occurring. When you push code that breaks the build, then your reaction is unavoidable, but defects are often subtle and easily overlooked. Poorly written code may pass verification without raising any flags, but the quality deficiency will almost certainly make a claim on productivity at some future date.
Much like a software bug that we have trouble pinning down, where you need to set a breakpoint and step through code, observing object state change. Process bugs are also, at times only evident when we study the work in the context of its progress through the system. To see the work in context, we need a model of our work stream.
Building a model is what gives as a starting point for observation of the process. Without a coherent model, the discussion of defects and other problems will inevitably focus on details of the task, or on the person doing the work. Deming said that
Eighty-five percent of the reasons for failure are deficiencies in the systems and process rather than the employee. The role of management is to change the process rather than badgering individuals to do better.
— W. Edwards Deming
The Card Wall as Process Model
The card wall is a tool for modeling what is actually happening. Forget about trying to get team members to comply with a process. Focus on what they’re doing and the reasons behind the actions. From that vantage point, you can begin to pin down problems and pick out practices to adopt that might resolve the problems you’re observing.
The card wall is a tool for modeling what is actually happening. Forget about trying to get team members to comply with a process. Focus on what they’re actually doing and the reasons behind the actions. From that vantage point, you can begin to pin down problems and pick out practices to adopt that might resolve the problems you’re actually observing.
Let's agree to define productivity in terms of throughput. We can debate the meaning of productivity in terms of additional measurements of the business value of delivered work, but as Eliyahu Goldratt pointed out in his critique of the Balanced Scorecard, there is a virtue in simplicity. Throughput doesn’t answer all our questions about business value, but it is a sufficient metric for the context of evaluating the relationship of practices with productivity.