Business agile is a system, not a methodology

by | Feb 8, 2018 | cerys, Digital Transformation, Strategy

An increasing number of non-technology projects are set up to run agile (small ‘a’). They recognise the futility of trying to replicate pure Agile or Scrum projects and instead need to pick and choose the ways of working and elements that fit their needs (see Lee’s post from last week). So, teams of limited experience are selecting the ways of working they think will work best for them. Without exposure to technical agile projects, or the services of a coach, it is easy for the team to overlook crucial aspects of the overall interlinked system in favour of those easier to implement. We might not believe the Agile methodology is the right one for all business teams, but it works for product teams because it is a whole system.

Thinking of agile as a system rather than a method

Bringing basic systems thinking to agile means we must consider the whole. This means examining the linkages and interactions between the components that comprise the entirety of the system. Much like the most productive individuals use a personalised, linked set of techniques to get stuff done, the best agile teams use an interlinked set of techniques to deliver outputs faster, fail faster, iterate products & services, etc.

When talking to agile business teams, I use this breakdown of elements to get them thinking about the system, rather than the methodology:

Infrastructure of agile – examples include Shared Goals, Customer Understanding, Backlogs, Commitments, Agile budgeting. They are the basic physical and organising structures that are needed for the operation of agile teams and agile organisations. Infrastructure gives people direction and alignment. It ensures continued focus on the customer. It is an enabler in review and feedback cycles. It creates the right conditions for changing the rhythm of work. Without the infrastructure, the enthusiasm for running agile soon disintegrates into uncertainty and endless talking, rather than focusing on doing.

Rhythm of agile – examples include Sprints, Planning, Reviews, Retrospectives. These are often the most visible changes for agile teams, and the thing that feels the most fundamental. A different working rhythm shakes up all sorts of bad behaviours, and brings a focus to the immediate needs, sharing truthful updates and ensuring the project is constantly course correcting. This enables a sense and respond mentality, rather than a predict and plan one. This is where, for many agile team members, the rubber appears to hit the road.

Agile ways of working – examples include anytime anyplace anywhere working, a focus on potentially shippable products and MVPs, and having complete autonomy over how you deliver a potentially shippable product. This is where teams have maximum flexibility to find what suits them.

Common issues for business agile teams

Typically when exploring reasons for the declining motivation and velocity with a team, we find the issues all lie in the infrastructure levels. Teams find it easy to embrace the rhythm (after all, we are all used to meetings in the diary) and at first it is exciting to have autonomy over the way you deliver. But, without the infrastructure, an unease and lack of alignment creep up and the team starts to fall back on old habits of blame, command-and-control and traditional (if fictional) project planning.

You can also think of the three layers in terms of speed of change. Much like pace-layers in technology stacks, where the infrastructure changes very slowly and under controlled conditions, whereas user experience changes very regularly, so it is with an agile system. The infrastructure changes slowly, and in a very controlled manner, whilst the rhythm can change a little quicker, with more experiments. The outer-layer of agile ways of working can be varied often depending on the need for collaboration, communication, innovation or governance patterns change.

And some further reading…