Agility is a Strategy, Agile is a Tactic

I have a different perspective.

My concern with an even stronger focus on practice is that it would lead to even more Cargo Culting than we see already. People simply copy practices they see and hear about in the hope that implementing them by the book will magically lead to them being Agile. We would end up with more teams using the autonomy encouraged by Agile to choose the way they work but with no alignment to the original goal of improving business results.

Worse still would be even more conversations about things “not being Agile” than we see today. As Jabe Bloom recently tweeted: ‘the statement “X isn’t Agile” fills me with meh‘.

I much prefer Joshua Kerievsky’s take on what he calls Modern Agile. I think he has taken the opposite approach by trying to take what we have learned over the last 20 years and describe the intent. I would describe what he calls disciplines as strategies, and I believe the transformation of an organisation to have greater agility is an example of what the Lean community calls Strategy Deployment.

Let me explain.

Strategy Deployment, like most Lean ideas, has its roots in a Japanese term, Hoshin Kanri. The literal translation is “Direction Management”, but a more colourful translation “Ship in a storm going in the right direction”. This brings to my mind the image of everyone using all their skills and experience to pull together, with a common goal of escaping turbulence and reaching safety. Thus Strategy Deployment is an approach to organisational improvement which engages the entire workforce in figuring out how the business can survive and thrive.

Significantly, this means a shift from organisations operating on the basis that senior management knows best, and tells employees what to do without thinking or asking questions, to one where they propose direction and ask for feedback and enquiry. Instead of assuming that they know the right answers as facts, Strategy Deployment assumes that any suggestions are opinions to be explored and challenged, with the possibility that they may turn out to be wrong, and making it acceptable for people to change their minds.

What leadership proposes, therefore, is strategy, using it as a form of enabling constraint to guide and open up possibilities of what could be achieved. This is as opposed to defining tactics as a form of governing constraint, dictating action and closing down any alternatives that could be explored. A useful metaphor here is the one used by Dave Snowden for types of skeletons. An enabling constraint is like an endo-skeleton (e.g. humans) – formed on the inside, maintaining coherence and allowing growth. A governing constraint is like an exoskeleton (e.g. crabs) – formed on the outside, protecting and limiting growth.

By being clear on strategy, and allowing and encouraging the whole organisation to use their skills, knowledge and experience to discover appropriate tactics, it is possible to enable autonomy while maintaining alignment. In this light, all the various Agile practices are simply tactics (and very good ones) to help organisations achieve greater agility as a strategic goal.

In other words, Agility is a Strategy, Agile is a Tactic.

Although obviously, it’s not quite as simple as that! I’m not sure that many executives would actually say that greater agility was a strategic goal. However, some of the primary outcomes that agility enables are relevant as strategic goals. I like to use the dimensions identified by Larry Maccherone as a starting point:

• Productivity – amount of delivery
• Responsiveness – speed of delivery
• Predictability – consistency of delivery
• Quality – delivering the thing right
• Customer Satisfaction – delivering the right thing
• Employee Engagement – delivering sustainably

And all of these would help achieve more general strategic goals such as focussing on new markets, regions, technologies, business models etc.

What’s all this got to do with the Agile Manifesto?

It seems to me that what the Manifesto authors had identified was a different set of strategies to deliver successful software and a thought experiment, I wondered what the Manifesto might it have looked like if it had been written as a set of strategies. I’m not suggesting actually rewriting it but it seems like a useful idea to explore. This is what I came up with:

We are uncovering better ways of developing software by doing it and helping others do it.

Through this work, our strategies have become to:

• Empower teams around economies of flow
• Reduce the batch size of value delivery
• Explore the evolutionary potential of solutions
• Sense and respond to feedback

Why did I choose those?

Empower teams around economies of flow – “Individual and interactions” is about people, working together as part of a value stream, using their collective expertise to maximise the flow of delivery.

Reduce the batch size of value delivery – “Working software” is about those teams delivering valuable software early and often in smaller batches, using incremental and iterative approaches.

Explore the evolutionary potential of solutions – “Customer collaboration” is about working closely with customers to discover how to meet their needs through empathy and experimentation.

Sense and respond to feedback – “Responding to change” is about using the smaller batch size for knowledge discovery as well as value delivery, and using that information to create feedback for continuous change.

What would you choose?

This is just one interpretation. It was not an easy exercise deciding what to include, and what to leave out, and it’s at least the 3rd version I have come up with. I’m sure people will have different opinions. I’d love feedback on what they are! Please leave a comment on what your strategies are to achieve greater agility.