Skip to content

September 28, 2021

VOICE: Applying an Agile Mindset to Organizational Agility

By Jon Smart
VOICE

This post is an excerpt from Sooner Safer Happier: Antipatterns and Patterns for Business Agility by Jonathan Smart, with Zsolt Berend, Myles Ogilvie, and Simon Rohrer. 


Taking a one-size-fits-all approach does not optimize outcomes for the infinite unique contexts in organized human endeavor. Instead, find your unique VOICE and use it.

You Have a Unique VOICE: Use It

The alternative to imposing one set of prescriptive practices across an organization without considering the many unique contexts is to apply an agile mindset to organizational agility: to recognize that you have a unique VOICE: Values and Principles, Outcomes and Purpose, Intent-Based Leadership*, Coaching and Support, and Experimentation.

VOICE is a way to approach business agility as an alternative to imposing a one-size-fits-all set of practices. 

VOICE

Values and Principles: behavioral guardrails that apply across contexts.

Outcomes and Purpose: outcomes such as Better Value Sooner Safer Happier along with a clear articulation of Why that is unique to your organization (as we saw in Chapter 1), with measures for the outcomes and fast feedback loops.

Intent-Based Leadership*: empowerment that decentralizes decision-making, strives for high autonomy with high alignment, and fosters an environment that leads to teams building a new muscle memory, the ability to continuously improve on outcomes in context. It’s not command-and-control, or micro-management, or a culture of fear, or making all the decisions. Leaders go first, role modeling desired behaviors with a clear employee engagement model so that everyone has a way to be heard and a way to influence and shape their own destiny.

Coaching and Support: to unlearn old habits, learn new ones, achieve mastery, and remove organizational impediments. Coaches draw on many bodies of knowledge and employ the practices that are hypothesized to optimize outcomes in context. Leaders at all levels coach and support continuous improvement and technical excellence. It is possible to learn to ski without a ski instructor; however, it leads to bad habits, it takes longer, there’s more pain involved, and it increases the risk that the learner will give up. Coaching provides support, guidance, and encouragement; helps others avoid bumps; and reduces fear. Coaching is needed because there is no one way, no cookie-­cutter approach that optimizes outcomes in all contexts.

Experimentation: is carried out at all organizational levels with fast feedback, as change is emergent and organizations are complex adaptive systems. We need to minimize the time to learning. Probing, sensing, and responding take place at the team, value stream, business unit, and organizational levels. “Double loop learning” takes learning from the Experimentation loop to create a second learning loop, which is feedback on the overall Values and Principles and Outcomes and Purpose. A goal here is to build a new muscle memory so that everyone is continuously improving on the system of work, being the best at being better.

Let’s take a look at each of these in more detail.

V: Values and Principles

An organization’s values and principles are its behavioral guardrails. They might include “Focus on Outcomes,” “Achieve Big through Small,” or “Invite over Inflict,” for example. They inform every decision and should be repeatedly communicated. Communicate three more times than you think you need to and you’re a third of the way there.

The values and principles signal intent and allow for behavior that is not in line to be called out. They include teams holding each other to account as well as their leaders’ behavior. The values and principles apply across contexts and can help to provide consistency in behaviors and decision-making in a large organization. Amazon, for example, has its fourteen Leadership Principles, a list that includes customer obsession, ownership, thinking big, and bias for action.

Following are at least four sources of values and principles as inspiration in determining what is most applicable for your organization.

The first source is the existing, organization-wide values. In my experience, these are usually so high level—“respect,” for example, or “integrity”—that there is still a need for values and principles specific to ways of working.

The second source is the Agile Manifesto. These apply as part of an overall agile mindset and are de facto. They date back to 2001 and are worded to be specific to software. In my experience, while treating the principles in the manifesto as a given, there is room to emphasize principles that are more up-to-date and suited to the context of business agility.

The third source is the values and principles that come with an agile framework being used, whether that’s Scrum, Kanban, SAFe, Disciplined Agile, or Large Scale Scrum (LeSS), and so on.

And the fourth source is the intentionally long list of principles that can be found in Sooner Safer Happier or downloaded here! The key point is to come up with values and principles that work for you, in your organizational context, and at your current point, taking inspiration from many sources.

While principles apply across contexts, practices differ by context. Practices emerge by applying context to principles and by using coaching and experimentation, leveraging many bodies of knowledge.

Within guardrails, practices should not be imposed on teams. Teams should be invited and supported to take ownership in order to work out the best way to apply the principles and improve outcomes for themselves. This keeps the locus of control internal. Team members feel that they are masters of their own destinies and can change things for the better without the sky falling in. That sense of control leads to greater intrinsic motivation. Over time, people build a new muscle memory, the ability to continuously improve. With it they build or strengthen an organizational capability for learning and adapting.

O: Outcomes and Purpose

Organizations need to know why they are looking to improve ways of working and what their desired outcomes are. Outcomes such as Better Value Sooner Safer Happier, for example. These outcomes should each have one or more measures.

When measuring outcomes, improvement over time is more important than the absolute value; everyone has a different starting point and context. The data should be transparent and timely to increase the ability to determine cause and effect. It should be possible to drill into the data to find outliers, identifying experiments to amplify or dampen. Targets should be avoided when inviting teams to change their ways of working. In my experience, targets drive cargo cult behavior and lead to a gaming of the system.

I’ve found that when organizations remove targets, make the trend over time transparent, and leave each area to decide for themselves and in conversation with their leadership how much they want to improve, the change comes from within rather than from without. It is important that BVSSH measures are gathered centrally and by an independent team. This ensures consistent data, algorithms, measures, correlations, and trend comparisons and reduces the prospect of selective gaming of data.

Outcomes and Purpose provide the What and Why for improving ways of working. They provide high alignment, which enables empowered teams, with support, to inspect and adapt in their context in order to improve. The goal is not Agile for Agile’s sake. It’s to enable agility to improve outcomes.

I: Intent-Based Leadership*

With a high alignment on the outcomes, foster an environment of high autonomy. Adopt intent-based leadership* (more on this in Pattern 4.3 in the book Sooner Safer Happier). Empower teams to improve on the outcomes, starting small, with fast feedback and support. Within minimal viable guardrails, move authority to the information, not information to authority. Decentralize decision-making. Do not impose prescription, micro-manage, or make Highest Paid Person’s Opinion (HiPPO) decisions.

Instead, be a gardener nurturing culture. Make the improvement of desired outcomes transparent. Adopt a pull-not-push approach within guardrails. Be a transformational leader, moving away from the command-and-control management style of the 1900s. It comes as no surprise that The State of DevOps Report shows that transformational leadership, in the context of product development, is highly correlated with higher organizational performance.

The leadership team should be team number one in adopting new ways of working. If a leadership team is not willing to role model desired behaviors, it is unrealistic and inauthentic to expect teams to do so.

Critically, foster an environment of psychological safety so that people are willing to admit they don’t know and are willing to experiment even though they know they might fail. They must be free to inspect and adapt. In order to improve, there has to be a safe environment. Project Aristotle, a study by Google into team performance, found that psychological safety is the number one determinant of high-performing teams.

Autonomy, empowerment, and psychological safety increase intrinsic motivation and engagement as people bring their brains to work.

C: Coaching and Support

Provide coaching on agility, on ways of working (not on one framework), optimizing for Better Value Sooner Safer Happier outcomes in context, and provide support in removing organization-wide impediments.

A success pattern is to start with a small Ways of Working Center of Enablement (WoW CoE) with as broad a scope as possible, ideally across the whole organization. The purpose of the WoW CoE is not to inflict the rollout of one set of prescriptive practices. It’s not to saturate the organization with Scrum or to drop everyone into mandated en masse training, or to run an Agile Imposition.

The purpose of the WoW CoE is to orchestrate the continual improvement of the system of work and support everyone in the organization to be able to do that on a daily basis, in order to see a positive trend on Better Value Sooner Safer Happier measures; to achieve big through small; to coach at the enterprise level; to run experiments to alleviate organizational constraints that bubble up; and to provide clear minimal viable guardrails, so that it’s agile, not fragile.

The WoW CoE supports teams and plays whack-a-mole on new impediments that pop up, which they will, frequently. It ensures that training in many forms is available on-demand, shares learning, collates data on multiple outcome measures, generates insights and feedback loops, and makes sure that desired behavior is recognized and rewarded.

The WoW CoE lead should ideally report to someone on the Executive Committee, either the CEO or COO. This enables organization-wide impediments to have top-table attention so that alleviating them can be prioritized. Otherwise, there will be a bubble of better ways of working restricted to the remit of the most senior leader who is sponsoring it, and a limited ability to resolve the larger firm-wide impediments that sit outside of that bubble.

The scope should not be just IT, as that will result in local optimization. Software development cycle time (from starting development to development done but not shipped) could be reduced by 90%; however, that can have little bearing on end-to-end lead time if work is stuck upstream in big-batch portfolio management, or if there is a project-based funding process, or if it takes twelve months to hire people, or if procurement is signing contracts with terms that prevent agility, or if it takes six months to get hardware, or if releases are batched up downstream due to dependencies, or if internal sponsors and stakeholders want to continue with an arms’ length, order-giver and order-taker, tell-me-when-it’s-done way of working.

A key part of better ways of working is multidisciplinary teams where it’s not about “the business” and “IT.” Instead, everyone is “our business.” For product development, your primary tribal identity should be your value stream, what you are producing that is of value, not your job role specialism.

Note that it is a Center of Enablement rather than a Center of Excellence. This is a small, central, servant leadership function, alleviating impediments (servant) and providing enablers (leadership) to improve outcomes. As there is no one-size-fits-all approach to optimize outcomes, as the domain of work is emergent, and as it’s about serving teams, I believe that it is inappropriate to suggest that it’s a Center of Excellence. The Dunning-Kruger Effect has shown that beginners overrate themselves and experts underrate themselves, so if the center is staffed with experts, they will be aware that there is much ongoing learning still to be done.

An approach that I have found works well to provide support at scale is a fractal pattern of WoW CoEs: one per business unit or value stream, and then, if appropriate, also at the next level down of nested value stream. For example: bank > investment bank > equity trading.

The lead of each WoW CoE is also a virtual member of the WoW CoE team at the level above. For psychological ownership, the people in the value stream WoW CoEs report into their value stream or business unit, not into the central CoE. This ensures a sense of ownership, a tribal identity, and a collective intrinsic motivation, rather than being viewed as an alien body telling the business unit what to do, resulting in tissue rejection. This scalable network can deal with impediments at the lowest possible level, aligned to value streams.

The central WoW CoE also coordinates a network of change agents and coaches, ensuring consistent messaging on “Why,” and leads a coaches network to share insights, to inspect, and to adapt. Applying the “achieve big through small” mantra, there should not be too many coaches at any one time in any one business area. There are different levels of coaching: at the team level, at the level of a self-contained business unit with a handful of value streams, and at the level of a large global organization of organizations with thousands of value streams. There is technical coaching and ways-of-working coaching. There is no one size coach fits all.

Coaches and change agents should strive to be omnists: they must recognize and respect all bodies of knowledge without framework fundamentalism. They must understand that different contexts suit different practices, within the guardrails of the organization’s values and principles. 

Leaders at all levels should become coaches for their teams on continuous improvement and be coached themselves. This gives a clear role for middle management in particular, giving the pressurized middle a role to play, as per the Toyota Coaching Kata.

E: Experimentation

Once you have high alignment and high autonomy within guardrails, with coaching and support, you can experiment. You can start to run small, safe-to-learn experiments. You can try different approaches and use fast feedback to make progress.

As you are performing unique, complex work within a unique, complex, adaptive system, you will need to probe, sense, and respond. The context here is changing the system of work in order to deliver better outcomes. This is emergent, whether the underlying work is also emergent (unique product development) or more deterministic (repetitive mass production or mass processing). As Edgar Schein has noted: “You cannot understand a system until you try and change it and when you do try to change it, only then will underlying mechanisms maintaining the status quo emerge.”

Any experiment is the testing of a hypothesis whose outcome is unknown, as it has not been done before either at all or in this exact context. We can’t time travel. Organizations are complex adaptive systems, and we are in an emergent domain. There is no linear cause and effect. Other ways that people have described fast feedback loops and testing hypotheses are W. Edwards Deming’s Plan Do Study Act (PDSA), John Boyd’s Observe Orient Decide Act (OODA), and Eric Ries’s Build, Measure, Learn.

To sense if the experiments are moving you in the right direction, you first need to be able to “see” and measure your current system of work. You need to know your starting points. Here I refer to Dan Terhorst-North’s “visualize, stabilize, optimize.”

You first need to be able to visualize steps in a value stream from left to right. You need to be able to see the amount of work in the system at each step (the work in progress), how the work is flowing (lead time and throughput), and how long the work has been there (wait time and aging).

You need to “know your flow” and understand your flow efficiency, the percentage of time that work is being worked on during the end-to-end lead time for an item of value. In traditional organizations, flow efficiency is typically 10% or less; work really does wait for 90% of the time.

This is where significant improvements can be made. Looking only at resource utilization and busyness tends to further reduce flow efficiency. When resource utilization exceeds 80%, lead time rises exponentially. Instead of busyness or local optimization, look at where the work isn’t, the white space between the work, with the items of value waiting like physical inventory stacked up by a machine.

Having shone a light on the system of work, next stabilize flow. Apply work in progress (WIP) limits at each stage in the value stream. The fewer cars there are on the road, the faster they can go. Pack the road with cars and everything grinds to a halt. Enable flow in the value stream. If evolution over revolution is culturally preferable, those limits could match the current high WIP levels and then be reduced gradually. Crucially, no work can be started until some work has finished and a slot opens up for it by the work being pulled to the right. The system of work becomes pull-based rather than push-based.

Stop starting, start finishing.

A problem often observed is HiPPO scheduling, where people “start starting.” More initiatives are run before completing or stopping others. The organization needs to learn the important ability to say “No,” or “Not yet,” or “What do we stop in order to do this?” in order to optimize for BVSSH. Doing more in parallel is like putting more cars on the road. It moves all of the BVSSH measures in the wrong direction.

If the context is one where work entering the system is ad hoc, such as a service desk, different classes of service are useful. For example, the service desk could create an expedited swim lane with prioritization by severity. If work is blocked downstream, people working upstream should swarm on the downstream constraint rather than sit idle or overproduce inventory upstream that will sit and wait in a growing pile of virtual inventory. The goal here is to permanently alleviate the constraint so that it is no longer the primary bottleneck.

Like the tide going down, limiting WIP exposes the rocks that have been there all along, hidden in long lead times. Limiting WIP is an “enabling constraint,” surfacing pain points. Glossing over the blockers to flow, going around them, or leaving work waiting will not lead to better end-to-end business—­outcomes. It will only leave inefficiencies in the system. Sometimes, depending on context, the pain of the constraint needs to be felt by blocking upstream work so that the complex adaptive system prioritizes its remediation.

Impediments are not in the path; impediments are the path.

We’re now into the optimize part of Experimentation, in order to deliver Better Value Sooner Safer Happier. The visualization and measurement of flow will provide clear indications of the biggest impediments. There could be too much work in the system or too much work in progress with considerable task switching, handoffs, and dependencies. There could be starvation, with a lack of flow from upstream or a lack of clear strategic outcomes to work toward. The Theory of Constraints asks that you identify what you believe to be your biggest constraint to flow, focus improvement efforts on alleviating it, and then repeat.

Limiting WIP and focusing on reducing end-to-end lead time will soon shine a light on the impediments. Run one experiment, or probe, then sense the outcome measures while remembering that cause and effect are not linear. Work out what your next improvement experiment will be, amplifying positive experiments and dampening negative experiments. Beware of local optimizations (for example, improving just software development), focusing instead on the end-to-end value stream. The biggest constraint may be upstream in portfolio management rather than downstream in increasing test automation, for example.

The weakest link determines the strength of a chain. Once you’ve strengthened that link there is no value in strengthening it further. Instead, strengthen the new weakest link. Repeat. The Toyota Improvement Kata is a great tool for building a habit of continuous improvement and iterating toward a goal. Ultimately, the goal is for the organization to become a learning organization.

Optimization can be any combination of small change and radical change. The terms for these, with origins in the Toyota Production System, are kaizen (continuous improvement) and kaikaku (radical change). It can be incremental and evolutionary or radical and revolutionary. Importantly, it is not one size fits all, and it comes from within. It is internally motivated, not imposed.


This post is an excerpt from Sooner Safer Happier: Antipatterns and Patterns for Business Agility by Jonathan Smart, with Zsolt Berend, Myles Ogilvie, and Simon Rohrer. 

* Source: IntentBasedLeadership.com.

- About The Authors
Avatar photo

Jon Smart

JONATHAN SMART is a business agility practitioner, thought leader, and coach. Smart leads Deloitte’s Business Agility practice, helping organizations deliver better value sooner, safer, and happier through the application of agile, lean, and DevOps principles and practices organization wide. Previously Smart lead Ways of Working globally for Barclays Bank, helping to triple productivity, where he and his team won the Best Internal Agile Team at the Agile Awards in 2016. Smart is also the founder of the Enterprise Agility Leaders Network, a member of the Programming Committee for the DevOps Enterprise Summit, a member of the Business Agility Institute Advisory Council, a guest speaker at London Business School, and speaks at numerous conferences a year.

Follow Jon on Social Media

1 Comment

  • Naveed Ismail Oct 4, 2021 6:13 pm

    Great post and I strongly believe the change is very impactful if it comes from within. Keeping the vision intact but make the change in small incremental manner and learn and adjust.

Leave a Comment

Your email address will not be published.



Jump to Section

    More Like This

    Map Camp: Weird Mapping – How to Create a Revolution
    By David Anderson

    A version of this post was originally published at TheServerlessEdge.com. Dave Anderson, author of…

    Serverless Myths
    By David Anderson , Michael O’Reilly , Mark McCann

    The term “serverless myths” could also be “modern cloud myths.” The myths highlighted here…

    What is the Modern Cloud/Serverless?
    By David Anderson , Michael O’Reilly , Mark McCann

    What is the Modern Cloud? What is Serverless? This post, adapted from The Value…

    Using Wardley Mapping with the Value Flywheel
    By David Anderson , Michael O’Reilly , Mark McCann

    Now that we have our flywheel turning (see our posts What is the Value…