Leading large-scale Agile Transformation is extremely complex. That’s why Agile Transformation fails so frequently. Because to succeed at it, you need a fundamentally unique approach that most organization’s aren’t following.

In this video, Mike Cottmeyer uncovers some of the biggest reasons organizations aren’t getting the value out of Agile they thought they would. He also explores some of the ways you can overcome those challenges to unlock Agile’s potential in your organization. Plus, we take a look at some of the critical success factors in Agile Transformation and explore the metrics you should consider in your next Agile initiative.

Relevant Resources

Read More from Mike Cottmeyer

The Mike Cottmeyer Collection

Mike’s Agile Transformation Talk

Agile Transformation

Follow Us on Social

LeadingAgile

https://www.linkedin.com/company/leadingagile

leadingagile

https://www.instagram.com/leadingagile

If you want to be successful at Agile Transformation—especially at scale—you’ll need more than Agile Coaches teaching your teams the ceremonies of Scrum or how to do SAFe and LeSS. Why? Because the #1 reason Agile Transformations fail in large organizations is that they aren’t set up with the right underlying ecosystem for Agile to work within in the first place. 

To achieve the outcomes necessary to run a structured and disciplined Agile Transformation that doesn’t fail, it’s not about focusing the work on the teams themselves. The focus needs to be on creating the necessary structure before the work of the teams can ever get you where you want to be. 

To be successful, your company will need an array of people to take on various Agile roles and responsibilities. This team of Agile Transformation Coaches consists of people focused on executive-level understanding and Agile leadership, people that teach team-level technical practices, and everything in between. 

In this blog, we’ll explore the various roles and responsibilities of the Agile Transformation Coaches we deploy on our engagements. 

Agile Lead Roles and Responsibilities

There are two roles at the top of the Agile Coaching stack—the Transformation Lead (TL) and the Expedition Lead (EL). The TL and EL typically work closely with executives and delivery leadership to create, execute, and drive the Transformation strategy within the organization.

Agile Coach’s Responsibility

The Transformation Lead (TL) partners with the executive team to lead them through the Transformation process. The Transformation Lead is a high-influence peer to the executive, and as such will challenge their partner in order to produce clarity around the Transformation strategy.

The Transformation Lead’s ultimate responsibility is to the high-level execution of the Transformation strategy and the communication of the required steps to reach the desired end state.

Leadership’s Role in Agile Transformation

The Expedition Lead (EL) works to execute the Transformation strategy within the enterprise. They work in conjunction with delivery leadership to educate and propagate information concerning the high-level Transformation strategy as communicated by the Transformation Lead.

The Expedition Lead’s ultimate responsibility is to own the outcomes-based plan for each increment of the Transformation, and the strategy alignment to delivery needs.

Agile Transformation Coaches

Program/Portfolio Coach

The Program/Portfolio Coach is a critical component for groups of large, scaled product teams. This coach is a member of the portfolio or program team who focuses on the overarching framework for the organization in question. They must be able to understand how the different pieces of team architecture, functionality, and development fits into the global structure. 

This role isn’t just teaching people new practices. Instead, the PPC is expected to influence and change the system around the people to enable the organization to create the optimal conditions that will maximize the business benefits of Agile Transformation.

Agile Process Coach

The Agile Process Coach educates the teams in this increment of the Transformation on Agile principles, providing them with tools and coaching for implementing the process in their own work. This coach conducts workshops and training sessions that teach Agile practices and ceremonies that lead toward the organization-wide adoption of Agile methodologies.

Technical Coach

A Technical Coach is a seasoned software developer with a breadth of experience in multiple languages, software delivery disciplines and full systems Agile coaching. 

The Technical Coach collaborates with the TL and EL to understand the roadmap for incremental change through each part of the Transformation process along with their desired outcomes. They will develop coaching plans to get teams to their target outcomes.

Analyst

The Analyst supports the team, providing tactical support for the overall Agile Transformation. They are involved in collecting the metrics used to outline the Transformation from a data-driven perspective. 

Scaled Agile Roles

All these coaches’ roles together are about more than teaching people methodology, more than just DevOps, and certainly more than just executive mandates. 

If you have nothing but Agile Process coaches, your Transformation will fail.

If you have nothing but Technical Coaches, your Transformation will fail.

If all you have is a Transformation Lead or an Expedition Lead, your Transformation will fail.

Because Transformation should be transformative, and to be Transformed is to Transform the business from top to bottom, in all the ways that people do work across the organization.

To do this, you need a team of coaches with varied skill sets and expertise. 

This week in SoundNotes, Chris Barton joins me to talk through a problem that shows up one way or another in every single CSM class I teach…

How do I get my team to want to do Agile when they don’t want to do Agile?

During the interview, Chris and I talk through different lenses you can employ to get a better understanding of what is driving the resistance and strategies for overcoming it.

We also spend some time near the end of the conversation on how to influence when you have no sway. This one came from someone on a team who is earlier in their career and is paired with an older Tech Lead that seems to view her primary role as Team Meeting Scheduler.

Whether you are the one trying to influence, or you are the recipient of someone’s efforts to influence, there is a lot here that you’ll find valuable.

 

 

Contacting Chris Barton

• LeadingAgile: https://www.leadingagile.com/guides/chris-barton/
• LinkedIn: https://www.linkedin.com/in/christopher-barton-09b33414/
• Email: Chris.barton@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

 

 

 

 

What is Agile governance? Simply put, Agile governance is a way to maximize the flow of value within an organization in the fastest way possible. Seems straightforward, and it is when you’re applying it inside a relatively new and small organization. In small, lean startups, there aren’t a lot of legacy processes and systems in place to overcome, and your teams are small and conducive to an Agile governance model.

But applying Agile governance inside a monolithic organization with legacy systems and thousands, if not tens of thousands of employees, can seem quite daunting.

So, we’re going to take the guesswork out of Agile governance and pull back the curtain on our three-tiered governance model. We’ll take a tier-by-tier glance at how we think about maximizing the flow of value inside large organizations and show you some of the things you should consider when scaling Agile inside your organization.

The Foundation of Agile Governance

You can’t have an Agile governance model without people and work for the people to do. If you didn’t have those two things, you wouldn’t have anything to govern. And while this might seem like a trivial statement, we can assure you it’s not. The foundation of a good governance model is in the structure and how you bring work to the people within it. Said another way, organizational design is critical to the success of your governance model.

The picture below demonstrates how we usually structure our three-tiered governance model.

Now, let’s take a quick look at each type of team.

Services Teams

Services teams are a particular class of product teams who are typically responsible for an area of a product that’s shared by multiple product teams. In a certain sense, the services these teams provide are a product in their own right. Usually, these teams are staffed by developers, testers, analysts, and any other specialists needed to deliver against their product backlog.

Feature Teams

Feature teams are what most people think about when they think about Scrum teams. A cross-functional group of six to eight people who have everything they need to deliver an increment of working tested product at the end of every sprint. Usually, these teams are formed around an individual product or business capability.

Program Teams

Program teams are needed in more complex organizations and sit between the strategy layer we’ll talk about here in a minute and the delivery/services teams. Their main priority is breaking down epics into features and features into user stories. More on this in a little bit too.

Portfolio Teams

A Portfolio team is a group of leaders who are responsible for identifying business needs, approving funding, and establishing time, cost, and scope constraints. They meet on a regular cadence to move high-level work items through the system of delivery.

*A Note on Team Formation:

At the Portfolio and Program level, we want teams that are built in such a way that they have all the different points of view and concerns within an organization represented. To get good at answering what is going to build, how we’re going to build it, what the details are, and what the schedule looks like, you need a certain mix of people. That said, each of the teams at this level typically has someone to represent the architecture view, the product view, the project view, and the analyst view inside an organization.

Now that we have a good understanding of how the Agile Governance model is structured, let’s begin taking a look at how we’re going to bring work to the teams.

Managing Flow in an Agile Governance Model

At each layer of governance, we want the teams to have a known backlog, stable velocity, and the ability to anticipate time and scope. Basically, what we’re trying to do with the governance layers is make sure that the work is flowing the way it should. That all the dependencies between teams are made visible and escalated so that we can manage them or break them when the time is right.

When we start thinking about how we’re going to sequence the work through the organization in a way that accounts for what we’re trying to accomplish, it looks something like this:

• Portfolio teams running epics through something like corporate governance phase gates. Let’s call them Gates 1-4.
• The Program teams are running featured through a Kanban-style board also. We tend to think about the various statuses as analysis, design, build, test, and deploy.
• The Feature/Services teams are working off a more traditional Kanban framework; not started, in process, done.

So, the goal is to get epics at the Portfolio tier of the Agile Governance model to flow across the board as fast as we can. We do this by getting features at the Program tier across the board as fast as we can. And we do that by getting user stories at the Services/Feature tier as fast as we can.

However, before you can begin doing any of that, we must first get proficient at decomposing the work at the top of the governance model into the kind of stories that can get moved quickly across the board. And getting proficient at decomposition starts with reimagining what a story even is.

Decomposition in Scaled Agile Governance  

Let’s get a baseline going for how we think about the work. In Scrum, we often think about stories from a user perspective. We build story maps where we create a persona and imagine their user journey to help inform the work we’re going to go and do.

In the early days of LeadingAgile, we started thinking about what this process looked like at scale and how we could apply it in a way that was more meaningful to the business and the executives that run it.

We landed on this idea of something we called a value story. Basically, what can we deliver to the market that someone will actually pay for? We know that executives are making decisions, and there are dollar amounts attached to these decisions. So, we started thinking about Epics at the portfolio layer as investment increments.

If the goal is to move these investment increments across the board in the fastest way possible, then we need to understand the constraints. Whether it be time, cost, or scope, we must have the ability to decompose this work in a way that’s respectful of the constraints. So, we must hunt for an MVP investment increment. What’s the smallest amount of value we can deliver within the constraints that someone will pay for so we can maximize the investment?

So that means that the Program tier’s job is to decompose the Portfolio epics into features that are aware of the constraints as well. They’ll run those features through their layer of governance with an emphasis on getting the highest value featured done first to maximize the investment of the organization.

It’s at this middle tier where the secret sauce of our governance model is located. If you recall, earlier when we talked about team formation, the Program teams have all the various points of view in the organization represented on their team(s). So, they’re uniquely positioned to not only understand what it is we’re trying to accomplish but also what it’s going to take to go and execute the plan.

So, the Program teams are not only in charge of decomposing the Portfolio epics into features, but they’re also responsible for turning those features into stories that are aware of the constraints at the Portfolio level.

The benefit of thinking about the work this way and having that middle layer act as a translation hub is that every feature and every story is tied to something that executive leadership has a vested interest in. It’s hard to get leadership to see the value in Agile when it’s seemingly disconnected from the things they really care about.

Explicitly linking value to all the work moving through each layer of governance adds a ton of clarity and purpose to the system of delivery and makes it easier to make decisions and defend choices along the way when something inevitably changes and the organization needs to pivot.

Dealing with Bottlenecks

Ideally, in an unconstrained system of delivery, we’d insert work into the Services/Delivery tier backlog, and they would just work on it in priority order until it was done. As stories got done, we’d see features moving smoothly across the Program tier, and every few weeks, epics would begin passing through Gate 4 at a regular pace.

That said, something that organizations must be aware of is the parts of the system that may act as bottlenecks and cause the work to flow asynchronously across the various levels of the Agile Governance model.

The reality is that when we build a system, especially a system of systems, we know we’re going to have bottlenecks. Especially when we’re dealing with Services teams that multiple parts of the organization rely on. We might have teams that don’t move as fast. Or teams that have more demand on them than other teams.

So the Program team’s job is also to ensure that they’re sequencing the work in a way that respects where those bottlenecks are and still maximizes the flow of value through the organization so that we can maximize the business’ investment.

The good news is that as these bottlenecks reveal themselves, it gives the organization a clue as to where they might make an investment to make a meaningful improvement to the system of delivery and how you’ll address it.

After all, when you have a bottleneck, you only have three options:

1. Elevate it by throwing more money or people at the problem.
2. Subordinate the system to it and have the work move slower
3. Exploit it by having the Program teams build part of the solution 

Agile Works If You Work It

We’ve spent the last 12 years or so implementing this type of governance in large organizations across a wide array of industries. We’ve had a ton of success with it too. But it all boils down to taking the aspects of Agile that work and thoughtfully applying them to an individual organization’s specific set of constraints, bottlenecks, goals, and desired business outcomes.

Agile is easy in the micro. Harder in the macro. But it’s never impossible, and it works when it’s done right.

In this week’s episode of SoundNotes, LeadingAgile Senior Consultant, Matthew Oatts joins me to talk about what to do when you are placed in a leadership role, but not given a lot of clarity on what you are specifically supposed to do or how you are supposed to do it. How do you lead people when you don’t have clear boundaries or you don’t have clarity on what your leadership is looking for. Oftentimes, this guidance is lacking because the people you report to don’t actually know and are just waiting for you to figure it out. How can you be successful in your role when success is not clearly defined for you? If you’ve ever found yourself in that situation, Matthew Oatts and I talk through different ways to respond when you find yourself in this situation.

Matthew’s 3 albums to listen to while working

• Brahms:  Hungarian Dances Nos. 1-21
• The Genius of Charlie Parker
• Miles Davis – Bitches Brew 

Contacting Matthew Oatts

If you’d like to contact Matthew 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

Agile Transformation is more than just installing Agile processes or Agile principles. It’s more than simply training your team on Agile methodology. But if that’s the case, then what is the actual path to becoming an Agile organization? 

You must create the conditions where Agile processes can be deployed and exploited for better outcomes than you had before—so you can get more value, better ROI, more predictability, and more. But to create this foundation, you need a way to move the organization incrementally and iteratively through Transformation that operates with certain characteristics. LeadingAgile has found a way to do this with what we call a Systems-first approach to Agile Transformation. 

In this podcast, LeadingAgile CEO Mike Cottmeyer and host Dave Prior candidly explore and discuss the details of the LeadingAgile Systems-first approach, including how it started, why it has become a proven and tested way to successfully enable any organization to Transform, and how each part of the system works.

 

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/

 

We’re exploring why we use the term working, tested product to broaden the scope of what Agile can do and how it can be applied in any business context.

One of the foundations of Agile is that you must be consistently producing a working, tested increment of software—or product— at the end of every sprint or time period.

The ability to produce increments of working tested software or product allows developers to be adaptable to respond to shifts in requirements, work out technical problems along the way, and provide a product at the end of the predetermined period that can be presented to a client or customer and work. It gives an organization time to receive and respond to customer feedback, improving each iteration of the software or product.

With consistent delivery, it can improve predictability, stabilize velocity, and enables the organization to adapt in real-time to market demands and customer needs.

Desired business outcomes are unique to each organization or business. They depend on the software or product they produce and their audience or market. The goal of adopting Agile is always about achieving the desired business outcome unique to the organization that is pursuing it.

The six most common desired business outcomes are:

1. Predictability
2. Improved Quality of Software or Product
3. Cost Savings
4. Early ROI
5. Product Fit
6. Innovation

If you can’t regularly produce a working tested product, you likely won’t reach any of these desired outcomes. Being predictable requires knowing how long it takes to complete work. Improving the quality of your product requires testing, releasing to market, and updating based on customer feedback. Cost savings and early ROI can’t happen if you’re losing time to development and not taking care of defects along the way. Product fit and innovation can only be addressed if you keep up with your market needs and anticipate what’s next.

And whether you are producing software or some other product, the process can be applied to many different contexts. The Agile mindset can be adapted to fit many industries or businesses. The term working tested product expands the scope of what Agile can do; it’s more general and can be used to explore what it means in any business context. Agile Transformation can go beyond software development and improve any organization’s operations to achieve its desired business outcomes.

The Process of Producing Working, Tested Product

Product owners and their teams are responsible for creating and managing backlogs and validating the work produced. They are responsible for defining the user stories and prioritizing the backlog to execute program requirements. They are the ones that must define clear acceptance criteria and definition of done.

From a process perspective, like in Scrum, the product owner brings the backlog to the Scrum team, and they accept the work into their sprint. This means they know the scope of what’s required, how to complete it, and when it needs to be delivered. They can negotiate the amount of work they accept into their sprint during sprint planning based on their team’s past velocity. Work is then incrementally completed and kept track of through daily stand-up meetings, and the sprint is reviewed afterward to see what can be improved next time.

During the sprint, work is validated by the product owner to ensure that it is on the right track or if it needs to be adapted. The constant loop of development and testing prevents work from getting too far without knowing if it’s performing right. In the end, this saves time in releasing the product and reduces the number of technical defects that could be present.

Getting to a Definition of Done

A working tested product is something that can be confirmed or tested and has a clear definition of done that can be met. Typically, the definition of done is defined by user stories that are features or desired outcomes for the end user, customer, or consumer of the final product.

User stories are accepted into the backlog and require clear acceptance criteria, a pre-decided behavior the increment needs to exhibit. With clear acceptance criteria and definition of done, the development teams know precisely what work must be finished by the end of the designated time period or sprint.

Being able to meet a definition of done and have a potentially shippable product at the end of each sprint means that developers can fix defects as they show up, and customer feedback can be addressed faster. Products can be released to market sooner or more regularly, allowing organizations to adapt in real-time to market demands and customer needs.

Avoid Pushing Work to the Next Sprint

The process of getting to a definition of done at the end of the sprint is essential because if you do not, you end up with an indeterminate, invisible backlog of work behind the delivery of user stories. In other words, you’re producing work much slower than you think.

For example:

• You have 1000 story points in the backlog.
• Delivery is 200 story points per sprint, so it will take five sprints to complete the backlog.
• You think you deliver 200 points every sprint but also put 150 points back in.

The 150 points create indeterminate work, such as re-work, defect remediation, and technical debt. You may know that you have 150 extra points, but if this process continues, you’re in a cycle of never actually completing your backlog of work.

When the delivery rate of work is slower than you think, it messes up the team’s velocity. Velocity is an important metric to know how much work can be completed in a specific time. If you always have invisible work and unfinished user stories, you’ll never establish a regular velocity, and your adaptability and predictability will suffer.

On the other hand, a well-articulated backlog, stable velocity, and precise definition of done get you to a linear burndown chart throughout the sprint. This ensures that work is completed in small increments, and the product is tested and approved by product owners. Then, the team can move on to new work at the beginning of the next sprint—instead of continually dragging pieces of projects from one sprint to the next.

How Testing Drives Better Business Outcomes

One of the foundations of Agile is consistently producing a working, tested increment of software or product.

The ability to produce increments of working tested software allows developers to be adaptable to respond to shifts in requirements, work out technical problems along the way, and provide a product at the end of the predetermined period that can be presented to a client or customer and work. It gives an organization time to receive and respond to customer feedback, improving each iteration of the software or product.

Over time, developing this regular cadence enables the organization to drive toward its desired end state.

I was thinking about how different LeadingAgile’s pair-programming (more simply, pairing) interview is from other interviews, like many interviews at the big tech-giant companies we all know about. Interviews at these massive tech companies are known for being difficult ordeals. There are even courses designed to help you pass them! Common challenges include multiple rounds of tech interviews and white-board programming exercises, where a candidate is expected to solve a problem writing correct code on a whiteboard with no reference material.

Why doesn’t LeadingAgile interview developers the way these other tech giant companies do? We believe that we can find and hire awesome developers while making the process compassionate and without undue stress on candidates. That kind of compassion is an aspect of Studios that we want to project. It brings candidates that are good teammates and good consultants. That compassion in an interview, along with a follow-up email describing what they need to learn/improve, also encourages “not yet” candidates to come back and interview again when they have more experience. Not only are white boarding interviews unnecessarily stressful, they do not represent what we do every day at Studios, namely pair program and find answers to things we do not know.

Our pairing interview is intended to be a reasonable simulation of real working conditions at LA Studios. We are looking to answer:

• Can they do the work we do?
• Do we think they will succeed as a developer who primarily pairs or works in an ensemble (some folks call it a mob)?
• Can they “develop out loud” while someone is helping?
• Is their preferred craft in alignment with what we have found to work? (TDD, CI, legacy rescue…)?
• If they do things differently than we do, can they speak to the pros/cons?

Our pairing interview does differ a bit from an actual working situation. Unlike on the job, the interviewer:

• Knows what they are looking for the candidate to demonstrate
• Will only help as much as needed to keep the candidate moving – the two are not trying to solve the exercise together

But we have found our pairing interview a good predictor of whether a candidate will be successful on one of our teams, because it does share so many aspects of our “real work.” Here are some things we look for as signs that a candidate will succeed in day-to-day development at Studios:

• Is there at least one programming language that they can be effective with? (Candidates may work in whatever language and tool set they are comfortable with.)
• What is their skill level with their language of choice? Do they write it idiomatically?
• Can they explain the what and why of the code they are writing?
• Are they careful?
• Are they skilled with TDD and generally test-first, and is that their default instinct?
• If they do not demonstrate the use of version control during the interview, are they able to talk about how they would use it in real work?
• Do they value small, single-concept commits with useful messages?
• Do they bring at least a little humor or fun to their work?
• Are they able to gracefully recover from setbacks?
• Do they accept instruction/redirection well?
• Are they curious if they are introduced to something new?
• Are they comfortable “not knowing the answer” in front of someone?
• If they do not know a specific detail, can they quickly find an answer online?

A “no” to any specific question above does not fail a candidate. Certainly, holding opposing views to some of the above will prevent a candidate from receiving an offer. For instance, believing that TDD is a waste of time or having a strong preference to wait until a feature is complete before they commit to version control are strong indicators that they will not be successful at LeadingAgile Studios.

But a “miss” on many of the things above that we are looking for is only likely to affect the level that we might place the candidate at. For instance, our most senior positions require strong TDD, refactoring, CI, version control skills. For them, we expect idiomatic use of the best parts of their selected language. Our least-senior position, Associate, requires some ability to code, curiosity, and an interest in learning. If we are considering someone for Associate, being able to demonstrate use of basic data types and control flow is sufficient.

There are things that we specifically do not look for by using pairing interviews, generally because they do not reproduce what we experience day-to-day:

• Whiteboard coding – as mentioned above, it is not what we do day-to-day and may create undue stress for the candidate.
• Ability to list the names of, for example, data structures or patterns. While we want candidates to be aware of and be able to show use of some patterns (based on career level), there is no mark against someone who can implement a particular pattern but doesn’t specifically state its name.
• Willingness or ability to do unpaid development work outside an interview. We recognize that not everyone has a life that allows them time to code outside of work. For instance, a person might be caring for a sick parent or be responsible for small children. If we were to screen out candidates who cannot do coding exercises at home, we would be reducing the diversity of the pool of people capable of succeeding at Studios.

LeadingAgile Studios is growing. We are looking for very skilled developers to lead efforts or very new developers who we can help grow. If you are not interested in interviews as performed at giant tech companies, either because you have experienced them or because you are not looking for an interview that requires weeks of preparation, contact us.

Agile methodologies have gradually emerged over the past 30 years but really became a thing with the signing of the Agile Manifesto back in 2001. When the Manifesto was signed, most Agilist were talking about small teams, embedded customers, and deploying working tested software on regular—and very short—intervals.

Fast forward 20 years, and we have large mega-corporations attempting to unlock the secrets of agility in businesses with tens of thousands of people, heavyweight governance, high-compliance regulatory environments, with expectations for making revenue commitments within strict time and cost constraints. How do we reconcile these two worlds?
This talk will explore the differences between team-level Agility, larger-scale organizational Agility, and ultimately business-focused enterprise Agility.

We will look at how the team-level approaches work and where they break down in larger companies. We will explore how large-scale organizational Agile approaches sought to address some of the shortcomings of team-level Agile but still fell short. Finally, we will discuss what it means to have true organizational Agility, Business Agility if you will, and the considerations necessary to unlock the dynamic possibilities of a truly Agile corporation.

We will close the conversation with why team-level Agile doesn’t necessarily lead to Business Agility and explore some ideas for how you might increase your chances of success and achieving the organizational benefits you are searching for.

When working toward becoming an Agile Organization, many companies begin by applying Agile methodologies at the team-level and then call the Transformation done.

The problem is that even when you do it perfectly, establishing a team-level Agile Delivery Model is almost always insufficient.

It’s insufficient because the rest of the organization isn’t built to be Agile.

We can’t simply provide the Teams with everything they need and assume they will figure out how to make good on the delivery. Teams don’t own the risk around finance, technology, brand, and so on, so how can we reasonably expect the Teams to make it all come together? The Agile principles established at the Team level can’t and won’t naturally scale to the remainder of the organization if the organization isn’t prepared to radically change. So how then do we go beyond simply going through the motions?

What does a true Agile Organization look like—and what must we change to get there?

Overcoming our Barriers

It’s not enough to have a ration of Sprint Planning and a slice of Jira and then call ourselves Agile. The bottom line is that Organizational Impediments get in the way of the Agile System of Delivery and must be addressed before we receive the benefits that Agile promises. These impediments often exist in many different reaches of the organization and are a symptom of the old ways of doing things.

It’s easy to assume that each unique organization will experience its own distinctive set of internal barriers that prevent Agility. However, most impediments are knowable, predictable, and can be approached in a planful way. When we become able to recognize what exactly within the organization needs changing, we can then begin our Transformation into being an Agile Organization.

Here, we’ll discuss some of the more common impediments to Agility and what an organization might look like when we overcome them:

Outdated Delivery Model

To become an Agile Organization, we must first establish a functional Agile Delivery Model. Many organizations operate “inside out” by creating project-oriented efforts that seek to keep their people busy and preserve the budget.

Instead, we need to operate “outside in,” considering what the most important things are that we need to solve in the market and what teams will be needed for it. We must also consider what capacity will be needed in the next 3, 6, 9, or 12 months and how we must operate within that. Additionally, we must build teams for resilience while we scale up and down. By doing this, we build stable teams and only spend money on the things we need to spend money on to solve a problem. What we reap is removal of dependencies in the organization and a smooth flow of work through the organization.

Product Mismanagement

Most organizations fall in one of two buckets regarding their Product Management:

• Sales-driven, order-taking, and building whatever the customer wants without considering which projects will actually move the needle
• Product owners building by directive. Build the plan, tell people what to do, and micromanage each task along the way

These methods prevent building the type of ecosystems and organizations that we want where we are learning and delegating and expanding our capability. This is not the fault of the product owner. We are placing project managers into a job with no clearly defined career path and holding them accountable to get the product out the door the way that we always have, meanwhile expecting that we achieve the Agile goals that we seek—adaptive teams that undergo dynamic learning and operate with predictability.

Do you see the problem?

We need to shift to command-by-intent. This way, we can deeply understand the customer and the markets that we’re going after. We can validate and justify our value propositions. We must be in tune with why we are trying to solve this problem, for this customer, in this market, relative to the other problems we could solve for other customers. We must connect our product management to the market and our value propositions to the delivery teams.

Inadequate Strategy Articulation

We find that Strategy for many organizations can be summarized by platitudes and slogans regarding who the organization wants to become. While these come from a good place, we can’t simply cross our fingers and hope to become what we say we can be.

Strategy is determining how we can manipulate our limited resources and capacity to achieve an outcome. Many organizations don’t have actionable strategies because they lack the ability to specifically articulate the plan. Value propositions, capability models, and OKR’s have proven to be resilient and allow organizations to have meaningful conversations about strategy.

We will fail to deliver Agility to organizations if we fail to connect our strategic goals to the tangible steps we must take to achieve them. If we cannot provide effective models for articulating strategy, we will continue working on projects that are not the most important to the organization.

Project-Focused Budgeting and Funding

Project-led funding leads to broken architectures and a lack of trust and confidence. We must move to a system that demonstrates our profitability and meets the expectations of regulators and shareholders.

Instead of a focus on Projects, we must lead with funding the Products we’re building. These changes in organizational design, development approach, team funding, operations, etc. afford an opportunity to reevaluate a company’s accounting for internal-use software and related capitalization policy.

We must clearly define and fund for business outcomes at the capability level so that investments are tied to tangible improvements. This method provides evidence of the returns generated from the investments that we have made.

Antiquated Technology & Business Architecture

To speak candidly, technical and architectural dependencies tend to be the hardest and most expensive impediments to deal with. For many organizations, the Legacy Application Technology and code base often support multiple slices of the organization and aren’t encapsulated. Additionally, the solutions architecture often doesn’t align with the product architecture, demanding that the organization orchestrate and coordinate hand-offs with other teams before getting the product pushed out. Each necessitated coordination effort creates a dependency which slows the process, creates blockages in production, and ultimately prevents Agility.

You must deploy software rapidly to respond to the market rapidly. You must be able to get things in the market safely, securely, and reliably. However, the architecture of many organizations doesn’t support this capability.

Agile Product Extraction enables us to take existing software applications and restructure them so that teams can push code into production independently. The goal is to enable teams to take an application, add features to it, and completely own the process end-to-end of getting it into production. By organizing teams in this way, and by modularizing our application software, teams become able to do their work in an Agile way that isn’t bogged down by excessive dependencies.

Compliance and Controls

We must be able to integrate compliance, controls, and auditing into our governance models and flow of work as opposed to these things being on the side. While we need independence of the review of our results, that doesn’t mean the audit and compliance regulators can’t help us plan the governance model so that they can still get what they need when they need it.

Mismatched Talent and Culture

What we often see is that we don’t know the nature of the people who should be in the positions that act as a catalyst to Organizational Agility. We cannot put people in a mismatched job, even if it is something that they desire. We cannot put people in charge of an advanced step in our Agile Journey if they are not wired to participate in the “continuous improvement game.” Our training in our organization must provide safety and understanding.

We need to be thoughtful when staffing our organizations by differentiating those who can operate with ambiguity and those who need to be stable and steady. Not everyone is capable of operating in a dynamic environment, and we must consider this fact when staffing our organizations.

Rigid Leadership

Establishing Organizational Agile Leadership is pivotal to building an Agile Organization. We must build a trustworthy system by encouraging our Leadership to become individuals dedicated to building a system that can operate the way we need it to. We must create leaders that understand the importance of functional systems and how exactly these systems will work. When our Leaders become pliable and buy into the Transformation, we create a support system that allows Agile to take hold of the organization.

Summary

An organization can’t reasonably expect to experience the benefits of Agility if they are not willing to fundamentally change their functionality to support Agile. The bad news? Most organizations weren’t built to be Agile and significant change is required. The good news? Most of the internal impediments that prevent Agility are common and can be overcome with a thoughtful and tactical plan.

Once we recognize the barriers in our organization, we can create a plan to systematically overcome each impediment to catalyze Agility when it makes sense and establish compensating controls when it doesn’t make sense so that we can better coordinate the work in a way that doesn’t impede the System of Delivery. And then, over time, we create the conditions where Agile can thrive.

Operating within your current constraints and overcoming these systemic barriers to Agility is how you become an Agile organization.

If you have a small team on a greenfield project, you can easily get started with DevOps. Your code isn’t that complex, and the needs of your technology environment tend to be limited. But, if you have a shop with thousands of people in it who are dealing with legacy code, getting started with DevOps, the right way, is an order of magnitude more complex. An instantiation of DevOps at this scale requires iteratively & incrementally moving through various stages of DevOps maturity.

This talk will cover how to approach DevOps when you have teams who are merely trying to become predictable and contrast that with more mature teams who might be looking to localize investment decisions, or who want to touch the market often so that they can innovate and learn.

Furthermore, we’ll explore the practices you’ll need to implement DevOps and the appropriate order in which to implement them to ensure you’re getting valuable outcomes along the way. Lastly, we’ll look at where the ownership and authority need to reside at various stages along the journey so that we can balance both consistency and Agility.

Finding, supporting, and retaining people with skills and talent is never easy. Over the past few years, between the pandemic and the great resignation, it has become even more challenging. What attracts the next generation of talented change agents? How can you help them grow into the skilled transformation ninjas you need them to be? If you are part of one of the older generations, how can you become more aware of your blind spots and take steps to improve the way you engage with the people who will lead us into the future?

This week in SoundNotes, Dave is joined by Lien Nguyen and Regan Jenkins who both work as staff consultants at LeadingAgile. During the interview, they discuss what LeadingAgile was able to offer that they could not find elsewhere, the different ways they are supported by the folks they work with, and they also offer Dave some tips on how he can show up for in a helpful and supportive way for those who are in the earlier stages of their careers.

Contacting Lien Nguyen

• Web: https://www.leadingagile.com/guides/lien-nguyen/
• Email: Lien.Nguyen@LeadingAgile.com
• LinkedIn: https://www.linkedin.com/in/lien-nguyen-077a52a9/

Contacting Regan Jenkins

• Web: https://www.leadingagile.com/guides/regan-jenkins/
• Email: Regan.Jenkins@LeadingAgile.com
• LinkedIn: https://www.linkedin.com/in/regan-jenkins-aa0526b7/

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/

Many teams that operate within Agile are struggling. The story is the same for an abundance of them—the Backlogs from which they operate fail to provide clarity on priority, definition, and scope. The teams are left with more questions than answers and have no clear path to creating value for the organization and customer.

We find that the backlogs that Agile teams frequently operate from appear as a thematic list of items that the product owner wants built. These macro-projects may span multiple sprints and prevent the teams from producing increments of working, tested product each sprint. Without achievable incremental progress, the teams’ velocity of output becomes unknowable. Without a stable team velocity, we become unable to make and meet commitments, causing future planning to be unreliable at best and impossible at worst.

Alternatively, backlogs may appear as a ream of minor engineering activities that are too small in scope to convey tangible value.

Neither of these methods of Building Backlogs provide clarity to the teams on the What, When, and Why of the project. The teams are left scrambling, unsure of what to prioritize with no clue how much of it can be completed in a sprint. Time becomes wasted searching for answers to these questions and can cause unwanted outcomes for the teams, the product owner, and the customer.

It doesn’t have to be this way.

Backlogs can and must be built in a way that provides clarity to the teams and allows for measurable, iterative progress to be made.

Rethinking Backlogs

Backlogs should consist of stories that allow for measurable progress. These stories must be small enough in scope that more than one can be completed in a sprint. They also must be large enough to provide tangible value to the product or feature and have meaning to the customer. The stories should not be prescriptive and must be open to negotiation for priority.

The scope of each story needs to be clear enough that the teams can estimate the time required for each and complete them within the predetermined time box. Each story needs a clearly defined state of “done” to allow for progress and prevent technical debt. The stories must be able to be exchanged for new directives if (and when) we learn new things. When we build backlogs in this way, we give the teams clarity around what they are building and how what they are building fits into the bigger picture.

Why is It Difficult to Build Backlogs This Way?

In many organizations, the individuals who decide what goes in the backlog aren’t available to provide clarity to the teams. Additionally, the stories are poorly defined and give insufficient directive. As previously discussed, the stories may be too big and span multiple sprints, thus preventing incremental progress to be made.

Team members may not have the authority to decide how to prioritize their work, and competing demands or too much WIP further prevents clarity on what to prioritize. Product owners that continue to build backlogs in this way prevent teams from stabilizing their output and optimizing their productivity.

How to Overcome the Difficulties of Building Backlogs in This Way

We must have open communication between the product owner and the teams completing the Backlog stories so that the teams produce increments of product that are most valuable to the customer and the organization.

User stories should be defined with enough detail that the team can execute on the delivery without having to ask excessive clarifying questions. This allows teams to produce working increments of product during each defined time period with confidence that everyone is on the same page.

We must lead our Backlog Building with a Systems-First approach—this entails prioritizing the creation of value over accomplishing tasks and projects. We must align our organizational structure and the way work flows through the system around a value-oriented approach. Building Backlogs in this way creates a team environment where we learn and adapt and expand our capability while ensuring the incremental work that we produce is valuable to the customer.

The Value of Building Better Backlogs

When we build better backlogs that support the teams, we become able to produce working, tested increments of product at a stable velocity. When we know the velocity of our output, we increase predictability and can reliably make and meet commitments.

Incremental and iterative delivery allows teams to track their progress, ensuring that they deliver and demonstrate value to the customer every sprint. Additionally, they become able to make tradeoffs based on scope and prioritization and adapt to changing customer demands and markets.

Providing teams with clear and actionable Backlogs empowers them to create value at a stable cadence with clarity around why and how their work is important to the organization.

An Agile Delivery Model will only take you so far. Many organizations simply go through the motions of Scrum. The teams are diligently having their daily standups, rigorously writing user stories, and dutifully performing a retro at the end of every sprint. Yet, they still fail to improve. Why then do all the ceremonies and cadences still fail to deliver on the promise of Agility?

The truth is that most organizations were not built to be Agile. Many organizations are wrought with organizational impediments and dependencies that get in the way of the Agile practices. We get all these Agile teams doing the practices only to come to terms with the reality that the organization isn’t designed for the way the teams are operating.

A functional Agile System of Delivery enables organizations to make strides towards Business Agility while at the same time revealing impediments to Agility that an organization must address.

System of Delivery: Where We’re Going

An Agile System of Delivery should begin by reinforcing the fundamentals of Agile at the lowest level—the Team—and scaling those foundational concepts to the remainder of the organization.

Teams Level – The 3 Things

To implement an Agile Delivery System across an entire organization, we must establish a firm foundation to build the System on. This foundation consists of the 3 fundamental mainstays of Agile–or The 3 Things–Forming Teams, Building Backlogs, and Producing Working, Tested increments of a Product.

First, we must consider Agile 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.

Next, we must address Agile 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 product. 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.

Once we establish functional Teams and build Backlogs, we must prioritize producing a working, tested increment of a product at the end of each designated period.

“The 3 Things” at Scale

Once we have established the foundation for our System of Delivery, 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 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 is the expression of backlog at scale. Practically, Agile 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 and Tools are the expression of working, tested product 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 Business Agile 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.

Benefits of the Agile System of Delivery

Operating your organization with this System of Delivery provides many of the benefits of Agility—you can expect increased predictability, cost savings, quality, and early ROI. Additionally, this System of Delivery reveals organizational impediments that hinder your ability to achieve Agility.

No System of Delivery solely enables an organization to overcome their impediments. However, with this functional System of Delivery in place, your organization is now making great strides toward Agility and is ready to take the next step: a complete organizational Agile Transformation.

Summary

An Agile System of Delivery that focuses on The 3 Things—Teams, Backlogs, and Working, Tested Product—enables an organization to receive the benefits of Agility and to recognize the impediments that are preventing their progress. However, the System of Delivery will only take you so far. While the System of Delivery manifests as the tangible outcome of “Going Agile,” the System of Transformation enables organizations to manage and implement the change required to be an organization that can be Agile. When the entire organization is transformed, then it may begin to reap the full benefits of the System of Delivery instead of simply going through the motions and calling it Agility.

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!