“Eighty-five percent of the reasons for business failure are deficiencies in the systems and process rather than the employee. The role of management is to change the process rather than badgering individuals to do better.” -W. Edwards Deming
The role of the CEO is to build or change the system rather than expecting individuals to do better. They need to take a systems approach because if leaders put good people in a bad system, the system always wins. Leaders need to understand that they are responsible for building the system.
“The first responsibility of a leader is to define reality. The last is to say, ‘thank you.’ In between, the leader is a servant.” -Max DePree, Chairman Emeritus, Herman Miller
Leaders’ communications help create realities to which they and others must respond. Framing is a way to communicate the context they want to shape and influence how the organization perceives reality. A frame is a set of one or more related ideas that influence or structure how one thinks about a topic. It defines the boundaries of what is relevant or acceptable to talk about. Frame control is a powerful leadership tool for creating positive change within an organization.
A major problem in many organizations today is that they are not Agile enough to respond to changing customer and market needs. Leaders often try to solve performance problems by replacing staff or cutting budgets. While these types of actions often provide short-term relief in the form of increased profitability, they address symptoms rather than root causes. A business can limp along for years or decades by cutting costs.
The Triple Constraints of Traditional Project Planning
Leaders in a non-Agile organization typically believe that individuals are the unit of productivity. They try to optimize work by organizing around pools of expertise, and they think that the sum of all work parts will produce the aggregate solution. Leaders also believe they can effectively time slice Subject Matter Experts (SMEs).
Leaders in a non-Agile organization also believe that their responsibility is for their function/department, not the system. This belief means that their followers need to be Agile enough to respond to changing customer and market needs so that their department can be successful. Their focus is on creating value for customers served by their department. This management style leads to local or departmental optimization vs. optimizing the whole system.
The triple constraints of traditional project planning are another belief in the business world that has contributed significantly to a lack of Agility. The triple constraints are:
- Scope is knowable in advance
- Work is estimable with precision
- People are fungible
This means that businesses operate under the assumption that they can plan their work precisely and replace employees easily if needed.
Traditional project planning and the belief in individuals as the unit of productivity can lead to a lack of Agility in an organization. Leaders in a non-Agile organization often believe they are responsible for their department, not the system. This can lead to inflexible decision-making and a reluctance to change when it is necessary. The triple constraints of traditional project planning often prevent organizations from being able to respond quickly to changes in the market or customer needs. To be more Agile, leaders need to shift their beliefs and focus on the system instead of individual departments. By doing so, they will be able to adapt quickly to changes and improve organizational Agility.
The Importance of Addressing Underlying Leadership Beliefs
“The only definition of a leader is someone who has followers.” -Peter Drucker
What makes a person a leader? A leader has followers, and to be a good leader, they need to believe in what they are leading. If they don’t believe in it wholeheartedly, their followers won’t either. That’s why it’s important to address the underlying beliefs of leaders.
According to a study back in the 1990s by HR Consulting firm Novations (now part of Korn Ferry), over time, employees change their behavior (up to 93% of the time) to match their manager’s behavior. The implication is that if a leader wants to change the behavior of their employees, they must start by changing their own behavior.
If a company wants to succeed, the leaders need to believe in the company’s vision and mission. If the leaders don’t buy in, the employees certainly won’t.
Align Beliefs to Enable Transformation
Frames are a way to look at the world and identify the beliefs that a person holds about the situation. Frames allow people to see the problem or opportunity in a new way and identify the steps needed to address it. Frames also allow people to communicate their ideas more effectively by providing a structure for their thoughts.
Leaders are not always able to control the events that happen around them. But they do have influence over how those events are perceived and understood by their staff members through what is called “framing.”
Leaders must take opportunities to reinforce the vision or alignment to a Frame. If someone is confused or unsure about the context and the vision of the message, it is the leader’s responsibility to seek to understand any confusion from their team. If a leader allows this gap in understanding to continue and too many of these occurrences accumulate, innovative ideas have no chance.
This table shows the current vs. desired system state to install to respond at market speed:
|Current State Beliefs
|Desired State Beliefs
|Individuals are the unit of productivity
|Teams are the unit of productivity
|Leaders are only responsible for their department
|Leaders are accountable for the system within which the teams work
|Belief in the Triple Constraints of Project Management
|A trusted system that builds accountability into the flow of work
The Transformation Frames
Most organizations were built to optimize for individuals instead of teams, leading to decision-making paralysis and a lack of autonomy at scale. The systems always win, meaning that unless there’s the right system in place, the organization will be limited in what it can do. The Transformation Frames is a proven model for Business Agility that shifts organizational beliefs about how they work to enable better decision-making and autonomy at scale.
The Transformation frames are:
- Systems First
- The 3 Things
- The 3 Things at Scale
- Managing Change
The context for the systems first frame is to hold these first principles:
- The Systems Principle: Systems get the results they’re designed to produce. Therefore, business agility starts with redesigning the system.
- The Leadership Principle: Leaders are primarily responsible for improving the system.
- The Capabilities Principle: Organize around capabilities because they are relatively stable.
- The Change Principle: Fearful people won’t try new things or take risks. Therefore, create an environment of trust and safety for people to adopt new ways of working.
- The “Call Our Shots” Principle: We can predict the value of Agile Transformation and deliver benefits that meet or exceed our predictions.
There are three schools of thought on Transforming into an Agile organization. They are Culture-Driven, Practice-Driven, and Systems-Driven. A Culture-Driven Transformation is focused on changing hearts and minds, being Agile rather than doing Agile, and focused on values and principles. The belief is that delivery systems will emerge based on new thinking. Practice-Driven Transformation concentrates on what the people do; focusing on roles, ceremonies, and artifacts. It can be management-driven or technically-driven. The belief is that Agile is a process or way to work. Systems-Driven Transformation focuses on forming teams, governing the flow of value, and aligning the organization first. The belief is that culture and practices only emerge within a rational structural and planning framework.
Applying system concepts across different divisions in the organization improves the effectiveness of the organization. This way, organizations can use their resources more effectively and achieve better performance levels. Systems Thinking evaluates how each division performs relative to all other aspects considered together instead of focusing on single areas or departments without considering any outside factors.
In a systems theory of Transformation, a proven hypothesis is that a) Agile Transformation begins by defining a rational system of delivery for the organization, b) true Agility comes by breaking people, process, and technology dependencies between teams across the organization, and c) a healthy system of delivery provides safety as team members adopt new practices, and over time, success with the practices causes culture change.
A systems-first approach to organizational Transformation solves the issues that get in the way of effectively practicing Agile and should guide the Agile Transformation initiative. For example, the consequences of not establishing a system for the flow of work can be both time-consuming and expensive. Without a system to govern the flow of work from inception to delivery, teams can quickly find themselves in unproductive meetings discussing their decisions rather than making them. This leads to an ad-hoc meeting culture where fear rapidly sets into anyone setting priority because no one knows exactly whose decision will stop all progress until it’s made clear again later downstream.
The goal isn’t Agile; the goal is an organization that responds at market speed. Agile is just one method to get there.
The context for The 3 Things frame is to hold these first principles:
- The Teams Principle: The team is the unit of throughput.
- The Backlogs Principle: Every team must have only one source of work.
- The Working, Tested Product Principle: Working, tested product is the primary measure of progress.
- The Predictability Principle: Unless a team is predictable, nothing else matters.
There are three things that make a business capability hyper-responsive to market demand. Business Agility requires teams, backlogs, and working tested products at its core. When an organization wraps the three things around a business capability, it can be very nimble and responsive to market demand.
Teams need to be cross-functional. A cross-functional team of about five to seven people can design, develop, test, and deploy to production. Creating a team like this removes any dependencies that would cause wait time for the team to complete a unit of work. Many complex organizations will have teams that don’t have a full working knowledge of a problem. A subject matter expert is partially assigned to the team in many cases. Usually, this is a long-time employee with company intellectual property with which only they are familiar. These individuals are generally very busy and in every meeting across the organization because of this specialized knowledge. This way, using subject matter experts creates a blocker for the team when they need this person’s input on design or implementation details. The team never seems to acquire the knowledge or teaming skills to investigate and learn their answers.
The team is the fundamental building block for capacity. To add, move or decrease capacity, it should be at the team level, not at an individual level. When an individual is removed from a team, it loses its cross-functional capabilities. The team is fully accountable for delivery. In this way, if there is an under-performing capability, leaders can pull two levers: team performance or product fit in the market; both are measurable.
A backlog is a list of prioritized units of work for a team. The work items are a construct from Agile and, at this level, are described in the voice of the customer, called user stories. User story properties defined by Bill Wake are “independent, negotiable, valuable, estimable, small, and testable.” The team’s user story backlog connects to the organization’s strategy. They should be able to draw a direct line from the strategy to a team’s user stories. The user stories are small; the intent is to have them completed in days or hours.
To call a user story complete, the team must build a working, tested product. Working, tested product means thoroughly tested and ready to be given to the customer. Creating a thoroughly tested product means there is no additional work to complete the user story. Therefore, this becomes the smallest unit of capacity. A user story is a way to build fast feedback loops. If a customer asks for changes, leaders could add that change to the team’s backlog and prioritize it based on business value against the other items. Because these user stories are independent, they aren’t dependent on each other, forcing the work into an implementation sequence; organizations can adjust the list as the market changes. The ability to respond this quickly is the truest form of Business Agility.
The 3 Things make a business capability hyper-responsive to market demand: teams, backlogs, and working tested product. When businesses wrap The 3 Things around their business capability, they can be very nimble and responsive to market demand. To do this effectively, they must implement cross-functional teams with a user story backlog connected to the strategy of the organization in order to gain speed and Agility when reacting to customer needs or changes in market conditions.
The 3 Things at scale are Structure, Governance, and Metrics. The context for The 3 Things at Scale frame is to hold these first principles:
- The Dependencies Principle: Dependencies kill Agility and therefore must be eliminated, encapsulated, or orchestrated.
- The Capabilities Principle: Teams organize around capabilities because they are relatively stable.
To scale an organization for Business Agility, the system must encapsulate or orchestrate the changes to business capabilities by providing a capability-aligned structure, a governance model that binds execution to strategy, and metrics to provide a feedback loop on decisions. Structure, Governance, and Metrics offer a system leaders can trust to delegate work.
Every team would operate with total autonomy and independence in an ideal world. The challenge is that dependencies exist, and products are inevitably more significant than a single Agile team can build within a reasonable timeframe. There is necessary specialization at the team level in many environments due to economies of scale, separation of concerns, and specialized domain expertise. All of these can drive a services team/product team dilemma.
There needs to be a frame for scaling teams, backlogs, and working, tested product to solve this problem. The frame is to organize value delivery around a set of business capabilities where we encapsulate work by capabilities and orchestrate external dependencies. This scaling frame aims to remove or mitigate the dependencies in the system that are creating bottlenecks.
When teams have encapsulated dependencies, they have the authority to make economic decisions in order to resolve conflicts. They can orchestrate these by adding a sequencing phase that sits above business priority, thus managing any bottlenecks on wait time for resources or making the capability more autonomous through software changes. External relationships requiring outside sources of control will also be visible, allowing higher-level negotiations between parties interested, whereas before, there were only lower-tier discussions happening which did little good.
The scaled version for using multiple teams is Structure, Governance, and Metrics.
Studies and experience show that a cross-functional team works best with 5-7 people on the team. A delivery team encapsulates a business capability and has a single backlog of prioritized work. This Delivery Team creates optionality through stories from their backlog that maximize the amount of work not done to deliver value quickly, ensure stories align to strategic priorities and demonstrate progress frequently via working tested stories. This team follows the organizational standards for delivering working tested products.
In large organizations, some business capabilities may need multiple Delivery Teams to complete significant work to provide new value to customers. Cross-functional teams help to encapsulate all the work required to deliver value. To scale, form a cross-functional team above the Delivery Teams called a Product Team. This cross-functional team has business and technical leadership roles to ensure that the solution matches business intent and aligns capacity and demand. This team creates optionality of solutions through features, maximizing the amount of work not done. They ensure that their backlog of work, made up of Features, aligns with the organization’s strategic priorities. This team can demonstrate progress via working tested product integrated from the Delivery Teams, and they manage the release of the integrated solution to meet the desired roadmap.
An additional team is also needed to help encapsulate or orchestrate across multiple dependent Product teams. A Portfolio team is responsible for maximizing the flow of value. This cross-functional team has business and technical leadership working roles to ensure that strategic alignment and solution vision are aligned. This team clearly articulates vision and value through the creation of Epics. They ensure priority alignment of Epics aligns with the organization’s strategic priorities. They understand the customer problems and hypothesize the importance of solving them. Therefore, they manage the allocation of budget to business capabilities.
In some vast organizations, they may need a fourth tier to manage the investment strategy across subordinate related Portfolio Teams. They can add other tiers, but do so at the risk of additional complexity. If they feel adding a tier is warranted, they need to return to analyzing their business capabilities and how they are aligned. Additionally, as they remove areas of manual orchestration for a value stream, they’ll need the ability to collapse unnecessary tiers.
No matter how many tiers an organization has, the following five categories of decisions exist to bind strategy to execution.
- Strategic Alignment
- Solution Vision
- Clarity and Capacity
- Measure Effectiveness
The Strategic Alignment Decision Category is centered around maximizing the performance of business capabilities. Performance is identified during the definition of the business capabilities and can be financial or a non-functional requirement such as security or compliance. During this decision category, the process is to create and document a shared understanding of the problem trying to be solved and prioritize it in terms of business value.
The Solution Vision Decision Category is where the work is defined and solutions and options are determined. Optionality is key here. It’s through this optionality that leaders can de-risk the delivery plan or trim the tail on features that have met customer demand, and work can stop and be redirected to higher-value areas. Here the teams will identify risks and validate the solution against business intent. This is where teams will use techniques to develop Objectives and Key Results (OKRs) to help them de-risk a solution and identify areas where fast feedback loops can help align to market demands.
The Clarity and Capacity Decision Category balance capacity against demand. The teams will plan how to manage dependencies and avoid rework to reduce time to value.
The Execution Decision Category manages the flow of the work to get to a working tested product. During this decision category, teams validate options to maintain the adaptability of the solution under construction.
The Measure Effectiveness Decision Category validates that the capability meets the needs of the customers and market. Additionally, the teams will create continuous improvement plans to ensure the system stays adaptable and responsive to change. Typically, measurement techniques like OKRs are used to measure the effectiveness of the capabilities being delivered.
Metrics are the way to measure the progress of the delivery organization. If there is one team, the measure of success is the value produced and given to the customer. Metrics can inform leaders when and if to pivot based on their business goals. Metrics help the teams expose the need for additional capacity based on their historical ability to deliver. This helps leaders and their teams decide where to use the money to create capacity. In a more complex system of teams, leaders need data to manage their organization measuring efforts working on the system and data to measure efforts working in the system. Metrics are used for good and not evil. Metrics are used to analyze the health of the hierarchy of the teams in the system to analyze and continuously improve that system. When metrics are used as part of a compensation plan, for example, there’s a side effect of people gaming the metrics and putting the individual or team goals ahead of the overall business goals.
It is important to measure the value delivered to the customer and the performance and health of the system of delivery. Measuring the value delivered to the customer ensures teams are building the right things. Measuring the health of the system of delivery ensures teams are delivering in the most efficient manner for that market segment. This efficiency shows up in an earlier return on investment of features delivered at a lower cost to produce the solution. Since there is a defined structure for the organization around capabilities, it can customize the level of responsiveness for capabilities based on market needs. Not all markets require the same level of Business Agility.
Teams, backlogs, and working tested product have been proven in several cases to be efficient and effective. The encapsulation of a capability works. Depending on the scale and size of the organization, The 3 Things might not be adequate to keep everyone aligned to the strategy and vision of the enterprise. The 3 Things at Scale Frame is used to scale the concept of The 3 Things and its major limitation, the need to manage dependencies beyond the control of an Agile team. In order to scale an organization, there must be a system in place to encapsulate and orchestrate dependencies efficiently. The scaling model for teams, backlogs, and working tested product are structure, governance, and metrics.
With good intentions, a team will stand up a pilot to show how an Agile team will work. The problem isn’t with doing a pilot; it’s the environment in which the pilot is set up. Building a pilot with a new team around a new capability doesn’t really prove anything. We know it will work. But that’s not the problem the organization has. The organization has a number of cross-capability and cross-value stream dependencies. The pilot chosen needs to be in an area that is important, with multiple teams that provide the ability to exercise the system at scale and work within the current system of delivery. This practice has led a number of companies and consultancies into a false belief that they have successfully transformed a portion of the organization, and the rest of the organization just needs to “catch up.” This practice ignores the fact that Agile isn’t the goal. The goal is to build an operating model that provides the ability to respond to customers and markets. They have to be able to change the tires while the car is moving.
The context for Managing Change frame is to hold these first principles:
- The Idealized Design Principle: Align the teams around a vision for the Transformation, one where all the current constraints are removed.
- Make The Change Principle: Use an iterative and incremental approach to build a pragmatic plan to move toward the end-state vision.
- Make The Change Stick Principle: Teams use metrics and assessments to continuously improve the health of the system.
There needs to be a systematic and measurable approach to moving the organization. Leaders define an end state for a set of capabilities, make the change, and define measures to make the change stick.
A proven model to manage this change process is to move a capability or a set of capabilities incrementally to the next quadrant leading to the target quadrant. This can be one team or a set of teams. Dunbar (1992) suggested that the human brain is limited in its capacity to understand the social world. He proposed that this limitation is expressed in the form of a cognitive limit on the number of people with whom one can maintain meaningful, face-to-face relationships. This number is around 150 people. Dunbar’s number is used as a guide to determine the size of an increment that will transform.
To use a mountaineering example, mountaineers have a long, hard climb ahead of them. They identify incremental points between the starting point to their goal, arriving at the peak of the mountain. These incremental points, called basecamps, provide a place to reflect and recover prior to starting the journey to the next basecamp. A group of people on this journey through the Basecamps is called an Expedition.
The Managing Change Frame identifies five major Transformation outcomes. The five outcomes are:
- Become Predictable
- Make Smaller Bets
- Break Dependencies
- Increase Local Autonomy
- Invest to Learn
Each expedition will define a target Transformation outcome based on the business goals for that Expedition. Not all Expeditions, or value streams, need to achieve all five Transformational outcomes. For example, a team that delivers product updates two times per year, once to update for government regulations and another release to add new features. This value stream may only need to achieve the first outcome of becoming predictable. Another value stream may need to respond monthly to market changes, so they will need to trek to Transformation outcome 4) Localize Investment Decisions.
The Expedition is organized by grouping a set of capabilities that work closely together to deliver value and bring those teams into an expedition. They limit the number of people to Dunbar’s number of 150. The 150 isn’t a hard and fast rule, just a guideline, and can be some percentage greater or less than 150.
The five Transformation outcomes serve as basecamps signifying increments of change to the value stream’s next stable state. Inside the Managing Change Frame, you will utilize the Systems First, The 3 Things, and The 3 Things at Scale frames to incrementally improve the organizational capabilities of the value stream under Transformation.
As an example of this equation, if the goal is to Transform 150 people at a time and it takes an expedition a year to reach its target Basecamp in a company of 100,000 people, the Transformation will take approximately 666 years. The good news is, as they go through the initial expedition, they’ll begin to form a reference model for change. Once the reference model is in place, they can spin up other Expeditions.
Using the Frames to Change Beliefs
Frames are a language that leaders use to change current beliefs. They provide a context for how the leader wants the organization to think about and model their thoughts in order to solve problems. Leaders need to be able to frame the problem in a way that is meaningful to their followers and then provide a solution that is framed in terms of what they want the organization to believe. This can be a difficult task, but it is essential for leading an organization through difficult times. To frame the vision, use metaphors, catchphrases, contrast, and stories.
When a good person is put in a bad system, the system always wins. The current organization is built to work well for the markets that existed during its inception and growth. With the advent of high-speed access and the desire for immediate feedback or satisfaction of current markets, it’s essential that organizations change to align with market expectations. The current systems must change to enable the teams to respond favorably to these rapid changes. Leaders in the organization cannot affect the change needed by focusing on an individual or group of individuals to make this change happen. Leaders must Transform the system within which their followers work to align their views and actions to the vision.
If the organization is slow in responding to changes in the market, it’s challenging to ensure that the organization aligns with its market strategy. Details matter, and the details are getting lost as the work flows into the organization, leading to misalignment in delivery or speed of delivery to the customer. This clarifies that changes need to be made to how the organization is working.
In the book The Art of Framing, Gail Fairhurst describes five framing tools to build the mental model leaders want their teams to have. Frames make beliefs visible using metaphors, catchphrases, contrast, and stories. These tools are used to create a mental model to make decisions within.
Stealing a line from Shakespeare: What light through yonder window breaks? It is the customer, and your Agile System, the sun!
When talking about Business Agility, they say things like, “You seem to be only worried about making your department efficient, but we need to all be aligned around customer value,” or “Our organization isn’t just about building things it’s about building the right things.” These metaphors show a likeness with current behaviors and open a conversation to change the way they think about working. For Business Agility, we use catchphrases “The 3 Things”, “The 3 Things at Scale”, “Systems First,” and “Managing Change.” These catchphrases give a shorthand way to direct the conversation into the Frames leaders want to focus on.
Organizations need their leaders to change from their current underlying beliefs to embrace the beliefs of the desired state. The Business Agility Frames, Systems First, The 3 Things, The 3 Things at Scale, and Managing Change help provide context and a mental model to craft to align the followers and lead the organization to win your market.