When do you intervene as #AgileLeader ? (#self-steering)

Self-steering or self-organisation that is the question

In an attempt to solve the confusion around self-steering, we have come up with the clever idea that we actually mean self-organisation. A handsome language game, which, incidentally, has not brought us a solution to the confusion. I first discuss self-steering and then continue with self-organisation. I also look at the role that an AgileLeader plays in this.

Self-steering

A self-steering team determines its own direction, that’s the meaning of the word. If someone else imposes his/her will, the team stops being self-steering. Agile teams, where a product owner and a scrum master (or agile coach) are involved, are therefore by definition not self-steering. When they need to adhere to a chosen agile framework (Safe, Less, Nexus, etc.), they are only partly autonomous in choosing the way of working together and the techniques they use. One might ask: ‘How autonomous’? If there is also a technical architecture, their choices are even more limited. When you are dealing with several teams, working on the same solution, how can you talk about autonomy? The more interdependency, the less self-steering. This is why scaling agile is so difficult. In short, autonomy is not that evident in the current forms of agile working. It is a myth!

Autonomy requires one single free will, which is rather complicated with a team. After all, a team consists of at least two people, so there are two distinct wills that have to agree on the small part in the whole on which they still have autonomy. Increasing the number of team members reduces the autonomy of the individual even further. With a tribe of 150 men and women, there is little left of individual autonomy. The only solution is groupthink, when the team functions as a unit. This is the fate of every well-functioning team! Because of the group pressure, the cognitive dissonance in the team is great and any dissenting opinion will be silenced. We no longer notice any signs of malfunctioning. The team is now completely self-steering and steers itself up the mountain or into the abyss. Self-steering does not necessarily lead to success.

Self-organising

The argument that we actually mean self-organisation when we speak self-steering does not bring us the desired solution, but it does lead to a new insight. By self-organization we mean ‘something’ that comes from within without an outside cause. Everything that somewhat resembles a network has this characteristic, chaos creates a balance, of itself, because that is the definition of self-organisation. If the cause came from outside, it would no longer be a self-organisation.

The question is whether this self-organisation actually exists. Is it not actually just the structure that we humans impose on something we don’t understand? The swarm of birds that are looking for a place for the evening fly this way because this requires the least aerodynamic energy. No bird organises, no wisdom or crowds, no god interferes with it, it is just as it is. It is self-organisation without a self and without organisation.

What is the alternative?

Logically, we can do nothing with self-organization and certainly nothing with self-steering. These are wrong names used for a way of working that is popular nowadays. Which language games do we have to play in order to arrive at a logical concept?

A good description for such a team can therefore no longer contain the words autonomy, self-steering or self-organisation. This requires a bit of linguistic artwork, which I hope will lead to something. Forget the word team, we’re talking about people who work together and where the agile leader, like any good manager, only intervenes when they no longer deliver value.

So we are no longer talking about self-steering or self-organising teams, but about value-driven people working together. As long as they deliver value, there is nothing wrong with them and nobody needs to intervene. As soon as the value stream dries out, someone will intervene, you can be sure of that. If that is not the agile leader, I can guarantee that an old-fashioned manager will pull the plug.

This blog is also in Dutch.

#Agility begin bij zelfkennis

Zelfkennis essentieel

Wanneer we kijken naar alle competentie elementen die een agile leider moet bezitten dan is zelfkennis een van de belangrijkste. Zonder zelfkennis geen agility. Voordat ik dieper op zelfkennis in ga wil ik eerst agility toelichten, want dit relatief nieuwe woord heeft zijn weg nog niet gevonden naar de verklarende woordenboeken. Uit het woord zelf is ook niet af te leiden wat het betekent, dus moeten we kijken naar hoe mensen het gebruiken.

Wanneer bent je agile?

Een organisatie is agile wanneer het snel kan reageren op veranderingen in de omgeving en wel op zodanige manier dat het waarde kan blijven leveren voor degenen die deze waarde nodig hebben. Wie dat zijn, is meestal een keuze van de betreffende organisatie. Dus agile ben je wanneer je blijvend waarde kunt leveren aan mensen die jij gekozen hebt, omdat deze op de een of andere manier belangrijk voor je zijn.

Ik denk dat als een organisatie agile wil zijn haar medewerkers dat ook moeten zijn. Je bent dus agile wanneer je blijvend van waarde bent voor de mensen die je belangrijk vindt. Liever gebruik ik een Nederlands woord voor agile en mijn voorkeur gaat uit naar wendbaar. Je bent wendbaar wanneer je van waarde blijft voor de mensen die jij belangrijk vindt.

Agile, hoe word je en hoe blijf je het?

In het begin heb ik al gezegd dat zelfkennis een belangrijke eigenschap voor de agile leider is, overigens is dat het eigenlijk voor iedereen. De vorm van zelfkennis waar ik het nu over heb is het onderkennen of je wel/niet van waarde bent voor een ander. Dit is een heftige confrontatie, want we zijn vaak zo met onszelf ingenomen dat we niet eens weten of mensen wel op de tentoonspreiding van ons ego zitten te wachten. Ik kwam eens een agile coach tegen die vaak zei dat hij meer recht van spreken had dan ik omdat hij meer ervaring had. Wel je kunt je voorstellen dat ik hem snel uit mijn lijst belangrijke mensen heb geschrapt. Ik had geen behoefte meer om voor hem van waarde te zijn.

Naarmate we onszelf ontwikkelen bouwen we een zelfbeeld op. De goede eigenschappen gaan naar de voorgrond van ons bewustzijn en de zwakke punten naar de achtergrond. Dit is essentieel voor het ontwikkelen van een gezonde geest. Wanneer het omgekeerd zou zijn dan denk je te min over jezelf en ontbreekt het vaak aan het nodige zelfvertrouwen. Dit is iets wat ik niemand toewens omdat dat vaak gepaard gaat met groot psychisch lijden. De mensen die voldoende zelfvertrouwen hebben zijn vaak ook succesvoller of ervaren hun succes veel fijner.

Het probleem met succesvolle mensen

Doordat ze succesvoller zijn maken ze een fundamentele redeneerfout. Ze denken dat dit te maken heeft met hun eigen vaardigheden. Voor een klein deel is dat zo, maar voor het overgrote deel is het puur geluk wanneer je succesvol bent. Iemand daarop aanspreken is moeilijk omdat feedback over de zwakke punten hun zorgvuldig opgebouwde zelfbeeld ineen doet storten. Toen ik de, eerder genoemde, agile coach terugkoppeling gaf op zijn gedrag, ging hij volledig door het lint. Interessant was het om te zien hoe hij bij mij van zijn voetstuk viel en niet echt meer van waarde voor mij was. Jammer voor hem want ik had wel meer levenservaring en hij had, net als ik van hem, veel kunnen leren.

Agile word je door jezelf te kennen, met name wanneer de belangrijke anderen ineens iets anders van je nodig hebben, begrijp je dan snel genoeg dat jij moet veranderen? Als je dan kunt veranderen is dat een voorbeeld zelfmanagement! Zelfkennis zonder zelfmanagement is van weinig waarde.

Zelfkennis alleen van waarde als deze op een ander is gericht

Dit brengt me op een ander punt, namelijk dat zelfkennis bij agile werk altijd in relatie tot een ander staat. Als je in een waardegedreven groep mensen (ook wel een zelfsturend team genoemd) samenwerkt dan kunnen jullie alleen gezamenlijk agile zijn wanneer de individuen dat ook zijn. Je moet zogezegd op elkaar kunnen bouwen. Dat is de reden waarom we op zoek zijn naar de ‘T-shaped’ specialist. Omdat wanneer je veel specialismen hebt je bijna overal wel inzetbaar bent.

Zelfkennis betekent daarom dat je je plek in het team weet, dat je bij alles wat je doet je nadenkt welke gevolgen dat heeft voor een ander teamlid en uiteindelijke voor de klant. Zowel in de specialistische als in de sociale vaardigheden! In het team zoek jij zelf naar je plaats, je vult de gaten die anderen laten liggen.

#Agile for all industries

(note: this blog is also in Dutch)

The Agile Manifesto was originally written for software development. It has had a huge impact on the way in which we have started to organise IT work. However, there is a serious flaw if you want to apply it in sectors other than IT. I am going to correct this flaw by rewriting the manifesto. My intention is to reduce the influence of IT thinking on agile development and challenge people from other industries to think along. The agile ideology is too important to leave it to IT professionals alone.

The old Manifesto (for software development)

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan

That is, while there is value in the items on the right, we value the items on the left more.

On our way to the new manifesto

The sentences can remain largely intact, I replace ‘working software’ with’ working services/products and finished work’, but this has not yet repaired the flaw. There is still something missing that the authors of the Manifesto have overlooked. Without that, the agile transition in IT would not have been possible.

The missing link is the actor technology (you are indeed reading ‘actor’ and not’ factor’), which has a much greater influence than you would think. It is a different type of actor than a human being who has a will of his own, but that does not alter the fact that technology has a greater influence than we admit. Without technology, it would have been impossible that the agile revolution in the IT would have progressed in the way it has. Automatic testing, devops, does not go without technology. It is technology that has been the engine behind the agile transition, not the Manifesto. It is not agile work that has brought about the digital revolution, but vice versa, because of the digital revolution we have started working agile.

This is the main reason why agile in the way it is promoted is difficult to transfer to other industries than IT. Each industry uses its own technology that determines the way it works. After all, there is little to sprint for a large infrastructural work, and dedicated teams are often not feasible. However, when we consciously opt for innovative technology that supports agile working, then it may well be possible. For example, I’m convinced that 3D printing, AI, automatic cars and augmented reality will make agile work possible in many other sectors.

The new generally applicable agile manifesto

I now come to an updated version of the Manifesto:

  • Innovative agile supporting technology above proven technology.
  • Individuals and interactions over processes and tools.
  • Working software over comprehensive documentation.
  • Customer collaboration over contract negotiation.
  • Responding to change over following a plan.

 

That is, while there is value in the items on the right, we value the items on the left more. We also consider technology to be the driving force in all attempts to become agile.

This seems to me to work better than the old manifesto.