Agile methodologies - Dramatic shot of Drill Instructors saluting the U.S. flag during the graduation of recruits from US Marine Corps Recruit Depot, Parris Island, SC.

10 things the Marines can teach us about Agile – part 2

Author: Lionel Le Boiteux

Intelligent Environments’ CTO Clayton Locke recently handed me a copy of the US Marines’ Warfighting manual. The Marines have had hundreds of years to work out how to organise 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.

Last month I looked at what the Marines can teach us about Scrum. This month I finish my list of 10 things by looking at what the Marines can tell us about behaviour and leadership on an Agile project.

5. 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.

Agile exists because software development takes place in an unstable environment Click To Tweet

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.

6. Self-organising teams 

Agile methodologies deal with disorder by using self-organising 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-organising 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.

7. Decision making

With decision making decentralised, 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 behaviour 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.

8. 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 minimised.

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 (MAGTFs). MAGTFs 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. The MAGTF 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 MAGTF.

9. Objectives and Key Results (OKRs)

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 (OKRs):

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.

10. 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 OKRs, and its behaviour should reflect whatever is required to deliver viable, shippable products.

The Marines call it focussing 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?

Conclusion

The Warfighting 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 warfighting are ultimately concerned with the effective organisation 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.

Click here to read Part 1 of this blog 

 

Agile methodologies - Dramatic shot of Drill Instructors saluting the U.S. flag during the graduation of recruits from US Marine Corps Recruit Depot, Parris Island, SC.
13 Apr 2017

Author: Lionel Le Boiteux

Intelligent Environments’ CTO Clayton Locke recently handed me a copy of the US Marines’ Warfighting manual. The Marines have had hundreds of years to work out how to organise 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.

Last month I looked at what the Marines can teach us about Scrum. This month I finish my list of 10 things by looking at what the Marines can tell us about behaviour and leadership on an Agile project.

5. 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.

Agile exists because software development takes place in an unstable environment Click To Tweet

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.

6. Self-organising teams 

Agile methodologies deal with disorder by using self-organising 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-organising 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.

7. Decision making

With decision making decentralised, 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 behaviour 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.

8. 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 minimised.

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 (MAGTFs). MAGTFs 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. The MAGTF 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 MAGTF.

9. Objectives and Key Results (OKRs)

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 (OKRs):

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.

10. 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 OKRs, and its behaviour should reflect whatever is required to deliver viable, shippable products.

The Marines call it focussing 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?

Conclusion

The Warfighting 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 warfighting are ultimately concerned with the effective organisation 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.

Click here to read Part 1 of this blog