Every so often I have the opportunity to deliver ‘Agile Concepts’ courses for managers at large (sometimes very large) software companies. One question that always comes up is what leadership means within an Agile team and/or organisation. Last year I chanced upon the video below that seems to sum up the answer perfectly. In this post I would like to expand and clarify on its implications for software teams, so please watch before continuing further…
Historically our model of leadership is often summarised as ‘command and control’. The leader is assumed to have superior expertise and wisdom than his subordinates, based on their more extensive education and/or greater time in the industry. Heavily cliched examples include the gifted Harvard MBA managing a car plant full of assembly line workers or the refined Oxbridge officer leading a division of ‘salt of the earth’ squaddies.
In the modern world, and especially in IT, this is rarely going to be the case. Given the pace of change in our industry it is guaranteed that the workers at the coalface will be the only ones who truly understand the technology. Over the past few years areas like Cloud Computing, Single Page Applications and Machine Learning have been growing at such speed that only dedicated specialists can claim to be au fait with the state of the art. Having ’20 years in the industry’ increasingly seems less like an assurance of trust and more like the reverse (as an aspiring ‘old codger’ in his 40’s I take no pleasure in saying that).
If we keep with the military theme then our model of leadership should be the special forces team, rather than any conventional regimental hierarchy. In these teams every individual is a master of their speciality and the group leader can never hope to match them all. A great resource for appreciating how and why these teams evolved from the conventional military is ‘The Jungle is Neutral’ - a famous first hand account of guerrilla warfare against the Japanese in the Malayan Peninsula during WWII. Within his account the author (Spencer Chapman) remarks early on that:
Experience had shown me that to be successful an enterprise of this nature must be run more on the lines of a polar or climbing expedition than a military exercise. In the former the discipline is just as strong but much more light-hearted, though a basis of military training and knowledge is essential.
During the early history of unconventional warfare (such as the SAS in WWII or the Seals in Vietnam) most early successes were based on subverting conventional chains of command, acting on the personal initiative of junior officers and working as a unified team without rank or deference. In other words what would be referred to in engineering as ’skunkworks’ projects. There is a close parallel between the arrival of unconventional warfare in the military and the advent of Agile within industry - in both cases there was substantial resistance from traditional power structures and vested interests which was painfully and incrementally worn away by the need to face up to a more volatile and uncertain world. You can see this closeness in the terminology, for example anyone who has tried to implement Agile in an Enterprise organisation will immediately understand the meaning of the military acronym UNODIR:
UNODIR, or "UNless Otherwise DIRected" is a military acronym used to describe the practice of not checking with the officers in command whether it is acceptable to do what you want to do. Instead, you simply file a report outlining what you'll do and drop it into the bureaucratic apparatus, stamped UNODIR. The nature of red tape is such that there is almost no chance of anyone seeing your report until it is way too late. (http://www.urbandictionary.com/)
A lesson to take from all this is that leaders in rapidly evolving domains should facilitate progress rather than give orders, and those that choose to wield authority from the top down are already on the road to failure. In many ways this is a very old idea. In the the 1965 Sci-Fi classic Dune author Frank Herbert writes the following exchange between the boy prince Paul Atredies and his mentor Thufur Hawat:
‘She asked me to tell her what it is to rule,’ Paul said. ‘And I said that one commands. And she said I had some unlearning to do.’
She hit a mark there right enough, Hawat thought. He nodded for Paul to continue.
’She said that a ruler must learn to persuade and not to compel. She said he must lay the best coffee hearth to attract the finest men’
If you ignore the sexism I don’t think you will find a better summary of how an Agile team should work. As David Marquet notes in the video when the team members understand both their jobs and the goals of the project they should be the ones who choose what to do and when to do it. Its no accident that most companies are at their most creative in their early years when they have a flat management structure and everyone is focused on survival to the next quarter. Once hierarchies are established and the common good is diffused into ‘targets’ the creativity starts to fade. Recent trends in progressive organisations try to reverse this effect, such as those companies that have abandoned the Victorian era concept of fixed holidays.
Recent years have seen a the emergence of 'semi-Agile' or 'business friendly Agile' processes, the most popular of these being Scrum. As Dr Evil might say these are the Diet Coke of Agile or the Margarine of Agile. They are Agile with the most important and revolutionary parts taken out.
In many ways Agile is being diluted to almost homeopathic concentrations. As Allen Hollub puts it in The Death Of Agile real Agile puts the team completely in control of their own destiny:
If I need the training I need it now, not in six weeks. If I need a new piece of software I need it now. An Agile team has a budget, and it spends it however they feel like it. If the entire team decides to go off to a conference they do that. They don't ask anybody, they just do it. If they need to buy a piece of software they do it. Now they've got to manage their budget, the budget is not infinite, but they're the ones making the choice. Not some separate governance related organisation.
As I see it there are two key difficulties in implementing this approach. The first is that (as stated in the original video) when we become a leader all of our evolutionary programming fights against giving up control. In hierarchical systems it has always been the case that the leader kept information back to assure his or her position and guarantee their ability to nominate a successor. For example in the world of martial arts it was customary for every technique to have several (increasingly efficient) applications and the truly effective versions to be concealed from all but the most senior students. What the Japanese called the ‘Okugi’ (the secret techniques) would only be shown to the chosen heir when the grand masters health failed and they were compelled to pass on the torch. Similarly companies using the anti-pattern of ‘water-scrum-fall’ frequently try to give teams only the illusion of control in order to assign responsibility whilst retaining authority. In my experience this does not work.
The second difficulty is that not all team members want to have the burden of command placed upon them. In our industry we often place a lot of responsibility onto very young shoulders, some flourish whereas others flounder. Dilbert sums this up perfectly.
However any organisation that fights through these issues will have a massive advantage over the competition. I can end with no better summary than this quote near the end of the video…
I don’t care who smart you are. On my submarine I got a hundred and thirty five thinking, active, passionate, creative, proactive, taking initiative people. Its a tidal wave. You don’t stand a chance.
