Today, Agile structures are often ahead of hierarchies. They are faster, more flexible, better. That’s mainly because teams organize themselves, which encourages people to get more involved and take on more and different responsibility. But doesn’t that promote self-exploitation? Is Agility in fact a form of modern slavery?
The accusation I often get
Agile is nothing more than a nasty trick designed only to get people and teams to exploit themselves even more. Some time ago, my colleague, Wolf Steinbrecher, dealt with this question very comprehensibly in the Teamworkblog.
His answer at that time: No. The opposite is the case.
First, what we commonly call self-exploitation is actually exploitation. Secondly, agility consciously creates structures to prevent this exploitation.
The reason for this lies
in the lean-influenced Agile mindset, which attempts to permanently contain waste and losses wherever possible, i.e. at all organizational levels – which, in the final analysis, is the secret of Agile success:
Mura – “Imbalance”
Muri – ” Overload”
Muda – ” Wastefulness”
Looking at it closely
then self-exploitation means that people voluntarily (!) decide to exploit themselves or to be exploited. In other words, to do extra things without getting anything out of it.
Yet what about when we choose to sacrifice vacation or time off, work unpaid overtime, be available around the clock, etc.? Are we really doing this voluntarily?
More likely is
that we do this – consciously or unconsciously – because we feel compelled, or at least pushed, to do so – for whatever reason. For example, because we think that “one” can demand it of us, out of fear of losing status or a job, or simply because automatic stress patterns take hold.
But if compulsion is the reason for what we do, it is not self-exploitation. It is exploitation.
We need to do, what we need to do?
It is logical and psycho-logical that we nevertheless speak of self-exploitation, is. For exploitation is deeply rooted in our high-performance culture: today we get recognition (love, praise, good grades, time, money, job, career, etc.) (almost) exclusively in exchange for performance.
From childhood we learn: We will be rewarded if we do what we are told.
This is a normal principle of life for us, and one that we take for granted
even if we may experience other things in an increasing number of areas of life, for example in today’s parent-child relationships.
This shows that the compulsive performance principle is not a force of nature. On the contrary, it has been and is being forced quite purposefully. And that for a very long time.
But because we assume a free will in a free world means that we accept this (compulsive) performance model for us also out of free choice. After all, we make a decision for it ourselves (!), that is, for this kind of “exploitation”. We could also reject it, for example.
Therefore, in the working world and mostly in self-management
every day, the vast majority of us follow the classic, hierarchical, i.e. tending to be rigid, authoritarian-patriarchal image of how things have to run:
Because they (or we) are allowed or even required to do so, members of an organization put pressure on other members of their own or other organizations to make them do things they (presumably) would not have done on their own.
Usually this happens
unconsciously and without reflection, actively and passively. So sometimes we are the ones who push, sometimes we allow ourselves to be pushed – all sandwich managers among us know what that means.
It rarely occurs to us that things can work differently. Although we increasingly reach limits with this principle, e.g. when we become dissatisfied or produce outcomes that are too slow and/or not good enough.
But that is exactly why agile working frameworks like Scrum and Kanban proceed differently
Here, managers do not control or command.
They rather lead in the very best sense. In other words, they make it clear what the company and/or project goals are and provide a good framework for the implementation teams.
In turn, the teams and their subject matter experts decide on the implementation: Which task is given which priority? When will which task be done? Who will do it?
As little management as possible should be done. And if there is management, it should be done to really add value and to really make sense. Primarily, that is, to help teams do their work. After all,they should deliver on time the results that the company has agreed on – together.
(By the way, one can rightly ask what is new and different about this, compared to classical management theory. The answer is: Little. Agility, however, is now implementing organizationally what we have known for many decades).
“Where would we get to…?”
For this to happen, expectations are constantly synchronized and, if necessary, roles and decision-making hierarchies are adjusted. Because depending on the role, task and area of responsibility, each team member may and must (!) decide for themselves and/or together in the team what is processed and when.
That’s why agility pays attention to the “sovereignty” of team members: Anyone who is supposed to decide must know their scope for decision-making and needs decision-making power to do so. Only in this way does the principle of pull vs. push work.
To work in an Agile manner means to collaborate in an positive and trusting way
And, above all, to create appropriate structures for this. For example, by abolishing superfluous control structures. This creates organizational freedom, raises potentials and exposes the view on value creation, i.e. on those things that interest the customer and the investors.
Distrustful hierarchical organizational forms naturally have difficulties in comprehending this.
In agile structures, however, people are
experts who work at eye level. So: for real this time. And not just for the image brochure, as has been the case in the past.
Because their task is to contribute to the maximum. As experts and also as experts on processes in their own work, who not only have their own specialist area in mind, but also think for the big picture. Also in organizational matters.
This is of course also appreciative and motivating. From an organizational point of view, it is above all smart.
Because in this way, the experts can do what in hierarchical structures is difficult for them due to a bureaucratic (e.g. reporting) and organizational (e.g. meetings) overbuild: Do their actual work. And do it when it suits them best and makes the most sense.
And also organized in a way that is good for them, for the results and for the team.
And that precisely not as the task of the individual, but as a decision that is made jointly by the team within the framework of an orderly and clocked process. And the management and/or the client also belong to the team.
So, does working agile push exploitation or even self-exploitation?
It certainly can’t be ruled out, and in our performance culture I even think it is quite likely, that agile working will be abused for this purpose. Nevertheless:
It contradicts everything that agile structures are intended to do and achieve
Agile working needs a clear, open and fear-free environment. It needs self-confident people who want to produce good results with and within the team and therefore want to learn together and do so. Errors, conflicts and grievances are regularly handled well and purposefully here.
So this means: Agile teams or organizations which tend to work under pressure and fear tend to “exploit” or tend to exploit themselves. Means: They simply don’t work in an Agile way.
It is important to realize that this state of self-exploitation is not a natural phenomenon. It’s up to us to change that.
And we CAN change this. But only if we decide to do so by ourself.
Today, Agile structures are often ahead of hierarchies. They are faster, more flexible, better. That’s mainly because teams organize themselves, which encourages people to get more involved and take on more and different responsibility. But doesn’t that promote self-exploitation? Is Agility in fact a form of modern slavery?
The accusation I often get
Agile is nothing more than a nasty trick designed only to get people and teams to exploit themselves even more. Some time ago, my colleague, Wolf Steinbrecher, dealt with this question very comprehensibly in the Teamworkblog.
His answer at that time: No. The opposite is the case.
First, what we commonly call self-exploitation is actually exploitation. Secondly, agility consciously creates structures to prevent this exploitation.
The reason for this lies
in the lean-influenced Agile mindset, which attempts to permanently contain waste and losses wherever possible, i.e. at all organizational levels – which, in the final analysis, is the secret of Agile success:
Mura – “Imbalance”
Muri – ” Overload”
Muda – ” Wastefulness”
Looking at it closely
then self-exploitation means that people voluntarily (!) decide to exploit themselves or to be exploited. In other words, to do extra things without getting anything out of it.
Yet what about when we choose to sacrifice vacation or time off, work unpaid overtime, be available around the clock, etc.? Are we really doing this voluntarily?
More likely is
that we do this – consciously or unconsciously – because we feel compelled, or at least pushed, to do so – for whatever reason. For example, because we think that “one” can demand it of us, out of fear of losing status or a job, or simply because automatic stress patterns take hold.
But if compulsion is the reason for what we do, it is not self-exploitation. It is exploitation.
We need to do, what we need to do?
It is logical and psycho-logical that we nevertheless speak of self-exploitation, is. For exploitation is deeply rooted in our high-performance culture: today we get recognition (love, praise, good grades, time, money, job, career, etc.) (almost) exclusively in exchange for performance.
From childhood we learn: We will be rewarded if we do what we are told.
This is a normal principle of life for us, and one that we take for granted
even if we may experience other things in an increasing number of areas of life, for example in today’s parent-child relationships.
This shows that the compulsive performance principle is not a force of nature. On the contrary, it has been and is being forced quite purposefully. And that for a very long time.
But because we assume a free will in a free world means that we accept this (compulsive) performance model for us also out of free choice. After all, we make a decision for it ourselves (!), that is, for this kind of “exploitation”. We could also reject it, for example.
Therefore, in the working world and mostly in self-management
every day, the vast majority of us follow the classic, hierarchical, i.e. tending to be rigid, authoritarian-patriarchal image of how things have to run:
Because they (or we) are allowed or even required to do so, members of an organization put pressure on other members of their own or other organizations to make them do things they (presumably) would not have done on their own.
Usually this happens
unconsciously and without reflection, actively and passively. So sometimes we are the ones who push, sometimes we allow ourselves to be pushed – all sandwich managers among us know what that means.
It rarely occurs to us that things can work differently. Although we increasingly reach limits with this principle, e.g. when we become dissatisfied or produce outcomes that are too slow and/or not good enough.
But that is exactly why agile working frameworks like Scrum and Kanban proceed differently
Here, managers do not control or command.
They rather lead in the very best sense. In other words, they make it clear what the company and/or project goals are and provide a good framework for the implementation teams.
In turn, the teams and their subject matter experts decide on the implementation: Which task is given which priority? When will which task be done? Who will do it?
As little management as possible should be done. And if there is management, it should be done to really add value and to really make sense. Primarily, that is, to help teams do their work. After all,they should deliver on time the results that the company has agreed on – together.
(By the way, one can rightly ask what is new and different about this, compared to classical management theory. The answer is: Little. Agility, however, is now implementing organizationally what we have known for many decades).
“Where would we get to…?”
For this to happen, expectations are constantly synchronized and, if necessary, roles and decision-making hierarchies are adjusted. Because depending on the role, task and area of responsibility, each team member may and must (!) decide for themselves and/or together in the team what is processed and when.
That’s why agility pays attention to the “sovereignty” of team members: Anyone who is supposed to decide must know their scope for decision-making and needs decision-making power to do so. Only in this way does the principle of pull vs. push work.
To work in an Agile manner means to collaborate in an positive and trusting way
And, above all, to create appropriate structures for this. For example, by abolishing superfluous control structures. This creates organizational freedom, raises potentials and exposes the view on value creation, i.e. on those things that interest the customer and the investors.
Distrustful hierarchical organizational forms naturally have difficulties in comprehending this.
In agile structures, however, people are
experts who work at eye level. So: for real this time. And not just for the image brochure, as has been the case in the past.
Because their task is to contribute to the maximum. As experts and also as experts on processes in their own work, who not only have their own specialist area in mind, but also think for the big picture. Also in organizational matters.
This is of course also appreciative and motivating. From an organizational point of view, it is above all smart.
Because in this way, the experts can do what in hierarchical structures is difficult for them due to a bureaucratic (e.g. reporting) and organizational (e.g. meetings) overbuild: Do their actual work. And do it when it suits them best and makes the most sense.
And also organized in a way that is good for them, for the results and for the team.
And that precisely not as the task of the individual, but as a decision that is made jointly by the team within the framework of an orderly and clocked process. And the management and/or the client also belong to the team.
So, does working agile push exploitation or even self-exploitation?
It certainly can’t be ruled out, and in our performance culture I even think it is quite likely, that agile working will be abused for this purpose. Nevertheless:
It contradicts everything that agile structures are intended to do and achieve
Agile working needs a clear, open and fear-free environment. It needs self-confident people who want to produce good results with and within the team and therefore want to learn together and do so. Errors, conflicts and grievances are regularly handled well and purposefully here.
So this means: Agile teams or organizations which tend to work under pressure and fear tend to “exploit” or tend to exploit themselves. Means: They simply don’t work in an Agile way.
It is important to realize that this state of self-exploitation is not a natural phenomenon. It’s up to us to change that.
And we CAN change this. But only if we decide to do so by ourself.
Wir verwenden Cookies, um unsere Website Service zu optimieren.
Funktional
Always active
Die technische Speicherung oder der Zugang ist unbedingt erforderlich für den rechtmäßigen Zweck, die Nutzung eines bestimmten Dienstes zu ermöglichen, der vom Teilnehmer oder Nutzer ausdrücklich gewünscht wird, oder für den alleinigen Zweck, die Übertragung einer Nachricht über ein elektronisches Kommunikationsnetz durchzuführen.
Vorlieben
Die technische Speicherung oder der Zugriff ist für den rechtmäßigen Zweck der Speicherung von Präferenzen erforderlich, die nicht vom Abonnenten oder Benutzer angefordert wurden.
Statistiken
Die technische Speicherung oder der Zugriff, der ausschließlich zu statistischen Zwecken erfolgt.Die technische Speicherung oder der Zugriff, der ausschließlich zu anonymen statistischen Zwecken verwendet wird. Ohne eine Vorladung, die freiwillige Zustimmung deines Internetdienstanbieters oder zusätzliche Aufzeichnungen von Dritten können die zu diesem Zweck gespeicherten oder abgerufenen Informationen allein in der Regel nicht dazu verwendet werden, dich zu identifizieren.
Marketing
Die technische Speicherung oder der Zugriff ist erforderlich, um Nutzerprofile zu erstellen, um Werbung zu versenden oder um den Nutzer auf einer Website oder über mehrere Websites hinweg zu ähnlichen Marketingzwecken zu verfolgen.