Category: Business Agility

The Next Agile Frontier – Agile Company Development

Dealing with common business challenges through agility

I’ve been helping companies improve their operations for over a decade. A repeating pattern is where a very successful company is facing growing pains affecting its ability to scale to the next level. Some examples of the challenges I’m called in to help with:

  • Losing the Ability to Innovate You often see companies that grow successfully to the point where it seems their ability to innovate stalls. When you look deeper, you see them struggling to cope with growing technical complexity, coordination costs across teams, and leadership bottlenecks. This affects product innovation as well as GTM innovation and other key business processes.
  • Time to Market / Time to Learn — The more complex the organization, the more time it takes to deliver value or close a learning loop. And in an environment of volatility, uncertainty, complexity, and ambiguity, this hurts your ability to compete. The bigger you are, the more you resemble the incumbents you once disrupted. Everywhere you look — product development or how the company runs its key business processes, there’s more and more friction and slowdown.
  • Losing Key Talent — Talented people are looking for an environment where they can thrive, have the right level of autonomy, work on interesting problems with minimum friction and headaches, and see the value and connect to a worthwhile mission/purpose. As companies grow, the way they operate becomes less and less attractive to talented people. They feel bottlenecked, stuck, and mired with more and more legacy and start looking for greener fields.

Business/Organizational Agility — The New Business Operating System

Addressing these challenges by improving our ability to innovate and deliver, solving complex problems in an environment of uncertainty, is what we call “agility.” It essentially translates to having a scalable ability to build/try/measure/learn, in fast cycles, customer-facing products, as well as business/internal processes, in a way that is aligned with the company’s strategic focus. You might also call these OKRs, Distributed Leadership, Nimble, DevOps, Lean Startup, or Scrum.

While Agile was created in the IT/Software world, more and more organizations realize that its principles and thinking apply broadly. Business/Organizational Agility is emerging as the term used for this new and improved “business operating system” that applies these agile approaches across the organization, from product development/IT through revenue-generating activities such as Sales/Marketing to how the C-suite/Senior executives are working as a team on the biggest gnarliest challenges the company is facing in executing and validating its business model.

This new “business operating system” typically requires some virtual reorganization to teams and teams of teams that own products/experiences/value, adoption of evidence/data-driven ways of working, and a leadership style that provides clarity and empowers teams to figure out how to work and how to achieve their goals. It includes work on focus/flow, empiricism, and continuous improvement at all levels of the organization.

A useful definition of the essence of this agility is provided in the Evidence-Based Management (EBM) framework created by Scrum.org. This framework can also be used to assess a company’s maturity on the journey towards being an “evidence-based managed company” or operating on an “evidence-based operating system.” The EBM framework purposefully stays away from prescribing ways of working.

In recent years I’ve been working with more and more companies that are applying these “Evidence-based agile operating systems” across the company.

The trigger to “upgrade the operating system” is sometimes proactive internal leadership. More frequently, there’s a major event driving it. This can be a major new threat/opportunity, a major change in leadership, or an investment/recapitalization event.

Focusing Agility Where It Matters The Most

Having a company-level evidence-based operating system doesn’t mean every activity in the company should be managed in an evidence-based manner. This way of structuring/working is especially useful when working on developing — developing products, services, or generally “ developing company #2” (the company you want to become). Running ongoing operations might or might not require this way of working.

Try this – once you come up with your strategy for the quarter/year (e.g. your OKRs) assess each element according to uncertainty, complexity, dependency, and impact. Then, based on this analysis, choose the ones that would benefit the most from an “evidence-based management approach” and plan how to manage them this way. This might mean organizing a cross-functional, empowered, focused team of the portfolio company employees and external SMEs (if relevant) that will work in short cycles to create useful increments of value in this area and review them frequently with other stakeholders. It might mean creating high-level “Goals” and providing people with clarity on the Bet while giving them the space to explore alternative ways to achieve the desired outcomes via trial and error in the trenches.

Replacing the Engine Mid-flight

More often than not, these strategic interventions will need to occur in parallel to continuing to run the business as hard as ever. People struggle to balance their day job (Company #1, the current company that needs to continue running) and transformation work (Developing Company #2 — the one we are working to create) — how much capacity to assign to each? Does managing the day job and transformation work as part of the same bucket make sense? Who’s in charge of each type of work? Who mediates when there are conflicts?

I hear from CEOs in these situations that they frequently need to get involved in resolving these conflicts between the day-to-day and the transformation. This results in delays, frustrations, and feelings of disempowerment. If this transformation also coincides with other bigger company changes (e.g., new leadership, new investors/owners), the environment is even more volatile.

Another common friction/frustration area is goal-setting. What should we focus on now? What’s realistic to achieve? Do we involve people who will do the actual work in goal setting? OKRs are a popular goal-setting mechanism. But they’re not as trivial to implement as they might seem… One common anti-pattern is to set too many OKRs, top-down. ( A better way is to provide alignment via Objectives and let teams come back with realistic Key Results. There’s much more to say about the effective usage of OKRs in a PE environment, maybe later…)

This balancing act between operational and transformational work, alignment, and autonomy is a key area of focus for business/organizational agility. In my experience, Patterns such as “product ownership” and “developers,” while they sound very IT/product-centric, can come in handy.

Organizing around Bets

Another common sign of trouble is when teams are overly dependent on other teams to the point that their progress is frequently blocked, and spend precious time coordinating and managing across the organization rather than executing. This can manifest as leaders of teams being extra busy in trying to coordinate the complicated network of dependencies and the desire for more and more “coordination/management layers” such as PMOs, project managers, and the like.

A preferred play is to reorganize around value — rethink team structure and bring together the people collaborating closely in executing the transformation into empowered, focused teams that self-manage with minimal overhead. These teams might include people from different functions — for example, Product Management, Marketing, Sales Enablement or Finance, Legal, and HR. This virtual team structure should be aligned with the key initiatives the company is focused on.

The New Frontier for Agility

Agile was born in software development and has been widely adopted in IT and Product organizations to the point that there’s little argument that product/technology organizations should operate using agility principles.

More recently, other functions, such as Marketing, have adopted these agility principles and practices. I see these as useful stopgap measures on the journey toward real organizational agility.

The next frontier I’m seeing in a couple of early adopter organizations is the evolution towards a more holistic definition of “development” that I explored in this article – developing the company’s capabilities.

Exploring the Connection Between Business Agility, OKRs and Private Equity – Interview w/ Yuval on the Quantive Dreams with Deadlines Podcast

If you’re here, you might be interested in OKRs. If so you should check out the Dreams with Deadlines podcast published by Quantive (formerly Gtmhub).

I was delighted to accept an invitation to come on the podcast to discuss OKRs, Business Agility, Agile, Evidence-based management and the connection to increasing value creation e.g. in the Private Equity space. Check out the podcast here or in the embedded audio below.

https://cdn.transistor.fm/file/transistor/m/shows/8550/f9a496eaa9f4c99574381dcc521d39a0.mp3
Dreams with Deadlines Podcast Interview with Yuval Yeret

We discuss the role of OKRs in aligning the goals of a portfolio company and how they can be used to facilitate cross-functional collaboration and focus on outcomes. we also discuss the importance of going beyond the surface level of frameworks like OKRs and Scrum to truly understand and utilize their principles, as well as the dangers of getting caught up in the hype of the latest buzzwords and trends.
 

What you will learn

  • The connection between business agility and OKRs in private equity
  • The role of OKRs in alignment and focus within an organization
  • The principles shared by various frameworks such as OKRs, Scrum, and SAFe
  • The importance of understanding and implementing frameworks effectively
  • The benefits of dynamic team organization and shuffling based on OKRs
  • The value of discussing outcomes rather than specifying outputs and having conversations about OKRs
  • The dangers of chasing the next shiny thing without fully understanding and implementing it
  • The connection between agile principles and OKR success
  • The role of transparency, collaboration, and psychological safety in creating a successful environment for progress and continuous improvement
  • The challenges and opportunities in improving work environments and creating meaningful organizational progress.

Fix Your OKRs – Back to First Principles

Context

OKRs (Objectives and Key Results) have become the latest management framework to suffer the fate of becoming popular too quickly, to the point where in many organizations, OKRs are a theater/charade with little useful substance or benefits. That’s a shame because OKRs have huge potential if used effectively. So let’s go about fixing your OKRs! 

Why OKRs

Let’s start with the basics. What are OKRs even about? 

OKRs aim to help you execute effectively on what matters most (your strategy), while overcoming silos, politics and turf wars, the ongoing grind (aka whirlwind), and other management challenges. To face all of these challenges, OKRs provide organizational alignment and focus. 

As defined by WhatMatters.com:

OKRs – an Alignment Framework – a collaborative goal-setting methodology used by teams and individuals to set challenging, ambitious goals with measurable results. OKRs are how you track progress, create alignment, and encourage engagement around measurable goals.

Let’s now dive into HOW OKRs (used well) set you up for success and what might go wrong. 

Achieving Focus – Focusing on the few Strategic Objectives

OKRs should help you focus on your strategic priorities. Having a small set of strategic objectives reduces context switching and provides a rallying cry that helps cut through silos and politics. 

Choosing where to focus is hard, though. It’s much easier to define an OKR for everything – and then when everything is important, nothing is really important. and that’s exactly what we often see out there. 

So with that in mind – 

Avoid … mapping all planned initiatives to OKRs. 

Try … rallying around 1-2 OKRs. 

Working IN the business vs. working ON the business

Another way organizations drown themselves in OKRs is by having OKRs for everything. 

Running the business doesn’t require OKRs. Key Performance Indicators (KPIs) can be used to manage/monitor operational work. 

OKRs should be used just for development/growth work – work we do to change how we do things. 

As you might imagine, This distinction helps reduce the number of OKRs significantly, leaving a set of fewer, more focused objectives. 

Development/Growth/Transformational work typically involves more uncertainty and complexity than running the business as usual. In this environment, a  lot is unknown – What’s the best way to achieve the goal? Does the goal still make sense? 

Our way of working ON the business might need to look different than our way of working IN the business. (see this article for a deeper dive on what working ON the business might look like, leverage the perspective of Private Equity firms who focus on working on the business to maximize value creation)

This environment calls for evidence-based management – a management approach designed to improve outcomes when facing complexity through unleashing empiricism, self-management, and cross-functional collaboration. 

OKRs are designed to be an evidence-based management approach. But there are a couple of key principles and practices that need to be in place for that to take place. 

Rally around Outcomes (rather than managing outputs/activities)

One key aspect in ensuring OKRs enable evidence-based management is the type of goals we use. Managing outputs and activities can work reasonably well for working in the business since that work is typically operational and defined. 

On the other hand, Using output/activity-based goals to work ON the business fixes plans, specifications, and designs too early. It reinforces a “factory” mindset where people focus on their deliverables rather than the wider problem/opportunity. And it lends itself to heavy-handed command and control. 

For complex, uncertain work, you should set goals using outcomes. Outcome-based OKRs unleash self-management, empiricism, and people’s creativity to explore/discover. They create environments where people are empowered to work together to solve problems. This is how you should be working ON the business. 

One of the challenges with managing through outcome-based goals is that you need to wait longer to see outcomes – making it tempting to manage through outputs or even activities. But remember – the role of OKRs isn’t to manage the day-to-day. It is to provide alignment around where to aim. People can use other processes to manage their work toward the OKRs. 

Instead of breaking outcomes into outputs/activities, experiment with identifying intermediate outcomes. This is challenging but satisfying (TIP: Slicing outcomes is similar to identifying a Minimum Viable Product, Minimally marketable features, and Slicing Stories… so your Product leaders and Agile practitioners can help out on this front). If coming up with outcome-based KRs is too hard, Start with making sure at least the qualitative Objectives are outcome-focused and, over time, evolve from output towards outcome KRs. 

Aligned Initiative over Command and Control

When leaders want to align their wider organization around their strategic goals, they often cascade OKRs throughout the organization. This strict cascading means that by the time you get to the people who will work towards the goals, they are bound to tasks/activities and don’t have the maneuvering room they need to seek the best way to achieve the goal, not to say reconsider what’s the best goal. This looks quite similar to OKR’s predecessor – Management by Objectives (MBO) which was very control-oriented. And it results in people who are disengaged. (did anyone say “quiet quitting”?)

There’s a false dichotomy that many leaders fall for, which is the belief that alignment requires control. Actually, alignment and control are two separate aspects that can work in concert to create effective management. Donald Reinertsen calls this Aligned Initiative. David L Marquet talks about Intent-based Leadership. Henrik Kniberg, in his usual brilliance, maybe nailed it best in this diagram describing Spotify’s “Aligned Autonomy” engineering culture principle (Jason Yip elaborates on this principle here). 

Why does initiative/autonomy matter so much? There are two main reasons. The most important one is that in the creative work that working ON the business requires, the best solutions emerge from the people in the trenches. And by providing them with a clear goal and empowering them to take the initiative, we dramatically improve our chances of achieving the desired outcomes. A secondary benefit is that people are intrinsically motivated by being empowered and provided with the right level of autonomy.

The key, then, is to achieve alignment without strict cascading. Leaders should use OKRs to provide context and direction. To inform about why rather than prescribe what/how. Teams/groups then come up with their OKRs. The connection can be reinforced as part of the “Why Now” for each objective. Teams/Groups share their intent with each other and with relevant leaders to help ensure alignment in an environment of empowerment/autonomy. 

(This might seem like a complex process to pull off… the good news is that there’s a lot to learn from agile ways of working about facilitating such processes. For example, I helped a fast-growing biotech startup create an approach for cross-company OKR planning leveraging a process similar to SAFe’s PI/Big Room Planning)

Figuring out the right Cadence 

A key aspect of evidence-based management is the feedback loop. Many organizations set OKRs for the quarter and then forget about them until the end of the quarter. It’s like setting your sales quota and only checking back at the end of the quarter. Recipe for disaster, right? 

The other extreme is to micro-manage OKRs to death. 

It’s all about finding the “goldilocks” cadence that provides frequent enough transparency and the opportunity to inspect and adapt at the right level. There can be a different cadence for everyone involved in achieving an OKR as compared to the cadence involving all stakeholders interested in that OKR. The right cadence also provides an opportunity to reinforce/communicate strategic priorities and focus. 

The Scrum framework provides one example of how such a cadence could look. Consider a cadence that involves Planning, Reviewing, and Retrospecting with a clear distinction between the team working on the OKR and its stakeholders. 

Cross-functional Alignment 

Leaders struggle to manage the cross-functional collaboration and dependencies many OKRs require. The coordination overhead makes it tempting to divide and conquer and cascade the OKRs into focused/defined OKRs for each function/group. The problem is that this immediately turns into output/activity focus and ends up with the same challenges described earlier in the Rally around Outcomes section. Why? Because functions cannot own cross-functional outcomes. 

So what’s the alternative? To organize around OKRs. After identifying the few real OKRs, assess who’s needed to work towards each of them. If they require cross-functional collaboration, create an empowered cross-functional work team to make collaboration easier. Another benefit of organizing around OKRs is that working on a team around a clear business strategic goal with a clear, quantifiable metric that the team is empowered to have a direct impact on boosts the feeling of purpose and creates better engagement and motivation. 

Disconnect/confusion between OKRs and agile ways of working

I often see teams and organizations that struggle with the relationship between OKRs and agile ways of working. They’re unsure of the best way to relate OKRs to their Backlogs and feel there’s a redundancy between the agile and OKRs cadence. 

Hopefully, at this point of the discussion, you can see that OKRs and agile ways of working are very similar. Both are based on focus, cross-functional collaboration, alignment, empowerment, and empiricism. 

So how do we address the overlaps? 

Some OKRs map cleanly onto existing teams/groups in a product development organization. In this scenario, they can inform the creation of Product Backlog Items for the team/s to focus on (or the creation of Features/Epics in a higher-level backlog ). If a new product development team or team of teams is created to focus on a cross-cutting OKR, the OKR can become the Product Goal / Vision for this new group. In both cases, how we’re doing on our OKRs should be inspected during Planning and Review events and inform decision-making. There’s no need for an additional ongoing OKR cadence. Quarterly or so OKR review/planning can replace “Release Planning” with a higher focus on outcomes/impact. If needed, this OKR review/planning can include a “dry run” planning exercise along the lines of SAFe’s PI Planning to make sure that the OKRs are both aligned with the business stakeholders and realistic. 

There’s a wider opportunity here, though. While Scrum was created as a framework for managing product development, it is appropriate for working on any complex problem. As we’ve established earlier, work to achieve OKRs is typically complex, even when it’s not product development work. The natural next step is to apply Scrum (or other agile ways of working) as the approach to doing the work towards achieving the OKR. Scrum can become the operating system for working ON the business.

All together now – OKRs AND Agility for the win

To sum up, OKRs and Agile/Scrum aren’t in conflict. Looking at OKRs with Agile/Scrum lenses reinforces the first principles that OKRs are based on. To successfully leverage OKRs, you should: 

  • Focus on working ON the business vs. IN the business
  • Stop starting, start finishing – Focus on a few key strategic initiatives (maybe even just one) 
  • Rally around outcomes rather than micro-manage outputs/activities
  • Provide alignment and enable initiative through empowered teams/groups
  • Organize around value – leveraging OKRs
  • Leverage agile/scrum to execute on OKRs
  • When in doubt – go back to first principles – Alignment, Empowerment, Focus, Empiricism

If you’re curious to learn more about these principles and how to apply them – a good place to start is the Evidence-based-management framework. The Scrum.org Evidence-based Management Training (PAL-EBM) workshop is a one-day workshop that explores this space and can be a great way to start fixing your OKRs or, better yet, get started the right way…

Agility / Evidence-based Management and their role in improving returns in the Private Equity…

In this article, I’ll explore the need for and the attributes of an agile business operating system related to Private Equity (PE) portfolio companies. It hopefully helps leaders of such companies and PE professionals focused on the operations side expand their perspective on what “Agile” and “Agility” mean in their world and how they can help them improve returns realized in their investments.

Dealing with common business challenges through agility

I’ve been helping companies improve their operations for more than a decade now. A repeating pattern is where a very successful company is facing growing pains affecting its ability to scale to the next level. Some examples of the challenges I’m called in to help with:

  • Losing the Ability to Innovate You often see companies that grow successfully to the point where it seems their ability to innovate stalls. When you look deeper, you see them struggling to cope with growing technical complexity, coordination costs across teams, and leadership bottlenecks. This affects product innovation as well as GTM innovation and other key business processes.
  • Time to Market / Time to Learn — The more complex the organization, the more time it takes to deliver value or close a learning loop. And in an environment of volatility, uncertainty, complexity, and ambiguity, this hurts your ability to compete. The bigger you are, the more you resemble the incumbents you once disrupted. Everywhere you look — product development or how the company runs its key business processes, there’s more and more friction and slowdown.
  • Losing Key Talent — Talented people are looking for an environment where they can thrive — where they have the right level of autonomy, where they work on interesting problems with minimum friction and headaches, and where they can see the value and connect to a worthwhile mission/purpose. As companies grow, the way they operate becomes less and less attractive to talented people. They feel bottlenecked, stuck, and mired with more and more legacy and start looking for greener fields.

Business/Organizational Agility — The New Business Operating System

Addressing these challenges by improving our ability to innovate and deliver, solving complex problems, in an environment of uncertainty, is what we call “agility.” It essentially translates to having a scalable ability to build/try/measure/learn, in fast cycles, customer-facing products as well as business/internal processes, in a way that is aligned with the company’s strategic focus. You might also call these OKRs, Distributed Leadership, Nimble, DevOps, Lean Startup, or Scrum.

While Agile was created in the IT/Software world, more and more organizations are realizing that its principles and thinking apply broadly. Business/Organizational Agility is emerging as the term used for this new and improved “business operating system” that applies these agile approaches across the organization from product development/IT through revenue-generating activities such as Sales/Marketing all the way to how the C-suite/Senior executives are working as a team on the biggest gnarliest challenges the company is facing in executing and validating its business model.

This new “business operating system” typically requires some virtual reorganization to teams and teams of teams that own products/experiences/value, adoption of evidence/data-driven ways of working, and a leadership style that provides clarity and empowers teams to figure out how to work and how to achieve their goals. It includes work on focus/flow, empiricism and continuous improvement at all levels of the organization.

A useful definition of the essence of this agility is provided in the Evidence Based Management (EBM) framework created by Scrum.org. This framework can also be used to assess a company’s maturity on the journey towards being an “evidence-based managed company” or operating on an “evidence-based operating system.” The EBM framework purposefully stays away from prescribing ways of working.

In recent years I’ve been working with more and more companies that are applying these “Evidence-based agile operating systems” across the company.

The trigger to “upgrade the operating system” is sometimes pro-active internal leadership. More frequently there’s a major event driving it. This can be a major new threat/opportunity, a major change in leadership, or an investment/recapitalization event. This is where the Private Equity (PE) connection comes in.

Private Equity — Betting on improving the value of companies

Generally, at least in my understanding, PE firms search for opportunities to “improve” assets in the form of companies. This improvement can be described as taking a company with current value (CV) and tapping into unrealized value (UV).

These opportunities are identified and validated via a Due Diligence (DD) process. Traditionally, PE “deal teams” focus on this gap between CV/UV and forming an investment hypothesis around what might be the return on investing to realize this additional value over a certain number of years. At this point, the PE deal team has essentially a set of “bets” that if successful will create outsized value for the investors.

Why are we saying bets/hypothesis? Because there’s a level of uncertainty around whether indeed these bets will create the value they’re intended to. There’s also uncertainty around the company’s ability to change/transform in the way these bets require. Some bets require creating products, and some change how products are sold/serviced. Some require different organizational structures. Regardless of the type of bet, one other thing to consider is that if this was such a sure bet — wouldn’t current company owners move forward on this already? In some cases, the answer is that they couldn’t without the funding brought in by the PE round. In other cases, the answer is that making the change isn’t trivial, and requires a strong capability to innovate and deliver in the company.

Validating Change Readiness as part of the PE Investment Hypothesis

One inherent but sometimes implicit bet is whether the company is change-ready. Does it have the culture and operating systems needed to execute the investment thesis? While traditionally PE firms focused mainly on the financials, more and more are realizing the importance of assessing and thinking about culture, team health, and other operational aspects as part of the investment thesis. Looking at modern due diligence processes, you might recognize elements of Lencioni’s 5 Dysfunctions of a Team framework (or The Advantage), eNPS/Glassdoor results, or other cultural / talent-oriented aspects. The EBM framework described above provides an additional facet to explore and think about.

If gaps are identified, working to become a lean, mean, agile change-ready company using an evidence-based operating system should be considered part of the PE “100 days plan” — as an enabler for working on other elements of the business transformation plan.

Focusing Agility Where It Matters The Most

Having a company-level evidence-based operating system doesn’t mean every activity in the company should be managed in an evidence-based manner. This way of structuring/working is especially useful when working on developing — developing products, services, or generally “ developing company #2” (the company you want to become). Running ongoing operations might or might not require this way of working.

One exercise that a PE deal team can run with the leadership team of a portfolio company is to assess each element/bet in the investment thesis and categorize bets according to uncertainty, complexity, dependency, and impact. Then, based on this analysis, choose the ones that would benefit the most from an “evidence-based management approach” and plan how to manage them this way. This might mean organizing a cross-functional, empowered, focused team of the portfolio company employees and external SMEs (if relevant) that will work in short cycles to create useful increments of value in this area and review them frequently with other stakeholders. It might mean creating high-level “Goals” and providing people with clarity on the Bet while giving them the space to explore alternative ways to achieve the desired outcomes via trial and error in the trenches.

The Day-to-Day Challenges of the 100 Days Plan

Some interesting challenges typically stress the business operating system when executing a transformation.

People struggle to balance their day job (Company #1 the current company that needs to continue running) and transformation work (Developing Company #2 — the one we are working to create) — how much capacity to assign to each? Does it make sense to manage the day job and transformation work as part of the same bucket? Who’s in charge of each type of work? Who mediates when there are conflicts? What I hear from CEOs in these situations is that frequently these conflicts between the day-to-day and the transformation go all the way up to their table, resulting in delays, frustrations, and feelings of disempowerment in times when people are already sensitive to any cultural changes and there’s increased challenge to retain top talent.

Another common friction/frustration area is goal-setting. What should we focus on now? what’s realistic to achieve? Are we involving people who will do the actual work in goal setting? OKRs are a popular goal-setting mechanism. But they’re not as trivial to implement as they might seem… One common anti-pattern is to set too many OKRs, top-down. ( A better way is to provide alignment via Objectives and let teams come back with realistic Key Results. There’s much more to say about the effective usage of OKRs in a PE environment, maybe later…)

This balancing act between operational and transformational work, alignment and autonomy, is a key area of focus for business/organizational agility. In my experience, Patterns such as “product ownership” and “developers”, while they sound very IT/product-centric can come in very handy.

Organizing around Bets

Another common sign of trouble is when teams are overly dependent on other teams to the point that their progress is frequently blocked and spend precious time coordinating and managing across the organization rather than executing. This can manifest as leaders of teams being extra busy in trying to coordinate the complicated network of dependencies and the desire for more and more “coordination/management layers” such as PMOs, project managers, and the like.

A preferred play is to reorganize around value — rethink team structure and bring together the people collaborating closely in executing the transformation, into empowered focused teams that self-manage with minimal overhead. These teams might include people from different functions — for example, Product Management, Marketing, Sales Enablement or Finance, Legal, and HR. This virtual team structure should be aligned with the key initiatives the company is focused on.

Continuing the conversation

Disclaimer: If it’s not obvious by now, I’m not a PE expert. I wrote this article based on my experiences as an agility coach in the trenches with PE portfolio companies, conversations with former clients who went through a PE transaction later on, conversations with CEOs, and my research into the PE space (I found the ParkerGale Private Equity FunCast especially useful btw). I’m sure I’m butchering some PE lingo and process. Please, call me out on it!

Hopefully, this article, as imperfect as it is, convinces you to take a different look at agility as something you or others in the PE ecosystem you work with should care about. If it has, or if it hasn’t, I’ll be happy to hear your reactions or comments and am of course happy to help you explore further.

Originally published at https://www.linkedin.com.

Improving Focus and Alignment by Organizing around OKRs and managing OKR Flow

Improving Focus and Alignment by Organizing around OKRs and managing OKR Flow

Today, I wanted to share two quick observations about OKRs.

Too many teams working on each strategic OKR

I encounter many organizations that use OKRs. Too many of them have this crazy matrix where the high-level OKRs — those that aim to achieve the organization’s strategy — map to too many teams/functions in the organization. This creates a need to cascade the OKRs, create sub-OKRs, or other techniques which eventually create a larger and larger distance between the OKRs at the team level and the strategic OKRs. While this at least creates transparency of who’s involved in executing each aspect of the strategy, we can and should do better.

One key thing that unlocks agility and value is to “Organize around Value”. Scrum talks about each team having ONE Product Goal they focus on. SAFe has a specific principle around “Organizing around value”.

If you’re using OKRs One question to ask yourself is what is the relationship between OKRs and teams/teams of teams. If most OKRs require a multitude of teams across the organization/portfolio to achieve them, this will require a lot of coordination.

Try reorganizing into a value stream network/topology/team structure that aligns with your OKRs — where each team/team of teams can focus, and where there is clearer accountability around which team/group owns a specific high-level OKR.

Yes, you can find OKR and Agile management tools that will let you deal with complex networks of cascading OKRs, but Simplicity FTW…

Too many OKRs

Another symptom I’m seeing way too often is too many OKRs. Some of that is related to the OKR matrix I mentioned above. Some of it is just plain old push vs pull and classic wishful thinking at all levels. What could we do about that? Do we have a proven approach that can help? mmm…

Maybe we should visualize the FLOW of OKRs through the funnel of considering them, prioritizing/refining, committing to them, working on them, reviewing, achieving…
How about LIMITING and REDUCING the amount of OKRs in progress across the organization at any point in time — the alignment that OKRs promise relies on focus rather than trying to boil the ocean
Next, let’s manage the flow of OKRs proactively. Maybe even use some metrics like OKR cycle time, throughput, WIP, and aging.
Let’s inspect the flow from time to time. We might learn a few things. Maybe we should adapt the definition of how these OKRs flow and how we’re managing them.

How many of you ARE leveraging Kanban/Flow practices to improve how your organization uses OKRs to align strategy and execution?

PS do you see how similar this would be to a portfolio Kanban? Could it be the next generation of portfolio Kanbans? ????

Organizing around Outcomes with OKRs and Scrum

Aligning Scrum Team Topology to Strategy with OKRs and Product Goals

Yeah, I know. Could I squeeze more buzzwords into the title? I guess I could include Digital Transformation, Cloud, AI, and Machine Learning for effect. But seriously, I wanted to share some insights around how to align your Scrum Teams to your strategy leveraging OKRs and Product Goals.

Driving Change Using OKRs

We maintain performance by tracking the health of Key Performance Indicators(KPIs). We use Objectives and Key Results (OKRs) to drive performance change. Objectives point towards the desired state. Key results measure progress towards that desired state.

This performance change could be about our product or the ability to innovate/create that product. (Gap between realized and unrealized value / ability to innovate in evidence-based management (EBM) terms)

By setting OKRs we’re typically setting our sights on a complex problem — the space where Scrum and Empiricism thrive.

Achieving OKRs using Empiricism and Scrum

Working in self-managed empowered multi-disciplinary teams using fast feedback loops is a great way to tackle complex problems.

This is true regardless of how much IT or technology is involved. We might have an OKR that requires business change involving mainly legal, marketing, procurement, HR, and so on, that would still benefit from using Scrum’s empirical team-based approach.

For example, if a health care provider is aiming to digitize their patient journey to streamline it and make it more efficient, part of that will be to implement an electronic medical records system (EMR). But the objective isn’t just about implementing an IT system. It’s a change in the operating model. The organization supports this change by the development of new procedures, systems, and capabilities.

Focusing on Outcomes rather than Outputs

OKRs and Scrum are both designed to focus on outcomes over outputs. Most agile practitioners would recognize the N from “INVEST in User Stories” which stands for creating Negotiable user stories that provide optionality/flexibility for learning about what’s the best way to achieve outcomes. Having said that, most agile practitioners do feel like user stories are a form of requirements — meaning they are required.

Actually, user stories, any other form of Product Backlog Items, and even the Sprint Goal should be considered options — meaning they are optional. We currently think they are valuable, but we might learn of more valuable things to focus on.

Even the Product Goal is just an option. Maybe there we will find a better Product Goal for the Scrum Team to rally around or maybe there’s another better Goal that requires a different team topology.

Be Agile about your OKRs

Similarly, OKRs reflect the strategic direction at a certain point in time. We might learn something that would suggest a change in the Key Results or even the Objective itself. The frequent transparency provided by sprinting towards an OKR enhances the empiricism that might drive these realizations and is an enabler for strategic agility.

Many organizations fail to see this perspective. They consider OKRs as if they’re set in stone.

The same sort of time, budget, scope-oriented project management mindset that is hampering so many agile teams is affecting OKR implementations as well.

The problem with activity/output-based OKRs

Many OKR practitioners struggle to figure out how to break an annual strategy/OKR into meaningful outcome-oriented quarterly OKRs. By default, they break the big outcome into implementation steps a.k.a activity/output/milestone OKRs. It’s the project management mindset again — we basically bring in the classic work breakdown structure (WBS) into the OKR framework.

Going back to the patient journey digitization effort. Many organizations would define an initial OKR of choosing an EMR system. This is an example of an activity. It doesn’t deliver business value on its own. Once we set this OKR it’s harder to think of alternatives that might obviate the need for an EMR system in order to achieve the desired outcomes.

We’ve seen it happen countless times on agile teams struggling to slice stories in a meaningful manner and not sure how to come up with a useful Increment at the end of a short Sprint.

When working with OKRs we can leverage the same techniques that help these agile teams identify valuable partial outcomes that enable us to inspect and adapt our tactical and strategic direction.

Organizing Around OKRs

Another common reason why we see output-based OKRs is the team topology.

We often see organizations defining OKRs and then mapping them to their existing teams. In this example, this will mean cascading OKRs throughout different IT and business functions. The cascaded OKR grows farther and farther away from the desired Outcome because functions/silos can’t deliver these outcomes. They can only deliver outputs. Hence, the prevalence of Output-based OKRs.

After we define these OKRs the different functions will, of course, try to collaborate but we know how hard it is to collaborate effectively across functions. And with each group focused on an output-based OKR, we lose the opportunity to align around outcomes and are back to managing “projects”. This might work fine for some OKRs. But some OKRs are simply too complex to successfully achieve this way.

OKR-Driven Team Topology

A better approach might be to consider the level of complexity each OKR exists in. Then, create focused cross-functional Scrum Teams around the most complex OKRs. You might call this “OKR Driven Team Topology”.

Each one of these teams would focus on an OKR and have that as their Product Goal. Their Product Owner would have ownership of the OKR. This team would be THE team to talk to about this OKR.

If an OKR requires more people than would fit one Scrum Team consider forming a Nexus (or any other agile team of teams structure) around this Product Goal. Or maybe you can split the Objective and have separate Scrum Teams working on each Key Results (KR). There are multiple possible topologies.

The key point is to try and keep the outcome orientation all the way to the trenches where people work to create usable valuable Increments. In your Sprint Review, Inspect the Increments created with an eye towards your OKR. Adapting might mean changing tactics of how to achieve the OKR or even changing the Key Result or the Objective itself.

OKRs and Focus

The approach I laid out above is the ultimate way to achieve focus on one strategic outcome.

Realistically, not all OKRs would map 1:1 to a team or Nexus. And that’s ok. For example, you might have 20% of your most complex/critical OKRs handled using dedicated teams with the rest of them mapped to existing teams/functions.

If that’s the approach you’re taking, make sure you’re limiting the amount of OKRs that map to each team in each time period. For example, set an “OKR in Process” limit of 3 per team per quarter. And when a team hits the limit, don’t set the OKR for this quarter. This will drive a tough but important conversation about priorities. But it will set the teams and therefore the organization for a better chance to actually deliver on the strategic outcomes that matter the most.

Having 3 OKRs per quarter that you actually achieve is much better than 6 OKRs per quarter that drag on from quarter to quarter.

NOTE: You might find it useful to start tracking flow metrics (WIP, Flow/Cycle time, Throughput, Aging) as they relate to your OKRs…

When to organize around outcomes with OKRs and Scrum

In this article, we explored the relationship between OKRs, Scrum, the teams’ topology, and outcome/output-oriented OKRs (and teams!).

A key step in accelerating agility is to continuously assess whether you’re optimally organized around value. OKRs can provide a very useful lens to use for this assessment.

This is the time of the year when many of you are drafting your annual OKRs. Take this opportunity to consider whether your current team topology (in IT/technology and beyond!) is well-positioned to achieve these OKRs.

Another opportunity to use this lens is If you’re currently trying to figure out what your Scrum team topology should look like (e.g. when starting your agile journey, extending or accelerating it). Considering your strategic focus via OKRs is a great perspective to consider in this process.

A discussion about Strategy/OKRs and how they map to team topology is now a core part of my conversations with clients and our implementation strategy workshops.

Are you trying to figure out how to connect OKRs and Scrum in a way that organizes around outcomes? Feel free to reach out and we can discuss how I might be able to help.

Using Scrum for Improving Operations

I’m encountering more and more people that are trying to solve different kind of problems with Scrum:

  • People designing Consumer Goods
  • Accounting professionals focused on Revenue Accounting
  • Marketers of many kinds
  • Healthcare professionals.

I’ve been having some interesting discussions with them that I thought I might share.

One of the key questions I start a conversation about Scrum with is Why — Why do we need Scrum? What problems are we looking to solve with it?

Next we typically explore Where/When — Where would it make sense to use Scrum? When would it or wouldn’t it?

One thing to remember is that Scrum was designed to help people solve complex problems, not all sorts of problems. What does this mean exactly?

Let’s look at a couple of examples of Complicated processes that might not need Scrum/Agile

Accounting teams run several sorts of processes — like Closing (the month, quarter, year), Reporting, Accounts Payable, Accounts Receivable.

Healthcare professionals treat patients. Whether it is an emergency room, an orthopedics clinic, or a covid19 testing provider.

Should we use Scrum for Operational Processes?

These might be complicated processes but they aren’t typically complex. Lots of steps, lots of work they need to be careful and diligent about, but it’s not something they need Agile for on an ongoing basis.

Hopefully, these operational processes are stable and predictable. If they’re not, we have some work to do. We need to get rid of variability and surprises.

We can use Scrum for Improving operational processes

Where Scrum IS often useful is in the process of continuously improving these operational processes. We know how to run the current process predictably. But once we decide to improve it, this might be a problem we have more uncertainty about — what does better look like? What will/won’t work? How do we go about implementing it?

What we find in many contexts is that people call these improvements “Projects” and its one of the areas they struggle with. Beyond the classic challenges of complex work, we see many cases of teams working on improvement projects that are based on people who also work in the operation. (for example an A/R professional working on a project to improve A/R or a physician participating in a project to implement electronic medical records software). These teams working on improvement “projects” struggle to focus. As we all know, Allocating capacity to improvement is hard. And switching contexts between the day-to-day operation and improvement work is hard as well.

Scrum helps these teams optimize the value they create through their improvement work.

Their “Product” is an improved operation that achieves better outcomes for their stakeholders while making life easier for themselves and their peers.

We want the entire company to be Agile

We hear that more and more. As you can imagine, based on the above, I think we need to be careful and apply the right tool in the right context. Agile approaches make sense in many contexts, and most companies would benefit from applying them beyond software development/technology/IT.

Identifying the different “Operational” flows in the organization and the various “Development/Improvement” activities that work to improve them is a great way to drive a discussion with a company or a leader exploring Agile/Scrum all over the company.

In Summary — Scrum for Improving Operations, not necessarily Scrum for Operations.

This distinction between the ongoing “Operations” where we don’t necessarily need Scrum or Agile, and “Development” or “Improvement” work that aims to improve “Operations” helps people outside of software/technology/IT relate and buy in to Scrum or other Agile approaches. Scrum/Agile are typically a better fit for working ON business operations, versus working IN the business operation.

PS You might find it interesting to read about “Operational Value Streams” and “Development Value Streams” in SAFe, which are similar concepts to what I’m describing here.

Entrepreneurial Operating System® / Traction®- How does it relate to Agile/Scrum?



I’m hearing from more and more companies that are using the Entrepreneurial Operating System® (EOS®) and are also looking at or practicing Agile e.g., using Scrum. In discussions with these companies, two key questions surface time after time:

  • My teams want to use Agile/Scrum — is that aligned with the fact that we’re using EOS® in the organization?
  • My teams use Agile/Scrum; can we use EOS®?

The short answer is that Agile and specifically Scrum and EOS®are mostly complementary.

EOS®, as well as Agile approaches, emphasize focus, alignment, and a disciplined approach with structured events, artifacts, and policies that limit the amount of work in process (WIP) systematically, and create better flow with cadence.

So what’s one big difference between Agile/Scrum compared to EOS®? Transparency and Empiricism

Transparency is emphasized in both but is used differently. Both approaches make the work transparent. Agile frameworks like Scrum are designed to deal with VUCA (Volatility, Uncertainty, Complexity, Ambiguity) through empiricism — an aspect that EOS® isn’t explicitly solving for. And in this environment, Transparency goes much further — it is not just awareness of what the team and individuals on the team are working on — it is the transparency of whether the product of the team’s work (whether the team is building a product or leading a company) is working and effective.

Scrum can help teams:

  • align towards the Vision — making the Vision or a specific sub-aspect of it their “Product Goal” (even if they’re not a Product team — it’s the overarching goal for the product of their work — be it winning deals, operating the company, growing, etc. )
  • plan and deliver on their Rocks and achieve Traction®- by using Product Backlogs, Sprints, and potentially concepts like “Program Increments” from SAFe, which align very well with the EOS®Quarter.
  • EOS® Big Rocks can map almost 1:1 to PI Objectives. For teams, We recommend having them at the team level and not as individual contributor to drive collaborative collective ownership toward results. When scaling across the organization, each team/function does have its list of PI Objectives/Big Rocks like in EOS, as well as an organization-wide list of Big Rocks / PI Objectives.
  • SAFe PI Planning or other types of Big Room Planning could complement EOS®Quarterly planning by involving the actual Teams and not just the function leads in the planning and accountability cycle.
  • Issues are very similar to Risks and how they’re managed in SAFe via ongoing ROAMing (Resolving, Owning, Accepting, Mitigating)
  • Scrum Sprints map to the Weekly Level 10 cycle. Sprint Review/Retrospective/Planning is an opportunity to inspect and adapt where we are within the quarter, which is especially important in VUCA. We’re not just executing a quarterly plan. We’re intentionally learning what works/doesn’t and adjusting course accordingly.

Another opportunity is to use Scrum at the leadership level — as a way to apply more empiricism to complement EOS®discipline.

  • All of the above could be used by the leadership team itself.
  • The “Product Backlog” is focused on the “product” of the leadership team’s work — which is leading the company — solving issues, growing, implementing strategies/tactics, etc. Changes in Process, People, Dealing with Issues, Advancing Rocks.
  • The Increment of each Sprint is not just a “Done / Not Done” answer to to-do items — it’s an actual “working change” in how the company operates. (For example — list of candidates for a VP position, draft scorecard, analysis of desired profitability range, etc. ) This Increment is ready for the leadership team to inspect, review, to adapt their plans (Product Backlog) accordingly every Sprint/Week. A leadership team could also decide to run longer Sprints e.g. Monthly, and use a weekly cycle similar to Scrum’s “Daily Scrum” to inspect and adapt progress within the Sprint. The Sprint length should match the level of VUCA the leadership team/company is facing.
  • The leadership Team acts as the “Developers” of the “Product.”
  • The PO/SM Scrum roles could map several ways –
  • Option 1
  • Visionary — Product Owner
  • Integrator — Scrum Master
  • Option 2
  • Visionary and Integrator™- Sharing the Product Owner role
  • Dedicated coach/Scrum expert as the Scrum Master

Similar to how EOS®starts at the top, Organizations NOT using Scrum yet could use Scrum to complement EOS® at the top level and then expand from there into the various teams.

This would follow the guidelines/mapping described above. In this scenario, solid Scrum Training/Coaching would be provided to the leadership team in advance of the whole organization, and they would become Scrum Practitioners better able to understand and drive what’s going on when Scrum/EOS®gets implemented throughout the organization.

For teams in an organization using EOS®…

If you’re starting to use Scrum in an organization using EOS®or if you’re using Scrum and your organization is in the process of implementing EOS®the list of mappings above will help you create some common language and reduce the conflict/confusion that might arise due to running both EOS®and Scrum at the same time.

Real/Imaginary conflicts between Scrum and EOS®

Is EOS®Waterfall?

The main aspect of EOS®that looks like waterfall is that it runs a quarterly cycle with planning the Rocks for the quarter in advance. I don’t consider that waterfall. And if care is given to making sure that Rocks focus on WHAT rather than HOW and leaves enough space to account for variability/learning, I don’t see a problem. It’s very similar to SAFe’s PI-level planning, which is again properly done with an eye towards emerging learning and adjusting course as needed while staying focused on the high-level objectives for the quarter.

How about individual accountability in EOS®- isn’t that in conflict with Scrum’s “Collective Ownership” approach? Isn’t EOS®in the way of Teamwork?

Indeed this is a potential area of conflict. But even EOS®makes several mentions of the fact that to succeed, team members need to prioritize the team’s rocks over their individual ones and support each other. When implementing EOS®, there should be an emphasis on accountability towards team rocks rather than individual rocks, even at the leadership team level.

Isn’t EOS® Micro-management under a thin veil?

The way to look at this is that EOS®allows teams to micro-manage their work — with the understanding that in a VUCA environment, there’ll be lots of surprises and emerging realities that are better addressed quickly. The Integrator role, like the Scrum Master, should lead the team through this discipline of tight-loop inspection and adaptation rather than feel a need to micromanage work or output. Learning the proper “Leaders who Serve” Scrum Master mindset would be very useful to any EOS leader if he wants to avoid EOS becoming a checklist-based micro-management tool.

Conclusion

As you can see above, as long as you understand the purpose and practices of EOS®, Agile, and Scrum and think about how they can complement each other, you can use them in tandem.

Furthermore – To maximize the effectiveness of EOS, you might want to enhance it with the empiricism / evidence-based management that Scrum provides.

If you want some help thinking through what this would mean in your context, we’ll be happy to discuss it further.

When do CMOs/Marketing Leaders consider Agile Marketing?

In our first post in the series about Scaled Agile Marketing we looked at whether you even need Agile Marketing. In this post we talk about the typical triggers that cause marketing leaders to take a serious look at Agile Marketing.

Scaled Agile Marketing is typically needed as part of a real Agile Marketing transformation — an attempt to achieve a significant change in how marketing is operating. Agile Marketing at the team level is something that can happen bottoms up or in islands in the organization. The point where scaling is needed is typically when marketing leadership decided they need a serious transformation across the marketing organization or at least big swaths of it.

While most of the marketing organizations we see score pretty high on the “do you need Agile Marketing?” scale, Only a few of them then go and do something about it. While many of them agree with Agile Marketing at the concept level, They really need a strong trigger before they take action on it.

So let’s look at a couple of common triggers for a serious Agile Marketing transformation at scale.

New Marketing Leadership

One very common trigger for any sort of change is when new leadership comes in and takes a fresh look at things. Agile Marketing might come about as a result of concerns about competency of the marketing organization or a desire to modernize how things are being done. Poor marketing campaigns results or dissatisfaction from business leaders is a common reason marketing leadership gets replaces in the first place. The new leader coming in hears things like “We don’t know what the marketing organization has been wasting its time on” or “They don’t speak our language, confuse us with their own metrics we don’t care about”.

Another situation is when a new marketing leader is brought in to help scale the marketing organization and realizes that the current structure/process is unscalable, bottlenecked, slow, and reliant on a few “heroes”.

Innovation / Customer Experience

As marketing leaders take on more and more responsibility for the whole customer experience and specifically the whole digital experience, they realize their current slow/siloed approaches are unfit for the pace of innovation and learning needed to “nail” the right customer experience. Being able to close a fast learning loop and run mini “innovation labs” as part of more and more of the marketing organization not just the “cool kids” in the corporate innovation lab is a typical requirement we hear about.

We Tried Agile and Failed

Many people try Agile Marketing in the small by mapping directly from the Agile Development. They send a few people to classic agile training (e.g. a Scrum Master class) or ask some coaches from the development side to help them out. Then a few weeks/months later they’re so confused and struggling that they either throw it away (Which is a shame but isn’t a trigger for a real agile transformation…) or they realize they need to look the things in a deeper more holistic and pragmatic manner.

Need to Scale Agile beyond a few small experiments

Similar to trying and failing, but these organizations tried some small agile experiments and understand they need to look at it differently now that they want to scale it further.

Drowning in work

This is especially popular with middle managers that are trying to make ends meet with more and more workload and the same (or in some cases even fewer) people.

Alignment with the Development/IT/Technology side of the house

As Dev/IT/Technology organizations move to Agile/DevOps approaches, Many marketing leaders feel the need to align their language, process, cadence with the way their peers are working and talking.

Revamping the Marketing Technology Stack

As marketing organizations try to build a modernized marketing technology stack many of them are realizing that they need an effective adaptive process to help deal with these complex projects. Since much of a marketing technology stack improvement project includes technology/development work it makes sense to everyone to use an agile approach for it. This then cuts across to some of the marketing-style work that is associated with the new technology stack, which in many cases brings about a wider discussion about an agile operating system for marketing.

Implementing a new marketing approach — e.g. Social Selling, Content Marketing, Account Based Everything

Trying a new approach to marketing involves a lot of uncertainty and complexity and collaboration across silos. Smart marketing leaders connect the dots and realize Agile Marketing is the right approach for figuring out how to effectively do Content Marketing, Social Selling, Account Based Everything, or whatever new thing you’re trying.

Now that we understand the benefits of Agile Marketing as well as the typical timing marketing leaders look at this, we’re ready for the next post where we will talk about whether you actually need to scale when you move towards Agile Marketing.

Page 2

In earlier posts in our Scaled Agile Marketing we looked at whether you even need Agile Marketing and then what typically triggers a serious discussion about Agile Marketing. In this post we move to the next step — figuring out if you need Scaled Agile Marketing.

So — Do you need Scaled Agile Marketing?

Scaling isn’t just a function of the number of people in the marketing organization. It’s more a function of how many marketers need to work together as part of one customer journey/experience.

Let’s look at an example. In the diagram below you can see a typical marketing organization that would possibly have a need for some scaling approach. They have agile teams that cross-cut the different marketing functions — focusing on delivering marketing value/impact for a specific product/customer journey rather than focusing on a specific marketing function/task.

Map it to your organization. If your teams are truly autonomous and work on separate backlogs and activities with minimal dependency then you might not need a full-fledged scaling approach.

If on the other hand they ARE working on one bigger customer journey, have some dependencies across teams and some floating specialists that need to be involved in multiple teams or are considering synergies and adjacency campaigns (e.g. If you’re using an agile ALM tool you can probably benefit from our Continuous Integration or Portfolio-level tools), a scaling approach would benefit you.

In this context SAFe’s Agile Marketing Train (A name coined in the field for the Agile Release Train in the context of Marketing) with its Program Increment Planning, Single Program Backlog, System Demos provide useful guidance.

Working with Agencies

In many cases marketing organizations work with external marketing/advertising agencies to deliver some of their campaigns or some of the materials for their campaigns. In most cases the way these relationships work don’t map well to “everybody working on one agile team” and some sort of scaling solution is required.

A rising trend is the “Internal Agency” model (see https://hbr.org/2015/07/6-reasons-marketing-is-moving-in-house) in which an internal agency is created as a shared service that supports the various lines of business in the organization. While getting rid of the dependency on an external vendor, this “shared service” presents its own scaling challenges.

SAFe provides a couple of options for how to deal with internal/external “suppliers” — for example they can become separate “supplier” Agile Marketing Train on a bigger Solution Train or a “supplier” team that is a “component”/”specialized” team inside an Agile Marketing Train. In any case SAFe provides guidance for how to involve them in a planning and execution cadence and how to create realistic plans considering their capabilities and availability without forcing them to be members of agile teams (although that is certainly an option and will be recommended in some cases).

Longer-term activities such as events, strategic campaigns

Most agile marketing organizations run a mix of high-tempo testing that is a great fit for agile iterations/flow with frequent planning but also some longer-horizon activities such as conferences, webinars, big product launches, that require more predictability and visibility beyond the “next 2 weeks” that classic team-level agile provides.

SAFe’s combination of high-tempo team-level agility with the Program level with it’s Program Increment Planning, Roadmap, visibility to Features helps deal with this mix of demands from the marketing organization.

There’s a preference for SAFe in the enterprise

In many organizations Marketing is following the product development/management organization into Agile. If product development/management organization chose SAFe as their agile approach, you will benefit from using it as your approach as well.

Same framework means using the same language. Even after adjusting SAFe to a marketing vernacular, it is still SAFe and marketers will be able to understand developers and vice versa.

Same framework means ability to share expertise, knowledge, training. While Agile Marketing isn’t exactly Agile Development a good agile coach or SAFe Program Consultant (SPC) can learn the marketing nuances over time.

Using the same framework means you’re better prepared for the day you will actually bring product development and marketing into the same customer experience value stream. While the typical starting point is for marketing to create “Agile Marketing Trains” focused on the marketing/customer journey value stream, many organizations are executing a “Digital Transformation” which means emphasis on the digital experience that combines both marketing/sales and usage touchpoints. (See Oracle’s Customer Experience Lifecycle for an example)

With this one bigger customer life-cycle in mind, more and more organizations have a vision of creating “Agile Customer Experience (CX) Trains” combining development, marketing, sales and others. These trains are needed in order to iterate and learn at the speed needed to compete in the digital age. Starting from the same or similar framework will ease the transition to these sort of trains — reducing the babel tower effect that might happen otherwise.

If you see a need for agile marketing AND your context fits at least some of these descriptions/environments, you probably need some scaled agile marketing patterns, which will be the topic of our next blog in the series.

Originally published at www.agilesparks.com on July 11, 2017.

To Infinity and Beyond — Achieving Organizational Agility

Agile Development — Just A Starting Point Towards Organizational Agility

For many people Agile is “Agile Development”. They use agile to improve the effectiveness and agility of software organizations. For these people scaling agile typically means developing even larger programs/products with an agile development approach.

Scaling Sideways Towards Business Agility

Scaling agile has another meaning — scaling sideways and handling a wider swath of the technology value stream:

  • First, the process of exploring options and selecting initiatives to focus on and to budget.
  • Then, identifying the right products or features. You follow up the development/build phases with delivery and deployment activities.
  • Finally after delivering working software to real users you can measure, learn and tweak/adjust/pivot.

As you can see, Becoming an agile organization means looking wider not just deeper.

Companies are using techniques such as Design Thinking, Lean Startup, Lean UX, DevOps, Continuous Deployment at various stages of the technology value stream. The challenge is that the lines defining where each approach starts and ends are blurred. There’s also considerable overlap that is confusing those trying to build their “business agility stack”.

For example — is Lean Startup just for the Explore/Identify phase or throughout the life cycle? I think the latter since we talk about a full Build Measure Learn cycle . Is it used in all cases? Probably not — it’s really a function of how much business/requirements/WHAT uncertainty you have. If you’re clear on WHAT to build, you don’t need lean startup and MVPs. You can suffice with Agile.

Similarly for Lean UX — is it a front-end kind of practice? I prefer to look at it as front-heavy but iterative which relies on closing the feedback loop based on experience of real users in the field.

Agile Beyond Software — Enter Agile Marketing

While the technology organization struggles to figure all this out, other areas of the organization are starting their own agile journey — leading to an even wider perspective on what it means to achieve agility at scale. A good example is Marketing. As Marketing organizations face more and more uncertainty and complexity they’re realizing that an approach similar to the one their technology counterparts are using can help them as well. Agile Marketing is the approach being used by more and more marketers to improve marketing agility. Agile Marketing is our fastest growing practice these days, especially in our Boston/US office.

To Infinity and Beyond — Achieving Organizational Agility

What lies beyond for the organization that achieved agility in its key business value streams? agility across those value streams. Think of the organization undergoing a digital transformation that is trying to compete based on a great experience all the way from the awareness stage through consideration, selection, purchase, all the way to using/consuming the service. Great experiences require identifying the right marketing tactics and the right product and more and more these days the lines are blurring between the two. More and more marketers see themselves as stewards of the whole customer experience (CX) not just the buyers journey.

I’m willing to make a prediction — I think we will see more and more MarDevOpsSales teams/tribes in the not so far future — I look forward to those “Big Room Planning” events combining developers, marketers, sales, customer support/success people — all trying to figure out how to work together 🙂

Exit mobile version