Coaching Process + Scrum + Agile: What the Marines can teach us about Scrum, Competences and Leadership.
The Marines have had hundreds of years to work out how to organize people towards a common goal in a changing and unpredictable environment, and what they’ve come up with is an approach that’s Agile in all but name.
What the Marines can teach us about Scrum, Competences and Leadership.
Lets look at things what the Marines can tell us about behavior and leadership on an Agile project.
ONE PURPOSE
Every strategist, whether in business or war or industry or other callings, understands the value of organized, co-ordinated effort. Every military strategist understands the value of sowing seeds of dissension in the ranks of the opposing forces, because this breaks up the power of co-ordination back of the opposition.
PLANNING
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 members 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.
SPRINTS
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.
RETROSPECTIVES
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.
SCALING SCRUM
As its popularity increased, Scrum had to scale up from a methodology used by individual teams to one that’s practiced across whole organizations.
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 organization:
...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.
DISORDER
There is a misconception in some quarters that Agile is leaderless or even chaotic. Actually it is neither, it just doesn’t look like top-down project management.
Agile exists because software development takes place in an unstable environment: business priorities and resources fluctuate; challenges and opportunities arise as solutions are explored; stakeholders change their minds.
Accepting that the world is inherently disordered (and that disorder is a source of opportunities as well as difficulties) is fundamental to understanding why Agile trumps up-front planning:
In an environment of friction, uncertainty, and fluidity, war gravitates naturally toward disorder. Like the other attributes of war, disorder is an inherent characteristic of war; we can never eliminate it. In the heat of battle, plans will go awry, instructions and information will be unclear and misinterpreted, communications will fail, and mistakes and unforeseen events will be commonplace. It is precisely this natural disorder which creates the conditions ripe for exploitation by an opportunistic will.
SELF-ORGANIZING TEAMS
Agile methodologies deal with disorder by using self-organizing teams. Individuals and teams are empowered to make decisions and deal with problems as they occur.
This changes the responsibilities of both the managers and the employees that report to them. Without a designated project manager, every member of a self-organizing team must assume responsibility for decision making:
...we should deal severely with errors of inaction or timidity. We will not accept lack of orders as justification for inaction; it is each Marine's duty to take initiative as the situation demands. We must not tolerate the avoidance of responsibility or necessary risk.
DECISION MAKING
With decision making decentralized, critical information about the project tends to be spread throughout the team.
Whoever is charged with setting the direction of the project, or its next iteration (in Scrum it would be the Product Owner), needs to elicit that information from the team in order to make effective decisions.
The environment and culture in which that feedback is gathered - which is determined by the behavior of everyone who participates - is critical:
Relations among all leaders—from corporal to general—should be based on honesty and frankness regardless of disparity between grades. Until a commander has reached and stated a decision, subordinates should consider it their duty to provide honest, professional opinions even though these may be in disagreement with the senior's opinions. However, once the decision has been reached, juniors then must support it as if it were their own. Seniors must encourage candor among subordinates and must not hide behind their grade insignia. Ready compliance for the purpose of personal advancement - the behavior of "yes-men" - will not be tolerated.
MULTI-DISCIPLINARY TEAMS
Agile teams are multi-disciplinary. With everyone in it together and working to a common goal, cross-domain problems and disagreements can be minimized.
Teams are tailored around the successful delivery of complete features and viable products, rather than around common skills or responsibilities:
For operations and training, Marine forces will be formed into Marine air-ground task forces: are task organizations consisting of ground, aviation, combat service support, and command elements. They have no standard structure, but rather are constituted as appropriate for the specific situation. It provides a single commander a combined arms force that can be tailored to the situation faced. As the situation changes, it may of course be necessary to restructure the Tasks again.
OBJECTIVES AND KEY RESULTS
One thing that must be top-down on an Agile project is its objectives. Every task, story, theme and Sprint goal should make sense in the context of a project’s overall Objectives and Key Results.
The intent for a unit is established by the commander assigning that unit's mission—usually the next higher commander, although not always. A commander normally provides intent as part of the mission statement assigned to a subordinate. A subordinate commander who is not given a clear purpose for the assigned mission should ask for one.
Based on the mission, the commander then develops a concept of operations, which explains how the unit will accomplish the mission, and assigns missions to subordinates. Each subordinate mission statement includes an intent for that subordinate. The intent provided to each subordinate should contribute to the accomplishment of the intent a commander has received from above. This top-down flow of intent provides consistency and continuity to our actions and establishes the context that is essential for the proper bottom-up exercise of initiative.
GETTING STUFF DONE
The Agile Manifesto says “we have come to value working software over comprehensive documentation”. The focus of a project team should be the Objective and Key results, and its behavior should reflect whatever is required to deliver viable, ship able products.
The Marines call it focusing on the main effort:
Another important tool for providing unity is the main effort. Of all the actions going on within our command, we recognize one as the most critical to success at that moment. The unit assigned responsibility for accomplishing this key mission is designated as the main effort—the focal point upon which converges the combat power of the force. The main effort receives priority for support of any kind. It becomes clear to all other units in the command that they must support that unit in the accomplishment of its mission. Like the commander's intent, the main effort becomes a harmonizing force for subordinate initiative. Faced with a decision, we ask ourselves: How can I best support the main effort?
During all process for success we need to develop self confidence, competences and leadership.
The War fighting Manual might seem like a surprising source of wisdom for Agile software development, but perhaps it shouldn’t be. Both Agile development and the Marine’s approach to war fighting are ultimately concerned with the effective organization of people and, critically both stem from practice, not theory.
They reflect ideas that have worked in the real world and reject of things that haven’t. The Marines have had hundreds of years to figure out what makes people tick and they operate in an extreme and dangerous environment. It’s no wonder they got there before us.
During all process for success we need to develop self confidence, competences and leadership.