Mission Orders, 6 military principles that can work for agile teams

Yesterday, I was watching a documentary on the "Battle of the bulge" A famous battle in World war 2. The docu makers were investigating German tactics during the battle. Specifically, tactics which had worked so well early in the war, over extended periods of time, towards the end of the war, fell apart after 3-5 days.
Early in the war, German officers had Mission Command, that is, Hitler and high command had high trust in their teams. As the war went on, and things started to go wrong, mission command was gradually eroded as trust fell (especially when his officers tried to kill him).
Mission command basically means, set the goal, let the teams be responsible for how they are carried out. Training is centred around this, discipline and training carry you through the unexpected, as long as you know the end goal.
Effectively, the German high command no longer trusted the lower ranks, and only gave them enough information, goals etc for the immediate goals and set them on their way. Once situation changed, the soldiers were disempowered and the strategy collapsed. Thus, this helped contribute to the collapse (thank goodness) of German team cohesion and the end of the war.
Anyhoo, this led me to look up Mission Command, and it's guiding principles. It's very interesting and people have already made the connections with software (and other teams). Here are Mission command's six principles as currently taught in US military academies (with the word 'orders' and 'commanders' replaced with team friendly terms)
1. Build Cohesive teams through trust
2. Create a shared understanding
3. Provide a clear intent (I reworded this from: Provide a clear commanders intent)
4. Exercise disciplined initiative
5. Use mission goals (reworded from Use Mission orders)
6. Accept prudent risk
They are pretty cool principles, what do you think?

Comments

Post a Comment

Popular posts from this blog

Using an agile storyboard as a scale of certainty

Image
As per my previous post, In my current team we have started using a 'Just in Time' (see how I feel weird about saying Kanban, not sure why yet) approach to doing various activities around development. Mostly this is around planning, but in that sense, we are also doing as much Just inTime as possible in giving an estimate. Scene setting We are a team that does 2 week sprints, but we also don't do a major release at the end of each sprint. We tend to wait for 5 sprints to pass before we do releases, there are a number of organisational reasons for that, but suffice to say, thats the way we do it around these parts. Our story wall (in ugly table form) The table below is a basic representation of our Story wall. As you can see, for the story wall, we deliberately do not just focus on the current 2 week sprint. We also have columns heading beyond the current sprint to encapsulate the entire release timeline (in this case the team have already completed two sprints so their are
Read more

A survey on release processes with organisations that 'sef-identify' as folowing agile practises.

Image
Earlier this year I ran a survey around ‘release processes’ specifically with companies that follow agile practices. I promised that I would publish the results and apologies for the delay, I have collated the responses below. Thanks to everyone that participated, really appreciate your time and energy. At iflix we're always looking to improve our release processes so it was really great to get so many good responses. We learnt we're not that far apart from our peers out there. We've got a lot to learn of course, some of that comes from hearing from others and some from the mistakes we make. The trick is to make your mistakes small ones and learn fast with minimal disruption to your customers. This survey was run at least 5 months ago, so it’s a snapshot in time.  Most places I have worked change their processes (inspect and adapt!). I've reproduced the responses in their entirety, so it is a bit of a long read. I’ve anonymised the responses somewhat, retaining
Read more