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…
- The importance of learning in flatter organisations.
- Those building agile organisations ask the wrong questions and end up building an agile prison for themselves.
- Developing a systems mindset.
- Why adaptability matters more than anything for the future of organisations.
- 11 laws of systems thinking that encapsulate some of the common mistakes.