Project Portfolio Management in Agile at Scale

By

What are the changes in Project Portfolio Management coming with Agile at Scale? In addition, what are the benefits and limits in Agile at Scale when aligning Tribes to the related business. At last, how to mitigate these limits?

Table Of Contents
  1. Agile at Scale benefits for Project Portfolio Management and Initiative Backlog when aligning Tribes on main related business
  2. Agile at Scale organization from corporate to tribe level: cascading of strategy, vision and maximizing delegation
  3. Initiative Backlog in Agile at Scale: Tribe initiatives without or with limited contribution
  4. Agile at Scale Initiative Backlog: transversal initiatives
  5. What’s next? Learn more about Agile at Scale

Agile at Scale benefits for Project Portfolio Management and Initiative Backlog when aligning Tribes on main related business

Change of Project Portfolio Management paradigm with Agile at Scale

To start with, we will use the word Initiative (also called Agile Epic) instead of Project to stress out the change of paradigm with the traditional project mode. In addition, we will also use the Agile word Backlog instead of Portfolio for the same reason.

Indeed, Agile allows priority changes. Really, the Product Management Team and the PO maximize the value delivered within the time and the capacity of their perimeter. To do so, the same happens like for the backlog of an Agile Squad:

  • Firstly, the backlogs of upper organizational levels are split in increments, here Minimum Marketable Feature (MMF) or Product Viable Product (MVP).
  • Secondly, the Product Management Teams prioritize, review and validate the delivery of MMF and MVP on a regular basis, usually quarterly or less.
  • Thirdly, the size of the MMF and MVP is such that the teams can build and deliver them within the same time period.

Nevertheless, there is a study phase to frame an initiative defining overall objectives and estimation like in traditional project portfolio management. But the Business keeps the freedom to adapt the delivery with learning and context change.

Somehow, for business as usual, it is closer to the way of deciding: how much are we ready to invest in this given business?

Agile at Scale change of organization impacts Project Portfolio Management

At the beginning of the Agile at Scale transformation journey, IT organization are re-framed to be aligned to the main related business. Moreover, there is a switch of paradigm from Project Management to stable capacity and prioritization within this capacity.

Agile at Scale Project Portfolio Management: from misalignment and need for project management to IT-Business alignment reducing the need for coordination.

As a consequence, this allows the following benefits:

  • Alignment of IT to Business reduces the number of stakeholders and increases the proximity between requestor and builder:
    • Shorter decision line then decision time,
    • Decrease the need for coordination across IT organizations as more than 50% of initiatives are within a Tribe: result is better efficiency and lower cost,
    • Increased flexibility,
    • Improved time-to-market.
  • Switch to stable capacity and prioritization:
    • More efficiency with removal of stop&go and reduction of need for on-boarding and for building new teams,
    • Improved time-to-market with ready capacity.

Note that stable capacity does not mean fixed capacity. The capacity changes on a quarterly basis with the business review on context, trend and adjusted strategy over the next 3-5 quarters. But the capacity needed by recurrent requests is secured and removed from the noise generated in traditional Project Portfolio Management.

In addition, keep in mind that this alignment is never total and there is still the need in some cases for contributions.

Agile at Scale organization from corporate to tribe level: cascading of strategy, vision and maximizing delegation

Agile at Scale cascading of strategy, vision and related budget to support delegation of delivery to Tribes. Transversal initiatives remaining are steered at Business/Support Unit or Corporate level.

Except the alignment of IT to business, the company organization in Agile at Scale, may seem similar to a traditional organization. We are not talking here about the organization within a Tribe.

Nevertheless, there is something quite different. If strategy and vision are cascaded, there is a strong will to maximize delegation for the decisions to be taken at the level where the information is: at Tribe/Product Management Team level or even at Product Owner level (Level 1).

  • The cascading of the strategy and the vision enforces the consistency across the Company and empowers a level to instantiate its strategy and vision in coherence with upper level.
    • Additional guidelines cascaded about the transversal strategy: offshoring ratio, internal/external ratio, travel, other non labor costs.
    • Budget provided to support this strategy, vision and guidelines covers at the same time change and run, labor and non-labor costs.
    • Quarterly reporting from one level to the upper one enforces:
      • Visibility for the upper level to root its decision in the reality of the field,
      • Review that objectives and ambitions are met or not. Indeed, all is about allocating means to the most promising business areas.
  • The maximized delegation supports value, time-to-market, quality and efficiency.
  • As alignment is never total, each Product Management Team, with the support of its Tribe, should identify on a quarterly basis recurrent contributions to book in the capacity of other Tribes for the next 3 to 5 quarters. In case of priority conflict, this escalates to Business/Support Unit (BU/SU) level (2) or even Corporate level (3).
  • Some initiatives are transversal and the Business/Support Unit (BU/SU) (level 2) or even the Corporate level (level 3) steer them.
  • The BU/SU or Corporate level may steer critical initiatives to the BU/SU or Corporate strategy, even if not Tribe or BU/SU transversal.

Initiative Backlog in Agile at Scale: Tribe initiatives without or with limited contribution

Agile at Scale Project Portfolio Management: initiatives with no or marginal contributions from other Tribes are managed at Tribe level with facilitation and coordination by the Lead Scrum Master.

This is one of the big benefit of the Agile at Scale model: with the alignment of IT to related business, many initiatives are within the Tribe. Thus, the delegation of Initiative Backlog is total at the level of the Product Management Team of the Tribe.

  • Some of them require no contribution from other Tribes (initiative 1):
    • No need for coordination outside the Tribe.
    • The Product Management Team is fully autonomous to prioritize the works.
  • Some still have contributions from at least one other Tribe but these contributions are marginal (initiative 2):
    • For the coordination, the Scrum Master of the Agile Squad manages contributions outside the Tribe. If several Agile Squads need to coordinate, then a Lead Scrum Master drives this initiative. For more, see my other post on Agile at Scale coordination mechanisms.
    • In order to make sure that contribution works are prioritized accordingly:
      • The Product Management Team assigns a representative in the other Product Management Team of the contributing Tribe. Then, this representative expresses the need for contribution and makes sure to that works prioritization is consistent in the other PMT.
      • In case of priority conflict, the issue escalates to BU/SU or to Corporate level.

Agile at Scale Initiative Backlog: transversal initiatives

Agile at Scale Project Portfolio Management: transversal initiatives with many contributions require the assignment of a Program Manager with Business/Support Unit or Corporate level steering.

In complex organization, total alignment of IT, and even of business, to Value Chains is not possible. Actually, some business activities are “Supporting” Value Chains and are required to deliver actual Value Chains. To illustrate, Risk or Compliance are examples in the Bank business.

Each time a Tribe delivers more functionalities on a Product or Service, it requires adapting Risk and Compliance Management. In addition, each time there is a major initiative on Risk or Compliance, it impacts all Products and Services. As a matter of fact, this is the usual scenario to trigger a transversal initiative (initiative 3).

  • Depending on the impacted scope, the BU/SU level or the Corporate level steers this transversal initiative. Furthermore, the steering governance dialogs with contributing Tribes to make sure that the needs for contribution are taken into account and that works are prioritized consistently.
  • Additionally to Tribe synchronization mechanisms, a Program Manager enforces the coordination, as it is much more intensive.
  • In some case, a dedicated temporary organization is created. In fact, people remain in their Tribe but some Agile Squads fully work for the Program to secure the delivery of the features. As a result, the steering governance (Product Management Team) of the Program/Train is autonomous to prioritize works consistently with its objectives. For more on Program/Train see my other post on synchronization mechanisms.

What’s next? Learn more about Agile at Scale

Check my other posts about Agile at Scale:

Icons credit:

Leave a Comment

Your email address will not be published. Required fields are marked *

10 − 4 =

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Scroll to Top