Knowledge of Variation
During Dr. Deming’s work as a statistician, he helped people understand what a system actually looked like by presenting the statistical outlook of its process. His infamous red bean experiment showed that within the acceptable deviation range, most of the future result from a process can be reliably predicted. This state is what he referred to as a stable system.
Deming explored that the result was influenced by two categories of causes: common and special causes. According to Deming, the understanding to differentiate between these two causes is extremely important. The aim of having this knowledge is not the complete elimination of variant in any observable domain, rather reducing it to a defined and acceptable range of deviation. It is very important to address the more systemic common causes rather than over-reacting to the special causes.
Deming used the statistical control chart to help us understand the difference between common and special cause. The variation caused by the common cause can be observed as fluctuations that occurred between the natural limit of the system. The common cause accounts to the majority of rational explanation of the results. Which can be translated as whatever falls into the range of the natural limit is caused by the operational nature of the system. Occasionally, some measurement point will fall outside the natural limit. This is what we called the special cause. Deming argued, in statistical chances, that addressing and identifying the common cause will yield better odds for long-lasting improvement of the system’s process.
Scrum acknowledged this directly. The prescribed Scrum event, role, and artifacts are designed to make the practitioners accustomed to actively reducing variation by regular inspection and adaptation toward a defined goal.
Scrum users must frequently inspect Scrum artifacts and progress toward a Sprint Goal to detect undesirable variances — Scrum Guide 2017
If an inspector determines that one or more aspects of a process deviate outside acceptable limits, and that the resulting product will be unacceptable, the process or the material being processed must be adjusted. An adjustment must be made as soon as possible to minimize further deviation. — Scrum Guide 2017
For example, Scrum advocates the practitioner to improve and be proficient on time-bounded and regular Scrum events.
Prescribed events are used in Scrum to create regularity and to minimize the need for meetings not defined in Scrum. All events are time-boxed events, such that every event has a maximum duration — Scrum Guide 2017
The excessive duration and number of meeting in an organization are the example of common causes that contribute directly to an unsustainable process owned by a Scrum Team. It is not an exaggeration that in some organization the number of meetings will consume the majority of the working time. The result of doing meetings may vary from terrible to great depending on how good it was being held. By making the event to have a purpose in regular and time-bounded fashion, the deficiency of the practitioners holding them will be exposed and painfully visible. Lack of clarity and focus on agenda, digressing, late start, lack of engagement, multi-tasking, political jousting arena are among the common causes that needed to be fixed to reduce the success variation of a meeting. It exposes the more important and common issue that almost everybody elects to neglect: our inefficiency and ineffectiveness in communication to process and distribute information within our system. When done right, the complexity of the inefficient meeting will be reduced by the consistency on improving the proficiency in doing time bounded and focused Scrum events.
In addition to Scrum, XP (Extreme Programming) also advocate a small batch delivery and extreme practices that are really great on reducing variation at the technical level. Test first development is a great approach to reduce defect risks by instilling a software version of “poka-yoke”. By creating a test to the majority of known common cause even before the development started, the varying defects will be greatly reduced.
Requirements are nailed down firmly by tests. There can be no misunderstanding a specification written in the form of executable code — Extreme Programming
Pair programming is a great approach to improve quality and reduce defects by working to a single task in a paired manner that enables review and development simultaneously.
It is counter intuitive, but 2 people working at a single computer will add as much functionality as two working separately except that it will be much higher in quality. With increased quality comes big savings later in the project — Extreme Programming
Every practice being advocated by XP arguably can be observed as an attempt to reduce every aspect that may cause variances on the result of software programming.
We will see a recurring theme like this in other examples of Scrum implementation. However, the main advantage of doing rigorous and regular practice that is advocated by Scrum should not be lost on the ritual sake. The economy of trying to achieve a stable state lies on the practical benefit as a systemic approach offers a long-lasting improvement. The improvement of the system should be attained by addressing the common cause and reducing the variation of parameters to an acceptable range of deviation.
The most common denominator of variances that any system faces in its software development process is the risk of failure. While in a simple problem domain, an analysis of the risk that may impede the success can be done easily, the opposite may not hold when an analysis is done against a complex problem. The complexity of software development, unless it was done before, usually can be only discovered when all of its moving parts are actually deployed and tested against the real environment where the software lives.
The heart of Scrum is a Sprint, a time-box of one month or less during which a “Done”, useable, and potentially releasable product Increment is created.— Scrum Guide 2017
To cope with the varying risks of failure of delivery, a regular and stable small batch delivery is proposed to gradually surface the risks associated with the software delivery. By consistently delivering a working increment of the solution, the varying success result of the overall delivery should also be reduced to a more favorable state.
When we understand the importance of addressing the variation within our system, the next thing that we want to address is how we actually acquired this knowledge. Deming composed the System of Profound Knowledge (SoPK) lenses to be inter-related. So far when we appreciate and understand the nature of our system and the variances related to it, we also want to be able to be really good on acquiring knowledge about our overall understanding of our own system and its process.
