So, we need to look at process AND the relationship system that exists between people, teams, levels, roles and how these dynamically evolve and emerge and towards which direction they do so.

People thrive in the constant play between order and chaos, autonomy and security – some of us prefer one over the other in specific circumstances. Organisations are made up of people, and people create structure out of chaos in order to bring about shared understanding that helps us navigate uncertainty and complexity. Systems are mental models that are created, communicated, affirmed through abiding in them, and maintained – they help us make sense of the opportunities available for actions we need to take, assign purpose and expectations to people outside of ourselves, and give structure to how we should behave, think, speak and interact with various sub-systems.

Why this is important to us is because work gets organised and delivered in the interplay between thoughts, communication, execution and co-ordination. For us to create something out of nothing, we create systems in which we hold the various activities. The nature of the system determines its efficiency – as an Agilist I don’t need to explain this point past referring you to Lean and how it changed systems across the world.

Is systems thinking not just process?[1]

No! And this is where organisations often miss out and get lost. Process is part of systems, yes, but it unnecessarily over simplifies the nature of the system to a linear and contractual entity in which as long as the process is followed, and controlled, the results will always be predictable.

This works fantastically for computers, and can even be observed in nature – like termites, ants, bees or flow dynamics of a herd migrating north. But, humans don’t always like control, we don’t like repetition and mundanity – we seek relationship, dynamic autonomous creation possibilities, and the means to connect meaningfully with others on things we create or care for. We are meaning-making and purpose seeking social beings – not computers relegated to processes and tools.

The other side to the systems thinking coin is the systemic part. Systemic orientation takes the multiple-ways-of-being-human into account and how this influences the nature of any system. The “way-of-being” part is called ontology. Only looking at process is a singular orientation to way of being, meaning, you’re expected to be only one way, think only this way, the right way, and produce only this outcome. Multi-ontology orientation to systems is understanding that people make process and levels, people form relationships and designate purpose to the relationship and that NOTHING gets delivered in a human system without relationships actively making it possible, or not.

Consider that Lean, for example, includes the pillar of Respect – and that in this human-oriented pillar, there are processes to be aware of – this is still singular-ontology orientation to systems.

So, we need to look at process AND the relationship system that exists between people, teams, levels, roles and how these dynamically evolve and emerge and towards which direction they do so.

Process driven systems often unnecessarily get re-organised or levels get restructured because the agreements and relationships in-between are not paid sufficient attention to. A good example of this is the recent systems orientation of Team Typologies in organisational design and emergent architecture in IT. There are four types of teams defined (singular-ontology), and three types of interactions defined (multiple-ontology).

They (Skelton and Pais[2]) forewarn that often organisations set up the types, and only consider a single interaction format (like prioritise for your next sprint) and when it fails, they say that the structure and process of team typologies doesn’t work.

In short, systems thinking tends to fail in complex and reassured environments when the systemic part is ignored. Systemic focus ensures that the interactions between multiple aspects of the emergent system is aligned and utilised effectively. Your job as Agilist is to see to both.

[1] Snowden, D. (2005). Multi-ontology sense making: a new simplicity in decision making. The cynefin centre

[2] Skelton, M., & Pais, M. (2019). Team Topologies. IT Revolution

When looking at the industry standards defined for Agile Coaching, in both the Scrum Alliance definitions and in the IC Agile definitions, both outline coaching as a crucial orientation to enabling Agility. Unlike consulting, mentoring or training, coaching seems to align best with what serves servant leadership. Unfortunately, Agile Coaches and Coaches alike face the added challenge of educating their clients on what coaching is and is not[1].

For now, we outline why coaching and systemic coaching is important to your toolkit. Coaching is defined by the International Coaches Federation as: partnering with clients in a thought-provoking and creative process that inspires them to maximize their personal and professional potential.

The process of coaching often unlocks previously untapped sources of imagination, productivity and leadership. COMENSA defines coaching as: a professional, collaborative and outcomes-driven method of learning that seeks to develop an individual and raise self-awareness so that he or she might achieve specific goals and perform at a more effective level.

Consider how Lean and Agile frameworks position continuous learning as a crucial part of being and remaining agile; now consider how partnering with a client, team, co-ordination level or leader might support their best learning in the domains of potential.

If we tell people what to do, we build dependency and rigidity into the system, not to mention remove two factors crucial to intrinsic motivation (autonomy and mastery and purpose). If people depend on us for correct doing that leads to predictable outcomes, then there can be no mastery or autonomy. Coaching supports the ways of being that best serves the system.

As an Agile Coach you need to have the ability to coach teams and individuals, but most of all, be a skilled practitioner of systems coaching. For more information on how to differentiate coaching from therapy, training, consulting and mentoring, check out this page: What is Coaching?

[1] Adkins, L. (2010). Coaching Agile Teams: a companion for scrum masters agile coaches and project managers in transition. Addison-Wesley