Navigating conflicting methodologies in product management

A methodology or framework does not guarantee a great product — far from it.

“What framework should we use to ensure our product’s success?” — A common request by organizations starting their product journey

Product development is complex and uncertain. Yet, many often put all their faith in methodological frameworks to find their path in the dark. As a result, they fail to reach their product’s full potential.

The goal of product management is to deliver the right product in the right way and at the right time. And all products are unique endeavors, never repeated. No two products have the same customers, needs, technologies, or teams to deliver them.

As such, product teams should not follow a methodological framework without modification. Yet, this is what many consistently choose to do. The result? Products crash and burn.

In this article, we will explore the pitfalls of putting blind faith in frameworks. But first, we should understand the common ones in play today.

Common product methodology frameworks

Your product journey has started. You must first face a framework smorgasbord and find an apt approach.

It is no easy feat to navigate the various options. The available frameworks never quite seem to hit the mark. Yet, either through inexperience or exasperation, you select one framework and follow it. With the best intent, you put misguided hope in the framework to lead you to product success.

Let’s understand the most common frameworks in the wild and some of their merits and traps:

• Scrum
• Extreme Programming (XP)
• Kanban
• Large-Scale Scrum (LeSS)
• Scaled Agile Framework (SAFe)
• Waterfall

Scrum

Scrum is a lightweight framework. It is purpose-built for the complexity and uncertainty of product development. Scrum has a foundation of transparency, inspection, and adaptation. In most cases, scrum works best when a single team is focused on a production solution. But it can also work in a multi-team situation.

This framework organizes work into feedback-centric, fixed-length sprints. Each sprint has a standard set of events within that time box. Teams use this construct to create small increments of value with high quality.

Scrum is often criticized for focusing teams on outputs rather than outcomes. It also does not include guidance around ensuring technical excellence. But nothing in the framework excludes having an outcome orientation or high-quality practices.

Extreme Programming (XP)

XP is known for its extreme aspects, hence the name. It excels at driving internal quality and technical excellence. Working in close, daily contact with the customer is central to the XP method.

XP is iterative in nature. And it includes innovative techniques that have withstood the test of time. Some of these techniques include:

• Pair programming
• Collective code ownership
• Frequent refactoring
• Continuous integration
• User stories

XP has never gained the mainstream support it deserves. But it is an excellent choice for keeping technical debt in check. Its close engagement with the customer assures solutions that customers love. Many pair XP with scrum to address scrum’s lack of engineering and quality guidance.

Kanban

Kanban has its origins in lean circles. It was developed by Toyota to ease just-in-time manufacturing. Kanban helps to keep inventories low and optimize the flow of value by minimizing waste.

This approach has gained popularity in software and product development. Support teams or other teams handling transactional, complicated work will often use Kanban. Kanban is frequently used for work that does not need as much iteration to arrive at the right solution.

Kanban focuses on:

• Visualizing the work
• Limiting work in progress
• Creating specific policies for work
• Continuous improvement of the process to optimize the flow of value to a customer

This framework is attractive to many because it meets organizations where they are. It allows them to start with their existing process and incrementally improve it.

---

---

Large-Scale Scrum (LeSS)

LeSS is a scaling framework based on scrum. This framework’s approach to scale is unique. It focuses on scaling with minimally sufficient processes and by descaling first.

LeSS recommends simplifying organizational structures and removing bureaucracy before attempting to add scale. Descaling increases an organization’s ability to deliver value with agility despite its size.

Most of the LeSS framework is focused on a cross-functional feature team. This team can control and own the end-to-end delivery of value to its customer. It utilizes many aspects of the scrum framework at its core.

LeSS has not gained broad mainstream adoption. But it remains a solid framework choice for scale. When many teams need to develop a product with minimal process overhead, LeSS works.

Scaled Agile Framework (SAFe)

SAFe is the most popular scaling framework. It appeals to large organizations who need a non-invasive solution to handle scale. SAFe fits this bill as it does not require them to restructure their entire organization.

SAFe attempts to merge all other frameworks into one, giant framework. It includes explicit, recipe-like guidance every step of the way. The framework uses many levels of planning intake to feed quarterly work to teams to deliver.

Many have criticized SAFe for being a melting pot of framework processes. It has been equally blamed for not creating agility in organizations. SAFe’s heavy process complexity often splits teams from customers, propagating a factory mindset.

Waterfall

Waterfall took hold of the software development industry in the 1970s and never let go.

The other frameworks above are part of the 2001 agile software development movement. Agile arose to move away from the waterfall approach.

Waterfall is a phase-gate, linear, big-batch, planning-driven approach to software development. It assumes minimal learning during the lifecycle of a product. Waterfall is not suited for the complex, uncertain nature of product development.

But this has not stopped many from trying to fit this square peg into the round hole of product creation. It has led to frequent budget overruns, late delivery, and, frequently, failure.

Pitfalls when applying a methodology or framework

Many pick one of the aforementioned frameworks and start running. They hope the framework will apply sanity to product development efforts. Unbeknownst to the ins and outs of the framework, they hit snags along the way.

Each framework, on its own, has blind spots and areas where it does not excel in a product context. Despite this, the application of the framework is usually where things go awry. There are many ways to go down the wrong path with a framework.

Let’s explore four common framework pitfalls you might run into and should avoid:

1. Applying the wrong framework

Picking a framework that’s not appropriate for the way you’re working is a common wrong turn. Many select the wrong tool for the task at hand.

Here are a few common ways the wrong framework gets applied:

Mistaking product development for a familiar, knowable endeavor

Product development is complex and uncertain. Using a framework that does not respect this leads to the wrong product in the end. Even if a framework supports empiricism, one can ignore this and reach a poor outcome.

To illustrate, many choose waterfall with a belief they can predict upfront what to build. Some select Kanban and get perfect at finishing what they start, but they finish the wrong thing. And others incorrectly use scrum by delivering incrementally without iteration.

Product creation requires an emergent, learning-forward approach. Ideally, you should use a framework that supports this. But if you are using one that does not, you must adapt the framework to embrace learning.

Learning early and often must be your technique, regardless of your chosen framework. This is how you chart your unique path to success.

Operating at scale without using a scaling framework

When many teams focus on the same product problem, the question of scaling enters the picture. Yet, typically, the framework selected is not meant for scale.

Scrum, Kanban, and XP are not native scaling frameworks. They can be used at scale. But much of how you scale with them will rely on your scaling expertise and experience level when you use them.

Scaling frameworks may be more appropriate alternatives. But, you should take caution here, too. A scaling framework can at times overcompensate with too much process overhead.

For instance, SAFe can easily lead down a path where process overhead can get out of control. LeSS implementations are also not immune to runaway process complexity. Using LeSS without descaling first is often the cause.

In short, moving to scale is a tricky endeavor regardless of the framework chosen.

Scaling without first descaling

An organization with a complexity tendency will carry this to the framework — it fits like a glove.

When a large, traditional organization jumps into a scaling framework, many traps await. If they don’t first descale their complexity, product development reliably slows to a crawl. Scaling an already unwieldy organization only adds extra, unbearable weight.

To illustrate, many bureaucratic companies select the SAFe framework and change very little. All the structures and policies remain but with different names. What results is what can only be described as renaming the deck chairs on the Titanic.

LeSS might serve these companies better. It includes many methods for descaling an organization’s structure and process. And LeSS recommends doing this first as the path to operate at scale.

Scale requires simplicity first.

2. Focusing on output without value

To state it simply, most organizations have a predisposition for focusing on output. They approach their product sequentially. They generate ideas, create a detailed plan and budget, build the ideas, and launch the ideas.

This leads to products nobody loves, except maybe the builders. And often, not even the builders love them in the end. Learning along the way is absent, avoided, and feared.

When these same companies select a framework, they apply their output-focused mindset. This happens even if the framework focuses on achieving value through learning. As a result, they incorrectly apply a factory mindset to product development.

Factory behavior turns teams into assembly line workers. The teams are cranking out unintegrated increments of work off a backlog. They are not connected to their customers or their stakeholders.

Experimentation and learning are absent in this mode. What results is the monotonous, incremental production output of one thing after another. Innovation and adaptation die here.

I’ve seen countless organizations and product teams fall into the factory model trap. It happens even when using the more empirical frameworks of Scrum, Kanban, LeSS, and XP. And to no surprise, SAFe and waterfall take the factory mindset to the extreme.

Cranking out more output sooner with quality does not matter if it is not what is needed. Learning along the way is a crucial but often ignored aspect in the use of most frameworks.

By not embracing learning, product value becomes elusive, and no framework will help.

3. Following the rule book without adaptation

Many continue to obey the rules of their chosen framework even when the rules are no longer relevant.

When learning something new, everyone benefits from step-by-step guidance. But once new habits solidify, rules are no longer necessary. Improvisation outside the initial rules becomes more beneficial.

Yet, I have seen many organizations chained to their baseline framework for years. They follow the same rules they started with to the letter of the law. Continuous process improvement is non-existent; they are stagnating in their status quo.

---

---

Here are a few examples:

• Scrum teams still ask the three daily scrum questions. But the 2020 Scrum Guide killed this practice
• Kanban teams become experts and visualize their process. But they don’t take the time to inspect and improve it
• SAFe teams keep trying to perfect the quarterly, big-batch planning process. Yet, this technique continues to fail at improving their predictability

Product development is complex and uncertain. It requires a continuously adapted process to address its ever-evolving context. Following the same thing repeatedly is no better than the monotony of a broken record, but many do it anyway.

Learn your way to the right process in the same way you learn your way to the right product. Adapt it continuously to your ever-evolving context.

4. Centralizing decision-making to a select few

Organizations tend to keep tight control over who can and cannot decide — a costly mistake.

Most organizations with at least a handful of employees have a hierarchy in place. And once a hierarchy is in play, decisions become complicated and take longer. Only certain levels can make decisions, elongating and complicating the decision-making process.

The tendency is to centralize important decisions to a select few. And this behavior pattern carries over to product development. SAFe and waterfall in particular embrace this; team autonomy suffers as a result.

Other frameworks are not immune to the tendency to centralize all decisions. I have seen this behavior sink its teeth into scrum, XP, Kanban, and LeSS implementations. It is an invasive, difficult-to-eradicate, anti-pattern.

Instead of centralizing decision-making to a select few, it should be democratized. This will use the wisdom of the crowd to its full effect. Getting those doing the work involved will lead to better decisions and engagement.

All hearts and minds making decisions will improve the effectiveness of any framework.

Taking it forward

There are many methodological frameworks to choose from for a given product context. These include:

• Scrum for iterative, emergent single-team efforts
• Extreme Programming for customer-centric, technical excellence
• Kanban for improving the flow of complicated increments of value
• LeSS for simplified scaling of scrum
• SAFe for a scaling recipe that embraces traditional cultures and structures
• Waterfall for predictive, sequential delivery of complicated, more certain, product efforts

The application of these frameworks is where many often falter. Either the wrong framework is selected, or the wrong thinking is applied to the framework. Common pitfalls include:

1. Applying the wrong framework to our needs.
2. Getting stuck in an output rut and not iterating to reach the right outcome.
3. Following the framework by the letter without adaptation.
4. Putting too much faith in centralized intelligence to guide the product path.

So, instead of picking a framework and hoping for the best, we should be more mindful of our context. We should select simple techniques that support a whole team approach to emergent innovation based on evidence. Then, we must change our own behavior to ensure we don’t misapply the framework.

Product success does depend on the framework you pick. But more importantly, it relies on your ability to adapt to your ever-changing context.

Featured image source: IconScout