Understanding Variation - An Important Key to Improving Scrum

Ajay Reddy

• 11 March 2014

• articles

• Scrum Variation Demming

What is Variation Variation refers to relative differences in the properties or behavior of comparable articles. Individuals, team, organizations, systems, processes, raw material, and finished products all have inherent variation.

Edward Deming was an early proponent for reducing variation to acceptable sigma limits that were mathematically calculated. He believed limiting variation (assuming the limited variation, itself, is useful and good) enables us to better manage, predict, plan, and use it. Donald Wheeler documented proof of this in his brilliant book “Understanding Variation: The Key to Managing Chaos”.

Manufacturing work such as production of screws, windows or cars naturally lends itself to efforts at managing variation. This is because there are routine characteristics inherent to the production process, itself. Manufacturers know they need a “1 inch screw” to be as close to 1 inch as possible. There is a degree of tolerance of a socket that take that can accept the 1 inch screw. A socket may take a 0.99993 or a 1.008 inch screw for example but not a 1.1. Consequently, the more we control variation, the more we influence quality, waste and efficiency as outcomes.

Want to learn more about how you can manage variation with Scrumban? Sign up for certified training now!

Before Deming, Walter Shewart developed statistical models needed to help identify what are acceptable ranges. Demings describes how to deal with ‘bad variation’ through the ‘PDCA’ cycle. Motorola’s Six Sigma (a formal method and certification program) has taken these principles and distilled them into ‘DMAIC’.

Knowledge work Knowledge work, a term coined by Peter Drucker in the latter part of the 20th Century, does not possess the same routine characteristics as manufacturing processes. Software development, the practice of medicine, the practice of law, and architectural design are all examples of knowledge work.

In manufacturing, the initial discovery, research, creative thinking and mental processing that are relevant to ultimately producing an actual part are separate and distinct from the production process. Consequently, that process is relatively consistent and routine for each part that’s produced. In knowledge work, the initial discovery, research, creative thinking and mental processing are integrated into the actual production process. These elements are all non-routine and inherently unpredictable.

Consider a short sampling of IT operations work, for example. Setting up an EC2 instance is probably more routine than installing a Weblogic server with the appropriate plugins which, in turn, is probably more routine than creating a website or developing a search algorithm. Consequently, managing for variation in knowledge work is more challenging than what manufacturing must content with in its space.

Originally developed within the context of manufacturing, Deming’s PDCA cycle and Six Sigma principles are wonderful methods. They’re just impossible to apply in the context of knowledge work without making some necessary adaptations.

For example, both the process of producing work as well as acceptable levels of tolerance in the final result contain far more variation than manufacturing. Failing to account for and manage these greater degrees of variation makes management methods like PDCA and Six Sigma far less useful.

Common and Assignable/Special causes Deming expanded upon the work of Walter Shewhart to highlight the two distinct types of variation that can be found in a process – common and special causes. In short, common causes (also called natural patterns) are comprised of the historical and quantifiable variations in a system. Special causes are unusual, not previously observed, and can have root causes that are assignable (meaning they are susceptible to intervention and correction assuming they can be identified).

Processes that contain only common-cause variation are essentially stable and predictable. We can create buffers in our planning to account for these known variations. On the other hand, special cause variations can be signals of emergent or previously neglected factors that can be corrected by changing a component or process (because common-cause failures are equivalent to noise in the system, specific actions can’t be taken to prevent the failure). Though we may be tempted to react to extreme outcomes originated by common-causes, our interventions are only likely to increase the level of variation and frequency of undesirable outcomes. And we certainly can’t buffer from them in planning.

Want to learn more about how you can manage variation with Scrumban? Sign up for certified training now!

Examples

One particularly challenging aspect knowledge work lies in how it’s particularly susceptible to “false positive” identification of special cause variations. Software development is complex, and research tasks can be particularly variable. For example, the time and effort it takes to design and develop a database cache solution will vary widely based upon factors such as whether 1) it’s something that’s routinely done, 2) the system contains multiple “moving parts,”, 3) there’s legacy code to contend with, 4) there are multiple options that can be employed, 5) the use of different technologies, and so on. A development team could perceive delays in implementation as a ‘problem’ (special cause) when it’s really well within what should be an expected variation.

Scrum is particularly susceptible to this. With its timeboxing, release and iteration goals, it’s easy for highly variable work items to extend beyond normal estimates. Estimation is the only Scrum ceremony that indirectly provides for natural knowledge-work variation, and it’s an imprecise process at best.

“Spikes” are another example of an imperfect attempt to account for variation (a special kind of story used for activities in research, design and similar categories of work). The purpose of a spike is to reduce to reduce the risk of a particular approach, better understand a requirement, or increase the reliability of an estimate. Unfortunately, spikes only work if you recognize an item of work contains a high degree of variation to begin with. And they remain imperfect estimates as opposed to any kind of probabilistic determination based on empirical data (which is what Kanban / Scrumban provides). Bill Wake’s INVEST principle (a reminder of the qualities of a good user story – Independent, Negotiable, Valuable, Estimable, Small, Testable) is also an imperfect accommodation.

As a framework, Scrumban accommodates for the inherent variation of knowledge work better than any other methodology by understanding the nature of work from the past. It’s no silver bullet, but it does a remarkably better job of helping making better decision making by enabling teams and organizations to better understand their work and providing a framework for balancing the business realities being faced.

We will continue to publish additional articles speaking to these important topics, and highlighting the reasons why your own organization may find Scrumban a welcome addition. In the meantime, if you’d like a really rockin’ Scrum management platform that’s also designed to seamlessly help Scrum teams adapt with Scrumban, take a test ride at www.scrumdo.com.

Want to learn more about how you can manage variation with Scrumban? Sign up for certified training now!