# Doctrine #1 - Empirical Control
![[Anticipate-Advance-Assess.svg]]
## Expecting the Unexpected
During my studies in electrical and information technologies in the late 90s, I had the opportunity to work as a student assistant with a team of engineers and physicist at IBM. Their main task was the production of new hard-disk generations. More specifically, they were responsible for the disk coating process, which involved creating layers of metals and carbon. These layers, measured in Ångström—a unit roughly equivalent to the diameter of an atom—were created using a well-established process known as magnetron sputtering. This process utilized a sequence of ultra-high vacuum chambers with a controlled plasma in each chamber. The entire product was manufactured in a clean room fabrication facility, roughly the size of two football fields.
As fascinated as I was by the ongoing engineering in this high-tech environment, I was equally surprised by how the team operated when brought a new disk in to production:
First, the team formulated a hypothesis outlining the parameters necessary to achieve the desired properties of the final disk. These parameters encompassed a wide array of variables for the plasma, such as voltage, gasses introduced into the vacuum chamber, the material itself and many more I never fully understood. The hypothesis was grounded in theoretical models, laboratory experiments, and knowledge acquired from past products.
After producing a larger batch of disk under production conditions, they started measuring the characteristics of the disks. Most likely they failed to achieve them, but the data gave the team hints were to adapt the parameters. Which led them to plan the execution of the next cycle.
At times, it took the team weeks and numerous cycles to achieve their desired results. During this pursuit, they had to eliminate common issues, such as a stray hair or a fingerprint fragment in one of the chambers.
> Development is the art of expecting the unexpected.
The team also found themselves needing to reevaluate their initial assumptions. For instance, they came across an issue involving minor but quantifiable deformations on the disks. Initially, the team hypothesized that these deformations were due to the plasma's extreme temperature, a seemingly logical assumption. However, the real culprit was the forces produced by high acceleration when the disks were inserted into the production machine. As a result, they needed to optimize the loading robot's movement.
> **Empirical:** Based on what is experienced or seen rather than on theory
Years later, while working as a programmer, I discovered the term for this meta-process: _Empirical Process Control_. This is how Ken Schwaber described the cycle in [[Scrum]], known as a [[Sprint]]. In his work, he explained that he had learned this concept from professionals in the chemical industry. ([[Process Dynamics, Modeling, and Control]]).
At this time, I was already familiar with this type of work from [[eXtreme Programming]], which operates on shorter loops. Initially, you define your expectations for the code change by writing a test case that naturally fails (marked as red). Then, you write the code to pass the test case (turning it green). Finally, you analyze the code and begin to refactor it, ensuring it still passes all existing tests. This completes one cycle, and readies you to start the next one.
Sprints in Scrum were offering us developers, an expanded cycle that facilitated our journey from a mere business concept to done functionality. The highest form of "Done" signifies that our users and customers have actively started utilizing the new features, which in turn, imparts us with invaluable insights. It was serving us as the definitive test for our business hypotheses.
Moreover, this rhythm adopted by the entire development and IT department, significantly reducing organizational noise and chaos. Large Scale Scrum ([[LeSS]]) is describing this pattern for a large number of teams working on one product.
So in fact, this Empirical Process Control Loop were not just optimizing the process to develop the software, it's controlling the entire results we are creating. In other words: Our [[Arena|Product]]. So a better description for them might be [[Empirical Product Control Loop]].
Scrum, XP and Agile were not inventing this. In fact, you can find those loops everywhere in models, methods, and organizations. [[Empiricism]] itself, as both a scientific and philosophical approach, dates back to the 17th century.
![[Empirical Product Control Loop#Examples of Empirical Product Control Loops]]
## Anticipate, Advance, Assess
In [[AME3]], there are two defined empirical loops. The first, at the tactical level, is the [[Match]] within an [[Arena]]. The second, at the strategic level, is the [[Tournament]] encompassing the entire Enterprise. They are structured into three phases:
![[Anticipate Advance Assess#Anticipate]]
![[Anticipate Advance Assess#Advance]]
![[Anticipate Advance Assess#Assess]]
The phases are not isolated from each other and can have some overlap. For instance, the IBM team collected a significant amount of data during the Advanced phase and drew conclusions from it instantly, which can be considered as assess. However, in a meeting, they summarized these insights and anticipate future experiments before advancing the next cycle.
## Strategy and Tactics
[[Rules]] of [[AME3]] are helping to implement the [[Anticipate Advance Assess|AAA-Loops]] and therefor the Empirical Control Doctrine. The organization and facilitation of the [[Tournament]] and [[Match]] are determined by the [[System Lead|System Leads]] and the particular methods and frameworks they elect to use. However, the shared rules ensure that the loops are interlocked.
As an example, the following images illustrate how the [[Tournament]] and [[Match]] integrate three frameworks. On the strategic level, the [[Tournament]] incorporates [[Wardley Mapping]]. On the tactical level, the [[Match]] integrates [[Scrum]] and a research cycle similar to the one used by the IBM team. However, each Arena likely has its own implementation for a [[Match]], utilizing different methods and frameworks.
![[Mapping Empricial Product Controle Loops.svg]]
On the strategic level, the loop of the [[Tournament]] does not have its own Advance phase. This phase consists of the combined [[Match|Matches]] of all [[Arena|Arenas]] and the remaining organization that does not operate within the AME3 framework. **Only the Teams and individuals actively working and interacting with customers are advancing.**
## The Perfect Length of a Loop
It's clear that the shorter the [[Anticipate Advance Assess|AAA-Loop]], the quicker the improvement and optimization process. However, certain constraints may necessitate a longer period:
* Technological complexity
* Market complexity
* Organizational complexity
* Social constraints
Often, we tend to select the time based on the constraints at hand. For instance, in the development of a new drug, the duration of a clinical test seems to dictate the maximal time for the loop. However, this approach has a drawback: we accept our assumption that we could not accomplish the goal more quickly. As an example, the development of the COVID-19 vaccine by BioNTec demonstrated that perceived constraints were actually unchallenged assumptions, as evidenced by their [[Projekt Lightspeed|rapid vaccine development initiative]].
By setting a fixed Timebox, we flip the problem on its head:
* We challenge ourselves to break down the problem into smaller, more manageable parts from which we can learn.
* We adopt a divide and conquer strategy to tackle the problem.
* We concentrate on fewer problems and resolve them in less time, providing us faster with better data for future decisions.
* We establish a rhythm that reduces noise and chaos in the organization.
## Designing the Loop in Loop in Loop
So, designing an [[Anticipate Advance Assess|AAA-Loop]] seems to be a trade-off. In larger organizations, these loops need to interconnect and build upon each other. It's clear that combining numerous loops can result in confusion and disarray. Fortunately, the Agile Community's decades of experience have shown that three interlocked loops are sufficient for most small and medium enterprises:
1. A Hour to a day long [[Anticipate Advance Assess|AAA-Loop]] for tasks handled by individuals and the Team, led by ...
2. A Week to a month long [[Anticipate Advance Assess|AAA-Loop]] for end-to-end improvements on the involving one or multiple Teams, led by ...
3. A Quarter to a year long [[Anticipate Advance Assess|AAA-Loop]] for the overarching [[Goal|Goals]] and [[Ambition|Ambitions]] of the Enterprises and entire Organization.
Several frameworks and methods effectively address one or two loops. Others are useful for supporting the loops, but do not define a loop on their own.
The challenge often lies in the fact that different parts of the organization may not operate in sync, which causes issues in communication and collaboration. Moreover, these organizational parts may not lead by the same doctrine of empirical control, which is crucial for planning common Goals and integrating data from the lower [[Anticipate Advance Assess|AAA-Loops]].
By elevating Empirical Controlling to an overarching strategic doctrine, the Enterprise ensures that various subsystems within the organization collaborate effectively within a generic structure.
[[AME3]] aims to maintain these [[Anticipate Advance Assess|AAA-Loops]] as flexible as possible, allowing different organizational parts to select the specific processes needed for their situation while providing enough structure to ensure subsystem integration.
## Next Level
Empirical Control is prevalent in various models, methods, and organizations. It is a fundamental component of effective product and service development and should, therefore, be the first strategic doctrine of an Enterprise.
In the context of [[AME3]], these cycles are embodied in the form of the [[Tournament]] and [[Match]] and is providing the foundation to manage the Evolution of the Enterprise. Which is manifested in the 2nd strategic [[2. Evolution Focus|Focus on Evolution]].
>[!button] [[2. Evolution Focus|Continue reading]]
<!-- AME3 Naming Checked by LLM-->