Strategy Deployment and the Agile Industrial Complex

There has been much debate online, and in particular on Twitter recently, about the imposition of Agile and the Agile Industrial Complex. See Ron Jeffries’ recent blog for more context. It’s an important topic. I have seen plenty of imposed Agile which I would call Incoherent Agile. Agile processes imposed as Best Practice without any coherence or alignment with the challenges that they are intended to be addressing. As a result the promised benefits aren’t realised, the people become demoralised and ultimately Agile is blamed.

I’ve refrained from getting directly involved the debate so far, but I do have a view, which I hope to explain here.

Lets first look at the idea of imposition. As usual, Cynefin provides a useful lens to look through with its four domains and associated forms of constraints.

1. The Obvious domain has Rigid Constraints, which allow no freedom of choice
2. The Complicated domain has Governing Constraints, which allow a little freedom of choice
3. The Complex domain has Enabling Constraints, which allow a bounded freedom of choice
4. The Chaos domain has No Constraints, which allow complete freedom of choice

When we impose something, we are effectively imposing constraints. Cynefin suggests that imposing no constraints will lead to Chaos, which we generally don’t want to happen (unless it’s an intentional, short and transitionary state). Thus imposition is not necessarily good or bad and it’s more important to consider the nature of the imposition in context, and whether we are imposing the right degree of constraint.

That leads to the question of what we are imposing in an Agile Transformation.

Much of the backlash against imposed Agile is a reaction to Agile imposed as a Governing or Rigid Constraint, where leadership decides which frameworks, processes or practices are to be implemented as the standard approach, leaving little or no room for variation or experimentation by the people actually doing the work.

This is exactly the sort of experience which led my interest in Strategy Deployment and the X-Matrix. It’s why I am a proponent of Agendashift and why I like the concept of the Engagement Model. I regard a Strategic approach to Agile Transformation as one where leadership sets Enabling Constraints, within which the solutions can emerge from the people closest to the problem.

Therefore, by choosing to use an Engagement Model, whether it be Agendashift, OpenSpace Agility or my own TASTE approach, I believe you are still imposing that Engagement Model on an organisation. The important distinction is that with an Engagement Model you are imposing Enabling Constraints. With Agendashift, those constraints have a strong focus on outcomes. With Open Space Agility those constraints come from the chosen theme or purpose. With TASTE, those constraints are defined by strategies and evidence.

All this means that we can impose Enabling Constraints, and invite people to participate within those constraints. That’s not to say that everyone should always be an agreeable participant. We don’t necessarily want everyone to be obedient and compliant. Engagement should allow for rebels and cynics to question the approach and keep everyone honest.

Much of the debate I have observed has been between Invitation as a force for good, versus Imposition as a force for evil. What I have hopefully shown is that the two are not mutually exclusive and that instead of arguing and fighting we should be working to help organisations impose the right levels of constraints and inviting people to collaboratively engage within them.