Agile Portfolio Management Topics: Data gedreven portfoliosturing

Rini van Solingen en ik schrijven een boek over agile portfoliomanagement. wij spreken hiervoor met verschillende bedrijven om vast te stellen hoe portfoliomanagement in de praktijk wordt toegepast,

wat er goed gaat en waar de volgende stappen liggen. Wij doen daarbij aanvullende literatuurstudie en bundelen dit met hun ervaringen. Alle interessante bevindingen delen we niet pas aan het eind in het boek, maar ook al tussentijds in blogposts en/of artikelen. 

Aanbeveling: Voed portfoliomanagement met échte data

Neem portfoliobeslissingen op basis van data en bewijs, in plaats van op basis van meningen en aannames. Het kort cyclische ritme van agile teams biedt de mogelijkheid data snel te leveren. In de praktijk is dat soms wel aanwezig, maar vaker niet dan wel. Portfoliobeslissingen zijn dan hele grote experimenten waarbij pas na de lange en grote investering duidelijk wordt of de keuze juist was. 

Echter, agile teams zijn in staat snel experimenten uit te voeren op strategisch ideeën. Hierdoor ontstaat een korte feedbackloop tussen portfolioniveau en uitvoeringsniveau en wordt de kwaliteit van portfoliobeslissingen snel sterk verbeterd. Portfoliomanagement kan dan bottom-up worden verrijkt. OKR’s bieden bijvoorbeeld goede handvatten daarvoor met de passende mate van onzekerheid. De te gebruiken data kan op een transparante wijze en voor alle betrokkenen in de organisatie toegankelijk worden gemaakt. En aanvullend is een obeya een hulpmiddel dat hierbij goed kan helpen en zorg draagt voor inzicht, transparantie en daadkracht.

Hulpmiddel: Sturen met behulp van OKR’s

OKR’s helpen om op een gestructureerde wijze naar doelen toe te werken. OKR is de afkorting van Objectives & Key Results en is een raamwerk om strategische doelen mee te stellen en te verbinden met de praktijk. OKR is in de jaren ‘70 ontwikkeld door Intel en wordt binnen vele organisaties gebruikt. Eerst bepaal je de doelstellingen (objectives) en leg je de link met meetbare resultaten (key results). Vervolgens beschrijf je activiteiten om deze doelstellingen te behalen door het realiseren van die meetbare resultaten.

Binnen organisaties worden OKR’s op verschillende niveaus ingericht waarbij OKR’s op een lager niveau bijdragen aan OKR’s op het bovenliggende niveau. Bijvoorbeeld organisatie, team en persoonlijk niveau. Op deze wijze kunnen organisatiedoelstellingen vertaald worden naar team-, en individuele doelstellingen. Doelstellingen worden idealiter zo SMART mogelijk gedefinieerd. Het is aan te bevelen om het aantal doelstellingen en bijbehorende key results te beperken (vuistregel max 5 doelstellingen en 3 key results per doelstelling).

Hulpmiddel: Inzicht, transparantie en daadkracht middels een obeya

Obeya betekent letterlijk ‘grote ruimte’ in het Japans. Een obeya, of (virtuele) ruimte wordt gebruikt om de link te leggen tussen de strategie en doelstellingen van een organisatie en de activiteiten die nodig zijn om die doelstellingen te realiseren. Het hebben van een obeya maakt consistente, coherente en effectieve besluitvorming mogelijk en werkt motivatie verhogend voor alle betrokkenen.

In het boek Leiderschap met Obeya laat Tim Wiegel zien dat in een obeya de vijf belangrijkste verantwoordelijkheden gevisualiseerd worden in verschillende borden: Leid succesvolle strategieën, lever waarde, acteer en reageer, verbeter prestaties en los problemen op. Hij benadrukt daarnaast dat het alleen hebben van deze informatieborden niet tot resultaten leidt. Daarnaast is het cruciaal dat teams een aantal gedragsprincipes volgen waaronder: denken in systemen en eigenaarschap en het doorlopend blijven verbeteren.

Commentaar/aanvullingen

Trots op een eigen hulpmiddel of aanbeveling met agile portfoliomanagement? Wij horen graag.

Review Agile Portfolio Management

There are not that many books on agile portfolio management, so I am curious what the book Agile Portfolio Management – A guide to the methodology and its successful implementation “knowledge that sets you apart” written by Klaus Nielsen, offers.

The book is divided into nine chapters, starting with project portfolio management, and ending with case studies on agile portfolio management. In between chapters explaining agility at scale, agile portfolio management, differences between project portfolio management and agile portfolio management, hybrid portfolio management and implementing and tailoring agile portfolio management.

Every chapter starts with the same overview figure. It shows 6 circles representing 6 topics where one or two circles are highlighted. I have no clue what the author wants to express. The first two topics/circles are the first two chapters. The third chapter is the fifth circle. The fourth chapter is the fifth topic/circle. Chapter 6 refers to the third topic/circle, chapter 8 Tailoring agile portfolio management refers to topic/circle 4 Tailoring portfolio management and topic/circle 5 Agile Portfolio management. 

The first chapter Project Portfolio Management explains in detail the financial approach within traditional project portfolio management. Based on PMI’s Standard for Portfolio Management several financial models like PV, NPV, FV, ROI, IRR, PP, DCF, BCF, PI are explained as well as the continuous stages as initiation, planning, execution, optimization and monitoring and control. Set-up of the chapter is somewhat difficult to follow. All the information can be found in 28 sub paragraphs of the last paragraph 1.7. Explanation of a specific financial model or portfolio governance or stakeholder engagement are all separate sub-paragraphs. I miss structure.

The next chapter The reality of Agility@Scale is more a chapter on lean thinking and principles. Important for agile portfolio management but looking at the title I was expecting something different. In this chapter a brief explanation of the Stacey Matrix and the Cynefin Framework, lean thinking and lean portfolio management (using the theories of the Toyota way, Womach, Larman and Vodde, Reinertsen, Poppendiecks, …), continuous planning, and innovation.

Chapter 3 Agile Portfolio Management starts with an explanation of the Agile Manifesto and underlaying principles. The twelve principles are expanded including (portfolio) practices. 

In many paragraphs a table has been used showing Portfolio Life-Cycle Stages (initiation, planning, executing, optimizing, monitoring and controlling), Portfolio Kanban (funnel, review/analyzing, portfolio backlog, implementation, done), Projectized and Recurring. There is no reference in the text or explanation. This table comes back, in exact the same form, multiple times. I would say that only table 3.9 The Portfolio Kanban High-level Overview makes sense. In total 20 times the same table except the title of the table in the field Projectized or Recurring. Even the title is sometimes wrong (same as the previous table). I have no clue and what this says about the quality of the book?

Some paragraphs, e.g., stakeholder analysis is discussed in too much detail (this is not different from PPM stakeholder analysis). Regarding risk management I can make the same remark, there is only a small sub-paragraph regarding a risk burndown chart and risk-based spikes. What I am missing are the real agile portfolio risks. Portfolio risk management is more than the sum of initiative or project related risks. Other topics which are typically Agile portfolio management e.g., portfolio value, portfolio metrics and reporting are lacking details, and the benefits of agile portfolio management is not explained. I have my doubts if a tool-driven portfolio reporting approach is an indication for a medium to high agile maturity. Unclear why the paragraph Exploring EDGE is positioned here, because in the next chapter agile portfolio management frameworks are explained.

Chapter 4 covers several (agile) portfolio management frameworks like SAFe, LeSS, AgilePfM, Nexus, DA (notice that DAD only covers the delivery life cycles), Scrum, XSCALE, Enterprise Scrum, RAGE and the Spotify model. The author mentioned that the latest version of SAFe is 5.0. It’s 5.1 but that is not what bothers me. The description of SAFe talks about the value-stream level (after version 4, it is called large solution). There are now three levels: portfolio, large solution and essential and not team, programme, value stream and portfolio. I would expect that the portfolio level was discussed in more detail, e.g., the portfolio Kanban, portfolio canvas and participatory budgeting. Table 4.3 Levels of SAFe shows the Conformity Rating for LeSS. 5 pages further, we can find table 4.4 Conformity Ratings for LeSS which shows the SAFe key terms! 

To refer to LeSS Huge for the agile portfolio aspects is not correct in my opinion. LeSS Huge is there if we need more than 8-10 teams to develop and maintain one product. Finally, the Spotify Model is explained. A pity the author didn’t discuss the Spotify Rhythm model with company beliefs, company, functional and market bets boards which is more related to agile portfolio management.

Chapter 5 compares Project Portfolio Management and Agile Portfolio Management. In chapter 1 it is stated that MoP is long overdue and the PMI’s Standard for Portfolio Management lifecycle is used to structure chapter 1. In chapter 5, it is stated that MoP is one of the best Project Portfolio Management standards and MoP is used to build comparison tables with Agile Portfolio Management (high level, key activities, roles, and documentation). Why no consistency throughout the book? I missed a paragraph explaining the Obeya room concept as an agile portfolio management artifact to replace the portfolio dashboard. 

I don’t believe that you can use the Stacey matrix, Cynefin model or the PRINCE2 Agile Agilometer to choose between project portfolio management or agile portfolio management. This only works if all your projects are the same (e.g., simple) and I guess you will have simple as well as complicated or complex projects in your portfolio.

The next chapter talks about hybrid portfolio management. Too short if you ask me. For me hybrid portfolio management is something you need when you have to select, prioritize and allocate initiatives to permanent agile teams responsible for the development and maintenance of specific products and services and/or to one-off temporary projects, to deliver your portfolio’s objectives. Resource management is two-fold. Individual resource capacity management for the temporary projects and up and down scaling of permanent agile teams. Et cetera. The author combines project portfolio management with agile portfolio management resulting in 6 different flavors: standard PPM stage-gate in combination with agile ways of working between the gates, with agile teams (each team is handled as a project), with projects using temporary and agile teams, with an agile framework or agile portfolio management with plan-based projects or with a combination of projects and agile teams.

Chapter 7 focusses on the implementation of agile portfolio management by describing the top 10 challenges and suggested actions for implementing agile portfolio management:

• Defining large-scale agile framework concepts and terms
• Comparing and contrasting large-scale agile frameworks
• Readiness and appetite for large-scale agile frameworks
• Balancing organizational structure and large-scale agile frameworks
• Top-down versus bottom-up implementation of large-scale agile frameworks
• Over-emphasis on 100% framework adherence over value
• Lack of evidence-based use of large-scale agile frameworks
• Maintaining developer autonomy in large-scale agile frameworks
• Misalignment between customer processes and large-scale agile frameworks
• Ensure people and process issues do not steal the show.

How to and the importance of tailoring agile portfolio management is the next chapter. The intro, before paragraph 8.1, is eight pages long, without empty or white lines! A bit of tailoring could make it more readable. Is the author now talking about tailoring the agile portfolio (selection or adjustment of initiatives) or tailoring the agile portfolio framework itself? What makes an agile portfolio different from a portfolio? Next a three-step tailoring process is discussed (initially tailoring based on the organization, tailoring based upon the content of the actual portfolio, and continuous tailoring of the portfolio).

The last chapter shows nine (brief) case studies on some degree of agile portfolio management. 

Too much traditional PPM theory, instead of agile portfolio management theory. And the case studies offer not enough practical aspects. Sometimes I review books and it’s clear that these books are self-published. This book with unbalanced chapters and paragraphs, inconsistency, the issues with the figures, blurred figures, misspelled names, typos, and wrong numbers, gives me the same impression but it isn’t. I would have expected more from the author’s publisher to improve the quality. Sorry to say, but I can’t recommend this book.

To order Agile Portfolio Management: bol.com

Bimodal Portfolio Management

Introduction

At the moment, many organizations are in the middle, or on the brink of, a radical change to more business agility. I receive quite often the question how to cope with both an agile portfolio as well as a more traditional portfolio with temporary projects and programs. Existing frameworks supports either an agile IT portfolio or a more traditional portfolio, but I haven’t seen frameworks which supports both.

If I look at existing traditional and agile IT portfolio management frameworks, I asked myself if combining these frameworks can bring an answer for those organizations who need to manage an agile as well as a more traditional portfolio?

In this article I will start with a brief explanation of the existing portfolio management frameworks by explaining the principles and the process (Management of Portfolios, Standard for Portfolio Management, Disciplined Agile Portfolio Management, Agile Portfolio Management, Evidence-Based Portfolio Management, and SAFe Lean Portfolio Management).

In the second part of this article I focus on Bimodal Portfolio Management where I combine the best of these worlds and offer a solution for both worlds in the form of a Bimodal Portfolio Kanban (see figure), Bimodal Portfolio Management Principles and Bimodal Portfolio Roadmaps.

To download the article: Bimodal Portfolio Management (article, 190626) v1.0

 

Review: AgilePfM – Agile Portfolio Management

The Agile Business Consortium has given detailed insights in the Portfolio Innovation Hub as part of their Agile Business Change Framework by publishing the book AgilePfM – Agile Portfolio Management (Editorial team: Barbara Roberts, Peter Coesmans, Peter Measey and Steve Messenger).

This pocketbook focuses on management of a single portfolio and is divided in 13 chapters (a supplementary Complex Agile Portfolio publication will follow).

AgilePfM is centered on six core behaviors:

1. Focus on the creation of value
2. Review the portfolio continuously
3. Involve the right people to shape and manage the portfolio
4. Clearly and continuously demonstrate that the portfolio is delivering optimum value
5. Encourage innovation and creativity
6. Encourage collaboration and empowerment

Besides the explanation behind the behaviors we get an overview of different organizational challenges and corresponding agile portfolio management guidance.

AgilePfM use some basic concepts of an innovation hub, an agile portfolio process, maturity of the initiatives within the portfolio as well as horizons for an agile portfolio. See the attached AgilePfM Quick Reference Card.

To download: AgilePfM (QRC, 171213) v1.0

The portfolio process is divided in four steps:

• Step 1 – Confirm portfolio drivers
• Step 2 – Confirm portfolio foundations
• Step 3 – Deliver the change
• Step 4 – Keep it current – Reassessing strategy and portfolio alignment

Without a strategy, it makes no sense. The VMOST (Vision, Mission, Objectives, Strategy, Tactics) is explained as well as some points to consider when creating and managing an agile strategy. For effective agile portfolios, the following rules should be considered:

1. If it’s in the portfolio, it must be in the strategy
2. If there is no strategy, STOP! DO NOT proceed without one
3. Constantly review the portfolio and adjust when required. No one-off exercise!
4. Concentrate prioritizing, blending, balancing on the near-term horizon

Initiatives can be divided based on their maturity within the portfolio:

• Unformed, nebulous ideas
• (Future) immature, starting to have some shape
• (Future) ready, clearer and prioritized
• Current, value being created
• Completed, value being tracked
• Reality, value delivered to the organization

In a separate chapter, several areas of consideration are given to help you formulate an idea generation process (defined and communicated method, respectful and open-minded evaluation of every idea and an idea must be treated as any other initiative)

The expected context of the rolling wave portfolio plan is dynamic and will change as events occur, both inside and outside the portfolio. The portfolio considers three horizons:

• Longer-term horizon (from a few months to several years)
• Near-term horizon (typically a few months)
• Today (snapshot view).

A separate chapter explores the budgeting dilemma and what agile budgeting means including the relation between portfolio and budget and how budgeting aligns with the six core behaviors. Agile portfolio management emphasizes the importance of the delivery of value

Several roles can be distinguished in the portfolio innovation hub. In the model, we see two groups: The influencers, stakeholders and beneficiaries and on the other hand the core change participants.

The first group delivers the business change and innovation leadership for the portfolio and strategy and for each individual initiative the business change ownership as well as the change coordination. Often known as the portfolio board. Idea generation can come from anyone in the organization.

The core change participants deliver change support, change co-ordination, change analysis and expert guidance. This group can be seen as the portfolio management team or portfolio office.

Effective agile portfolio governance ensures the portfolio remains aligned to the overarching strategy and goals of the organization. The following principles will help to achieve this:

• Ensure value drives priority (do the right things)
• Never compromise quality (Do the things right)
• Decide with the initiatives, don’t manage them
• Give clear considered direction
• Stay informed

Conclusion: When we think of portfolio management we often think of more traditional portfolio management as described in Management of Portfolios (MoP, AXELOS) or the Standard for Portfolio Management (PMI). When we look at agile portfolio management we find some guidance in the portfolio SAFe configuration and Disciplined Agile (DA). AgilePfM offers a combination of both worlds. The concepts of initiative maturity and rolling wave planning horizons make sense. The rules and behaviors are a combination of the more traditional and the agile ways of working. I miss the set-up of a portfolio Kanban board to visualize and manage the flow (by using WIP limits). This is absolutely a pocketbook that is worth reading.

To order: AgilePfM – Agile Portfolio Management

Agile Portfolio Management Framework

In one of my previous blogs I wrote about ‘Agility by delivering changes as ‘business as usual’

In that article I created a list of aspects to take into account when designing an agile portfolio management framework. In this article I expanded and re-ordered the list and I summarized it in a picture. I updated the original article too.

Agile Portfolio Management Framework:

Strategy assessment

• Internal and external environment assessment (SWAT)
• Portfolio management must facilitate sustainable business change (People, Planet, Prosperity, Processes, and Products)
• Strategic objectives setting
• Develop strategic themes.

Direction Setting

• Portfolio vision, goals and objectives
• Portfolio management facilitates innovation as part of the roadmap
• Portfolio management must move away from the iron triangle and focus on delivering value, capacity and time-to-market
• Close cooperation between enterprise architecture and portfolio management (addressing enabler epics (NFRs, technology drivers, innovations) to be part of the roadmap) to invest in (digital) technology to win, serve and retain customers
• Portfolio management will have large impact on strategic decisions (achievability, technology trends).

 Selection

• Funding at value streams or permanent agile teams level and not at project or programme level
• Funding must be aligned with the strategy or strategic themes. Enlarge or lower the number of agile teams must take place to align with the strategic themes
• A short simple business case justification must be used to put epics on a portfolio backlog
• The portfolio backlog epics must be prioritized based on attractiveness, risk or opportunity costs, time criticality and the duration. The weighted shortest jobs first (WSJF) from SAFe is a good example. Standish ‘Law of the eatable elephant’ is in line with this.
• Epics can be business related as well as non-functional
• Epics must be head and heart-driven, not just head-driven
• Keep epics as small as possible but it must contain more than one feature
• Number of epics in the roadmap must be WIP limited.

Planning

• Portfolio plans will be replaced by a portfolio backlog with epics and a rolling-wave portfolio roadmap (Roadmaps include six key elements: time frame, prioritized and identifiable outcomes, strategic themes, context-specific content, dependencies, investment outlay)
• Starting point for a portfolio roadmap must be a portfolio vision
• Rolling-wave portfolio roadmap must be a living document. Only the first part must be committed to make sure changes can be embraced
• Portfolio roadmaps must have a cadence or heartbeat to increase throughput and integration moments/milestones to create learning loops
• Portfolio roadmaps must show retrospective events
• Portfolio roadmap achievability must be based on (group of) team(s) velocity and not on optimized resource utilization. 100% resource utilization will lead to a lot of busy persons but no delivery!
• Portfolio roadmap must be approved by senior management and communicated to the organization
• Must be a continuous integrated portfolio planning process with regular strategic reviews (included fact-based feedback loops) and pivot when needed
• Portfolio roadmap development includes strategic option analysis / scenario planning.

 Delivery

• Portfolio dashboards must show the funding of value streams (and permanent agile teams) and the alignment with and budget allocation across the strategic themes
• Portfolio dashboards must show progress on epic level. Details of epic break downs in features and user stories are not for the portfolio level (respect the decentralized decision making)
• Focus must be on delivering value / benefits and not on OTOBOS (On Time, On Budget, On Scope)
• Possible portfolio dashboards Key performance indicators and metrics (not limitative): productivity (feature lead time), agility (predictability, number of releases), quality (satisfaction, #defects), metrics for self-improvement, time to market, NPS
• Use timely, accurate, and relevant information based on real time (automated) performance data, avoid manual aggregation
• Portfolio dashboards must show data-driven recommendations for decisions
• Portfolio dashboard reporting at anytime
• Dependency management on epic level (inter and intra dependencies)
• Doing the right things (metrics on effectiveness), Doing it right (metrics on process efficiency). Compare over more than one period
• Customer feedback to evaluate the effectiveness of the roadmap
• Portfolio dashboard reporting creates transparency and will motivate stakeholders
• Integrated tooling (EA and PPM) must give real time insights (rich information) about the health of initiatives, capacity and what-if scenario analysis corresponding with the requester’s role.

Behaviour

• Senior management commitment (much more leadership, less management)
• Decentralized decision making
• End-to-end transparency
• Inspect regularly and adapt where needed
• Feedback is crucial
• Empowered employees
• Culture of collaboration (remove silo’s).

Looking forward to your comments and adjustments so we can co-create a new Agile PfM Framework.

Agility by delivering changes as ‘business as usual’ (extensive version)

Organizational agility developments

Many frameworks use the model ‘run the business’ (permanent teams doing the work) versus ‘change the business’ (work will be done by temporary groups of people). Projects and programs are managed via ‘change the business’. We see project and programme managers bringing people together for a definite period of time to make this happen. But in many cases we are confronted with budget overruns, delays and unhappy customers because what is delivered is not what they really need. As a reaction on these unsuccessful projects a group of people created the agile manifesto, and based on that several agile delivery frameworks were designed to help to deliver more successful projects.

This agile manifesto is embraced by many organizations and these organizations started to keep the people together who delivered e.g. a new system. These teams are able to deliver changes much faster by using Scrum, Kanban etc. These small focussed agile teams are self-organizing and are continuously learning to deliver more with the same people and within the same time-boxes. Collaboration is the norm. What these teams are delivering is managed by a product owner. It is the product owner who prioritizes the work to be done by maintaining a backlog with potential features and user stories. For these teams we don’t need a project manager to bring people together and structure and control the work. The members are already together, are self-organizing and can be seen as part of the ‘run the business’ side of the organization.

So for those changes that can be managed by a single agile team there is no need for a project manager. But in many occasions you need more than one agile team to implement the requested change. We need to scale up from a single agile team to many agile teams. The Scrum guide (developed by Ken Schwaber and Jeff Sutherland) gives some directions to use the scrum of scrums to align the teams and to make integration into one solution possible. In practice this works well for just a few teams, but what do you need if you have to make use of several component and feature teams to deliver one integrated solution? Scrum of scrums is not enough, you need a project manager to manage all stakeholders, all dependencies, the complexity and to deliver one integrated solution. Several organizations are on this level. They still run projects and project managers will make use of these permanent agile delivery teams.

Probable you could ask yourself, why do I want to make use of a temporary project manager? Is it not possible to have a permanent, maybe virtual, structure to take care of stakeholder management, dependency management and integration and have as a result a more or less continuous flow or at least short delivery cycles of changes bringing into production without ramping up and down project governance structures and teams.

You now see that several frameworks to support this level are being developed and used by many different organizations. To mention a few: Nexus developed by Ken Schwaber, Scrum at Scale developed by Jeff Sutherland, SAFe developed by Dean Leffingwell, the Spotify model copied by several organizations, Less developed by Craig Larman and Bas Vodde and there are many more. If you have implemented one of these frameworks the need for a project or programme manager will decline but on the other hand they can take new roles like roadmap manager, integration manager, release train engineer, value stream engineer.

Does this mean we don’t need any more project or programme managers? I think for the coming years we definitely need project and programme managers. In those cases, where we need more than the already existing permanent teams we have to build these non-existing teams. And these teams can of course make use of agile ways of working or just choose the for them most appropriate delivery method. If there is a need for a piece of specialist work we must select the right people and bring them together to deliver. This is typically a task for a project or programme manager. If you want to transform your organization, open new product/market combinations, integrate departments, or merge different organizations I expect that most of the organizations will not have permanent teams in place to handle this.

To support this way of working we see frameworks on project level (PRINCE2 Agile, DSDM AgilePM and PMI APM) and at programme level (MSP and DSDM AgilePgM). The competences of these project and programme managers have to change. where in the traditional way of working the focus was on project results using a formal mandate we now see a shift to business results realized by using influence without power. Stakeholder management becomes even more important with a focus on empathy, negotiations and persuasiveness. Servant leadership becomes key.

Here too, I see developments to reduce this type of project management work. Where we first saw integration of development and operations people into DevOps teams we now see the first BusDevOps multi-skilled teams where product management, marketing, development and ops people are in the same team and as a consequence again less projects and project managers.

Scrum or Kanban?

During the first part of a product life cycle the uncertainty is high and the focus is on goal driven iterations for the first product launch and market fit product. During this part of the life cycle Scrum is a great fit to cope with uncertainty and product iterations developed by the whole team. During the rest of the product life cycle the amount of uncertainty and change gradually declines. Here Kanban is a good fit. User Stories will be realized in a continuous flow by one or more of the individual team members.

When a major product upgrade has to be delivered by the whole team Scrum could be a better choice for that goal oriented iteration, otherwise Kanban stays a good fit.

To avoid the error prone handover and to shorten the time to market the Development and Operations teams can be integrated. Kanban is a good fit for the DevOps team. When to start with DevOps varies.

Agile portfolio management

Does this have consequences for portfolio management too? At this moment I have not seen any mature agile portfolio frameworks. The first framework that includes the portfolio level is the SAFe framework and DSDM included an agile portfolio management paragraph in their little book The Agile PMO.

In one of my previous posts I already proposed a change in the MoP framework to include the ‘run the business’ permanent agile teams in the portfolio view. If we want to reach more business agility, I strongly believe that we have to decentralize decision making. If we don’t and still want to make decisions at a higher more central level Standish ‘Cheetah’s Law’ is applicable and the speed of decision making could obstruct delivery success.

So for me the following aspects need to be taken into account to design an agile portfolio management framework:

Agile Portfolio Management Framework:

• Strategy assessment
  • Internal and external environment assessment (SWAT)
  • Portfolio management must facilitate sustainable business change (People, Planet, Prosperity, Processes, and Products)
  • Strategic Objectives setting
  • Develop Strategic themes
• Direction setting
  • Portfolio vision, goals and objectives
  • Portfolio management facilitates innovation as part of the roadmap
  • Portfolio management must move away from the iron triangle and focus on delivering value, capacity and time-to-market
  • Close cooperation between enterprise architecture and portfolio management (addressing enabler epics (NFRs, technology drivers, innovations) to be part of the roadmap) to invest in (digital) technology to win, serve and retain customers
  • Portfolio management will have large impact on strategic decisions (achievability, technology trends)
• Selection
  • Funding at value streams or permanent agile teams level and not at project or programme level
  • Funding must be aligned with the strategy or strategic themes. Enlarge or lower the number of agile teams must take place to align with the strategic themes
  • A short simple business case justification must be used to put epics on a portfolio backlog
  • The portfolio backlog epics must be prioritized based on attractiveness, risk or opportunity costs, time criticality and the duration. The weighted shortest jobs first (WSJF) from SAFe is a good example. Standish ‘Law of the eatable elephant’ is in line with this.
  • Epics can be business related as well as non-functional
  • Epics must be head and heart-driven, not just head-driven
  • Keep epics as small as possible but it must contain more than one feature
  • Number of epics in the roadmap must be WIP limited
• Planning
  • Portfolio plans will be replaced by a portfolio backlog with epics and a rolling-wave portfolio roadmap (Roadmaps include six key elements: time frame, prioritized and identifiable outcomes, strategic themes, context-specific content, dependencies, investment outlay)
  • Starting point for a portfolio roadmap must be a portfolio vision
  • Rolling-wave portfolio roadmap must be a living document. Only the first part must be committed to make sure changes can be embraced
  • Portfolio roadmaps must have a cadence or heartbeat to increase throughput and integration moments/milestones to create learning loops
  • Portfolio roadmaps must show retrospective events
  • Portfolio roadmap achievability must be based on (group of) team(s) velocity and not on optimized resource utilization. 100% resource utilization will lead to a lot of busy persons but no delivery!
  • Portfolio roadmap must be approved by senior management and communicated to the organization
  • Must be a continuous integrated portfolio planning process with regular strategic reviews (included fact-based feedback loops) and pivot when needed
  • Portfolio roadmap development includes strategic option analysis / scenario planning
•  Delivery
  • Portfolio dashboards must show the funding of value streams (and permanent agile teams) and the alignment with and budget allocation across the strategic themes
  • Portfolio dashboards must show progress on epic level. Details of epic break downs in features and user stories are not for the portfolio level (respect the decentralized decision making)
  • Focus must be on delivering value / benefits and not on OTOBOS (On Time, On Budget, On Scope)
  • Possible portfolio dashboards Key performance indicators and metrics (not limitative): productivity (feature lead time), agility (predictability, number of releases), quality (satisfaction, #defects), metrics for self-improvement, time to market, NPS
  • Use timely, accurate, and relevant information based on real time (automated) performance data, avoid manual aggregation
  • Portfolio dashboards must show data-driven recommendations for decisions
  • Portfolio dashboard reporting at anytime
  • Dependency management on epic level (inter and intra dependencies)
  • Doing the right things (metrics on effectiveness), Doing it right (metrics on process efficiency). Compare over more than one period
  • Customer feedback to evaluate the effectiveness of the roadmap
  • Portfolio dashboard reporting creates transparency and will motivate stakeholders
  • Integrated tooling (EA and PPM) must give real time insights (rich information) about the health of initiatives, capacity and what-if scenario analysis corresponding with the requester’s role

Behaviour

• Senior management commitment (much more leadership, less management)
• Decentralized decision making
• End-to-end transparency
• Inspect regularly and adapt where needed
• Feedback is crucial
• Empowered employees
• Culture of collaboration (remove silo’s)

Looking forward to your comments and adjustments so we can co-create a new agile portfolio management framework.

• Updates:
  • 30-09: added Scrum or KanBan paragraph
  • 30-09: Agile Portfolio Management Framework additions
  • 02-10 Picture Agile PfM Framework