Just installing Scrum, SAFe, or LeSS is insufficient. Methodologies & frameworks alone won’t achieve Business Agility. Empowered & autonomous teams won’t emerge just because you want them to.

The reality is that change is hard. There’s no one-size-fits-all approach.

But there is a set of guiding principles that every successful Agile organization has in common. Our Chief Methodologist, Dennis Stevens, will guide you through these principles & help you discover how your organization can begin applying them to get you the results that matter.

Many large-scale Agile Transformations are struggling. Some have failed. Others can’t figure out why things aren’t working after multiple attempts. It’s easy to blame the people, the process, and the culture. It’s especially easy to blame management. However, the underlying problem is that most large organizations weren’t built to be Agile.

Organizational Barriers to Agile

Many organizations that adopt Agile operate with hindrances present. These dependencies don’t necessarily limit an organization’s ability to “do Agile;” however, these barriers negatively impact an organization’s ability to achieve Agility. Here are a few of the most common dependencies that organizations encounter:

• Individuals Spread Across Multiple Teams
• A Lack of Instantly Available Resources
• Too Much Work-in-Progress
• Limited Access to SMEs
• Shared Requirements Between Teams
• Technical Debt and Defects
• Low Cohesion and Tight Coupling
• Large Products with Diverse Technology

Enterprises that don’t address these barriers, whether due to ignorance of the presence of these dependencies or a present refusal or inability to do so won’t achieve the level of Agility that they seek.

Overcoming these impediments requires an intentional, realistic inward look at an organization’s functionality. An Agile Transformation will naturally break or otherwise limit these dependencies when conducted effectively.

Beginning Your Agile Journey

To begin an Agile Transformation, we must first recognize what exactly we’re transforming within the organization. Many suggest that Systems, Agile Practices, and—stop me if you’ve heard this one before—Culture are the keys to a successful Transformation. If we can believe this, where should we start our Journey to ensure that we are attaining the better business outcomes and delivery system that Agility provides?

While Culture, Agile Practices, and supporting Systems are all integral and must be present to achieve a successful Agile Transformation, it is of equal importance where you begin.

Culture-Driven Transformation

Many organizations begin their Agile journey by prioritizing a culture shift. This can manifest in a few familiar ways—CSM workshops, collaborative office spaces, rearranged desks, and motivational posters come to mind. Prioritizing this kind of cognitive shift is usually founded in the reasoning that if our people’s individual hearts and minds change, a new delivery system will emerge. Undeniably, if everyone bought into Agile adoption, if everyone just “got it,” complete Agile Transformation would be a much simpler process.

This idyllic outcome may be a plausible reality for a company with thirty-five enthusiastic employees. However, structural barriers exist that hinder Agility for large-scale enterprises. While an adherence to the values and principles of Agility promotes Transformation, a mere state of mind is an inadequate foundation for successful Transformation.

Practices-Driven Transformation

After completing a successful Agile pilot, many organizations overlay standard Scrum roles, artifacts, and ceremonies across the remainder of the organization in hopes that these practices will take root. They operate under the assumption that going through the motions of Agile enables them to overcome structural dependencies and foster a culture that supports Agile Transformation.

But while daily standups, sprint planning, and burndown charts give the appearance of Agility, these activities have become conflated with the benefits of Agility. While Scrum practices are integral to an Agile Transformation, these practices won’t yield better business outcomes if the underlying systems of an organization don’t provide a suitable environment where Agile practices can thrive. For this reason, many organizations that “do Agile” won’t get the benefits of Agile they sought at the onset.

Systems-Driven Transformation

While we recognize the importance of Culture and Practices, we’ve learned that a functional system that supports Agile practices must be established first, then the cultural shift will naturally follow over time.

Teams Level – The 3 Things

Once we understand what we’re Transforming in the organization, we must establish a firm foundation to build the System on. This foundation consists of the 3 fundamental mainstays of an Agile Transformation–or The 3 Things–Forming Teams, Building Backlogs, and Producing Working, Tested Software.

Forming Teams

An Agile team should consist of everything and everyone necessary to deliver—6 to 8 people dedicated to producing a working, tested increment of the product. These teams need to be cross-functional and decoupled to prevent dependencies.

Building teams in this manner not only prevents dependencies that hinder Agility, but also provides accountability to the team, ensuring that teams are able to make and meet commitments.

Building Backlogs

For many organizations, backlogs have become a series of thematic items that the product owner would like to build—frequently spanning multiple sprints and keeping the team from producing tangible increments of working, tested software. Alternatively, a backlog may appear as minor engineering activities.

A backlog must be functional and be built in a way that gives the teams clarity around what they are building and how what they are building fits into the bigger picture.

Producing Working, Tested Software

Developing a working, tested increment of a product at the end of each designated period is the ultimate goal of adopting Agile.

“The 3 Things” at Scale

Once we have established the foundation for our Agile Journey at the Teams Level, we need to scale those fundamentals across the remainder of the organization. The 3 Things at scale take the form of Structure, Governance, and Metrics.

Structure

Structure is the expression of teams at scale. We strive for collaborative participation at all levels of the organization. A vertical slice of the organization including Portfolio, Program, and Delivery teams align around value streams, products, or business capabilities. This regulatory structure ensures that the encapsulated slice has everything they need to deliver value to the organization.

Governance

Governance is the expression of backlog at scale. Practically, Governance describes the way we manage the flow of work, prioritize decisions, and make economic tradeoffs in the face of uncertainty. The Portfolio Team plans and provides the strategic business outcomes in the form of epics. The Program Team then decomposes the epics into features and further negotiates with the Delivery teams on prioritization. Many associate this Governance structure with a Waterfall methodology; however, we can apply this in an Agile way that ensures that the work being completed at the lowest level is strategically aligned around the things the organization actually cares about.

Metrics

Metrics and Tools are the expressions of working, tested software at scale. This entails the ways that we measure how an organization is delivering value not only at the team level but across the entire organization. These metrics look differently at each tier of an organization. For example, Delivery Teams focus on Backlog Size, Velocity, and Escaped Defects, whereas Program Teams are concerned with Cycle Time and Features Blocked. Meanwhile, the Portfolio Teams prioritize Takt Time, ROI, and Time/Cost/Scope/Value. These metrics allow all levels of the organization to maintain strategic alignment and ensure that we’re focusing on work that’s valuable to the business.

Summary

Agile fails in many large enterprises due to their operating within a broken system that’s full of dependencies. To overcome this, an organization must build a functional System founded on the fundamentals of an Agile Transformation: Forming Teams, Building Backlogs, and Producing Working, Tested Software. With this foundation firmly set, we become able to scale these fundamentals to the remainder of the organization, dismantling or diminishing dependencies along the way. It is then that Agile Practices may take hold, and an Agile-centric Culture may then follow.

In this episode of SoundNotes, Dave is joined by LeadingAgile Chief Marketing Officer Tim Zack. Tim offers his unique perspective on how to communicate within an organization during an Agile Transformation to influence lasting change. The biggest part of an Agile Transformation is asking people to work differently at a job they might have been doing for years. People are naturally resistant to change, especially when their livelihood is on the line.

Tim discusses the strategies that organizations can use to communicate where they want to go. It’s about influencing people over a period of time, not going in and trying to change the culture first. This is why we lead with a systems first approach because they adapt to change faster than people. Making lasting change in an organization is a slow, repetitive process as people become ready to hear it, understand it and apply it.

Contacting Tim Zack

If you’d like to contact Tim you can reach him at:

• LeadingAgile: https://www.leadingagile.com/guides/tim-zack
• LinkedIn: https://www.linkedin.com/in/timzack
• Twitter: https://twitter.com/timzack
• Email: tim.zack@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

• LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
• LinkedIn: https://www.linkedin.com/in/mrsungo
• Twitter: https://twitter.com/mrsungo
• Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

And if you’re interested in taking one of our upcoming Certified ScrumMaster or Certified Scrum Product Owner classes, you can find all the details at https://www.leadingagile.com/our-gear/training/

The other consultant and I stared in amazement. We were coaching a small group on how to bridge the company’s strategic intent into a list of items that would be in this group’s work backlog. After talking through the general concept, one person’s idea of a strategic goal was what we would have defined as a backlog item. The topmost goal was, “This is what I am going to build.” And the rest of the model involved breaking down “How can I best build it?” And my experience shows that this scenario is not uncommon.

In fact, you or your team members may find yourselves in the category of not understanding strategy that well. If you don’t often work with strategy and the distinction between strategy and execution or tactics, your team’s delivery goals are seen as your strategy.

For companies in search of Business Agility, it’s important to track how efforts on the ground link to the company’s strategy. With the strategy to execution link in place, the organization has more ability to adjust to changing conditions. Leadership can update their strategy, and the systems managing direction and work will cascade change down through the organization. Many organizations are turning to Objectives and Key Results or OKRs to create this strategic alignment, and I’ve included a short description of an OKR below. However, the first step is often tackling (gulp) strategy. We’ll get to that in the second part of the blog post.

So what can the practical, non-strategic folks do when faced with a request to handle ‘strategy?’

The other Agility benefit comes from decoupling the problem to be solved, in this case as defined by strategy, from the solution that develops as the strategic aims are met.

Objectives and Key Results (OKRs) As a Tool for Strategic Alignment

To better align enterprise strategy with execution, many organizations use the Objectives and Key Results (OKRs) framework. Once in place at all levels of an organization, you can draw a line between each activity, its associated strategic impact, and the overall goals and strategies of the entire organization.

OKRs have two main components:

• Objective: What aspirational state do you want to reach?
• Key Results: What is the measurable change in behavior or outcomes that the organization is making to progress toward the Objective? The behavior changes are not the act of ‘doing’ something. They often reflect the change in behavior of the groups receiving the work.

Once the Key Results associated with an Objective have been measurably achieved, the premise is that the Objective will have been reached. The reality is that when we begin a journey, we rarely understand that along the way, we will discover new and better ways to accomplish our objectives. So often, our Objective remains the same, while the Key Results we use to measure progress often change.

Getting Started With Objectives

But that’s all in the future. For now, at the start of your OKR journey, you may have been asked to create one Objective. Just one. And you can’t figure out where to start—nor when you will be done—not to mention how to ensure that you are doing it ‘right.’ It’s frustrating. Most of us spend our careers focusing on getting the right answer. Then OKRs come along, and we have to live knowing that OKRs may only give you the right focus until you determine that something else makes more sense. OKRs are humbling that way.

Here are a few of our natural biases that trip us up on our journey to successful OKRs:

• Most of us don’t think in terms of strategy. We organize our lives with tasks and To-Do lists.
• How long should a strategy item take, anyway? What size of change will be meaningful?
• Our long-term goals and how we keep score on achieving them is fuzzy in contrast to what is urgent today.
• We don’t frequently re-examine our plans or strategies for getting from “here and now” to “there and then.” Once we head off in a direction, we don’t want to stop until we arrive at our pre-determined destination, whether or not it’s still worth reaching.
• We don’t track our progress towards achieving objectives along the way. Our focus is 100% completion – whatever that means to you. We don’t stop to check how much progress we’ve made.

Here are a few ideas for getting started that address these stumbling blocks.

Objective:

Write one. You know where you want to go or have a pretty good idea of how your contribution makes a difference in the organization. Don’t agonize. Write one. Keep it short; I recommend under 14 words. Purists go for five words; I am not a purist. One hint: Don’t focus on numbers like sales increases—that’s a goal. Focus on the change that will make your numbers happen. Maybe: “Open up a new market in Thailand.” What’s your Objective?

A note on the size of an Objective: every organization has its guidelines. The length of time it takes to complete an Objective also varies with where you are in the organization. Top-level OKRs may take years. At the division level, less than 12 months, and for smaller teams, a quarter is likely to be a good-sized objective.

Key Results:

Key Results are tough cookies to tackle. And everyone has their own journey as they find Key Results that make sense for them. If you have either a list of process steps or a To-Do list, those will make really poor Key Results. Why?

• Process steps apply to any work you do. They don’t explain why doing them is valuable. And no matter what task comes in, the process takes over completing the task. Avoid using them as KRs because you’ll have to rewrite them.
• Task lists are also poor Key Results. They are not strategic in nature but tactical. If you have your task list and want to work backward into strategic intent, start by asking yourself the following questions:
  1. If I finish these tasks, what valuable thing happens that is visible as valuable to the organization?
  2. What behavior changes do I expect to occur from my users? Do my users move more quickly through getting their job done? Do people spend more time on my site? Do they buy more?
  3. Focus on the outcome of what you create. Our task lists are usually a list of outputs; they answer, “I did this.” An outcome focuses on is the impact of completing a task. If you don’t know the outcome of your work, bring in someone who knows that part of the picture. For larger efforts, it can be hard to see the impact of a small part of the puzzle. Once you understand how your work fits into the whole, your motivation to complete your part of the picture—and your level of satisfaction in your work increases.
  4. Can I measure interim steps in achieving my Key Result? Yup. Can I tell how far I’ve progressed toward a Key Result in real-time? How many people have been trained? How many databases will I have set up? All of these are good Key Result tracking metrics.

This list above is the trick to turning your task list into Key Results that address strategic intent.

Key Results: The Measurable Part

In step 4 above, I mentioned measurable Key Results. Let me clarify. Every Key Result should be measurable. Yes, every one. And most people struggle to find a measure of their Key Results. A couple of tips here:

1. Select measures in Key Results that you can track at any time. The official name for these is “LEADING indicators.” At any time, you can check and see how far you’ve progressed. Your Key Result shows a 10% decrease in processing time. Great. Your systems should allow you to create a baseline and check progress.
2. Avoid Key Results that are incomplete until they are finished. Revisit your Key Results until they have interim measurable steps.

Key Results Review

When you have your Key Results, look through them carefully.

Through the process of moving from a task list, often several task items roll up into one measurable Key Result with a user behavior change. This is typical. Instead of a LOOONG list of things to do, you now have a way to check on actual results that your company cares about. The better news: if, along the way, you discover a better way to achieve your key results, you simply change your task list without an impact to the OKR.

 Putting It Together

Once you have your Objectives and Key Results, put them aside overnight. In the morning, look at them with fresh eyes and answer these questions:

• Does my Objective still look like it will create a positive change in my company?
• Does the wording need to be tweaked for clarity?
• Have you found a better measurement for your Key Result?
• If all the Key Results are reached, will the Objective be closed? If not, what else would close the gap? If I will more than achieve my Objective, which Key Result can I remove?

OKRs are written both as individual endeavors and group challenges. Either way, bring fresh eyes to your OKR until you are pretty happy with it. Then, submit it—and keep checking on it to check your progress.

Good luck!

This week on SoundNotes our Founder and CEO, Mike Cottmeyer, joins Dave to discuss why simply showing up and having the answer for the customer is not enough. During this conversation, Mike explains the process he follows when engaging with clients to ensure he is truly hearing them and understanding the way they see the problem, and how that begins a series of steps that enables him to work with the client to find the best solution for them.

If you are involved with introducing change in an organization, especially from a consulting standpoint, this interview is a must.

Contacting Mike Cottmeyer

If you’d like to contact Mike you can reach him at:

• LeadingAgile: https://www.leadingagile.com/guides/mike-cottmeyer
• LinkedIn: https://www.linkedin.com/in/cottmeyer/
• Twitter: https://twitter.com/mcottmeyer
• Email: mike@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

• LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
• LinkedIn: https://www.linkedin.com/in/mrsungo
• Twitter: https://twitter.com/mrsungo
• Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

And if you’re interested in taking one of our upcoming Certified ScrumMaster or Certified Scrum Product Owner classes, you can find all the details at https://www.leadingagile.com/our-gear/training/

Introduction

“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:

1. Scope is knowable in advance
2. Work is estimable with precision
3. 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:

1. Systems First
2. The 3 Things
3. The 3 Things at Scale
4. Managing Change

The context for the systems first frame is to hold these first principles:

1. The Systems Principle: Systems get the results they’re designed to produce. Therefore, business agility starts with redesigning the system.
2. The Leadership Principle: Leaders are primarily responsible for improving the system.
3. The Capabilities Principle: Organize around capabilities because they are relatively stable.
4. 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.
5. 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:

1. The Teams Principle: The team is the unit of throughput.
2. The Backlogs Principle: Every team must have only one source of work.
3. The Working, Tested Product Principle: Working, tested product is the primary measure of progress.
4. 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:

1. The Dependencies Principle: Dependencies kill Agility and therefore must be eliminated, encapsulated, or orchestrated.
2. 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.

 Structure

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.

 Governance

No matter how many tiers an organization has, the following five categories of decisions exist to bind strategy to execution.

1. Strategic Alignment
2. Solution Vision
3. Clarity and Capacity
4. Execution
5. 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

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:

1. The Idealized Design Principle: Align the teams around a vision for the Transformation, one where all the current constraints are removed.
2. Make The Change Principle: Use an iterative and incremental approach to build a pragmatic plan to move toward the end-state vision.
3. 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:

1. Become Predictable
2. Make Better Bets
3. Decouple Ecosystem
4. Localize Investment Decisions
5. 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.

This week LeadingAgile Senior Consultant Matthew Oatts joins Dave for a different kind of interview. This is the first of two interviews we will be posting with Matthew and they both focus on what it is like to work here at LeadingAgile and how to make the most of your early days with the company. Because LeadingAgile has a unique point of view and approach to organizational change and Agile transformation when people join the company we take extra care to make sure they are up to speed on the LeadingAgile Why and How. As the company has matured over the years our on-boarding process has gone through a number of iterations and has evolved into a very comprehensive robust program.

But, Matt joined LeadingAgile during the 2nd half of December of 2021. In consulting, the last few weeks of December are pretty slow and this meant Matt was going to need to wait for an on-boarding class to start. This gave Matt some time to dig around on his own and discover his own path while he waited for his official introduction to the way of LeadingAgile. During this interview, we discuss some of the most valuable things Matt picked up on during his first few weeks and his take on what it is like getting started at LeadingAgile. In a few weeks, once he has officially completed his onboarding, were going to do a follow-up to see how he felt about his official introduction to LeadingAgile.

For anyone considering working here, or getting started working here, this interview should offer valuable tips on what makes LeadingAgile a unique place to work and how to make the most of your initial days with the company.

 

Contacting Matthew Oatts

If you’d like to contact Matt you can reach him at:

• LeadingAgile: https://www.leadingagile.com/guides/matthew-oatts/
• LinkedIn: https://www.linkedin.com/in/mmoatts/
• Email: matthew.oatts@leadingagile.com

Contacting Dave Prior

If you’d like to contact Dave you can reach him at:

• LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
• LinkedIn: https://www.linkedin.com/in/mrsungo
• Twitter: https://twitter.com/mrsungo
• Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

And if you’re interested in taking one of our upcoming Certified ScrumMaster or Certified Scrum Product Owner classes, you can find all the details at https://www.leadingagile.com/our-gear/training/

The Great Junior Consulting Experiment

A few years ago, LeadingAgile embarked on an experiment to create a junior consulting role for young college graduates. We knew it was the right time as a company to grow and create space for new academic disciplines to add to our practice. There was just one problem.

Being that we’re consultants, the responsibility to the client is sacred. There’s so much to learn for someone new to the job, and it can be challenging for those on the account to create safe opportunities for them to learn while simultaneously doing the work.

So the first batch of junior consultants had their work cut out for them. There was a lot of pressure to perform in the opportunities we were given. What I learned going through this process is this – it’s hard to speak up.

I think this is something many eager young professionals struggle with entering the workforce – we have many insights, but knowing how to share them (and how to be listened to) can be a challenge.

As I was soon to find out, being heard did not always mean being listened to.

The Urge to Tell

With bold ambitions, I graduated college and set out in my career to change the world. But showing up at the client site on day one was a different story. I was terrified. I knew nothing and wanted to guard that secret with my dying breath.

To fill the empty void of imposter syndrome sitting in my gut, I opened my mouth and started talking. I wanted people to know I had good ideas and correct answers.

On a few occasions, I went to absurd lengths to prove it. I would challenge my team members on the smallest issues, creating lots of casualties along the way, just to get the satisfaction of feeling listened to.

It didn’t take long before these hiccups manifested in gaping holes in my relationships. I felt like nobody understood me, and there was a great divide between us.

I thought, “if only I got better at telling people the answers, they would all see I had them.” But I was missing a very important distinction between truth and my version of the truth.

It’s Not About Being Right

It was right at this time that one of my mentors watching me through this experience told me something I needed to hear:

“I do think you have a perspective that is valuable and needed, but you have to realize that our clients are dealing with complex situations. There’s politics; there’s feelings around the politics. There’s a minefield you can’t even see.

The whole truth is much bigger than you, even though you have an important part to play in it. To weave yourself into the larger truth, you have to connect with others and hear from them what they have to say.”

And it made me think: “maybe it wasn’t about answers at all?”

Maybe the truth was something bigger than me. And maybe, in the uncomfortable pause awaiting truth, when my urge to jump in with answers showed itself, I could look deeper into others to find it.

Influence Starts With People

If you are like me, frustrated that your answers aren’t reaching people, then maybe there’s more work to do besides having the correct answer. Perhaps part of our solution is about the people and the work we have to do preparing people to listen.

This takes time, and the more I grew to respect that, the more I could get past this urge and find ways to really relate to people. When I started focusing on the people, the edges softened, the space opened up, and we could actually share more with one another.

This is not so different from how we engage with organizations. When we walk in the door, there is more history and sub-text baked into the language than we could ever imagine. The types of problems customers bring us are complex, and we can’t just pretend we have the answers. To really influence, we need to spend time getting to know the people, their unique problems, and how they talk about their problems.

If we focus on the answers and forget the people, we’re wrong every time.

Agile teams need clearly defined backlogs with easily actionable requirements.

Without an organized backlog, teams can’t deliver regular increments of working, tested product. If we aren’t delivering regularly, we might not be responding to our customers and markets quickly enough.

Backlogs are also necessary to measure the scope of the teams, and how much work they can complete during a given sprint. The ability to know the scope of the teams allows you to create stable velocity delivering work at the end of a sprint.

Building a stable velocity is essential to becoming more predictable and adaptable in the marketplace.

Lean more about well-formed backlogs in this podcast: https://go.leadingagile.com/2fv

Learn more about the benefits of predictability in this blog post: https://go.leadingagile.com/s8f

Connect with us on our social media platforms:

https://www.facebook.com/leadingagile

https://www.linkedin.com/company/lead…

https://twitter.com/leadingagile

 

The foundation of Agile is to form teams, build backlogs and produce a working, tested increment of product. These are The 3 Things necessary for Agile to succeed.

When a company wants to adopt Agile, an important first step is defining a strategy of what the teams will look like and what they will be formed around.

Our team forming strategy allows us to create autonomous teams that collaborate to create a finished product. We empower team members to use their expertise to make decisions and create a consistent workflow.

With the teams formed in this way, we are set up for success on the path to sustainable Business Agility.

In case you missed it live, here’s the AMA with our Chief Methodologist Dennis Stevens and our Product Practice Lead Andrew Young.

They sat down to field questions on Agile Transformation and Agile in the Product space.

They cover topics such as planning cycles, iterative funding, metrics, value streams, OKRs, leading indicators, Business Agility, and more.

To make a meaningful change requires people to think, feel, or do something different—and usually all three simultaneously. But people are naturally resistant to change. We become comfortable in what we know, and moving into an unknown experience can be scary.

There are many reasons people resist change, particularly in a work environment. There are the people who “have always done it this way” and are hard to convince that doing things a different way will create a better outcome. Maybe the new method involves more work, and they’re comfortable with their current workload, or they don’t have time for more work. For many people, resistance is rooted in fear. They have a secure job, a family to support, and a livelihood that’s at stake. Any change that could threaten that is bound to create resistance.

From a leadership perspective, you may not even know that people are worried about these things personally. All you see is the resistance. You create a vision. You communicate the vision. You create a plan for change, and then you expect that’s what will happen.

But without addressing the issues that your people must face, change won’t take root. People may try for a little bit, but they’ll end up going back to their old ways once they see their environment hasn’t changed around them.

So how do we influence change while supporting the people making the changes?

We’ve created a change management strategy called PSTIR that gets people on board, creates safety for the people to change, and provides a way to measure progress in a way that’s meaningful for the entire organization.

Building The Foundation for Change

Change can’t be something that’s done to the organization or for the organization. Change is something that must be done with the organization.

Creating lasting organizational change requires those being changed to be fully participative, immersed, engaged, and on board with the future state vision.

The ones implementing the change—leaders, influencers, or stakeholders— need to have a vision or a hypothesis for the change when it’s complete. That vision needs to be shared with the organization and customized where appropriate to make sure it fits. There’s no one size fits all approach to change management.

Next, we need to enact the change and show the organization what the new normal looks like.

Last but certainly not least, we need to sustain the change over time.

How To Successfully Implement Change

So, what is PSTIR?

PSTIR is a way of progressively elaborating our change backlog and engaging those implementing the change and those being changed. It is a strategy for aligning beliefs across the organization to engage those being changed. PSTIR can be applied to the changes made with individuals, teams, organizations, or the system itself. The basics are the same regardless of where it’s used.

PSTIR: Prepare, Socialize, Tailor, Implement and Reinforce

Prepare

Determine who needs to be involved in the change and who the leaders and influencers are; they will drive the change. Leaders need to develop a clear hypothesis of how the system looks different in the future state vision, what changes need to happen for the system to get a different outcome, and how to measure progress. Help people see themselves in the system and why they are essential to the change.

Socialize

Engage the leaders and influencers to align them to why we want to make the change and what it will look like. Listen to their feedback and apply it to the plan. Create the necessary conditions to execute the transition with the rest of the teams in the organization with support from the leaders.

Tailor

Act on the feedback we receive and make changes to the plan as needed. Take people’s understanding of why something will or will not work and put that into the plan. Get the leader’s agreement on how we will implement the change. Customize to meet the needs of the organization.

Implement

Execute the change to make it real for them. Provide training, workshops, one-on-one coaching, etc., for the teams. Make sure the organization that’s being changed gets immersed in what we’re doing. Help people see what their work will look like in the future state.

Reinforce

Measure progress and show results to all involved. Celebrate successes along the way publicly so everyone can share in the progress. Continue to modify as needed based on results and feedback.

Together, we’ll prepare for how the system is different once we make the change. We will socialize the change with key leaders and influencers to align them around the change we tailor based on their feedback. We implement that change in the organization. And finally, we reinforce that the change happens and celebrate the successes.

As we know, change must be done with the organization. However, the approach you cultivate along your journey can help you create change. PSTIR is a strategy for aligning those beliefs to create lasting organizational change.

Change is hard, but leveraging PSTIR will help you create a safe environment for your people to embrace the changes required for a successful Transformation.

Mike Cottmeyer was recently a guest on the Agile to Agility podcast with Miljan Bajic where he discussed Transformation, Business Architecture, and Scaling. Listen now.

Agile to Agility Website

Transcript:

Speaker: Miljan Bajic  00:29

Who is Mike Cottmeyer and what’s been your journey?

Mike Cottmeyer  00:33

Okay, well, that’s a big question, man, who is Mike Cottmeyer? Well okay, well, I’ll take it from a professional angle. So, I’m the CEO of a company called Leading Agile, started about 11 years ago, I’m based in Atlanta, Georgia. We’ve gotten pretty big over the last couple years, we’re about 160, almost 270 people, we focus almost exclusively on Agile Transformation. More often than not in kind of either the IT product development space or IT services space. We like to consider ourselves kind of a full stack consultancy in the sense that you know, obviously, you have to deal with the work surface levels and what the teams are doing but you know, how do you orchestrate teams across dependency boundaries? How do you go up into Portfolio Management? How do you go up into investment management, that kind of a thing? What do you do with audit and compliance? What do you do with planning cadences? What do you do with Enterprise Architecture like, the whole thing, right? So like, what we really do is, I like to think of us as like, we kind of refactor organizations to be able to operate with more business agility, right, in a nutshell. And then aside from that, you know, I’m a dad, a husband, I have three boys, you know, so it’s basically family and work for the most part, for me.

Speaker: Miljan Bajic  01:53

You got a lot of guitars and are those guitars in the background?

Mike Cottmeyer  01:56

I do, I play guitar. So I actually, as soon as I said that, I went well, it’s not 100% try skill at hand. I play guitar and I did jiu-jitsu and I’ve been kind of on a bit of a fitness journey for the last couple of years as well. So yeah, but the hobby is all kinds of very, guitars have been persistent in my life since I was about 12 years old. Yeah.

Speaker: Miljan Bajic  02:13

Nice. How did you get into this agile space? You said, you’ve been doing this 11 years but I’m sure it’s more than that. Like, how did you end up?

Mike Cottmeyer  02:21

Yeah, well, back in the early 2000s. Well, I guess, you know I spent the first 10 years of my career mostly in IT infrastructure. So like, literally like 19, to about like, 30 or so and then, so I guess 30 put us in the early 2000s. And you know, the manifesto had just been written and I was working as a project manager in a company called CheckFree here in Atlanta and squarely like in the PMO. But I had always kind of adapted practices, project management practices to deal with variation because like, my worldview was that things were not as certain as the Gantt chart implied, kind of view. And so, I was working on this company called Check free in the PMO, doing PMI style project management and I was working with development teams and there was a guy who’s on my team now named Brian Sondergaard, who I worked for. And we were going back and forth on some things and so I inquired, I like, what do you guys like, tell me, what do you guys formally doing and they were doing they said it was extreme programming at the time.

But what they’re really doing was like scrum with technical practices and things like that, I ever more aligned, it felt like to me was Scrum. And so, I built a relationship with this dev director that I was working with and he and I would collaborate and I was reading books and you know, reading all the Kent Beck stuff, [unsure 03:48]. There were so a lot of guys writing kind of in the rough space and scale project management space, agile project management space, that time Jim Highsmith write on that kind of stuff. And then so the same guy, Brian Sondergaard, ended up coming in working for him in his dev organization and we just started doing some really cool stuff with Agile program portfolio management. We were inventing a lot of things, taking David Anderson’s work on Kanban and agile management stuff that he was doing and literally building like, what you would recognize now is like, early versions of safe, you know here frameworks and like flow based management systems at the higher tiers. And so, it’s that for a couple years, that group reorganized and I kind of find myself back in a regular PMO and I’m like, that’s not cool, right?

At that point I said that, no disrespect to PMOs out there but it’s like, we’ve done so much cool stuff like I just couldn’t go backwards. Right? And then, so I ended up going to work for Version One for a little bit and that was like my first introductory to like a pure play agile organization and I was on the team that went in, trained and consulted. And what was super cool about that was and I know a lot of practitioners are listening to this, will recognize it, when you have a tool, the tools are typically designed to work in an agile way. And if you’re working with an organization that’s not really structured for agility, like you start to recognize there’s a lot of stuff that’s broken and you have kind of two choices. You either change the tool to accommodate the organization or you change the organization and unfortunately, most of the companies that we were dealing with, didn’t have agency or influence to change the organization.

But I started writing a lot about what I would do and I started doing talks about what I do. And the cool thing about Version One is like, any talk, any conference I can get accepted to, they let me go speak and I was off speaking. Yes, going to conferences, building networks, you know, meeting with people I got to meet, you know, people who were like my heroes like, Jim Highsmith and Alastair Coburn and Christopher [unsure 05:55] and Joshua Kerievsky and you know, Kent Beck and like all these guys, right? And was fortunate to become friends with some of them through the years, right which is pretty cool to become friends with your heroes a little bit. Literally standing on the shoulders of giants, left out Mike Cohn, never really became buddies, duster dirty, you know, just all those luminaries of our field just consumed everything, right? And I was just writing and writing and speaking and stuff and then you know, when joined a company called Pillar Technology for about a year, ended up not being a great move for me personally but great company or fine.

Sold to Accenture, I think and then loving years ago launched leading agile and stated goal is I wanted to make, I want to double my salary and work part time but I failed miserably. For 11 years, became a CEO and learned a ton about stuff I’d never want to learn about like, banking and [unsure 06:57], benefits and investment strategies and you know, growth and SGMA and cost of goods sold and all kinds of stuff like that, yeah. Trying to keep the company as agile as it can possibly be so like, we try super hard to organize in ways very similar to how we ask our customers to organize and manage their processes, empower the people and you know, distribute decision making and try not to be super commanding control. And you know, that kind of a thing so we try to do what we say to do, right and we try to be that way.

Speaker: Miljan Bajic  07:30

Yeah, that is awesome. I think you know, obviously I know they prior and you know, I’ve known other people that worked and it’s you know, from Leading Agile, at least what I’ve heard people that work for Leading Agile. Like, the way that you engage with your clients is, you know, focus more on coaching, focus more on meeting people where they are in companies. And I want to kind of go back to something that you mentioned which is, you said you refactor organizations. And I want to go to a topic, I haven’t discussed this with anybody on the podcast, I’ve done business architecture. And I want to start there and then we can kind of go down but from your perspective and you said something that’s related to this, you said, if your systems and capabilities are not aligned to your products and customers, your practices don’t matter. So, I want to come back to that but could you just maybe for those that are not familiar with what business architecture is, could you maybe just describe it?

Mike Cottmeyer  08:28

Well, so we’re in an interesting phase of Leading Agile where we have people that are deep experts in things that are not deep experts in. And so, like the Stevens who was one of my early, like, co founder kind of people, deep expertise in business architecture, I kind of think I’m just kind of a business architecture hobbyist, right? But in principle, what we’re talking about with business architecture, is we look at the organization not through the lens of what the people do or what their function is but more through the lens of what are the services that the business provides. And so like, the analogy I use, the reason why I talk about refactoring is because I think there’s like a really strong metaphor here. It’s like when you take like a legacy monolith and you want to like move to the cloud or do DevOps or something like that, right?

You can’t pull the whole monolith up and put it in a cloud, right? What you end up doing is you’re pulling out services and you end up encapsulating services and you put encapsulated services, service boundaries and contracts and all those things, you move that to the cloud, right kind of thing? And that’s what a lot of organizations are like, but it’s people and structures and processes and org design and things like that. And so, what when we do an early stage transformation, I actually don’t bring typically agile coaches. I mean, everybody’s like very familiar with Agile and Scrum and things like that but I wouldn’t call them agile coaches per se. We typically do in early stage like a startup engagement where the business architect and somebody who’s like really, like a product person but probably a little different than most people would think. Like, so we go in and we will literally do like business capability models, heat maps at your organization.

Speaker: Miljan Bajic  10:13

And then I’m assuming this is somebody like pretty high up like, C.O.O. Like, because those are the people that have usually authority to make these type of changes, right or is it somebody like?

Mike Cottmeyer  10:22

Yeah. Well, that’s probably an interesting angle. Right? So, one of the things that I talked about as a company and just from us is we have to be incredibly patient in our sales cycle. Because like, it all comes down to span of control and so, you know, so if you’re dealing with like a division, right, it might be like a division head, it could be a divisional C.I.O or Senior Vice President or Vice President is working with a business partner on that side nav, span of control over like a piece of the organization. But yeah, absolutely right, the kinds of changes that you have to make, have to be sponsored at the top because they’re not process changes.

Process is part of it but like, you literally have to create a hypothesis organizationally for what you’re going to group people around. Right? And so, let me take it from the other side, like one of the, like I did a talk for the scrum gathering in Vegas, it had to have been, you know, eight, nine years ago at this point. But I did this talk called, ‘the three things’ and it was like, the three things you need to know to transform any organization. And the three things are just really simple, team’s backlogs, working test, the software and the way Scrum works, we know this, right? The way Scrum works is you have to have a dedicated team of people that own the product that are interfacing with like, a product owner who’s responsible for the backlog and they have to have the ability to produce a working tested increment, the end of every sprint, like period, hard stop. Right? And if you don’t have those conditions, then what starts to happen, right is you get teams that are breaking the rules of Scrum because they kind of have to, right? And so like, at the lowest level of the organization, you have to ask yourself is what is necessary to form a complete cross functional team that stays together over time. And what it is it comes down to is that you have to have a capability or a feature set or encapsulated service with technology boundaries, a dedicated team, a service owner or product owner and you have to have the deployment capabilities to produce a working tested increment at the end of every two weeks and that’s just true, right? And so, you can either kind of take the scrum approach that says, okay well, we’re going to start doing Scrum and then your impediments will reveal themselves and the impediments will get resolved by the scrum master. But in practice, right, that’s too low level to address these systematic issues.

Speaker: Miljan Bajic  12:57

Exactly. Because I think what happens is like, then the dependencies are exposed and you start seeing all of a sudden, all of these dependencies, you still have delivery issues, right?

Mike Cottmeyer  13:08

For sure, right? For sure, and that’s really, so you hit the nail on the head, right? It’s like, its dependencies in some form of fashion at the end of the day, they get away, because you know, the Scrum and this is where safe comes in, it’s kind of interesting, right? So, what scrum came along and said was, okay, we’re going to encapsulate the dependencies inside the team. And we’re going to give the team agency to how to resolve those dependencies in real time, that assumes that the dependencies are encapsulated within the team. So now, when you have multiple Scrum teams that have dependencies between them, right, what’s safe came along and basically said was, well, I’m going to encapsulate the value stream and we’re going to put the boundaries of the dependencies between teams, within like a release train or a value stream or big room planning around it or any string between things and we’re going to do this stuff, right?

What we find is really complex organizations, the value streams are not really encapsulate very well, either. Right? So, what do you do with dependencies between value streams, right? Now, the last guys right, Bassford, and [unsure 14:15] you know, I think Dave actually got the model right. It’s like, you’ve got to break the dependencies, you got to put the right technical architecture and stuff but the challenge is that, it can take years in some of these organizations, right? That’s not a flip of the switch, even if you want to defund it, you couldn’t do it overnight, you couldn’t do it safely, quickly. It takes a minute, right.

Speaker: Miljan Bajic  14:35

It also takes people like, I think maybe it takes a lot of people to understand what needs to happen. Then maybe just to kind of add another thing here, which is reference architecture. So, we talked about business architecture, business architecture, just for to keep it simple, it has to do with organizational design, policies, essentially, how do you architect your organization, right? Like, you know, where does reference architecture, we’re not talking about IT reference architecture but business reference architecture fit in and what is your?

Mike Cottmeyer  15:10

Well, let me tell you the way I usually use that word, right? So, there are organizational patterns that I think are universally true. Right? And I think safe and last, and maybe some other things like discipline, Agile Delivery, some of the stuff that like [unsure 15:28]’s done with met objectives and I guess now he’s part PMI. A lot of what those people have built upon are really sound foundational principles, like encapsulated teams at the work surface level, Kanban or flow based kind of governance models on top, right, at a lean agile metrics that enable us to measure improvement, things like that. And so, I think there’s like a reference architecture to organizational design that I believe is true and I think it’s [cross-talking 16:01]

Speaker: Miljan Bajic  16:00

But those are more like patterns, right? Like, they’re taking a bunch of, you know, patterns and just putting them together and viewing these frameworks around.

Mike Cottmeyer  16:09

Yeah. Well, that’s where I was going, right? And so, that’s always where I preface it, this is how I use the word reference architecture, right? It’s like those base patterns, the base structures, the rules of operation, just the things that we just know to be inherently true. It might be like a design pattern, like if you read a design patterns book in code, right, and I’m not a coder because I can’t write a bunch of stuff off. But like, these design patterns are universally true and then they get implemented in an organization. Right? And then all of those patterns get instantiated into an operating model for that organization and this is my challenge with last and Scrum and some of these other things is, I think all of them are built on incredibly sound reference architecture but they’re overly specific in their reference implementation.

Speaker: Miljan Bajic  16:58

Correct. So essentially, instead of dealing with complexity, where like, instead of the reference architecture being fixed, which save has a picture and then all of these. Instead of like, leveraging those patterns and almost evolving that architecture, so that architecture has to be emergent, rather than fixed, right?

Mike Cottmeyer  17:16

Also, so Dean has like, a couple of, you know, for what he’s trying to build, right? The challenge with kind of going down the path that we go down is that it’s really difficult to scale. Right? The fact that I’m in 160 ,170 people is mind boggling to me, that’s really tough, right? But like what, so Dean kind of, at least this is my understanding from the outside of that organization, what they’ve really done is they’ve packaged a reference implementation that basically gives people guidance. It’s a little bit like the rough days, where it’s like, these are practices that are good for most people, most of the time, we fully expect you to tailor them, right?

But the certification is around the implementation details and you know, like most people, even with Scrum, it’s like, you go to a certification class and it isn’t good practices that most people can do most of the time, it’s like, this is safe, right? And we don’t tailor it or we don’t [cross- talking 18:11] safe, right? And so, even if we do tailor them, sometimes we make bad tailoring decisions and it causes the system to break and all kinds of stuff, right? And so because Dean is trying to create certification, right, he’s codified all the stuff, right? And it’s a thing and it has released numbers and all these different things, more power to him, right? I mean, there’s good guidance in there and we work with safe shops all the time. Right? But it’s like, I mean Dean knows, right, I’ve had conversations one on one with Dean is that he knows that there’s an underlying organizational architecture required to support this, last I talked with him, it’s beyond the scope of what he’s trying to certify.

Speaker: Miljan Bajic  18:52

No. I mean, I spoke to him on this podcast too and I asked him about that specifically and he’s like you know, like you said, if you have you know, somebody that doesn’t know what they’re doing, of course, they’re going to you know and he’s seeing those patterns but?

Mike Cottmeyer  19:07

And he’ll come in and consult for you and customized model for you and do all those things. Right? So again, I think it’s high integrity but just like everything, right, in life it’s like, we take the surface level stuff and the biggest problem we see in the transformation space right now is you’re taking a reference implementation, overlaying on top of an organizational design that it wasn’t meant for, it doesn’t work or it doesn’t work as effectively as you would like it to.

Speaker: Miljan Bajic  19:33

And that’s why it fails, in a sense a lot of times, so maybe to tie this together, like you know, we’ve been saying or what I wanted you to kind of expand on is like, okay, organizational architecture is key. You have to have somebody on the business side, usually supported by the board to make a decision that we have to look at the whole organization and how it’s architected. Right? And then when we look at architecture, we have to understand that in order to deal with this type organization, the architecture can’t be fixed, it has to be contextualized for our own organization rather than just relying on a recipe, like treating say for any other framework, like a recipe. And then even though we don’t have half of the ingredients, we’re saying, let’s do the same, right?

Mike Cottmeyer  20:22

Yeah. Well, so sure, right? So, like the process, so like, one of the things that we’ve been unpacking for last couple years is we talk about the difference between like a system of delivery, right, that consists of reference architecture patterns and reference implementation details and then there’s a system of transformation. Okay, how are you going to implement it? There’s a third system we call, system and continuous improvement, which is, how are you going to sustain it and continuously adapt it? And then, you know, this is something that maybe, you know, a company wouldn’t put in but we call it, a system of engagement.

But it’s like, how are we going to start to build mindshare over time to get the organization to converge into these patterns. And so, a lot of the process for us is getting everybody aligned around the reference architecture patterns, picking a slice of the organization that wants to go and do this, con expedition and then we move it to a defined steady state. And for us, a lot of times and this is another thing that I think is hard for people get over, I was literally just talking with some of our developers this morning. And it’s like, sometimes at an early stage transformation in the presence of dependencies when things are not aligned as well as we would like them to, sometimes we have to put in compensating controls and we use the metaphor of like, scaffolding.

You know, I want to build a wall and I don’t want the wall to have a bunch of metal stuff around it. But while I’m building it and it’s hardening, I have to put some scaffolding around it. So, there’s a lot of things that we do in an early stage, depending on the organization that might be heavier and save as much grief as saved gets heavy and heavy. We’ll do things that are heavier than safe because they’re scaffolding. And then as we improve the systems underneath, there are systemic transformation, then you can start to dismantle the scaffolding.

Speaker: Miljan Bajic  22:11

I think I heard you talking, maybe you can expand on it here. Like, most of the organizations today, larger organizations are structured around capabilities. And a lot of times you might have to start with those capabilities and move them into value streams over time, rather than just quickly trying to organize by value streams.

Mike Cottmeyer  22:33

Yeah, so there’s an interesting journey that we’re starting to uncover, especially if we’ve been fortunate to work with some really large clients. And what you find is that, there’s a sequence to events that they like, A has to be true before b can be true before C can be true and so a lot of times you’ll walk in, and people aren’t even organized around business capabilities.

They’re organized around functional silos and there’s project management that stitching processes and resources and things like that, right? So again, all this depends upon the complexity of the organization, the size of the organization, like if you can walk in and you can reorganize around products or feature sets and they’re discrete and you know, that’s awesome, right? I’d rather do that first but a lot of these mega organizations, a lot of times they understand business architecture, they understand what their business capabilities are.

So as a first pass, you kind of think, okay, well, I’m organized around business capabilities because I can create complete cross functional teams are on those and I’m going to orchestrate the project work across, I’m going to deal with dependencies across business capabilities, it kind of becomes like a first pass. And then like on a second pass, now we’ve got a bunch of teams formed around business capabilities but the rub is going to be in and this is legitimate, that those dependencies left unchecked, drive orchestration costs up really high. So, because the orchestration is so high, it actually creates a business case for breaking dependencies and then as you break dependencies, you can regroup business capabilities into value streams.

Speaker: Miljan Bajic  24:15

So, it’s almost like you’re exposing the cost of dependencies and using that as a trigger or nudge to say, hey, you know, this is costing you.

Mike Cottmeyer  24:29

100%, yeah. Because like, you walk into organizations and I mean the numbers, I can remember 20 years ago when I first, maybe a little longer than that, when I first got into project management. You know, it seemed like if you were budgeting something like and again, I’m making this up, it was like maybe six developers, two testers, a project manager, maybe split across a couple teams or something like that. And now, it seems like you walk into places and like for every one developer, there’s two testers and three project managers and a BA and like, all this stuff, right? And it’s like, the complexity has gone up so much we have all these people run around managing complexity. And part of the challenge that we’ve got is, I think that’s just a function of bad org design, right and unnecessary complexity. So like, what starts to happen is that once you get the organizational design, right, you’re able to surface, not only the dependencies but the cost of managing those dependencies. And then what you can do is you can and I’m not saying that you have to lay people off but it’s like, you can redeploy those people into other higher value functions within the organization, rather than being scorekeepers. There’s just too many scorekeepers around in most companies that we deal with.

Speaker: Miljan Bajic  25:41

This is crazy, so like, what you’re saying is like, not almost but I think it’s exactly, like if your organizational structure policies is not aligned, that can cost you. That can almost like, you know, a lot of times, it’s going to force you to fail because that’s a lot of times one of the underlying issues or impediments to having a more you know, product value, whatever you want to call it based on organization.

Mike Cottmeyer  26:15

Yeah, the other fascinating thing and I literally just previous, our as talking, we have kind of an emerging practice within our methodology group. It’s kind of like, the broad arc is methodology and then we have kind of product and business architecture and kind of within product, there’s a specialty that’s starting to emerge around finance and financial management. Because what we see a lot and I know this will resonate with you, it’s like, as you start to build out, even if you’re building out these little expeditions that are like team, program, portfolio, right, that kind of thing. It’s usually a layer, an audit and compliance type layer, governance layer that rides over all of this, that is still looking at three to five year plans and 18 months cycles and annual funding and all these different things. And you know, I think that is indeed an artifact of an organization that struggles to make any commitments, right?

So, they’re planning and scorekeeping and doing all these things, even at the highest levels of the organization and what’s been pretty cool. And these are some big names that we’re working with is that once you get the organization performance and it can make any commitments and it can deliver in small batches, then the next trick is to go up a layer and say, okay, how can we exploit this new organizational capability. So that we can make better bets and market, get faster feedback and be able to learn from what it is we’re doing because what my team is doing is, they were pitching a white paper they wanted to do with us. And you know, one of the things that we’re talking about was the idea that we’ve installed agile but we haven’t really and maybe we’ve even reduced costs and increase efficiency but we haven’t really maximized the product value or gotten to where we can actually put things in market and start selling them earlier. And again, that’s an artifact of the way we’re governing and doing audit and compliance and such is not congruent with the improved way that we’re doing software delivery or product delivery, you know right?

So, what are the steps necessary to be able to bring those top level functions into alignment with this new deployment capability. And the way that you’re going to maximize value at an enterprise level is to take your multi year annual planning cycles and to break them into some sort of quarterly cadence with quarterly funding, right? Where you can fund a quarter or maybe two, right, I’m not being super dogmatic, it’s probably not continuous at that level but I can fund a quarter release and maybe by the end of the second quarter, realize that maybe I’m not quite on track. And maybe I have the opportunity to go correct something in quarter two or pivot into quarter three and I actually become more adaptive and agile at the senior most levels within the organization. And I think that’s where the and again, in a mega organization with value streams that are global, I mean sometimes that’s where you got to start attacking.

Speaker: Miljan Bajic  29:15

That’s really interesting, I’m also interested to hear your thoughts, how do you move from funding capabilities or cost centers to funding value streams? Like, that also needs to happen at the highest level and that needs that shift, what have you seen and like, that’s working, that’s not working in that shift?

Mike Cottmeyer  29:38

Well, like I said, right? I mean, I’m dealing in a world where I have people that this is their specialty. Right? And so, that might be a topic for another podcast to put vows of it. Right? But this is literally what Larry and I were just talking about, right? They’re hitting me with all this detail, right and I’m like, well really like if you think about it what we’re really doing is we’re trying to get them to break big projects into small projects and run the small projects on tighter cadence. Like, yeah that’s exactly it, I’m like, okay well, then sometimes we just need to say that, you know because that’s all it is. Right? So, how do you get them too, right I mean, it all comes down to understanding what their constraints are and what they’re trying to accomplish. And to be able to build a system that gives them what they need, is agile is sometimes and this is a reason why we came up with this little quadrant model and our base camps and expeditions and things like that, is agile is a lot of times what we want is, we want everything to be adaptive and emergent. And you know, it’s just like, just going to park it really fast.

Yeah but if I’m building nuclear submarines or I’m building cars or I’m building missiles or I’m building large scale financial services, infrastructure, things like that, right and these are differently building websites or consumer products and things. And there’s lots of things that have to come together in order for that to be able to happen. And so like, one of the things that I talk about and I’ve done this for a minute, like the earliest revs of our website, say this right up at the top, it’s like most the time, like people aren’t using or they don’t aspire to use agile for like, hyper adaptability and exploration. What they’re really using Agile for is because they believe it will help them become more predictable and that’s why that tends to be the first step on the journey is because when you organize complete cross functional teams and you get them to establish stable velocity against a known backlog. And they get to a really clean definition of done at the end of every sprint, that is a much more reliable indicator of project progress than you know, Gantt charts and progress reports and all that kind of stuff, right? And so, we can do is we can use Agile concepts to actually get to a place where we can make any commitments more effectively than our traditionally managed counterparts.

Okay? And so now we have dedicated stable performance teams that we can count on, that are aligned to business capabilities or value streams or products, I can start to think about how to fund those things in a more stable way. Right? And now this need for predictability in control isn’t done by top down edict and rules and tight governance and things, it’s more like, fun, stable funding and periodic measurement of progress. And I believe, in order to have that conversation at the most senior levels, the necessary precondition is to be able to actually be a performance organization.

Speaker: Miljan Bajic  32:59

I mean, that reminds me of what you also described, like the almost the trust influence loop, it’s like, let’s deliver a first on let’s meet the organization where they are and meet that, you know and it’s almost like in order to help them evolve, you’re building that trust and you’re delivering them what they want and slowly.

Mike Cottmeyer  33:20

The very first, the very earliest thinking this of this is like everybody, you know, this is like 15, 20 years ago, right? So like, everything I would hear would be like, you have to trust a team. Well, the ecosystems that they’re working in, their practices, their org design like, nothing lends itself to trustworthiness, right? And so, it’s like, what I would tell people is like, you’re asking these leaders to trust these teams but these teams have no track record of ever living anything on time. Right? And I was talking with one prospect one time and they’re like, well the executives need to stop asking us for dates, they need to stop giving a scope, they need to stop giving as much as you need to just give us a big pile of money and just let us do it whatever we want.

They didn’t say quite like that but that was certainly what they’re saying, right? And I’m like, okay like, seriously, if you were building a house or doing whatever, would you just give the contractor half a million dollars and just say, just go for, just do the best as you can? You’re the guy that’s close to the ground, you know what kind of house I need, like no, right, you want to know what you’re going to get for your money. And there’s some reasonableness, right, there has to be some ability to deal with variation and respond to change and exchange requests and things like that but you want some idea what you’re going to get for your money. Business owners are no different than matter, executives are no different than that, they want some reasonable controls to know they’re going to get pretty close. And so, if you’re going to go up to the most senior executives with some form of, you need to trust the teams, my belief is that you got to get the team’s trustworthy first.

You have to create the organizational design, you have to create the process, you have to create the metrics, you have to get instantiate, you have to be able to put stable inputs in and get stable inputs out. And this is all scrum basics from, I’m not saying I don’t think anything unethical, I mean, [unsure 35:01] was writing about this stuff in his earliest works about basically how to deal with variation and process control. I mean, that was like early stage stuff, I mean, David Anderson’s been writing about this and Kanban and has Agile Management books.

Speaker: Miljan Bajic  35:16

I mean, that’s the whole lean, like in a sense, if you can manage the variance, you want to minimize the variance but sometimes, you know, right, it’s not as easy as you know, mass production plants and then things like that.

Mike Cottmeyer  35:29

So, what the trust influence loop came in and so what we’re talking as that little, like that little figure eight thing on the side and it’s been a while since I’ve talked about it but like one of the things that we were talking about earlier is consultants. And I would say this is 100% true of internal change agents as well, is that there’s an influence loop, which basically goes something from like, you have access to somebody, you have to have empathy for their problem they’re trying to solve, you have to have a point of view that actually they believe will solve their problem and then you create safety for them. A lot of times, what we do is agile is, we come in and we say we know your problem, this is what you need to do to fix that. And then they go well, not quite my problem and even if it is my problem, it’s not the problem that has my pants on fire, right?

So it’s like, I’m not dealing with that right now and so this whole influence game is a game of access, empathy, point of view and safety. Right? So, you loop through that and then on the backside, the trust side is you get permission to do something, you have to do with integrity, you have to do with competence and you have to share results. Right? And so, there’s this virtuous cycle and so this is reason why part of what’s up underneath like this base camp model and the reason why we do incremental.

Speaker: Miljan Bajic  36:42

That’s what I wanted to hear, maybe you can talk about that next, which like, how does the base camp get the expeditions and how is it supported by that, trust influence problem?

Mike Cottmeyer  36:52

So, you think about it, especially from like a marketing perspective, a sales perspective, an early stage engagement perspective to piloting and to roll out and to growing like a large account. And again, right, all this stuff, I’m a consultant, that’s the world I live in but even from a practitioner perspective, you’re doing the same things, right? There’s marketing, you’re selling, you’re getting started, you’re scaling, right, all these things. And there’s an influence game that has to be played, right, you have to tell a story that convinces somebody that this is worth doing and then once you do it, you have to get the results you promised. Right?

So if I say, hey, you’re going to get all this greatness from doing Agile and I train everybody on Scrum, I train everybody on safe and it ends up being a chaotic mess for three years. And you don’t get the results, like why would anybody continue to invest in that, right? It’s just a [unsure 37:38] system at that point, right? And so, what we recognized very early on was two things and again, this is through the lens of a consultant, running a consultancy, is if we didn’t demonstrate tangible value really quickly, we didn’t get to stay for very long, right because, no, seriously, right?

Speaker: Miljan Bajic  37:57

No, I’m laughing because I’ve been in many of those situations and I know you’re sure most coaches and consultants have.

Mike Cottmeyer  38:04

Yeah, and it’s like, you go in, everything’s great. It’s like, it takes a minute, it was six months and you’re like, yeah okay, I can’t get the next tranche of funding. It’s great, man, I appreciate you, see you later, right kind of a thing? Or maybe you have some success but it’s just not mind blowing. Right? And so, the evolution of these expeditions, the base camps and so just to put into software language, like an expedition is like a slice. So, I think of an expedition is like an increment of the organization and then base camp is like an iteration. If you guys go back to like, you think about like Jeff Patton’s, Mona Lisa metaphor, which I think is just brilliant, right?

So for Dewey, he’s using it to describe incremental and iterative and he uses increments is like, okay, I’m going to take the Mona Lisa canvas, I’m going to split into six, I’m going to work on the upper left corner of it, right, that’s an increment. An iteration is like, taking it from like a sketch to a watercolor to an oil painting, kind of a thing. We’re making it more rich as we go and so like, we think of transformation incrementally and iteratively, as well. So, but we can promise typically and like a three to four month early stage engagement is we can take a slice of this organization, team level to portfolio, structure, governance and metrics, all the practices, culture, all that stuff and get it to a predictable state. And that’s what we promise and we can do that repeatedly in three or four months and then they go, wow, this is actually really working. And they go, okay, let’s do the next chunk and then the next chunk.

Speaker: Miljan Bajic  39:38

What do you do in a sense like, when you’re taking those vertical slices, there’s almost like prerequisite to what they need to have in order to create that vertical slice, right? So, there’s some type of expectations that you set you know, if we’re going to do this, this is what we need from our organization to create that vertical slice.

Mike Cottmeyer  39:54

Yeah, so remember, I talked about system of delivery, system of transformation, system of engagement? So, from a system of delivery perspective, you’re building on patterns, reference architecture, filling in reference implementation details, things like that, right? So, we have a hypothesis of what this is going to look like at base camp one. And then we might have some idea of the first couple of slices and then the system of transformation is all about how you run the expedition to base camp journey. Right? So, we have outcomes, based plans and a bunch of guidance that we’ve evolved over time, right? So we’re going to move this slice into this known state but on the system of engagement stuff, which I think gets to your question is, the way we do that is we’ll get like all the leaders in a room and we’ll walk through, here’s the reference architecture, here’s the things that you’re going to have to do, here’s the things you’re going to have to overcome, here’s going to be the nature of your dependencies, here’s going to be your challenges. Now, are we 100% right, I think we got 80 or 90% of them.

The details of people in particular architecture issues are all going to be all over the place. I mean, there’s a lot of uncertainty but the patterns, the failure patterns are fairly known. So, we walk them through, we say this is your failure patterns, this is what’s going to happen, these are things we need to fix, this is how we’re going to do it. So, we start off with a workshop that brings everybody into a cognitive box and then we expand that box into a bigger piece of the organization, then you can go for breadth or depth or whatever and lots of different strategies. We do something called the find the end state, it’s usually about two months and we’ve got that scripted out too, we look at business architecture, technology architecture, org design, product architecture and literally create a team formation hypothesis. We put names in boxes, we help them figure out what tooling and instrumentation they’re going to use, we help them figure out what they’re going to measure, what they want to control, what success looks like, all those things, that takes a minute. And then what happens, then we create a plan for a pilot and then we’ll do a pilot and then the pilot is going to work back to all of those core things we’ve been talking about all along. And they’re going to see, okay, this pilot is going to go to Basecamp one and this is going to be the characteristics the organization, they’re going to build or make any commitments, they’re going to be able to deliver on quarterly boundaries, we’re going to be able to do it in a reliable, predictable way.

We’re going to have dependencies managed, we’re going to have economics trade-offs dealt with, we’re going to get value, right? The risk in this early stage, right, is that you build the engine and you get really good at building the wrong product. I mean, that can happen, right? So, now you’re in the stance of like, okay well, if we focus on building a product but we don’t have a delivery engine, is that better than building a delivery engine and not knowing what the right product is? Right? So, as we’ve kind of advanced, there’s a little bit of a dance right and in early stage, we might literally help them get better at building the wrong product but now they have the ability to start to deliver on regular paths. Right?

Speaker: Miljan Bajic  42:53

The right product.

Mike Cottmeyer  42:55

And then as they start realizing, okay, I’m getting data now and I start to realize that we’re building that then, that’s when we might start introducing more product management practices. Or if we know we have dependencies, that we need to do like product extraction, technical decoupling, things like that, we might start laying, bringing in some more like XP software, craftsmanship coaches and start laying the foundations and building the capability internally so they know how to do red, green refactor, things like that. And so, we just layer these capabilities as we move them from predictability to smaller batches to fully encapsulated teams and so that’s how it works. Right?

Speaker: Miljan Bajic  43:32

So, maybe, just to pause on that because I think you know, we can take it lightly, like that’s how it works, that’s been my experience in a sense of how it works. But that takes a lot of effort on organization committing, the other big part that I would like to know from your perspective is, how do you make it sustainable? So, you bring coaches, consultants to help organizations realize this and then eventually, what you want them is, you want to work yourself out of the job, so they can do this long term. What are some of the things that you do and some of the challenges that you face because they think long term in our organizations to be able to deal with same type of issues that they dealt when they brought you in?

Mike Cottmeyer  44:17

Yeah. So, the metaphor that I use and they’re all systems metaphors, right? Is it leading Agile is like transformation in the cloud, right? And so, in an early stage transformation, you might subscribe to our services and we come in and we help you do all these things. But an any non trivial sized company, there’s two dimensions you have to deal with it, at some point they want to take that in the cloud service, they might want to make it like an on premise service, kind of thing. They might want to have their own instance of it. Okay? And so, typically on the lots of words but typically the word we use most commonly it’s like a setup like an Agile transformation office. And the Agile transformation office needs to have all the core services that Leading Agile has, right?

So, we’ll help them identify a playbook, will get a coaching and development services, like a talent service, a way to manage the transformation and Expedition readiness service, right? All these different services that we’ve got that are in Leading Agile, will help our client build them and then we’ll teach them how to run it. And then, you know, obviously, we’d like to maintain a presence to help sustain it and nurture it and things like that. But what we found and I know you know this, there are not enough Agile coaches or technology coaches in this world to help the companies that need to be helped, right? And so, I don’t believe, I don’t think there’s any scarcity in this and so like, one of our largest, longest standing clients we’ve invented a lot of this stuff with them, which has been a very cool relationship is we built an Agile transformation office with them. It’s their transformation office, they run it and at one point in time, I want to say, I had 45 consultants on the ground with them doing senior level transformation, leadership, Expedition leadership, we would call integration coaching, some specialists around product and finance and all those different things.

But at one stage, they had 250 coaches, they were on the ground doing team level stuff that were sourced all over the place. They were sourced from other consultancies, internal people and then over time, they started inserting their people in expedition leads and transformation and things like that. Right? As they started getting more confident in their ability to do it and then now it just kind of ebbs and flows, like if we’re going into like a gigantic company, right? So, you did the first 13,000 people and there’s hundreds of 1000s of people will have to go, right? And so, we’ll go into incubate another slice of the organization and we may be at this for 10 years or so. Because they want to go but what we’re leaving is we’re leaving behind the capability for them to sustain it themselves because we’ve instantiated the playbooks.

Speaker: Miljan Bajic  47:17

But also, you’re kind of you know, essentiated the playbooks, you’re developing the skill so they can develop and maintain and evolve those playbooks. Right? And what’s interesting is that I think, you know, based on what you’re describing and that’s why like, you know, I wanted to talk to you is like, that’s what it takes for organization to transform. And if we look at the last 10 years and we look at you know, Agile transformations, like 99% of them failed.

So, and that’s a huge number, it’s not like, you know, at least most of the organizations that I’ve been part of and the ones that have been part of, that have been successful is essentially what you’re describing. So, I’m curious to hear your thoughts you know, in a sense, like if that’s what it takes for organization to succeed and most organizations are not doing this. What are your thoughts? Like I mean, what do we need to do as a community, what do we need to do as coaches because it’s a big ask to do what you just described in here for organizations to be able to transform?

Mike Cottmeyer  48:23

So here’s the thing that I think is, there’s a couple of factors, right? So, there’s like a belief factor and then there’s like a pragmatic reality factor. And so like the belief factor and this is the one thing I’ve been, I’m a little too extreme on this and I’m going to acknowledge this. But it’s like so many people in the Agile world, they lead with culture and they say, well, it’s a culture change and we need to change mindset, we need to change attitude and we need to change the way people behave and stuff like that and that’s true, right? But the reality is that, people are operating in broken systems.

Okay? And unless we get the systems that they operate in right and bring the process into congruence with the operating system or the structure this, yeah, right? It’s really difficult to ask people to change their minds, the way that I articulate is like, I have two salespeople and they’re both in the same region. And I want them to cooperate but I have them incented for, you get paid based on what you kill, I get paid based upon what I kill but they want us to cooperate. I can’t ask what to cooperate if our financial incentives are to compete. Okay? And so, we have to create the ecosystem, we have to change your org design, I have to change the process to encourage the collaboration that we want. So, I think leading with culture, it’s just the way I term to say but leading with culture I don’t think is a winning strategy.

Speaker: Miljan Bajic  50:01

I mean, it’s almost like, what less guys and what it’s like, you know, change the system, right? And changing the system will force you to change you know, the culture as a result of that you know, the practices would change. But here’s the trick, right, which I think is the biggest of them all. In order to do this, you have to have a leader with the mindset that is willing to change the system and if you don’t have that?

Mike Cottmeyer  50:30

That’s the chicken and the egg problem, right? But I don’t need to get to change their entire leadership style. So, like a little bit of the way that you flip that influence, as you say, look, I get you have to make any commitments, you have to be financially responsible, you have to be a good steward of the resources, you have fiduciary responsibility, your stakeholders, all these things. I’m going to build you a system that’s radically different than what you’re doing today, that is going to achieve better results.

Are you willing to take a bat? Right? The other side of it is like, because and I’ve been in this world where there was a consultancy, where I kind of partnered with 10, 11 years ago. And this lady goes in and she’s like, telling all the leaders well, you need to change all of your behaviors, you need to be more empowering, you need to do this and they were just like, out, right? So it’s like, you got to like, it’s like the influence trusting you, you got to tell them the story they need to hear and then evolve their thing.

Speaker: Miljan Bajic  51:26

Exactly and I think that’s what’s so powerful what I liked, when I first heard about base camps and expeditions. It’s like, if somebody was asking me and saying like, Milan, you have to do this, I’ll be like, go f*** yourself. Right?

Mike Cottmeyer  51:41

I didn’t know you could say that word on your podcast like I’ll be all down?

Speaker: Miljan Bajic  51:44

You can but you know, because in a sense like, you know that’s not, but if they’re actually walking me through and I say, this is what I want to do and they show me and help me and they say, okay, what do you, like it’s easier for leaders to do that. If they’re going through that type of and I think that idea of expeditions and base camps is?

Mike Cottmeyer  52:03

Yeah, I had a colleague in the industry and an Agile conference a couple years ago. Yeah, there’s a little bit of liquor involved, though, I’ll acknowledge that but we’re having this very intense conversations. She’s like we need to empower and trust your people and just let them decide and I’m like but it’s my money that pays their salary. If they jack up the account, I’m still paying their salary, regardless of whether they’re damaging your reputation and my economics and my family’s livelihood and all these things. And so like, a lot of it is like balancing between what’s sufficient control to make sure that we don’t lose the wheels on this thing versus empowering people to make local decisions. But you know, getting back to the question that you had asked me about like, what’s getting in the way? I lied with, we’re spending too much time on culture, right?

There’s still a big problem 20 years later, I think the other thing is, you said, what do we need to do with the community? I think pragmatically, this is the challenge, is that most people if they’re independent, are in a small company, they’re trying to make a living and they’re doing the best they can within the agency that you’ve been granted. So, a lot of times, they don’t have the span of control. Sometimes they don’t know how to go tell those executive stories. I mean, I have my team, could not sit in a conference room of the C level suite and tell those big stories, right?

Speaker: Miljan Bajic  53:17

Which goes back to that access, you can’t influence if you can’t.

Mike Cottmeyer  53:21

Yeah, well, you don’t get access, if you can’t influence, right. Yeah, for sure. Right? So, they tell a good story to a director or VP and maybe they make some good local changes but they don’t get the broad base changes that they need. I mean, it’s taken us 11 years to even get to the place where, I think I’ve had a pretty strong story and market but it’s taken me 11 years and I mean, there are more people that used to work for Leading Agile in this world and currently work for Leading Agile in this world. Our hypotheses on like, what are the right kinds of consultants and what do they need to know and what kind of work designed I put them in?

And what personality attributes do they need to have? I mean, like, we’ve changed everything, we reinvent this company every 9 to 18 months and it’s constantly evolving to solve this problem. And we were fortunate that we had enough early success and I was able to accumulate enough working capital that we can take chances and risks and build marketing teams, all these things go on, tell these stories. But what the thing that I actually can’t comprehend right now is why like the bigger consultancies don’t deeply understand the story because we, you know, obviously, almost anytime we go into an organization, there is a gigantic world class strategy firm in there or something like that. And what I find is that the strategy firms are making the same mistakes as small firms, a lot of times.

And so, that’s the thing, it’s a little mind numbing to me because they have business architecture practice, they have product construction practices, they have the ability to do this stuff. So then I have to believe that it comes down to their beliefs about what to do and what’s in their economic advantage. So, I think that there’s some belief stuff, I think there’s some structural stuff that’s getting in the way but I feel very fortunate the way we built this company is that we generally get to do work on our terms and get in. And so like, what happens is we market and tell stories and you’ve clearly read a lot of our content and the companies that resonates with, they call us, right, our phones ring. I’m on three to five sales calls a week, I’m not going to close everything, of course, [cross- talking 55:26].

Speaker: Miljan Bajic  55:25

But like you said, there’s still more, there’s like you know, in a sense, there’s way too much work and there’s way too many companies that need the help. It’s just that like, that’s what kind of puzzles me too in a sense, where are we going to be like, in the sense that, you know, there’s been this whole buzz around Agile and it’s really failed, in a sense to really help organizations the way that the organizations need help.

Mike Cottmeyer  55:52

The reason I think we’re still in the game and I think there’s still a conversation around it is because I think organizations recognize that it’s principally sound. And they believe that if they can crack the code, that will make them more successful and they’re right. But as a whole, we don’t have good operating models for how to get there.

Speaker: Miljan Bajic  56:18

Well, unified voice.

Mike Cottmeyer  56:21

Or unified voice, well I’ll even say, you know and maybe this is you know, maybe somebody will get some nasty phone calls or emails as a result of saying this is, I actually think the Agile conferences are trending in the opposite direction. As I look at like, I’m probably not going to submit to Agile 2022 this year because I look at the tracks and you know, I mean these are important topics but it’s like a lot about it is diversity, equity inclusion, it’s about all these different things and again, all important stuff, right? And I’m not diminishing that in the slightest but I feel like the voice of okay, transformation and business architecture and doing this in a structure, I don’t think that’s what people want to hear. Right?

And I think to some degree, they want to deal with the easier issues and this is tough, right? Because as an individual practitioner, it’s tough to take what I say and go do it because you almost have to, I mean, I hate to say it’s self-serving but it’s like, you almost have to hire us to do it. Or you have to be like, really deeply entrenched in it and like, really understand it and you might have a shot but like I said, I’ve got a lot of [cross-talking 57:24].

Speaker: Miljan Bajic  57:24

Well, that’s almost like, I use an analogy with the cooks and recipes and chefs, right? Like, it constantly has changing ingredients, so you can bring me in, if I’m a chef, you can bring me in to help you come up with the recipe. But what happens if you don’t have the ingredients, the same ingredients and I’m not there and you’re a cook that doesn’t know what they’re doing, you’re going to mess it up. So like, in a sense like, what we need is like, how do we develop more chefs in organizations and you know, that they can actually deal with whatever is given to them. Architect based on context, not just, hey, here’s a safe and we went through a four day training on safe or whatever, right?

Mike Cottmeyer  58:05

So, here’s like, the interesting hard part, right? I have thought of the idea of like building a certification or building a program or something like that. But you think about it, you know, Jim kind of works with me and Jim was in the Scrum Alliance and really helped that organization make a lot of inroads into PMI and really took it from kind of a niche to and really kind of blew it up. And I think he would tell you directly, it’s like, people want to pay $1,200 or $800 now maybe and get a two day certification and they want for the resume, right and that’s a market and they want employment. And so, and I watched what the Scrum Alliance does with the advanced Scrum and things and it gets traction to a point but it’s like, the money is isn’t selling these [cross-talking 58:54]

Speaker: Miljan Bajic  58:56

Like, I said the money is selling recipes and training people on recipes not creating chefs.

Mike Cottmeyer  59:02

Yeah, I used to get onto the marketing team at Version One because they want to say, they weren’t saying marketing agile made it easy on them. No, this isn’t easy, it’s hard. Right? And then so, I think they said Agile made it easier or something. And I get it, right, because it’s like, you need to sell an easy but it’s not easy. You know? So I’m like it’s team’s backlogs, working, tested software, if you can figure that out, it’s super easy. But getting the team’s backlogs, working software is taking us 11 years to figure out of that. So yeah, and we’re still figuring it out. Right?

I mean, I’ll be the first to say it’s like, I mean, I was telling the guys today we’re going to do a podcast and we’re going to just talk about stuff that’s just super exploratory. Because it’s like, we don’t have every answer, I think we’ve got the base patterns, right? And I think we have the principles right but the practices and the how tos are constantly emerging as we learn more stuff. You were talking to clients about using Agile to build the next rev of nuclear submarines and and you know, battleship and things like that and defense. Like, I mean, this is like cutting edge stuff that people want to use this for so that the industry still has poll, right? I mean, people want this, we just need more mature practitioners that understand how to apply these concepts in a less dogmatic way. So?

Speaker: Miljan Bajic  1:00:16

Exactly. And I think that’s going to be the trick, I know it’s been an hour and I feel like we could continue talking but I do have to go, [cross-talking 1:00:24]

Mike Cottmeyer  1:00:24

Yeah, we should do this again sometime.

Speaker: Miljan Bajic  1:00:26

Yeah, definitely. What would you like to end with, like a message or invite or?

Mike Cottmeyer  1:00:30

No, I think where we left it is pretty cool, right? I mean, if anybody’s [inaudible 1:00:34], I mean obviously hit our website leadingagile.com, connect with me on LinkedIn. We’re super happy to answer questions and talk about this stuff. I mean, it’s kind of what I do for five hours a day is just talk to people, right? Whether it be my teams or clients or whatever and super passionate about this and if you’re in the market, you’re looking for a job, we’d love to have you reach out on our careers page. It seems like I got 20 or 25 open positions all the time and so for the right people, it’s a great place to be and we’re doing some really cool stuff. And I do believe we’re on the cutting edge of a lot of this stuff so hit our website and just check us out and if it looks like a fit either work together or to work here. love to hear from you.

Spike solutions are one of the ways extreme programming teams “figure out answers to tough technical or design problems“. Their use has evolved over the years and as they’ve been adopted by Scrum Teams. There are also many teams out there who may be using spikes in a way that creates more work without solving problems.

In this episode of SoundNotes, Stephen Cavaliere joins Dave to talk all about Spikes. In order to make things as simple as possible the podcast has been broken up into three parts:

• Part 1: What is a Spike? How does it work? (Begins at 02:42)
• Part 2: How do you estimate Spikes? (Begins at 11:55)
• Part 3: How does a team evolve their use of Spikes as they mature, or move through Basecamps (Begins at 23:32)

LeadingAgile Blog Posts About Spikes

• Getting the Outcomes You Want From Technical Spikes: https://www.leadingagile.com/2021/04/the-right-way-to-technical-spike/
• Managing Risk and Uncertainty in Agile: https://www.leadingagile.com/2014/02/managing-risk-uncertainty-agile-2/
• That’s Not Agile: https://www.leadingagile.com/2012/07/agile/

Contacting Steve

• LeadingAgile: https://www.leadingagile.com/guides/stephen-cavaliere/
• LinkedIn: https://www.linkedin.com/in/stephencavaliere/
• Twitter: https://twitter.com/SteveCavaliere
• Email: Stephen.Cavaliere@leadingagile.com

Contacting Dave Prior

• LeadingAgile: https://www.leadingagile.com/guides/dave-prior/
• LinkedIn: https://www.linkedin.com/in/mrsungo
• Twitter: https://twitter.com/mrsungo
• Email: dave.prior@leadingagile.com

If you have a question you’d like to submit for an upcoming podcast, please send them to dave.prior@leadingagile.com

And if you’re interested in taking one of our upcoming Certified ScrumMaster or Certified Scrum Product Owner classes, you can find all the details at https://www.leadingagile.com/our-gear/training/

 

Achieving lasting change to an organization through an Agile Transformation or increasing Business Agility is not for the faint of heart. There are tomes written about the best way forward. Stages, steps, processes–and in many cases—the “solution” is to plan more, track more, and deliver on time.

In contrast, Business Agility is intended to be flexible. A goal of Agile Transformations is, in part, to gain the ability to adapt to what can be empirically shown to be true. While it is tempting to put a straitjacket on an organization and make sure that what is delivered is what was promised, the reality is that we may not actually want what we originally requested. The best solution may emerge as the problem and solutions are explored.

Most organizations need to answer: how might we reach a business or product outcome when we may not understand what the outcome will look like? The answer lies in deciding where to constrain versus encourage action and, in fact, mandate creativity, complex thinking, and integrated solutions. No one can mandate creativity. However, we can set the stage for creativity to emerge.

MOVING FROM PROJECTS TO PRODUCTS

We are working with a large IT organization that has been working diligently to create a predictable software delivery pipeline for the last few years. To manage the pace of change effectively, we have to work through each part of it a few teams at a time. Until recently, financing for the organization came through business cases and project-based funding. The development groups relied on project-style requirements to tell them what to do next. The result was a software development organization that was Agile – but Business Agility was sorely lacking.

In response, the IT organization embarked on a move from Projects to Products. This shift could have led the organization to a free-for-all where teams worked on what they thought was most valuable. The trick was to create responsible empowerment across all groups. If groups weren’t aligning to projects, what were they aligning to? And ultimately, whether we have a product or project focus, the goal is to deliver on strategic initiatives or bring to fruition strategic intent.

INTRODUCING OKR: OBJECTIVE & KEY RESULT

One popular method of aligning work to strategic intent is the OKR or Objective and Key Result.

In this last iteration of organizational change, the move was towards delivering more valuable work. The valuable work was defined as 1) strategically aligned and 2) delivering value to users and customers. LeadingAgile chose the humble yet powerful OKR (Objective and Key Result) format as the way to have a conversation between those working on software and the other levels of the organization tracking value.

PARTS OF THE OKR

OKRs have two main components:

Objective: What aspirational state do you want to reach?

Key Results: What is the measurable change in behavior or outcomes that the organization makes progress towards the objective? Behavior changes are not the act of ‘doing’ something. They reflect the change in behavior of the groups receiving the work.

Other components can be added depending on the situation:

Initiatives: A set of actions to achieve key results

Outcomes: Lagging indicators that tell you the score once an objective is complete.

FIVE PRINCIPLES OF OKR

It’s the underlying principles of OKRs that make them great vehicles for communicating intent from the folks creating them. Here is a breakdown of why OKRs have become so popular – and are a significant component to add to your work expanding Business Agility.

1. OKRs are created by the people who will do that work.

   • The people who do the work generate the OKRs. Yes, they undergo a review and discussion process, but they allow the person or group writing the OKR to determine the best way forward. When people choose their way forward, they are more motivated to complete the job well.

2. Management can see the objectives that each part of the organization believes are most valuable to work on and prioritize.

   • OKRs bring excellent transparency to what each part of the organization is working on. Management can review that the components create a complete picture of all the aspects that groups are working with. And if necessary, they can locate specific areas where objectives are not aligned.

3. Objectives are not hierarchical.

   • Most organizations rely on cross-functional cooperation. OKRs can mirror that reality. One part of an organization can create objectives and key results linked to OKRs from anywhere within the organization. As long as it’s agreed that the objective is valid and valuable, where the work comes from is irrelevant.

4. Objectives are written in the problem space.

   • The objective says: we will solve this problem. It leaves the detailed execution to emerge as solutions develop and evolve. This flexibility of solutions generates the Business Agility of the OKR driven organization.

5. Key results are created with leading indicator metrics built into them.

   • Keeping track of progress as work proceeds is another important reason OKRs are valuable. At each moment, the team can review how much progress has been made towards a key result and adjust effort and focus.

OKRS IN PRACTICE

Here’s an example of how objectives and key results can start and evolve in practice:

If my objective is to increase sales effectiveness, then one key result could start with attending training. In this example, attending training is considered an output. It states what I did but doesn’t tell me anything about the outcome. A way to align with the intent of the key result is to ask what results I want from attending training. Possible results could be using five new training techniques or having a 10% higher close rate on sales calls measured monthly.

Through questioning motives and targeting outcomes, the key results focus on any important work or effort.

In the final key results, you are able to track progress. The key results create actionable intent towards an objective that everyone agrees is in the organization’s interest. It also engages people in different chunks of work that are growth-oriented. It’s a win/win situation.

As you move through your Agile Transformation towards Business Agility, consider adopting OKRs as a tool to increase value and track progress over time.