Mission: Implement an agile mindset!

This is what many initiatives sound like at the moment. The agile mindset is on everyone's lips. Organisations are expecting a lot from the "rethinking" of their own workforce.

Suddenly, what should apparently make the difference in times of disruption seems to be within reach: intrinsically motivated employees!

But what is behind the promise that the agile mindset would help companies improve?

For some time now, it has been observed how the new mission for everyone, the “agile mindset,” has caused many employees to feel uncertain. Are my existing soft skills sufficient? What are they, in the first place? What is the agile mindset about? Does it have anything to do with my soft skills at all?

Teaching agile principles and practices seldom suffices to give employees more confidence. Measures implemented in many places with the goal of changing behavior, such as training the workforce in agile methods, are rarely capable of painting a different picture than the “old” one.

But what is the reason for that?

Two questions are often neglected not only in the context of making employees more agile.

Firstly, what problem does agility solve for the company and why can agility help address it (not the focus of this article)?

Secondly, if it is an organisational goal for employees, executives and board members to develop an agile mindset, what is the current status quo? What do employees currently think? What is the prevailing attitude or mindset? Why are we not thinking agilely before planned change?

When we talk about changing mindsets, we cannot avoid establishing something like a baseline, that is, describing the current state (of prevailing thinking and existing mental models). To do this, the question arises, what is the expected benefit if everyone thinks and acts “differently” and “agilely” and, initially more importantly, where do our current mindsets actually come from (historically)?

By the way, anyone who believes that this topic only affects employees and is less relevant for managers has done the math without the host and should not be surprised if their agile transformation is doomed to failure from the start. But that's just a side note.

Our Roots

Those who cannot remember the past are destined to repeat it

To raise a little awareness at this point, it is worth taking a look in the direction of the following three people. Not only many of the agilists are of the opinion that these individuals have had a lasting influence on the way of thinking in all areas of our companies and continue to do so today.
 

1. Frederic Winslow Taylor

Wikipedia (Germany):

“Frederick Winslow Taylor (20. März 1856 – 21. März 1915) war ein amerikanischer Maschinenbauingenieur. Er war weithin bekannt für seine Methoden zur Verbesserung der industriellen Effizienz. … Im Jahr 1911 fasste Taylor seine Effizienztechniken in seinem Buch ‘The Principles of Scientific Management’ zusammen, das 2001 von den Mitgliedern der Academy of Management zum einflussreichsten Managementbuch des zwanzigsten Jahrhunderts gewählt wurde. … Infolgedessen wird das wissenschaftliche Management manchmal auch als Taylorismus bezeichnet.”

Alfred Sloan of General Motors and also Henry Ford (founder of the automobile company of the same name), were certainly both early adopters of Taylorism and adapted the methods of scientific management at the time for their context of their businesses. The age of mass production was born.

Wikipedia (Germany) Excerpt Taylorism:

“At the same time as Scientific Management became popular, the term Taylorism also emerged. Both terms were initially used by supporters as well as critics. Since about 1970, however, Taylorism has been used almost exclusively in a critical context. Criticism is mainly directed at the following aspects which hinder flexible task fulfilment:

  • Detailed specification of the working method: “one best way”
  • exact specification of the place and time of performance
  • extremely detailed and fragmented work tasks
  • One-way communication with specified and narrow content
  • Detailed objectives with no connection to the company’s goals that is recognisable to the individual
  • External (quality) control

The fact that there has been criticism of Taylorism since the 1970s does not, in my experience, prevent companies from continuing to use the same or similar methods today. Whereas at the beginning of the 20th century, due to the emergence of mass production, a large part of the workforce was engaged in assembly line work, today knowledge work is predominant in companies [12]. This also seems logical against the backdrop that one now has to deal with customer needs in a much more diverse way in order to be able to offer competitive products and services.

The 'secret sauce' to Amazon's success is an 'obsessive compulsive focus' on customer over competitor

One of the potential conflicts for today’s application of Taylor’s model is the separation of planning and execution. Management levels design the process of execution (one process for all) and workforces execute. All this without giving the why or the context to the executors (one-way communication). This may have been a quantum leap for business management and process management of mass production at the time, but it does not work well in complex environments with variable customer values (see also David Snowden’s Cynefin Framework [2]). The way work is organised and many things related to Taylor’s methods are also often summarised in agile with the collective term “command-and-control-ism” as a behavioural pattern.

An example: Within software development in traditional organisations, everyone knows the role of the business analyst. The business analyst analyses the business case and develops the necessary specification for the provision of the product(s) or service(s) to be developed on the software side. Then programmers go in and write the source code for it. The more detailed the specification, the less creative leeway there is.

This approach is in complete contrast to the challenges of software development, where, not only with the introduction of object-oriented programming and developments such as design patterns (the Gang of Four), the work demands design and architecture within the development of applications, services and platforms.
The consistent continuation of classic working methods in the “industrialisation” of software development was certainly the reason for the resistance within the communities shortly before the turn of the millennium, which ultimately led to the movement around the agile manifesto and the development of methods such as XP and SCRUM.

The speed of the Internet provides a fundamentally different perspective on how business relationships occur ... The approach relies on collaboration, not on competition ... on sharing information, and understanding what we as businesses do best

2. Henry L. Gantt

Most people are familiar with him as the inventor of the Gantt chart. In classic project management (e.g. MS Project), this is still the central planning and visualisation method par excellence. It can be assumed that the inventors of the waterfall model – which originally came from the construction industry – were also inspired by this method. In the context of “management science”, Gantt developed the necessary control mechanisms (e.g. Man Record Chart) to be able to track the task completion of the workforce, or to optimise it. 

Transferred to today, imagine if an organisation went and introduced keystrokes per minute as an efficiency KPI in order to check the performance of developers on a daily basis. Unthinkable. Nevertheless, efficiency orientation is widespread, which likes to express itself primarily in maximum resource utilisation as a central component of classically thinking companies. 

Another development of Gantt was the exact identification of employee utilisation or idle time (idle chart). Here, too, the approach was to find times when workers were idle and to systematically reduce them. 

From the queue theory (see also Gunter Dueck [13]) or the bottleneck theory of Eliyahu Goldratt [14] We know today that this mindset of the indispensability of full resource utilisation also massively endangers any agile transformation. The reason for this is simple: if everyone is working at 100%+ capacity, there is simply no time to even think about change in any form, let alone deal with it continuously in an improvement process. Not to mention the detrimental effect on Time2Market through systemic impact on lead times.

Furthermore, Gantt invented the bonus system. This was intended to create financial incentives to maximise the above-mentioned efficiency in the workforce (Carrot & Stick Motivation [15]). Gantt’s bonus system in combination with Taylor’s separating organisational structure is still one of the decisive obstacles why organisations fail to establish end-to-end coordination as one of the most important building blocks of scaled agility.

Local optimisation leads to global sub-optimisation!

Local optimisation leads to global sub-optimisation! This is not only true in the context of systems, but also in the context of power structures within companies. Incentivisation via the achievement of a local goal almost always ends up in directing energy primarily towards the achievement of that goal and not towards the fulfilment of the actual purpose. It is also well known that such incentives always remain extrinsic and that motivation only intrinsically brings added value to companies.

Research shows: For simple straightforward tasks monetary rewards work outstanding…but when a task gets complicated, when it requires some contextual creative thinking those kind of motivators don’t work …

In his book Drive [4], author Dan Pink describes three factors for intrinsic motivation: Autonomy, Mastery, Purpose. In environments with complex tasks, monetary rewards are not very motivating. In fact, in today’s world of multi-layered problem and solution spaces, self-determination, self-fulfillment and a sense of purpose are much more effective as motivational drivers. The classic carrot & stick motivational strategy is generally less preferable from a neuroscientific perspective.

So if management expects employees to pull together, why not incentivise them to achieve “overarching” goals aligned with customer value? Why do divisions, directorates and departments still have mostly individual-based, isolated goal achievement agreements that do not take any of these three dimensions into account? Isolated, financial incentives encourage competitive behaviour among key people in individual work system components. In my opinion, the reason for this design lies in outdated thinking patterns (Henry Gantt sends his regards) or the fact that these are generally rarely questioned (“Because we have always done it this way”).

3. James O. McKinsey

And last but not least, James McKinsey. He wrote “annual budgeting” (Budgetary Control). Annual budget planning is standard today, as it was a hundred years ago. Here, too, there have been many approaches for some time to bring this process closer to a more modern approach with shorter cadences (see also beyond, or participatory budgeting [3]).

Unfortunately, those sitting in the “drivers seat” here continue to be taught the same system during their studies and, above all, little questioning of it. This is a fact that should not be viewed entirely uncritically, given that the agile manifesto is more than 20 years old and the approach of annual budget planning was also increasingly unpopular in lean management.

In the communities (including my personally preferred thought model for scaled agility, the Flight Levels System (flightlevels.io by Dr. Klaus Leopold), there is also a lot of discussion about how the general claim of gaining speed due to constantly changing markets (speed of innovation of technology [7][8]) interferes with the annual budget allocation mechanism. The currently leading framework for scaled agility – SAFe – also offers approaches here (lean budgets [5]).

An important aspect of scaled agility is the basic assumption that speed and quality arise from distributed responsibility, among other things. If one does not let go of the central responsibility in management, new responsibility holders, with a higher level of on-the-spot problem competence, can hardly make it their own. The “Command-And-Control-Ism” mindset ergo prevents the partial empowerment of the workforce.

This time-honoured centralist approach is also found in the area of decision-making. My colleague Markus Andraschek coined the great term Cost-Of-Delay-Of-Decision. Why not set a price for decisions that are not made or are made too late? Long decision-making processes and the active avoidance of decisions costs money!

As mentioned above, organisations often have the mantra of the inevitability of maximum resource utilisation. This is a historical thought artefact from Taylor’s and Gantt’s efficiency optimisation, which has long since become secondary. The principle to be superimposed on this is flow, as described earlier. This principle has existed since long before Agile made the rounds, originates from the context of the Toyota Production System (Kanban) and is an elementary component of Lean Management. For this reason, most people only know it from the manufacturing context.

By the way, applying flow does not mean that you cannot optimise resource utilisation. But not without having established flow first. How organisations manage their knowledge work according to an inventory within a production line is the core task of developing and operating agile operating systems or process organisation architectures within companies. To illustrate the flow principle to someone in a nutshell, we recommend this video by Henrik Kniberg [9] (if you don’t happen to be able to take a Kanban course in which you can participate in a ship folding experiment by Dr. Klaus Leopold).

"100% Utilization equals 0% flow. If you focus on keeping people busy, what you get is a bunch of busy people. … Think about that next time you got stuck in a traffic jam.”

Summing up

Finally, no change without space for change. Change is not a second rucksack that can be strapped on to the workforce. Work systems must first get out of systemic overload!

Silos that slow down the system can only be overcome with great resistance if one continues to insist on exclusive bonus incentives. In modern corporate cultures, collaboration is needed. This is opposed by competition. Segregation is counterproductive from an agility perspective and prevents the staff from growing together. The identification with corporate visions and value streams or own products and services is unnecessarily torpedoed.

There are certainly many more areas and topics that are shaped by the historically conditioned industrial age thinking that still prevails in many places. It is important to understand where we have come from and why we should question this thinking, against the backdrop of an evolutionarily changing world. Perhaps we also need to ask ourselves whether our way of thinking currently still fits the demands of society and the markets.

"People don't resist change; They resist being changed"

Can the agile mindset be implemented?

Is the agile mindset implementable? Can we take on the job like that?

Difficult, from my point of view.

The way people behave in systems depends on the set of rules that the system participants accept for the system or not! In many places, the rules simply do not make sense, or no longer do, because they are based on the preservation of a system that consists of outdated mental models. The argument of maintaining stability thus loses its meaning for many. Maintaining the status quo is then often just a denial of the need to maintain meaningfulness.

Attitude and mindset are personal attributes that are difficult to access from the outside. Behaviour is an expression of them. If one wants the attitude or mindset of the staff to improve in the sense of better cooperation, it is worthwhile to look at the question of which systemic and communicative circumstances/rules trigger the behaviour of the people in the system.

The only effective point of intervention is therefore the system itself, i.e. its set of rules [3].

Think about it 🙂

Sources