Because the team cannot do this on its own – then the team would already be self-sufficiently organized – it has to come from somewhere else. But what do I do now as an agile coach? Convincing the colleagues? A tedious task and I cannot rely on it that they are actually going to do it then. What about workshops? Or certificates? What about the official company and management strategies?
Authoritarian management
Help does arrive, but from an unlikely source: from the authoritarian management.
Simply command it to the colleagues. Say it: This is a management instruction; you have to do it like that from now on.
Of course, the agile coach knows that this explicit instruction and the expectation that the colleagues will implement this correctly, even without any self-interest or personal responsibility, has to be evaluated rather critically. On the one hand, agile has come to deliver a better adaptation through decentralised decision-making. But on the other hand: I already know that this will be good for the colleagues, so it would be legitimate in this case. And so, as an agile coach, I take the liberty to rely on tried and tested management traditions – be that as a benevolent dictator or in a corporate style, through an official management instruction claimed by me.
Binding, quick and sustainable?
Suddenly the classic management seems explicitly more seductive as it was before because this time it serves my own interests. This time it serves the right purpose and the solution is so much easier to obtain instead of implementing it by coaching:
- The colleagues are not doing the right thing? They need a decree from the management?
- A colleague is disturbing the team? He needs a clear message from the higher-ups!
- The team does not like my process? Where is the company’s statement that this is the way how things are now?
- The team does not want to cooperate? The lead must put him in another team!
- The colleague criticizes my decisions in front of all people? Management should kick him out of the company, because he is a troublemaker.
With each of these decisions – each time that I as an agile coach pull classic hierarchy and authority out of my hat – I believe that I am getting a binding, quick and sustainable solution.
The new agile manager
In truth, however, I do something else: I do not solve problems; I only change the formal world, regardless of whether the informal, true world follows this guideline then or not. If it does not work out then it would not be my problem anyway, but a management or employee failure. If the management instruction is not followed then it is a problem for the management and colleagues not mine. If management fails to take action then it has to crackdown even harder!
And suddenly agile becomes an infamous form of classic authoritarian leadership, in which personal responsibility and self-organisation is demanded, but now it is one’s own responsibility for the management’s decisions and the self-organisation according to strict guidelines.
I suddenly slipped from the role of the agile coach into the role of the classic manager, who does the same thing as generations of bad managers did before him: I do not take colleagues seriously, I do not trust their decision-making power, I ignore their competence and I expect them to follow instructions instead of thinking and designing for themselves. Except that I use the agile pretext to legitimize myself – while at the same time actively preventing the emergence of real agility, showing the colleagues that everything comes still down to hierarchical management in end.
Agile Misunderstandings
Agile methods have a clear intention: They want to increase the added value in the creation of software. For this purpose, agile methods offer a whole stack of values, principles and methods supporting this.
In practice the intentions behind these tools are often no longer so clear, and sometimes they are completely lost; the method remains with its intricacies and hooks, but without the desired effect. This is the kind of agile misunderstanding I want to report here – and how to deal with it. For that purpose I wrote these articles.
The article by Johann-Peter Hartmann is published for the first time in a German version of the blog of Mayflower GmbH.
The post Agile misunderstandings appeared first on JAXenter.
Source : JAXenter
