Thoughts on Agile Product Management in Large Corporate Environments

Agile software development describes a set of values and principles for software development under which requirements and solutions evolve through the collaborative effort of self-organizing cross-functional teams.

The Agile philosophy is geared towards shortening delivery cycles by engaging business functions, customers and development teams in effective collaboration, and by having a way to quickly identify and act upon when things are starting to go wrong.

I've worked with Agile for the past 10 years in big and small organizations, and I totally agree that Agile methods like Scrum are very effective at helping teams perform. However, such methods do not address any of the issues surrounding teams. And those issues are especially important in large organizations, because while teams usually execute one project at a time - say an Agile delivery -, organizations execute combinations of several projects that may overlap, called programs. Programs require much more coordination than projects, for obvious reasons. 

Most Common Frameworks

There are three big frameworks for executing Agile programs at scale:

• Large Scale Scrum (LeSS) by Craig Larman and Bas Vodde
• Scaled Agile Framework (SAFe) by Dean Leffingwell
• Disciplined Agile Delivery (DAD) by Scott Ambler

LeSS was was developed to scale Scrum upward based on the insight that "Scrum hits the sweet spot between abstract principles and concrete practices". So, LeSS aims at scaling up the activities in Scrum, applying them at the team-of-teams level. 

SAFe is based on the concept of Agile Release Trains (ART), which are long-lived, self-organizing groups that work to define, build and test valuable, working functionality items based on a backlog every 2 weeks. To to this, SAFe relies on multiple levels: Portfolio for governance, funding, and coordination for all the ARTs, Value Stream to support developing large, complex system architectures, Program to run each ART, and Team composed of the Agile teams working with Scrum or Kanban. These levels have defined artifacts and processes to synchronize alignment, collaboration and delivery for multiple teams. Note that at the Team level, SAFe looks a lot like Scrum.

DAD is "a people-first, learning-oriented hybrid agile approach to IT solution delivery. It has a risk-value life cycle, is goal-driven, and is enterprise aware." DAD's priorities are people, learning orientation, Agile and drawing on other sources, especially the Unified Process for governance and life-cycle management. Compared to Scrum, DAD has an Architecture Owner to focus on architecture and technical risk reduction.

Which Framework To Choose?

I think the first philosophic change for a large organization to implement Agile is to value working software in the form of quality releases from short development cycles over comprehensive documentation, and analysis. Probably the second change to embrace is valuing individuals and collective work, and therefore reducing layers of processes, tools and hierarchy to enforce communication and collaboration.

Culture usually follows structure, so organizations with weak Agile cultures or just getting started with Agile will favor SAFe because it does not require such a drastic organizational change as LeSS or DAD do. In fact, managers coming from waterfall frameworks will kind of feel at home with SAFe. The company that's probably closest to LeSS is Spotify.

Personally, I prefer the LeSS framework because it is practical and strives for an organizational design framework with Scrum at the center. My least favorite is SAFe because it's more process-heavy, adding layers of complexity that are harder to reconcile with Agile, and the risk that the core values of alignment and program execution result in top management dictating product roadmaps.

Applying Common Sense

One of the main problems I see in implementing any of the frameworks is that they require a Product Manager type of role to have full ownership of the backlog. Product Managers are supposed to be fully responsible for identifying customer needs, prioritizing features, and developing the vision and roadmap, even within SAFe (at Program level, in that case). However, the reality in large, hardly Agile companies like Nestlé is that authority is shared between Product Managers and Business Owners.

A pragmatic approach to solving this challenge is applying common sense. In my case, what I'm doing is enforcing collaboration and commitment and drawing a clear line in the sand in "who owns what". For example, Business Owners are usually only interested in strategic features, which are captured in user stories, not necessarily in enablers or capabilities. However, those are also part of the Backlog - as well as technical debt - so Product Managers must make sure capacity is allocated in a way that ensures investments are balanced across conflicting needs. By splitting capacity in business vs enablers/capabilities and having each "owner" - Business Owner and Product Manager - prioritized in their split, that need is ensured.

In one of the programs I manage at Nestlé, we have split feature types for each release in strategic - owned by Business Owners - and other, which comprise user insights and structural features including technical debt, fixes, etc., and are owned by the Product Manager. Every time we plan a release, I negotiate the % of capacity that will be allocated to strategic features, and then feature prioritization takes place on each side of the "fence": Business Owners advocate for strategic features in the backlog, while the Product Manager advocated for the rest. This is working pretty well.

Long story short, it doesn't matter how many frameworks to scale Agile are designed: there's no silver bullet. As with anything new, organizations should start with top management commitment and small implementations to gain knowledge and start changing the culture, and with it the structure. Maybe instead of so many frameworks we should all be learning the basics of Agile and using good leadership scale it.