Latest information from Radtac

See all topics

Subscribe to the Radtac blog

Connect with us

Recent Posts

Latest information from Radtac

Float, Move, Fight.

An alternative prioritisation model.

Sailors in navy


While I was coaching at a client site earlier in the year I got talking to a Scrum Master and ex Royal Navy Warfare Officer called John Harrison, after everyone had gone home. Now I’m not quite sure how we got on to the subject, but I seem to remember we were discussing how to bring his Royal Navy experience back into what he does as a Scrum Master. Then we started relating different military forces to the Stacey Matrix, but that's a whole other blog :)

John and I started talking about how we could create a change backlog based upon the key things that the management team need to consider, and focus on ‘right now’ to meet their vision (build a high-performing Agile capability with the business). We could see around the organisation that different improvement incentives were going on (Continuous Integration being the major player), but visibility of its priority towards the management team vision was not apparent.

Drawing on his experience, John then came up with the following analogy:

In the situation where a Royal Navy ship is in battle conditions, there are only three priorities the captain of a ship needs to consider: Float, Move, Fight. This is how a captain directs the priorities of the ship in order to keep working towards an objective.

Float - Keeping the ship above water by repairing damage

Move - Directing efforts to ensure propulsion and steering is functioning

Fight - Making sure weapon systems and tactical defence is maintained.

 

It's worth considering these priorities are not fixed. The main priority for the ship under battle conditions is to fight and defend. However, what if you are not watertight, what if you can't move?

I thought it was an interesting analogy, so the next day we scribbled it up on a whiteboard with the management team:

Float-move-fight model

We started off by trying to figure out what each of the priorities meant to the client organisation, then we added our thoughts under each.

Float - A stable state. What’s our minimum stable position? Being “the most basic needs for us to achieve the team goal”. In our example, this meant skilled teams, clear product vision, defined toolset.

Move - A functional state. Can we function and move forward towards our goal? To us, this meant “what do we need to put in place in order to increase our flow and efficiency?”. In our example we looked at work efficiency, such as how the work flows to the teams, and how the IT side works with the business.

Fight - What are the strategic elements for our goals? This was our ultimate goal, “what are the Agile enablers that will allow us to be high performing?”. In our example, we penciled in CI and test automation as the technical goals, and vertical retrospectives as an organisational goal.

Great, so we went from nothing to something pretty easily. We now had some categorised priorities for the management team. As you can see, the usual feedback and dependency loops ended up in the diagram. 


I think it's important to mention that this was a starter, something to be revisited often, and re-asserting our interpretation of the categories purpose will be paramount to not losing the focus and intention of this tool.


As with any retrospective or focus tool, it’s what you do next that counts. With regards to the client in this example, it gave them focus high-level items for a backlog to be refined, and initiatives planned. 


There are lots of possibilities for this tool and I’m now looking for an opportunity to try this out in a team creation situation. For those coaching or creating teams and using a social contract principle, this could be a great tool to get the team started and focused on figuring out how to work together towards an objective as a team.

While writing this I came across a comment in a tweet by Dan North where he mentions ‘visualise, stabilise, optimise’, and then, when you look further, there are lots of similar models. So let's add ‘Float Move Fight’ to the list.

 

By the way, in Navy terms it's a “no-no” to call a ship a boat. In the Navy a boat is a submarine, which could get confusing if you need to actually get aboard a boat on the ship ;)

Want to learn more about prioritisation? Check out Radtac's Agile training courses here.

Author

Andy Hiles

Andy Hiles

Principal ConsultantA firm believer that great teams build great products. Andy is a highly experienced process coach, agile practitioner, and certified Agile trainer with the British Computer Society. Currently co-organiser of the South Wales Agile Group Read more