Agile's Big Problems in Big Companies

When rollouts bump up against an organization’s culture, progress can stop. It turns out, old behaviors and practices can appear as a brick wall to Agile methodologies.

?The Corporate Brick Wall

Well-versed Agilists are quick to blame the brick wall for perceived shortcomings. They say the root cause of problems is because companies didn’t set up the Agile mindset fully.

But here’s the issue. The experts say companies only gain Agile’s full benefits through “transformative implementations.” It’s when an entire organization takes on the Agile mindset. That includes?top managers, not just the project doers. Such rollouts demand significant change and any problem that results is not Agile’s fault. The problems are because the organization didn’t make the right changes[i].

Agilists blame backlashes against the methodology on top management’s unwillingness or inability to change. It’s leadership’s fault, not Agile’s. They didn’t embrace Lean-Agile Leadership. Really?

Top Management Buy-In

If the issue is with top managers, then you can’t help but ask, “what’s stopping management’s buy-in?”

Buy-in. That’s the missing component causing Agile’s problems according to many Agile proponents. Curiously, you’ll hear the same complaint from experts in other processes and methods. Buy-in is not just an Agile hurdle.

Consider how companies can realize notable gains from automation or cloud-based marketing initiatives. The same is true for?diversity?and digitalization. Indeed, there’s a long list of initiatives that may boost a business’s performance.

Everything Needs Buy-In

When we listen to experts in these other areas, we hear them say they also need management’s buy-in[ii]. Of course they do; every initiative does. You have to wonder how much buy-in there is to go around.

Perhaps buy-in isn’t how to describe the issue. Teams can’t flip a switch to gain buy-in. Instead, the critical challenge is to figure out how to earn mindshare across top management teams.?Agile is competing with every potential initiative. The question may be whether Agilists are tackling the mindshare challenge correctly.

Agile Pilots in Large Companies

Take a step back and look at the most common approach to setting up Agile. It’s simply to pilot a?project or two and then roll out the practice.

The first step is to train a group of project doers and pilot Agile practices on a few development projects. Most Agilists have experience doing this for software projects. But in large companies, you’ll find typical developments are not solely software. They’re more likely to integrate the software with tangible products and services,[iii]?often creating complex systems.

The combination projects set up a problem for evangelical Agilists. They need a hybrid Agile-Waterfall approach, not Agile methodologies alone.

Burden or Benefit?

In a purely Agile pilot, teams will ring-fence the projects from day-to-day operations. The purpose is to remove these projects from old practices. It’s these old practices, the Agilist tell us, that hurt development efforts. Agile purists call it “burdensome bureaucracy.[iv]” This statement is intentional.

Perhaps unknowingly, the statement also declares that no benefit accrues from old-school standardization aided by a Waterfall approach. While shunning rigidity in large companies is positive, negating the leverage of standards[v]?is not. The upshot is that pushing an “Agile or none” approach to all developments may stamp out good standards and undermine management buy-in.

?Declaring The Win

No matter how you work out the Agile-Waterfall challenge, the big step in any process and method rollout is to declare the benefits of the new approach. This leap forward means discounting any gains from ring-fencing the project. And then make the case that it’s a simple decision to do away with the slow, non-flexible project approach and set up the new Agile-centric methods across the entire organization.

But think about the pilot. Is it the best way to gain top management commitment and mindshare?

The biggest implementation problem is to change the organization. Yet, the piloted Agile project runs apart from the organization’s other processes and practices that may or may not link to development.

Ring-Fencing

A?ring-fence?pilot doesn’t probe or test how the change should occur — even when change is the most significant concern to those at the top. To declare Agile’s benefits based on such pilots suggests that by merely snapping your fingers, the old methods and behaviors go away leaving the Agile manifesto to rule the day.

Plus, there’s another even bigger issue. Agile implementation teams assume scrum and fast feedback benefits – speedier product success at lower costs – are precisely what top managers want the most. Sure, top managers in big companies want faster product development. But they have their eyes on a bigger prize, something they want more than faster developments:?higher stock value.?

Change in big companies, as Agilists lay it out, can be a significant threat to a top manager seeking to carry out her job effectively. And if there’s a struggle between Agile and top managers driving shareholder value, who do you think will win?

Gaining Mindshare

How can Agile win the mindshare battle? The answer may seem divorced from the issue, but it’s not. It’s to understand the jobs that different parts of the organization do and the results they seek. For product developers, the job is to realize faster success in the market for each product. The job is to conquer crucial DevOps challenges[vi]. But top management’s job is much different.

Gaining mindshare demands more than saying Agile delivers successful products faster, and therefore top management should be pleased. You gain mindshare by helping executives do their job better. Unless you can draw a straight line between Agile methods and shareholder value, it’s hard to win over senior managers. And as far as I know, there’s no such line.

Stock analysts sometimes site fast development speed as critical to how big companies operate. But they seldom call out Agile as a critical value-driver. This is where Agile comes up short.

Large Company Value

Gaining buy-in within large companies will remain a challenge without convincing analysts and top managers that Agile drives shareholder value. And to do this, the Agile approach must yield improved customer delight and increased cash flow. Plus, it must create stellar positioning over competitors.

Yet, a big problem remains. Agile doesn’t guarantee notable gains in these three improvements. Now, with Agile being around a few decades[vii], you’ll need to show these gains when your competitors are also using scrums and backlogs.

The dilemma for Agilists is their guidance may help deliver a product faster and at a lower cost, but it doesn’t always drive shareholder value.

SAFe? Advancement

An expansion of the traditional Agile approach seeks to solve the dilemma. It’s called SAFe, which stands for Scalable Agile Framework[viii]. The decade-old add-on is the most significant tool Agilists have developed to fill the gap.?Recognize that experts say it’s essential the Framework evolves. Managers shouldn’t treat SAFe as a static set of practices laid on top of Agile project management. Don’t expect to drop it in place without a need for changes and advancements.

?Lean Portfolio Management

At its core, SAFe leverages Lean Product Development and Portfolio Management. The Framework guides implementation teams to engage top managers in overseeing product road maps and portfolios.

The SAFe approach encourages executives to focus on value streams. And by doing so, we’re told, it helps Agile methodologies become the robust solution large companies need.

Streaming for Customers

A value stream in the SAFe’s lexicon is the flow of value to customers. This value flow isn’t direct to shareholders. Presumably, experts think shareholder value is an indirect consequence of customers receiving value and that driving shareholder value needs no special attention. Optimizing customer value streams will optimize shareholder value. But does it?

For large companies, SAFe correctly expands Agile to embrace programs, the portfolio, and road maps. Yet, in its current state, SAFe has two critical problems.

SAFe Problem 1

The first problem is that orchestrating everything in the Framework does not make it easy to diffuse Agile thinking across a large company’s C-suite.

Consider the list of topics top managers will need to learn. The list includes Kanban workflows, scrums, canvases, themes, release teams, epics, enablers, and portfolios. It would be a unique company with top managers in every function, from sales to research, finance to HR, and throughout operations, well-versed in these topics. This gap makes the buy-in challenge difficult.

SAFe Problem 2

The second problem is that the SAFe-Agile combination is incomplete. Like portfolio management, lean or otherwise, it focuses on project execution. The Framework doesn’t shape strategy or create new ideas. Or better stated, it doesn’t do so deliberately.

By stressing project execution and high-level decisions like budgeting, the Framework expects two foundational pillars to be in place. First, a strategy will exist. And second, stellar idea creation and project selection will take place before “execution work” begins. This thinking doesn’t mean SAFe bemoans strategy or concept creation. Instead, it means SAFe doesn’t go as far as it should to create, form, and shape the best set of products to drive shareholder value.

Excellence without Strategy

In its current state, The Scaled Framework doesn’t work to form or reshape strategy, at least not purposely and deliberately. And it doesn’t guide companies to create a set of developments that purposely drive gains, build synergy, or make bold strategic moves. Nor is SAFe designed to help top managers decide if one strategy with its collection of projects is better than another.

But SAFe does help managers spot problems and impediments to gaining shareholder value. These challenges will show up in spades at portfolio and roadmap reviews. Unfortunately, this is after the fact. If the Framework is revealing problems, the condition already exists.

These critical issues leave the current state of Agile and SAFe poorly suited to build senior management buy-in.

Shareholder Value Connection

Agile and SAFe don’t tie workflow and outcomes to shareholder value. They’re more about telling top managers what to do than enabling them to do their primary job better. Remember, those at the top made it there based on their skills and abilities. Why would they feel more empowered to do their job by embracing new Agile methods and giving up what they know?

Recognize the?Product LINE, not just the Product

The tie to shareholder value starts with understanding strategy. Here, the key is how this higher level of thought plays out across sets of products, not just one product at a time.

A?multi-product systems[ix]?approach affects shareholder value directly. Its gain is far greater than that from orchestrating agile development one product at a time or promoting independent customer value streams. This more robust approach focuses on an entire set of inter-related products defined as a?product line[x]. It’s not the sum of disparate new product projects.

Product lines, guided by?strategies and execution roadmaps, drive shareholder value far more than Agile project excellence carried out one product at a time.

?Product Line Strategy and Shareholder Value

Three critical drivers connect product development to shareholder value. And they do so directly, regardless of a company’s mindset, Agile or not.

Driver 1 – Customer Satisfaction

The first driver is Competitive Positioning. It’s the deliberate positioning of products to grow market share and block competitors from taking share.

Agilists will argue these gains come from faster product development. That’s true to a degree, and good Competitive Positioning demands each development project to realize Agile’s benefits. Teams must carry out each project quickly and cost-effectively.

But Competitive Positioning goes farther. It requires the products to work in unison to boost one another and fend off competition. The coordination across products and markets is critical because the competitive game is more than an Agile race. Speed matters, but positioning does too.

Notice how gaining share and blocking competitors work together. In strategy, we refer to such positioning as creating a competitive Moat. Warren Buffett made this term famous. You’ll find investment advisory services dedicated to evaluating competitive Moats[xi]. A “wider” Moat rating means higher shareholder value. It’s a direct link.

?Driver 2 – Cash Flow

The second factor is cash flow or, better stated, growth in Free Cash Flow. Shareholder value ties direct to future cash flow, but not just from one product. It’s the cash flow from a product line’s entire set of products and projects that matters.

Doing great with one product but poorly on others can cause difficulty. These are cases where you can’t use Agile to scrum your way out. The issues are not about how teams carry out development. The problem is with the characteristics of the products and the reasons they exist. Solutions to these issues go beyond the skills of many talented project managers and Agile experts.

Most product lines have components and approaches to drive top-line revenue and help control costs, the contributors to cash flow. These include components such as platform-levers, multi-generational planning, and reusable technologies[xii]. Teams must advance and exploit these contributors at the product line level, cutting across products. The cash flow gain is at the product line level. There’s no gain doing this for only one product.

The multi-product nature of product lines challenges Agile thinking. To realize cross-product gains, product line teams must exploit project flexibility while adhering to strategy-imposed design standards[xiii]. Achieving these gains are why combining Agile with Waterfall methods is so important to large companies, and critical to improving shareholder value.

?Driver 3 – Customer Satisfaction

Customer Satisfaction is the third value driver. It’s a measure of how much customers enjoy an entire product line, not just one product. Consider it the star count in a five-star rating for the product line. If this measure slips or doesn’t improve, you’ll find shareholders voting with their feet. And if it’s strong and getting stronger, you’ll enjoy healthy shareholder support.

To maximize product line outcomes and results, teams must continue their Agile approach. Quick customer and stakeholder feedback is terrific for each project individually because it drives up the customer appeal of that product.

The product line, though, demands more. Here, teams and managers must hone their understanding of attribute-satisfaction tradeoffs well before developing project parts and confronting technical challenges. This work demands deep customer satisfaction analyses[xiv]. The job is to probe potential attributes[xv]?and backlogged features at the product line level. It’s to assess all products, potential and existing, against all segments.

When product line strategies mature or begin to fail, total customer satisfaction will falter. This is often due to normal life cycles, competitive shifts, and changes in customer needs. Not surprisingly, Agile’s single-product orientation makes it difficult to respond to these change. Such responses, whether small adjustments or major pivots, demand coordination across the entire product line. When tackling such change, Agile joins old-school processes to become the burden.

Product Line Velocity

The flow of product line results can be represented by a single measure known as the?Product Line Velocity[xvi]. It combines the three value drivers – Competitive Positioning, Cash Flow, and Customer Satisfaction.

Simply knowing these three factors and setting up the Product Line Velocity metric isn’t enough. Top managers must have a multi-product view if they wish to tie product development to shareholder value. And this view must be from beginning to end. It’s about an entire flow of investments, insights, concepts, and products.

Leaders must guide the flow using sharp?Strategic Thinking?applied to the product line.

The?flow?starts before the usual beginnings of both lean product development and agile approaches — before concept development, gemba value creation, and experimentation. It begins with learning and insight building. The flow then couples to strategic thinking, more insight building, and forming targets for concepts.

?Beginning the Flow

The beginning of the flow is crucial. It sets the value of all work that follows. A poor start that creates independent products implies a turbulent flow toward increased shareholder value. The turbulence happens as project adjustments and decisions are hurried to correct projects and their relation to one another. Agile can speed up the projects but can’t increase the inherent value of the entire project set.

A good start will yield coordinated projects and products with a more laminar flow. Agile then speeds it along.

Equally important, the flow extends through product retirement and end-of-life reviews. This extended flow is essential because life cycle management can significantly affect cash flow and customer?And observing and analyzing the extended flow is critical to organizational learning and insight building.

The product line flow includes more than development projects or programs. It also involves targets for innovation, key insights, and market segments. And it incorporates advancements for platforms, technologies, and design standards.

Responding to Forces

Plus, managing the flow demands orchestrating responses to?forces?that both drive and hinder the velocity. These forces always include customer likes and dislikes or the appeal of all the products. But there are far more forces affecting outcomes. Other influences include competitors’ moves, economic shifts, and regulatory changes. Plus, you’ll also see brand engagement and customer experience critical to the flow.

Most managers in big companies could quickly plot a web of both positive and negative influences on the flow. Often, the web center is the alignment (or not) of organizational functions not involved directly on project teams. These functions include every group in the company. But sales, marketing, operations, and IT frequently float to the top of the list.

Aligning the Flow

Such alignment or misalignment affects whether the flow is?fast and laminar or slow and turbulent[xvii]. Unfortunately, most project managers can’t address internal alignment issues.?Instead, that task should be part of management’s governance and oversight role. In strategy execution, however, a management team must recognize alignment challenges before initiatives begin. Spotting such issues after the fact does not help increase velocity or shareholder value.

Strategy matters a great deal when products and offerings relate to one another. This inter-product connection is the common thread that forms?product lines.?Yet unknowingly, the Agile and SAFe approaches don’t recognize nor purposely engage with product lines as strategic entities.

Check it for yourself. You’ll see Agilists offer only a vague description of how projects connect to business strategy.?Instead, Agile and SAFe seek to tie individual development projects directly to?business?strategy. This might be sufficient for small companies with one dominant product, but it’s not helpful in large enterprises with many complex and intertwined offerings, often driven by separate business units.

?Mix-Management and Prioritization

SAFe espouses traditional mix-management and prioritized resource allocation to orchestrate a project portfolio. These are core tenets of lean portfolio management. And they seek to link project prioritization and the portfolio mix to business strategy. But recognize how this approach is not about creating or reshaping strategy deliberately.?And product lines are merely part of the discussion, not the central theme with velocity directed OKRs[xviii].

In their current form, Agile and SAFe treat business strategy as a “given” — one not to be messed with. This split between projects and strategy aggravates Agile implementations by creating a bigger divide between project doers and top management.

Red Queens’ Race

There’s much written as to why Lean, the foundation of SAFe, isn’t in itself a strategy.[xix]?Consider how Toyota, the?epitome?of Lean, compares to Tesla, the near antithesis of Lean. At year end 2020, Tesla’s calculated shareholder value was greater than the combine value of all other automotive companies, Toyota included. For many Agilists, especially those supporting SAFe, this fact is best hidden when trying to win top management buy-in.

Over the last several decades there was much low hanging fruit to be gained by embracing operational excellence. Companies did this by tackling Lean, Agile and other DevOP techniques. Now, with nearly every company pushing time-to-market, Lean, and Agile, the DevOp challenge is like an Alice in Wonderland Red Queens Race. To paraphrase Lewis Carroll: “Here, you see, you must run as fast as you can to stay in the same place”

You’ll find the solution to the Agile-Strategy problem lies in product line strategies, not business strategy. But to make such strategies usable in the DevOp world demands a clear understanding of?product lines as systems[xx].

?The Product Line System

Systems thinking reveals certain?parts?and?forces?that drive the product line’s performance[xxi]. The job is to orchestrate this system to boost the Product Line Velocity. Strategy is about how you pull that off.

Product Line as a System[xxii], called?PLaaS?, introduces a new level of thought to the Agilist’s toolbox. It enables a fast flow of product line outcomes directly connected to shareholder value. Strategies purposely seek to drive this critical flow and remove hindrance and bottlenecks before they happen.

A product line system is not just the roll-up of individual projects. Nor is it just a portfolio view of projects and programs underway. Instead, PLaaS builds on projects and portfolios to form coherent oversight of the system parts and the responsive work that influences or reacts to the forces.

It’s in the Roadmap

The difference between the current Agile product roadmap and a product line systems roadmap tells the story.

The?PLaaS roadmap[xxiii]?is a set of graphics that captures those parts and forces that drive a product line toward improved shareholder value, including pre-concept analysis and insight shaping through post-retirement reviews. The roadmaps Agile teams use today focus on project management, backlogs, and timing. They don’t focus on the product line parts and forces. The PLaaS roadmap presents a critical view of product line dynamics and the flow of influences and forces.

?System, Strategy, and Velocity

The link between?systems thinking and strategy is important. A key systems principle is that not all parts and forces are equal. The principle tells us a small set will control the system’s performance. The limited set is far more impactful than the other parts and forces combined. Focusing on and amplifying these few parts and forces is the essence of a strategy.

A PLaaS approach purposely determines the make up of the product line system and the critical parts and forces that drive its performance. Forming a strategy is then a matter of figuring out how best to shape the system and drive its key parts and forces to gain the maximum velocity.

PLaaS drives velocity by aiding managers to coordinate strategy moves, products, markets, technologies, and organizational work. And it connects these activities to top management’s core job: improving shareholder value. PLaaS, therefore, is a needed step, beyond Agile and SAFe, in securing top management buy-in.

Bottom-up, Top-down?

Once you realize the importance of product line strategy in driving shareholder value, the Agilist’s current approach to secure buy-in looks increasingly futile. Implementation teams can’t solve Agile’s problems by pushing Agile’s lexicon on top management. In some large companies, that’s more like demanding management get frontal lobotomies than change their mindset. The problem in big companies isn’t a bottom-up issue. It’s a top-down issue that starts with the strategy, specifically, product line strategy.

Tying the bottom to the top demands organizations link a mindful Agile approach to intelligent systems thinking[xxiv]. That way, Agile enables better execution of a product line strategy. Companies need this skill to carry out brilliant strategy moves that drive product line velocity. It’s what gains management mindshare and buy-in.

?Rethink Agile for Lager Companies

Agilists need to rethink the whole of what they wish to achieve in large companies. They shouldn’t limit themselves to pursuing excellence in one-off project management. With SAFe in its current state, the Agile approach will continue to fail to integrate with a meaningful strategy.

More is needed. And it’s precisely what product line systems bring to the table. If you want to bridge the gap between Agile and Strategy to gain management buy-in, it would be wise to learn more about product lines as systems.

?????????

Help and Resources

You’ll find a list of resources on our website, including, videos, blogs, and white papers. And for those who wish to be fully knowledgeable in product lines as systems, please consider our certified training. It provides deep learning to help you leverage new knowledge and drive powerful gains to products, product lines, and your career.

???SAFe is a registered trademark of Scaled Agile, Inc.

????PLaaS is a trademark of The Adept Group, Inc.

References

[i]?Lack of Support for Agile: Over the last few months I’ve read three different Agile blogs bemoaning top management buy-in.?PMI recognizes the issue, Certification seek to address buy-in, and Agilist pontificate on the issue. Top management buy-in is Agile’s most pervasive struggle.

[ii]?Every other initiative also demands buy-in. An interesting twist is the number of business improvement approaches that place the Agile title in front of nearly every functional area – Agile Marketing, Agile Finance, Agile HR.?Each is asking for management buy-in.

[iii]?Digital-Tangible-Service Systems: The software to hardware system is quickly evolving. IoT is accelerating the change. Plus, SaaS models coupled to human services is making notable gains. In large companies, its becoming harder to find purely digital, tangible or human service offering.

[iv]?Burdensome Bureaucracy is the title Agilists give to the old-school waterfall rigidity. Recognize how this “put-down” is a biased statement that there is no such thing as “Beneficial Bureaucracy”.

[v]?Leveraging standards is critical in large companies. Standards enable product components to match technologies and to enable developments to go quickly. Standards help companies avoid the chaotic nightmare of always “reinventing the wheel.”

[vi]?DevOps is the intertwined relationship between development and operations (creation, production and in-market management.) It’s focus is on operational excellence, not strategy formation or strategy responsiveness.

[vii]?Agile Manifesto was created in 2001. Since then, its diffusion exploded throughout the software world while gaining credibility and use in developing digital-tangible systems.

[viii]?SAFe??is a registered trademark of?Scaled Agile, Inc. SAFe was created by Dean Leffingwell. Foundational thinking in support of SAFe was introduced in Leffingwell’s book “Agile?Software Requirements”, published in 2011.

[ix]?Multi-product vs Single Product: Most product development approaches are based on the Single Product Paradigm that prevails in industry and academia. See?https://adept-plm.com/multi-product-thinking/???and?watch the webinar at https://adept-plm.com/on-demand-webinar-the-impact-of-multi-product-thinking/

[x]?Product Line Definition-?https://adept-plm.com/product-line-definition-1/

[xi]?Moats – Morningstar Investment Advisory?https://www.morningstar.com/

[xii]?Product line strategies and roadmap components:?https://adept-plm.com/eight-important-facts-about-product-line-strategies-and-roadmaps/??and??https://adept-plm.com/what-is-responsive-roadmapping/

[xiii]?Platform-levers and design standards:??https://adept-plm.com/platform-levers-and-product-line-strategy/

[xiv]?Jobs-to-be-Done segmentation and understanding customers:?https://adept-plm.com/jtbd-verb-based-segments-product-lines/

[xv]?The term attributes refers to both tangible and emotional gains to customers.

[xvi]?Product Line Flow and its Velocity:??https://adept-plm.com/process-flow/

[xvii]?Chain-link alignment:??https://adept-plm.com/chain-links-and-product-line-strategy/

[xviii]?OKR stand for?Objective and?Key?Results.

[xix]?Harvard’s famed business strategist Micheal Porter argued several decades ago that operational excellence is not a strategy. Porter’s claim has proven correct, but no one predicted how long operational excellence as the main stay of big companies would play out. The next few decades won’t look the same. Companies shouldn’t expect operational excellence to be the dominate force behind all performance gains.

[xx]?Product Lines as Systems:?https://adept-plm.com/product-lines-as-systems/

[xxi]?Product line system parts and forces are detailed in?https://adept-plm.com/product-line-system-parts/???and????https://adept-plm.com/product-line-forces/

[xxii]?PLaaS is an acronym for Product Line as a System

[xxiii]?PLaaS Roadmaps:?https://adept-plm.com/roadmapping-the-roadmap/

[xxiv]?Thinking modes: Systems Thinking, Strategic Thinking, Design Thinking are distinct modes of thought. Mindfulness and deep insights come from overlaying and integrating these thought modes.

?