Break the Cycle of Yesterday's Logic in Organizational Change and Agile Adoption

Nowadays, one obvious fact about the agile market is that there is a strong push to select just one of the mainstream agile frameworks for so called “agile transformations”. Such approaches are plan- and work process driven to build a dual operating system focused on structural changes and small batch size deliverables. From these, three fundamental expectations of executives for agile changes are created:

• Firstly, introducing a dual system as savior of transforming the entire enterprise into high performing product-centric organization.
• Secondly, the one-size-fits-all thinking is seen as a solution to accelerate products market entry.
• Thirdly, those approaches are understood as scaling approaches. Inadvertently, the strong mesh of bivariate correlation of “new structures” and “old structures” gets adopted.

This results in the necessary interplay between organizational levels getting massively interrupted. Interdependent interplay, proven approaches, significance of engineering practices or sense of purpose get cudgeled by slavishly serving framework taxonomies. This causes reactivity because agile evangelists’ query roles, hierarchies, and organizational structures.

Another critical pattern is the pretended notion that by applying a one-size-fits-all approach, an agile way of thinking is even possible. It is an illusory expectation that those scaling frameworks could lead into a newborn mind set. Sadly, that is a false bias which perpetuates yesterday’s logic. Peter F. Drucker stated that yesterday’s logic grows if the same thinking is that caused the problem is used to create the change.

Why? The DNA of any company is the self-concept that it stands for and why. Sociologically speaking the cultural structure is what the organization is. In other words, it is the unique selling proposition that refers to the unique benefit exhibited by the enterprise. Employees are emotionally connected to this culture, that is why they signed in, and consequently their trust is formed around this enterprise self-concept. Sadly, the nature of one-size-fits-all approaches is to destruct the organizational culture by reinventing the “right” cultural mindset around ostensive needs for it. Energy gets bogged down in the marshy ground of the all-inclusive pattern - adopt the framework, experiment, and improve. Indeed, the logic behind those changes is continuous adopting deterministic causality driven change environments.

One-size-fits-all system causality

Like Tibetan-prayer-wheels, each framework promises to be the best business changer if one follows their special consultancy. Affected by the marketing machinery, executives and senior managers pick one of them. Hoping it will suit them instead of looking to their inner and outer organizational opportunities and boundaries to find real value adding outcomes for their business.

These artificial dual operating systems get designed alongside the line organisations with their job descriptions, hierarchies, performance contracts, engineering models and cultural values. Hurdles are preprogramed because for many technical driven enterprises, industrial standards simply don’t scale with agile frameworks. A logical inference is that the necessary variety is very much lost. Operationalization of variety with minimal investment costs are entrapped. Consequently, the change system behavior will be like dandelion seeds - the change will take time, costs will spread, and development transaction costs will increase.

These frameworks create an image that current structures are somehow in a wrong state. One major underlaying assumption is that these artificial distinctions create a kind of ideal organization structure. Therefore, enterprises are furiously battling to change common structures. This is a common pattern and explains why business agility is ensnared in straitjackets of yesterday’s logic. Those straitjackets evolve bivariate correlations of right or false.

It leads to false causality bias. The agile change evangelists suggest a system causality where for each event A there is another event B that precedes it and fully explains why A had to happen. Reinventing organizations with such yesterday’s logic does not mean crossing the Rubicon to make it difficult to optimize structures for mere change. According to Karl E. Weick, a distinguished mastermind in organizational studies, the organization should rather be understood as a jazz improvisation, a flexible mental model.

Dual operating systems lead to Buridan’s paradox

Buridan’s paradox is a phenomenon of electronical engineering and appears as metastability. Metastability arises when an electronical circuit must decide between two states and refers to an input that is in undefined state. Hence, the electronical circuit spends more time in circulation than it was meant for an intermediate range of defined operations. As a result, the metastability state causes unpredictability in the circuit with vague outcomes. Organisational metastability happened if circuits spend more time in undesired outcome which is a major root cause of battling with acceleration. In many cases departments, units or teams focus on improving the understanding of how to enact the framework structures “best practices” with the “right mindset”. Meanwhile, executives keep focusing on the duration time to sell products. Whereas line managers fight to combine new structures with the strictness of framework structures. Upon approval by senior management, they create even more unpredictability by following an eclectic paradigm of cherry picking in their divisions to ensure “acceleration”. Another point is that the mechanism of permanent prioritization, time boxing and adopting structures produce a force majeure of fragile change systems. It leads to the mushy ground of the imperative of understanding and the tendency to micromanagement. Sadly, this kind of change pattern leads to the mystery idea of constrained improvement on team level as a prior driver of the change.

Again, the nihilistic changes of socio psychological values result in unbalanced accountabilities which massively influence companies’ decision mechanism. They are still increasing the latency of decisions. Decision making mechanisms become time-consuming activities because of bike shedding - the tendency to spend excessive amounts of time debating and deciding on trivial and often subjective issues. One-size-fits-all approaches eclipse this cost of system metastability by emphasizing and targeting the blurry aim of agile maturity as well as lip service to acceleration.

Despite all the churn, the most important question from management does not change: Will you deliver in time? In this manner, delivery in time might mean to be ready with a new 3D technology product for a trade fair. Another example could be “Premarket Notification 510(k)” requested from the FDA before product launch or working alongside of a product engineering process. Delivery in time becomes a priority even for market leaders because the time for long lasting product development is already over.

The example of standardized industries yields to the real adaption zones

The example of standardized industries allow us to explore very specific circumstances. They are a very good model of figuring out the real adaption zones while also struggling with organisational disturbances. This might be ubiquitous in any technically driven industry.

In strongly regulated industries standardization of processes, documents, traceability, verifications, software, functional modelling, and prototyping are strictly requested by the Medical Device Directive,  the FDA, Electromagnetic Compatibility (EMC), international electrotechnical commission standards, quality audits, regulatory authorities and so on. In these regulated industries a software update is indeed driven by regulations.

In medical device production, for example, it is industry standard to exert certificated Application Lifecycle Management and Product Lifecycle Management-systems to ensure requested traceability. Also, the whole product engineering system is oriented on standardized models such as CMMI, PEP (variants) or German V-Modell XT (variants). These steps include initial concepts, product design, prototyping or functional modelling, device testing, design verification and validation, and manufacturing. These development processes are supposed to ensure that the design results are appropriate for the device's intended use. However, contrary to commercially non-regulated products, regulated product development is performed within strict regulatory requirements that provide additional constraints for the development, manufacturing, marketing and continuous improvement of products. Rethinking the interplay of requirements, engineering cycles and sequence of events, verification cycles or documentation and their interdependency are mostly more valuable than ambiguous acceleration.

Following standardization should prevent quality issues, often called findings. Instancing findings are always extraordinary events which must be fixed in a quite short time otherwise further product production and market launch are at risk or must be postponed wherefore the stakes are high in monetary terms. In this case the focus is not on a so-called end to end manner but moreover on the interdependent system and its conditions for effective adaptiveness to achieve the expectations. To focus on delivery in time is the focus of every involved department. The value is not blurred, but clearly defined as anticipating the findings as quickly and as qualitatively as possible. However, the anatomy of findings is always at a different complexity level that they must cope with. There is no desperate need to accelerate but moreover activating self-acting power, focus on interdependence of product delivery as well as common purpose. Equally vital is an engineering culture of trust in the expertise of other’s, based on the enterprises self-concept. This understanding results in less trouble reproducing results in part because accountabilities are clear across multiple departments. And yet, all activities are embraced by the question: Are your artefacts suitable for your environments without negative outcome for your acceptor and yourself?

Adaption zones and variety are bottom lines of organizational change

A few days ago, I mistakenly received an email from a former client who I left several month ago. The question was if there was a velocity expert in the enterprise to enlighten forecasting with velocity. This raised the question in my mind: Why on Earth should follow the sacred cow of arbitrarily agile rules and artificial agile measures such as velocity, how does this support an organizational change to deliver on time?

Kanban as a stimulus provides the challenge as well as the opportunity to collect real data, picture the real workflow, and regard the scale of large, interconnected change. Existing organizational KPIs are not touched. As for any organisational change, of course, management must encourage the change switching to a pull paradigm. In a medical device development division with 120+ employees, we introduced business agility by using Kanban systems. The first concern was choosing a proper digital tool, making sure the workflows are visualized without tool boundaries. Another concern was the possibility of collecting real data, such as delivery rate, cycle time, waiting time, duration time, and so forth.

Consequently, we started by visualizing the different product development flows, team working flows, and portfolio management. Nevertheless, each team Kanban board indicated different types of work. By adopting work in progress limits for each team as well as focusing on costs of delay, we created a huge improvement of predictability of delivery dates. The portfolio Kanban system was defined to manage inside and outside dependencies, interdependence between interfaces, and delivery target dates. Another responsibility of the portfolio system was the capability and economic analysis of incoming requests before commitment.

Accordingly, another important point was emphasizing a working environment that allowed every expert to contribute their full talents. We did not contradict both existing roles and the self-responsibility of accountability. Thus, the whole Kanban system was meaningful for all employees.

The stimuli of adaptation are visual boards, portfolio, and dependency management, concentrate on pull paradigm, outcome measures, theory of constraints (TOC), Ashby’s law of requisite variety and managing probabilistic forecasting sufficiently underpinned by collecting real data. The principle of visualization enables experts to understand the status and target dates of their product development, while portfolio Kanban systems are used to enable understanding multiple product states as well as making business-driven decisions. The quantitative data from the Kanban systems are used for dependency management on the portfolio level to handle capabilities and alignment. Meanwhile, the pull mechanism encourages work in progress control and significantly involves commitments. Outcome measures such as throughput or cycle time related to customer satisfaction. They cannot be seen only as value metrics but also how the distribution looks over a period. The theory of constraints is a concept of limiting the number of bottlenecks. Those are understood as limiting factors in the workflow and actively handling them increases predictability of delivery. A useful forecasting method was a recurring Monte Carlo simulation feed with the random sampling of the Kanban systems.

These patterns helped us to avoid the one-size-fits-all trap by acting with a real-life controlled pull system by preventing artificial time boxes and focus on product delivery time. Every single team could manage their own workflow and capability. Real-life control of dependencies between teams was handled of predecessor or successor tasks. The cross-functionality was focused on cross-department collaboration to shorten waiting times and unevenness. This approach offered predictable forecasting as well as managing collaboratively waiting for tasks across the division. A further opportunity was mastering strategic varieties such as cost down, offshoring, procurement, and purchasing changes without losing control of workflow management by absorbing those strategies in real-time. The fast incorporation of market demands, strategic changes yet maintain delivery dates could be managed by the avoidance of structural changes of the organization.

Real data is defined as data which is generated out of the Kanban system which mirrors the actual workflow. Such a system can be effectively tailored based on the needs of the different adoption zones. A practical example is a simple thermostat; a device that regulates temperature based on inputs from its environment. W. R. Ashby, a pioneer in cybernetics and great organizational change thinker, states the law of requisite variety (LRV). The concept of LRV provides fundamental insights about changes and how achievements can be understood. Variety is defined as the possible number of system states. It allows us to incorporate the concept of probabilistic forecasting in dealing with change systems and provides us the opportunity to discover hidden values of organizational changes. That means that any change system, which can cope with a changing environment, contains matching varieties in relation to its environment. This underlaying approach can be understood as a system regulator of system inherent repercussions - that a regulator of a given system must be a model of this system.

This mechanism was adopted for example in a system engineering company, in a medical device development enterprise, or project management for industrial robots’ development. Contrary to other approaches we shared a perception of how things are done. We figured out what are the essential “survival” variables for example when and in which condition documents are handed over to uncover the 1:1 outside bounds and doing so for every involved expert group.  The variety in the Kanban system increased to 1:n.

We took a similar approach to mission “critical” variables like high-priority tasks. That allowed every group to perceive a pattern of behavior that is appropriate for their particular environment. The variety for every single team was low enough to define service level agreements for response time as well as participating interdependency. For the whole Kanban system, the variety increased and matched the external variety of its environments. By repeating this mechanism, the manageable workload for each group was in a stable state.

To increase the internal variety, we visualized high-priority tasks on the boards and defined the rule that every high-priority task must prove its immediate business value. An example for such a task is the need for a power supply for a prototype for customer presentation. By not trying to avoid variety but very much face the variety and yet increase it we dramatically reduced waiting time, sketchy high priority tasks, and precisely adjusted predictability.

Best practice is first collectively changing an entire division or at least a unit with several groups. Otherwise, you won’t generate enough real data for computational algorithm-based Monte Carlo simulation supporting dependency management as well as forecasting.

The very first consideration should be to introduce a digital Kanban tool which suits best in the existing landscape getting the best opportunities to connect it, for example, with GitHub, testing systems or a PLM-System. Another important factor is linking dependent tickets intra-group wise. They help manage work item dependencies in each group and support exploring deeper relationships. Moreover, these micro adaptions result in the Butterfly effect of thinking in business terms almost automatically all over. Yet another improvement for everyone is a common understanding of what needs to be done, and when.

The combination of engineering practices, digitalisation and organisational change ensures an adaptive, integrative, and unifying approach. No existing organisational matrix, roles, structures, or engineering practices get superimposed from a dual operating system. This modality of an organisational change respects the enterprise’s self-concept, not stacked in one-size-fits-all thinking.

Controlling and timing context is guided by Kanban systems. It will bring dependencies in and across adaption zones to light. It also allows to focus on the question - Are you prepared for your environments without negative outcome for your economy of scale, other groups, or the end-user as well as delivery time? After all, it results in data driven ability to address organisational flow and what interdependent solutions could look like. When used within this context, variety emerges as ability to adapt - the adaption zones. Kanban system dampens the possibility to cope with every request because of focusing on cost of delays as well as waiting states.\

About the Author

Roland Konrad Kobald is an adaptive scaling coach. He has around 12 years’ experience with agile and scaling methods and more than 5 years’ experience as independent coach. His main emphasis is adaptive change in regulated industries, software development as well as system engineering products by using Kanban and scalability as an alternative to one-size-fits-all