Panarchy

The panarchy model explained

Panarchy is a conceptual model that describes how complex systems of people and nature are dynamically organized and structured dynamically across scales of space and time [Allen 2014]. The word Panarchy comes from “Pan” the Greek god of the wild and “arkhos”, the leader.

Those systems are linked and have some impact between them regarding their own evolution cycles so called “ecocycles” with 4 phases α, r, K and Ω [Gunderson 2002]:

• α: reorganization start of the ecocycle due to an external change - an ecocycle linked to this subsystem has changed and impacts this subsystem
• r: exploration to adapt the ecocycle to changes
• K: conservation - the ecocycle is stable enough to accumulate resources from  an ecocycle linked to this subsystem
• Ω: release - the ecocycle reaches a saturation point that will lead to some reorganization with a new α phase

To understand those phases, just imagine a small boat with a couple of sailors on it. Every time the boat is loaded with some heavy burden that breaks the boat balance (α) , sailors should explore  (r) new positioning to enable extra resource accumulation (K). When the cargo is too large, the balance is upset and the ship capsizes to release the excess load (Ω).

From a DevOps point of view, the shape of an ecocycle does ring a bell but DevOps rose in 2008 from a conference at Toronto [Debois 2008] with an infinite shape created for pure infographic needs that came even later, while the ecocycle shape rationale was also published way sooner before DevOps [Moustier 2020a] since Holling published it in 1985 [Holling 1985]. Moreover, the shape has been fully explained and also developed in 3D to show a saddle-like structure [Gunderson 2002].

‍

Panarchy relates to the interaction between ecocycles. When an ecocycle reaches phase Ω, it literally releases some resources to linked ecocycles. This impact is named “revolt”. With the boat example, the river receives the released cargo thus increasing its own phase K.

Now, say the cargo company has found some new method supposed to facilitate loading to avoid capsizing from others’ experience (the bigger system represented by the company has accumulated resources from every return of experience - phase K). This knowledge can be viewed as accumulated “memories” which will change the Way of Work of our boat that will have to adapt (α) to integrate the new WoW.

‍

From this model firstly designed to deal with Man/Nature interactions, many papers emerged in different domains such as [Allen 2014]:

• organization of complicated and complex systems
• change management and identifying aspects of resilience
• sociology
• manner in which tourism is conceived of for sustainability
• dairy farming
• urban systems and regional economic systems
• law

It appears that the Panarchy concept is also used in psychology [Varey 2010] or supply chains [Wieland 2021].

In the agile environment, the “Liberating structures”, recipes to run efficient workshops with tens of people also refers to this theory [Lipmanowicz 2014] with the “Ecocycle planning” and the “Panarchy” workshops.

Impact on the testing maturity

In the testing domain, Panarchy has also been involved along with three other parts to build a model for agile testing at scale named “PanTesting”. This model encourages to merge ecocycles so that high efficiency cadence and synchronization are ensured between parts of the organizations [SAFe 2021-07].

‍

Agilitest’s standpoint on this practice

The ecocycle merging is extremely significant for test script automation. When you start thinking in terms of Panarchy, you start spotting ecocycles everywhere. Here are some ecocycles that may impact your automation strategy

• product development ecocycle: it requires merging the development and test automation ecocycles to have automated scripts along with the latest product increment
• market use of the the product: it impacts generated data and thus the main test cases and data sets to automate in ATDD mode
• the ecocycle of possible data: the more the script can cope with unforeseen data, the more robust the script will be - this is part of Jidoka which can be found in Lean
• the ecocycle of features in the product: the closer automation and features are, the higher the quality level
• the ecocycle of possible behaviours in the product: this one is close to the ecocycle of the product, except it also includes non specified and unpredictable behaviors - see Jidoka
• technology ecocycle: technical knowledge to enable automation should be considered to avoid laggards in the team; since Agilitest is a #nocode technology [Forsyth 2021], it will the facilitate T-Shape people and avoid disconnecting them with tools that are not simple to use

‍

To discover the whole set of practices, click here.

‍