Agility in Governance: Work Patterns

Co Authored by Tony Ponton and Phil Gadzinski

Moving through to the second of our keys to governing with agility, we look at how we are organised to do the actual work – a combination of teamwork and taskwork with the ultimate goal of productivity.

From a traditional governance perspective we are examining the completion of artefacts; the compliance with process; holding delivery to long dated work breakdown structure (wbs) charts and plans created when we knew the least about the work; and generally looking for variance to time, cost and scope. This suits project thinking designed for intermittent change in a more stable ecosystem – discrete work packages designed to solve for one outcome, not continuous delivery from persistent teams that we see work best in environments now reorganising for the increased and changing demands from customers. 

A key to high performing organisations that use agile methods is the enablement of the teams to describe their own local “way of working” and create a safe space for ideas to flourish. Distribute this permission – move away from mandated process and stage gating of work, focus instead on high level intent that you ask people to consider. Governance becomes more about “have” they designed for work, rather than “auditing compliance to” the design of work. Then focus on providing supporting guide rails to guide people towards the right way of working from their teams. One size definitely does not fit all – and one agile way of working or playbook doesn’t either. When asking people to work differently we need to help to achieve that. 

So what do we look for in this new system of work to provide assurance that we are designed – or learning and evolving – for optimal productivity?  

  1. Design for Flow 

With the move to stable persistent teams, it becomes critical that they have a steady managed flow of work from customer need and prioritised accordingly. We can’t afford the delays between projects stopping and starting when we have everyone on deck and on the payroll. This is to ensure we get the most value from this archetype. We are starting to see the emergence of Flow as a philosophy of work – it’s not new, having evolved from the Toyota Production System and the Toyota Way, with its roots in Lean. A great new way to look at this is The Flow System – which covers as one of its helixes Team Science. We want to adopt more holistically and at all levels in the hierarchy the activity of Value Chains and Value Stream Mapping to visualise our system, so we know how we are working and create understanding of our interactions. From a governance perspective, we are looking to ensure this has occurred, with visible interdependencies in and between teams for the competition of work.

  1. Distribute Decision Making 

When we design our systems of work to incorporate agility it is also important to change our way of decision making. The speed of change and VUCA that exists in the competitive landscape today confronts every organisation. This means organisations can no longer wait for the escalation of every decision through singular points and multiple layers of the organisational structure. 

This accelerates the need to ensure we embrace the principle of distributed decision making and ensure that we design our system of work purposefully to enable this distribution. 

The reasoning around this is that the principle of distributed decision making is integral to enabling the flow of work and the information throughout the organisation. It enables expedient directional decisions, timely interventions and pivot point decisions. 

We work to ensure that “close in person, place and time” become the method of decision. What we mean by this is, when you design the system, are the decisions able to be made by the persons closest to the work, close to the place it’s happening and as close and quickly to the time the decision is needed. 

This change has a direct effect on the methods of leadership and requires change to enable, encourage and provide the guide rails for decisioning. 

We will delve deeper into this in the Leadership Archetype in further posts. 

  1. Clarity of Purpose and Intent

Structure follows strategy. We often forget that – and if we have an organisational structure that’s NOT designed and aligned for the decomposition of strategy to the teams, there will be significant waste and delay in your work – and the likelihood of providing the wrong things. The longevity of strategy has been decreasing over the last ten years to the point where we now need more dynamic strategic planning and responding to change. Annual planning cycles and fixed three year strategies just don’t survive. From the governance perspective, it’s important to understand the nature of how teams are organised for clear flow of work to delivery. Assurance folk take on the organisational responsibility to determine if the structure is optimal.

4. The Team Codifies it’s Way of Working

In the move to agility and even more so once persistent teams are created, it is essential knowledge is codified and teams can describe how they work. 

This in turn creates a safe space for ideas and continuous improvement to flourish ensuring everyone in the team, including their stakeholders, suppliers and customers have clarity on how they work in order to achieve the organisation’s goals.

It is vital that the teams themselves describe their work and have autonomy to improve the way they work or they lose a sense of ownership and the intent of agility. Importantly it enables the IP and the framework of the team to persist as people move on. 

From an assurance perspective, we do still want to provide those supporting guide rails the enabling constraints so to speak. A great method to achieve this is to adopt an enabling pattern and distribute that – such as the Remote Agility Framework that we have both contributed to the creation of. So we look to ensure people have defined the process -we support them in the “how”- but they develop their way of working themselves- the “what”.

Most importantly, we work to instil a change in the organisational mindset to trust the teams and create an implicit understanding that:

” The team and the people who do the work, know best how they work and how the work gets done the best.”

Source:Gadzinski and Ponton 2020

To that point it is also important to understand that teams also know what information is best shared between them rather than what is often enforced upon them. In Team Topologies, Matthew Skeltons quote is poignant when trying to understand how this sits with the organisation.

Many organizations assume that more communication is always better, but this is not really the case. What we need is focused communication between specific teams.”

Source: Matthew Skelton, Team Topologies: Organizing Business and Technology Teams for Fast Flow

Governing this new way of working is far more effective when we use the way teams are organised as key information. Is there clarity of purpose and clear flow of work ? Does the team have the authority to make decisions and move forward ? Or is there residual control mechanisms left over from the “before times” that are actually counterproductive to and in fact slowly but surely devalue and take the system back to what it was before the changes? 

Our next post will explore the third of our fingers , 

“Data Based Decisioning” and its underpinning relationship to the “Patterns of Work” , “Organisational Transparency”  and “Conductive Leadership” 

All images supplied by

Agility in Governance: The Compelling Need for Agile Governance

Co Authored by Tony Ponton and Phil Gadzinski

Once upon a time, on a cold snowy day, agile came along and the world hasn’t been the same since. 

Geoffrey Moore in Crossing the Chasm quotes that Disruptive Innovation gets us to change our behaviour and the things we might use to solve problems. He positions that there is a repeatable evolution of an adoption going through a specific life cycle and adoption path. From the Early Innovators seeing the novelty and maybe trying to differentiate themselves, to Early Adopters, then we cross that chasm and start seeing the Early Majority adopt the new “thing”, followed by the Late Majority. The laggards kinda still float out back asking why? A rule of thumb, a heuristic, however you get the meaning. 

When it comes to the large scale, organisational level adoption of Agile, we are well and truly in the Late Majority stage. Alistair Cockburn has talked about this; we talk about this when we discuss and give keynote presentations and workshops about agile and where to next for agile.  

Figure: Crossing the chasm curve, from Moore.

However one thing got left behind in the large scale organisational transformation to agile.

When many organisations make the strategic decision they are going to redesign their organisational structure and operating model with the goal of increasing agility, they go all guns blazing into breaking people out of their boundaries into new constraints –  tribes, squads, groups, nations, you name the term for a collection of people organising around a problem to solve for. Sometimes for a customer. Traditional existing ways of getting things done are ripped apart; people are pushed into working with people they don’t know; around work they don’t yet understand; often without the time to come together as a team and design how they want to work. To set their teaming models so they can start doing something useful. We don’t need to name organisations – there are plenty of public examples. We have  been involved in these kinds of transformations directly a number of times – indirectly many more. 

Continue reading