Author: Lionel Le Boiteux
Our CTO, Clayton Locke, recently handed me a copy of the US Marines’ ‘Warfighting’ manual. He’d picked up the book from his son, a Marine, and thought that how the Marines go about their business had something to say about how we do ours.
I was relieved that he wasn’t giving me some subtle career advice but I was a little sceptical: ever since movie villain Gordon Gekko told his protégé to “read Sun Tzu, The Art of War”, comparing war and business has been a bit of a Hollywood cliché.
That was before I’d read it.
By the time I was finished I was left with the impression that if you asked a group of US Marines to develop some software they’d probably invent Scrum to manage the project.
The Marines have had hundreds of years to work out how to organise people around the effective pursuit of a goal in a changing and unpredictable environment. Ideas that didn’t work didn’t last, and what’s left over has passed the harshest tests of history.
This month I examine four things the US Marines can teach us about the structure of a Scrum project. In next month’s second part I’ll conclude my 10 things by looking at what the Marines can tell us about behaviour and leadership on an Agile project.
2001’s Agile Manifesto challenged the traditional approach to planning software projects. We value following a plan, it said, but we value responding to change more.
Scrum projects enshrine this approach with Sprints of work separated by moments of reflection and planning. The regular planning meetings look at the journey the project has made and how plans, priorities and resources have been changed by it.
The Marines would understand:
Like friction and uncertainty, fluidity is an inherent attribute of war. Each episode in war is the temporary result of a unique combination of circumstances, presenting a unique set of problems and requiring an original solution. Nevertheless, no episode can be viewed in isolation. Rather, each episode merges with those that precede and follow it—shaped by the former and shaping the conditions of the latter—creating a continuous, fluctuating flow of activity replete with fleeting opportunities and unforeseen events. Since war is a fluid phenomenon, its conduct requires flexibility of thought. Success depends in large part on the ability to adapt—to proactively shape changing events to our advantage as well as to react quickly to constantly changing conditions.
Agile methodologies tend to break projects down into iterations, and in Scrum those iterations are called Sprints.
The name is a big clue about how they should feel when you’re doing them: a Scrum project with ten iterations isn’t a marathon in ten parts, it’s ten dashes with breaks for recovery, reflection and re-planning:
It is physically impossible to sustain a high tempo of activity indefinitely, although clearly there will be times when it is advantageous to push men and equipment to the limit. The tempo of war will fluctuate from periods of intense combat to periods in which activity is limited to information gathering, replenishment, or redeployment. Darkness and weather can influence the tempo of war but need not halt it.
Soliciting and learning from feedback is an essential part of all Agile methodologies. Each Sprint in a Scrum project ends with a retrospective meeting so that feedback can be gathered and used to influence the next Sprint.
Members of the team are expected to provide an honest commentary on both the project and the methodology being used to run it:
Critiques are an important part of training because critical self-analysis, even after success, is essential to improvement. Their purpose is to draw out the lessons of training. As a result, we should conduct critiques immediately after completing training, before memory of the events has faded. Critiques should be held in an atmosphere of open and frank dialogue in which all hands are encouraged to contribute. We learn as much from mistakes as from things done well, so we must be willing to admit mistakes and discuss them. Of course, a subordinate’s willingness to admit mistakes depends on the commander’s willingness to tolerate them. Because we recognize that no two situations in war are the same, our critiques should focus not so much on the actions we took as on why we took those actions and why they brought the results they did.
4. Scaling Scrum
As its popularity increased, Scrum had to scale up from a methodology used by individual teams to one that’s practised across whole organisations.
Since Scrum wasn’t originally imagined on that scale, it’s had to adapt over time and the model that’s emerged, Scrum of Scrums, is one that mirrors the hierarchy of independent units detailed in the Marines’ own approach to organisation:
…each belligerent is not a single, homogeneous will guided by a single intelligence. Instead, each belligerent is a complex system consisting of numerous individual parts. A division comprises regiments, a regiment comprises battalions, and so on all the way down to fire teams which are composed of individual Marines. Each element is part of a larger whole and must cooperate with other elements for the accomplishment of the common goal. At the same time, each has its own mission and must adapt to its own situation. Each must deal with friction, uncertainty, and disorder at its own level …
As a result, war is not governed by the actions or decisions of a single individual in any one place but emerges from the collective behavior of all the individual parts in the system interacting locally in response to local conditions and incomplete information … Efforts to fully centralize military operations and to exert complete control by a single decision maker are inconsistent with the intrinsically complex and distributed nature of war.