Portfolio Management in an Agile Context

Team

DNB has taken a significant step from a project-oriented to a product-oriented operating model. At the center are cross-functional delivery teams with end-to-end product responsibility—from idea and design to development, delivery, and continuous support. The principle of “you build it, you run it” gives teams ownership and autonomy throughout the product lifecycle.

Funding is provided through a fixed capacity model, ensuring stability and predictability. This allows team members to be 100% dedicated to their product, without being split across multiple projects. The result is less context switching, higher productivity, and better quality.

By working backlog-based, teams can pull the work that creates the most value—when they have the capacity. This flips the traditional model: instead of moving people to the work, the work is moved to the people.

Teams are held accountable for the outcomes they create—it’s the results that matter. How they get there, and which frameworks or methodologies they choose to use (such as Scrum, Kanban, or others), is less important. The freedom to choose how they work allows for adaptation, learning, and continuous improvement, while keeping the focus on what truly matters: creating value for the customer. However, this freedom must be exercised within clear boundaries, with shared rules of engagement to ensure flow and avoid bottlenecks when teams collaborate.

Portfolio Family

As the wall between IT development and IT operations is broken down at the team level, we take an important step further: we group teams into so-called portfolio families. This is a more agile and value-driven way of organizing work, where technology and business merge in shared priorities and deliveries. What DNB calls portfolio families is often referred to elsewhere as value streams or product areas.

A portfolio family consists of several teams working closely together toward a common goal. They have mutual dependencies—whether related to technology, business, or customer needs. In practice, this is a team-of-teams, where we gather the necessary skills and capabilities to deliver value end-to-end—from idea and development to operations and continuous improvement. Technology and business meet in a shared language, supported by common goals and incentives, where insights, data, and customer needs guide prioritization.

Teams within a portfolio family should have a high degree of autonomy, with the freedom to make decisions and adapt to customer needs. At the same time, the portfolio family ensures that teams move in the same strategic direction. It’s about balancing local empowerment with holistic value creation.

Portfolio

Portfolio families are grouped into larger portfolios, which are collections of portfolio families with a shared overarching purpose. At the portfolio level, the goal is to align multiple portfolio families through clear objectives and missions, enabling coherent and coordinated value creation across products and solutions.

Portfolio leadership must take a holistic view: understanding how different products and solutions interconnect, how they support strategic goals, and how to best prioritize and manage capacity to maximize value for customers and the business.

This structure connects technology and business across the entire organization—from operational to strategic levels. Teams have their “home” in the line organization but are grouped into virtual portfolio families and portfolios, where business and technology jointly own a shared set of goals, capabilities, and associated products and solutions.

Each portfolio has its own focus area and delivers value to different parts of the organization. Some portfolios target specific customer segments, others deliver shared capabilities across segments, and some provide common services that support the entire enterprise.

For both portfolios and portfolio families, we strive to live by three key principles:

• They should have a clear focus (be strong in a defined area)
• They should be genuinely end-to-end
• They should have as few dependencies on others as possible

Achieving this in practice can be challenging, especially when dealing with tightly coupled technical architecture. On the journey toward becoming an agile enterprise, the goal should always be to break these dependencies—not just coordinate around them. We will come back to this point later in the article.

Portfolio Management

Portfolio management is carried out locally within each portfolio by a dedicated portfolio leadership team. This team is responsible for optimizing priorities and investments across portfolio families and ensuring that capacity is used where it creates the most value within the products and solutions the portfolio owns.

In addition, we have a central portfolio management function with a mandate to take a holistic view across all portfolios. This unit contributes to strategic coordination, shared prioritization frameworks, and optimal capacity allocation across DNB’s entire portfolio landscape.

As mentioned earlier, the portfolio management function can either be a bottleneck or an enabler on the path to delivering value more frequently and with greater precision. Below, we explore three common pitfalls that can undermine the effectiveness of portfolio management—and how to avoid them.

Pitfall 1: Technical Quality and Architecture Are “Just an IT Thing”

We all want to deliver solutions that create real customer and business value. That’s why we’re here—to meet needs, create impact, and contribute to organizational goals. But when all attention is focused solely on functionality, and technical quality and architecture are deprioritized, we undermine our ability to deliver future value in an agile way. Systems become fragile, technical debt grows, and teams lose the ability to work quickly and independently.

Without continuous technical improvement, we build monoliths and complex systems that require coordination across teams and value streams. This hampers flow, increases risk, and makes autonomous and efficient delivery difficult. It’s ambitious to call yourself an agile organization if you continue to manage such dependencies without actively breaking them down.

Agile frameworks like the Scaled Agile Framework (SAFe) have emerged to manage these dependencies at scale. They can provide useful structures for coordination and planning but often address symptoms of deeper technical and organizational challenges. By investing in agile enterprise architecture—and actively reducing dependencies—the need for extensive frameworks can be minimized. Frameworks like SAFe can be a good starting point, but they should not be the final destination.

What You Should Do Instead

• Measure and visualize the balance between different types of work
  Ensure the portfolio has visibility into how capacity is spent—on features, bug fixes, risk management, and technical improvement. Visualization provides insight and enables steering toward a healthy balance over time.
• Create incentives for holistic prioritization
  Portfolios should be rewarded for thinking both short-term and long-term. This requires a team effort between business and technology, jointly prioritizing immediate customer and business value alongside investments in technical improvement and modernization.
• Empower enterprise architects
  Give architects a clear mandate and responsibility to resolve dependencies between value streams. Use modern principles such as:
• Event-driven architecture – for loose coupling and fast response
• API-first design – for parallel development and clear interfaces
• Domain-driven design – to create clear areas of responsibility and reduce complexity

Modernizing and reducing technical debt is not a cost—it’s an investment in future value creation. Sometimes you have to slow down to speed up.

At DNB, we monitor how our capacity is distributed across different types of work—such as business development, modernization, and compliance. This is visualized in a dashboard that provides a simple and updated view of how efforts are allocated. It can be viewed across all portfolios, at the portfolio level, and down to individual portfolio families.

We also have dedicated architects in each portfolio who actively promote modern architectural principles. They help untangle technical knots and reduce dependencies—so teams can work more autonomously and deliver faster in the future. To ensure we’re actually simplifying the architecture over time, we also track the number of service domains. This gives us a concrete measure of architectural complexity and allows us to monitor real progress in building more scalable and robust solutions.

Pitfall 2: Measuring Outputs Instead of Outcomes

A common pitfall in portfolio management is focusing on outputs—the tangible “thing” being developed—rather than the outcomes the work actually creates. In the context of portfolio management and prioritization, we should be less concerned with which products and features portfolios are developing, and more focused on the impact these deliverables have on customers and the business.

Paradoxically, some organizations use activity-based outputs to measure how agile they are. Instead of assessing whether they’re achieving better business results, they measure the number of standups, sprint lengths, story points, or how many teams use tools like JIRA. This provides a picture of activity—but not of impact.

A well-known example is Nokia, which at one point measured its agility using a “Nokia test” based on Scrum practices. Teams held standups, worked in sprints, and had product owners in place—everything looked right on the surface. This was just before they made several strategic missteps and sold their mobile division to Microsoft. They did Agile, but they weren’t agile.

This illustrates the importance of not losing sight of the outcomes we’re optimizing for. Agile, Lean, and DevOps are tools—not goals in themselves. Measuring agility through activity alone can lead to a false sense of progress, where you believe you’re moving forward while actually standing still. Agility is about delivering meaningful value faster and more sustainably—not about following rituals.

What You Should Do Instead

We should shift our focus to outcomes—what we actually want to achieve. There are two categories of outcomes we should measure and improve:

1. What – The impact of what we deliver
   This refers to the value we create for customers, users, and the business. It could be increased customer satisfaction, higher revenue, improved market share, reduced carbon emissions, or enhanced public safety. These outcomes are typically tied to strategic goals and purpose—they’re the reason we do the work. Measuring what we achieve provides insight into whether we’re delivering value, not just activity. It helps validate hypotheses, understand customer needs, and adjust direction. Without such goals, we risk delivering a lot—but little that truly matters.
2. How – The way we work
   This refers to the quality and efficiency of our work processes. Here, we measure flow, time-to-value, technical quality, security, and team well-being. These two categories—what we achieve and how we work—are closely linked. When we improve how we work, we get faster feedback, higher quality, and more engaged teams, which in turn leads to better what outcomes. This creates a positive cycle, and it’s important to establish metrics in both categories.

If we only focus on how we work, without considering the impact we create for customers and the business, we risk building features no one uses—just faster. And if we only focus on what outcomes, without improving how we work, we may end up with an organization that learns and adapts more slowly.

At DNB, we use OKRs as a management tool to prioritize what we want to achieve. In addition, we’ve developed a dashboard that provides insight into how we deliver value. Here, we measure key indicators such as flow time (time-to-value), flow velocity (how much value we deliver over time) and flow load (how much work is in progress simultaneously).

Pitfall 3: Locked into the Plan—and the Money

The final pitfall concerns planning and funding initiatives in a non-incremental way—often through a single, upfront allocation based on the assumption that the entire solution and its value are known in advance. This reflects a traditional waterfall approach, where the future is predicted at the point when we know the least. The result is often speculative business cases and rigid plans that hinder learning, flexibility, and adaptation along the way.

Of course, there are situations where a waterfall approach is appropriate—like when building a bridge. Everything must be planned in detail before the first concrete is poured, because there’s no room to change direction midstream. Once the bridge is complete, it’s essentially “done,” and there’s little new value to be gained by adding functionality. This stands in stark contrast to knowledge work and digital solutions, where value creation is continuous, unpredictable, and often dependent on learning along the way. The same code is never written twice, and the insights gained through usage and feedback are crucial for creating real value.

Does this mean we should stop planning ahead? Absolutely not. Seeing the long-term direction is important—but it’s about planning smarter. Instead of locking into detailed solutions early, we should focus on goals, desired outcomes, and hypotheses about value. Funding should support an iterative approach, where we invest in smaller units of independent value and adjust course based on what we learn.

There are certainly initiatives that don’t lend themselves easily to short-term outcome-based steering. Large modernization efforts, such as platform replacements or addressing technical debt, can be difficult to break down into small, valuable deliveries. In these cases, a certain degree of holistic planning and long-term investment is necessary. But even then, it’s important to have clear hypotheses about future impact and to establish reference points that provide insight and guidance along the way.

What You Should Do Instead

• Break large initiatives into smaller units that deliver independent value and learning
  Small initiatives provide faster feedback and make it easier to see whether you’re on the right track—and whether capacity is being used where it creates the most value.
• Link initiatives to OKRs to ensure direction and impact
  Each initiative should be clearly connected to the organization’s Objectives and desired Key Results. This provides direction, simplifies prioritization, and ensures that efforts contribute to strategic goals—not just local optimization.
• Fund incrementally based on actual value
  Instead of requesting all funding upfront, invest step-by-step—based on what actually delivers value. This allows for learning and adaptation along the way. Teams must be able to demonstrate that what they’re working on creates value—not just delivers functionality. This requires transparency and insight into goals and impact.
• Dare to “cut the tail” when value is missing or already sufficient
  If an initiative doesn’t deliver the desired impact, have the courage to stop it and prioritize something with greater potential. This means ignoring sunk costs. Similarly, we should also have the courage to stop further development of a product once it provides sufficient value, and redirect our efforts toward what has the highest opportunity cost.
• Plan ahead—but focus on goals, not solutions
  Long-term planning is still important, but it should focus on desired impact and direction—not detailed solutions that limit adaptability.

It can be challenging to strike the right balance between steering based on goals, desired outcomes, and hypotheses about value — while also planning and coordinating enough to identify technical dependencies across teams. Architecture and complex inter-team connections require a certain level of planning to ensure flow and avoid bottlenecks at the intersections where multiple teams need to collaborate. One of the most important responsibilities of a central portfolio management function is to help portfolios identify and resolve these dependencies.

At DNB, we aim to combine long-term direction with agile adaptation. We have a bi-annual strategic planning process that allows us to look ahead, see the big picture, and define the outcomes portfolios should contribute to. Here, goals are set, major initiatives are broken down into smaller units with independent value, and priorities are sequenced over time through roadmaps. This process is combined with regular big-room planning events at tactical and operational levels, where teams and leaders come together to coordinate dependencies and ensure delivery progress.

Incremental planning and funding require courage—because we love predictability, even when it’s an illusion.

To summarize. Agile portfolio management is about building an organization that continuously learns, adapts, and improves. It requires a willingness to challenge established truths, experiment, and learn along the way.

The journey toward becoming an agile enterprise is not linear. It consists of small steps, adjustments, and insights that gradually build a more value-driven and adaptable organization. At DNB, this journey has largely been incremental—and we’re still on the way. Portfolio management plays a key role in this development, not as a control function, but as a strategic enabler and facilitator.

There are many great sources of inspiration, several of which have influenced this article. For DNB employees, the first stop is our ITOM Portal.

Further reading:

On technical quality and architecture:

• Accelerate by Nicole Forsgren, Jez Humble, and Gene Kim
• Project to Product by Mik Kersten

On outcomes over outputs:

• Sooner Safer Happier by Jon Smart

On incremental funding:

• EDGE: Value-Driven Digital Transformation by Jim Highsmith, Linda Luu, and David Robinson
• #noprojects: A Culture of Continuous Value by Evan Leybourn and Shane Hastie