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 https://www.vecteezy.com/

Agility in Governance: Organisational Transparency

Creative Commons Zero (CC0

Free to use (cco)

Co Authored by Tony Ponton and Phil Gadzinski

As we wrote about in our previous posts, after twenty years of working in agile, non-agile and transitional organisations, we have distilled what agile governance is into a key metapattern and four archetypes we believe are needed to effectively govern any modern system of work – whether we use agile methods in the work or not.

hello

In the spirit of symbolism we see them as the symbol of a “Guiding Hand if you like, “Four fingers and the thumb to lead and enable them”. In this post we will talk to the first of the Fingers  – “Organisational Transparency”. 

The key to agility lies in the speed at which information flows around the organisation, followed by how this information is used in decision making. Transparency is an essential component of speed and also a key enabler for building trust between people and teams. Share everything. Often. This means both the good and the bad information, don’t spin it, be honest , as they say “The truth will set you free”(the Bible, John 8:32) or in this instance will create a culture of trust.

We often talk about transparency as the key to success in agile operating environments, however it’s always hard to lock down in reality. Often it’s just an evolution of scarcity – we don’t have time to communicate or collaborate openly, we focus locally. Sometimes it’s a function of the operating models we create – we create functions based on hierarchy and optimise for them and don’t reward transparency across the walls. We then measure and reward silos individually. This breeds competition between functions and reduces the amount of collaboration we might do instead. Occasionally it’s intentional – machiavellian, corporate politics – protection, ego, status and power. Survival instinct for some is about self preservation and that can often be at the expense of others safety and security.

So what does this need for transparency actually mean for an organisation? There are four key imperatives to consider: 

Continue reading

Agility in Governance: What is Agile Governance trying to achieve?

Co Authored by Tony Ponton and Phil Gadzinski

Having talked about what “Agile Governance” is and why we need it, we thought it best to discuss what we are trying to achieve when we change our system of assuring work. The following quote from Kent Beck really describes it well:

 Silence is the sound of risk piling up” (Kent Beck Extreme Programming Explained).

Not knowing what is truly occurring, where the work gets done, creates and invites risk. Delays in elevating information increases risk. To solidify that point, let’s take the example that we make 35,000 decisions a day (many internet sources quote that number). Whether that number is correct or not, leaders and teams are making many, many decisions a day per person. Even if we significantly reduce this lets say for argument’s sake individuals in teams are making up to 10 directional impacting decisions every day; 5 days a week; 46 weeks per year. Per person. That’s 2,300 potentially wrong decisions every year per person – compounded. 

Each wrong decision increases the misalignment on top of the previous incorrect decision. If the information flow is truncated or delayed then the error rate of decisions that are based on gut feel, the highest paid person’s opinion, or pure guess become exponential. We need to better manage that risk.

Continue reading

Agility in Governance: What is agile governance? 

Co Authored by Tony Ponton and Phil Gadzinski

In our last post we spoke of the need for agile governance. In order to write further on the topic we felt it’s best to define, at a much deeper level, what agile governance is, so to that end this post will address that definition. 

Firstly, when we talk about agile governance, we are not talking only about project management offices and project management processes. Whilst they have a place in the governance system, they are only a small piece. Agile governance is about how you govern your entire system of work, at all levels, to enable your organisation, whether it be large or small. Governance is about providing assurance over whether our controls are working or not. In fact it’s about how we control our systems and why.

Successful agile governance requires building a culture of distributed governance and taking authority to the work (reference:Turn the Ship Around – David Marquet), whilst retaining control levers. It demands a sense of responsibility and ownership from all to allow for building greater levels of trust. We know that high performing teams have a greater sense of responsibility for what they see and do collectively and individually. 

Continue reading

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