Continuous Portfolio Management as a Contributor for Achieving Highly-Aligned, Loosely-Coupled Teams

In many software organizations, there is a business need for fast software delivery in order to frequently test business hypotheses and drive development based on the resulting feedback. Achieving fast software delivery rests on two fundamental activities. These are: 

1. Rapidly deciding on what to build (next), and 
2. Rapidly building and deploying the corresponding software to production 

That is, in order to optimize the organization for the overall speed, the speed of portfolio decision-making and the speed of delivery both need to be high. 

We discussed how the speed of delivery can be improved using continuous delivery techniques in two previous InfoQ articles: Improving Speed and Stability of Software Delivery Simultaneously at Siemens Healthineers and Adopting Continuous Delivery at teamplay, Siemens Healthineers. In this article, we focus on continuous portfolio management, and describe our journey towards it. 

Both continuous portfolio management and continuous delivery need to work in tandem to enable the organizational speed necessary for timely user evaluations of ideas implemented in software. The resulting feedback loop greatly reduces the risk of running on untested assumptions for too long. 

Additionally, both continuous portfolio management and continuous delivery processes need to be set up in a scalable manner. Adding new teams to either process needs to be simple and easy in order to allow the organization to scale. 

Continuous Portfolio Management 

In general, portfolio management is there to decide what to build. There are two extreme ways to make these decisions. One is to leave the teams full freedom to decide, without providing a strong overarching prioritization framework for the organization. This typically results in chaos. Consequently, it does not scale. It might be applicable in the smallest software delivery organizations at best. 

Another extreme is to establish a rigid command and control decision hierarchy. The people on top decide what to build, and controls are installed throughout the organization to ensure all the teams follow. This might only work in environments where the people on top of the hierarchy would actually know with certainty what to build. In the context of software delivery, this is very rarely the case. Typically, the opposite is true. There is lots of uncertainty and ambiguity around which ideas might be worth building. A lot of experimentation throughout the hierarchical organization is required to test the assumptions inherent in the ideas. 

That is, the two extreme ways to make portfolio decisions are not suitable in the context of software delivery. Given that, what would be a good way to establish portfolio management for rapid software delivery? It would need to fulfill the following criteria: 

• Provide enough rigid structure to align the teams contributing to big organizational initiatives 
• Allow enough flexibility to run experiments to test assumptions in the ideas throughout the organization 
• Distribute decision-making authority appropriately throughout the organization 
• Allow for continuous decision-making through largely independent value streams 
• Be fully flexible in terms of production releases of individual teams 
• Allow for adding teams at scale 

Rigid structure means that the set of initiatives for everyone needs to be fixed. All teams are only allowed to be working on those initiatives. New initiatives are added through the defined decision-making process. 

The forcing function in portfolio management needs to be the distributed team alignment. Team misalignment leads to work in process overflow as teams tend to implement overlapping solutions, making local optimizations instead of collaborating to achieve a shared goal. 

In the next section, we present a portfolio management system we employ at scale at the Siemens Healthineers teamplay digital health platform. It fulfills the criteria above and is used by 30 development teams distributed around the world. The system was inspired by the following frameworks: 

• Spotify rhythm incl. Data Insights Beliefs Bets (DIBB) framework 
• Data Understandings Hypotheses Bets (DUHB) framework by Avvo (see the presentation “Building a Culture of Continuous Improvement” for details)
• Inceptions by Equal Experts 
• Lean portfolio management by SAFe 
• Wildly important goals (WIGs) by The 4 Disciplines of Execution 
• North Star Framework by Amplitude

Portfolio Entities

The portfolio management at teamplay is embedded in the overall Siemens Healthineers strategic planning. This is driven by the Hoshin Kanri process. It provides strategic input for all divisions in the company based on the purpose and priorities of the corporation. The Hoshin Kanri goals for teamplay serve as input to the teamplay portfolio management. 

Within the teamplay portfolio management, a hierarchy of portfolio entities is established. It consists of three portfolio levels explained in the table below. 

The North Stars, Business Opportunities and Business Features have relationships between each other. These are illustrated in the picture below. 

There is a many to many relationship between the North Stars and Business Opportunities. That is, a North Star can be supported by many Business Opportunities (e.g. the North Star Goal A is supported by the Business Opportunities A and B). The opposite holds true as well. A Business Opportunity can support many North Stars (e.g. the Business Opportunity C supports the North Star Goals B and C). 

Likewise, there is a many to many relationship between the Business Opportunities and Business Features. A Business Opportunity can be supported by many Business Features (e.g. the Business Opportunity A in the figure above is supported by the Business Features A and B). Further, a Business Feature can support many Business Opportunities (e.g. the Business Feature F supports the Business Opportunities C and D). 

A Business Feature is owned by a single development team. This is shown on the right hand side of the figure above. Each team has its own backlog. The individual team backlogs reside below the central portfolio backlog. 

Delivering business value for a Business Opportunity often means delivering several Business Features by different teams. Delivering a Business Feature by a single team does deliver business value within the bounded context of that team. Still, "larger business value" delivery requires crossing bounded contexts, and hence, crossing the team and business feature boundaries. 

Stacked-ranked North Stars and Business Opportunities enable alignment throughout the organization. This is achieved using the so-called Global Stack Rank (GSR) presented in the next section. 

Global Stack Rank 

As shown in the picture above, the North Stars and Business Opportunities are prioritized globally. This means the prioritization applies for the entire organization. Hence, the name Global Stack Rank or abbreviated GSR. Every major activity in the organization is captured using the GSR. 

The GSR governs the topics all the teams- technical and non-technical- work on. Additionally, the GSR governs the relative priority of topics among each other. The higher a BizOpportunity is in the GSR, the more support it should get from all the teams, considering their bounded contexts. 

The teamplay leadership team is responsible for prioritizing the GSR of North Stars and Business Opportunities. The product owners of individual teams are responsible for prioritizing the Business Features. The Business Features from the Business Opportunities higher in the GSR should be prioritized higher in the teams. 

Let us consider an example GSR structure: 

North Star 1 (GSR: 1) 
|
→ BizOpportunity A (GSR: 1.1) 
|
→ BizOpportunity B (GSR: 1.2)
|
North Star 2  (GSR: 2)
|
→ BizOpportunity C (GSR: 2.1)
|
→ BizOpportunity D (GSR: 2.2) 

Further, let us consider an example team T, that due to their Bounded Context(s) can contribute to 3 BizOpportunities A, B and D with the respective current GSR of 1.1, 1.2 and 2.2. 

It can happen that team T's contribution to Business Opportunity A is rather small based on a small intersection of team T's bounded context and the Business Opportunity A's domain. In that case, team T is doing all they can to support the Business Opportunity A due to its high GSR. Nevertheless, in that case, team T is not going to allocate most of their capacity to Business Opportunity A because it is not needed. 

Our experience is that the system above contributes well to the distributed alignment of teams. Although difficult to quantify, it would be fair to say that over 50% of conflicting prioritization decisions that need to be made by the product owners can be answered directly by the GSR. The rest needs negotiations with stakeholders. That is, GSR serves to make the teams more autonomous in their decision-making on what to build next while staying aligned with other teams and the overarching priorities of the organization. 

It is important to note that the Business Opportunities in the GSR can be either revenue generating or technical. Both types of work undergo the same GSR prioritization process. 

Typically, feature work on Revenue Business Opportunities can be treated in a transactional manner. A team may work on the customer visible features 1 and 2 today, and switch to working on the features 3 and 4 tomorrow. ​

By contrast, technical work on Technical Business Opportunities typically requires an ongoing effort corridor. For instance, ongoing effort is required for cybersecurity, operations, API management, data privacy, maintenance, etc. 

For a given time period, the product owner needs to strike a balance between the Business Features from the Revenue and Technical Business Opportunities in the GSR. The product owner bears freedom and responsibility for the appropriate split. 

Portfolio Dynamics 

The Global Stack Rank (GSR) is supported by a number of staggered meetings in order to unfold its impact on the organization in terms of distributed alignment of loosely coupled teams. 

To approach this, we divided the organization into widely independent value streams. A value stream is a conglomerate of teams that represents a bigger bounded context. An example of such a bigger bounded context in the healthcare domain are teamplay performance management applications. These applications help medical imaging departments optimize their performance. 

A bigger bounded context consists of several teams. Each team, in turn, owns at least one smaller bounded context contributing to the bigger one. Referring to the example above, smaller bounded contexts are individual applications like teamplay Dose for radiation dose reduction or teamplay Usage for analysis of medical imaging scanner usage. 

Further, a value stream has a name, description, an owner and a distinct end customer group. With the structure of values streams, we introduced the following portfolio dynamics for distributed decision-making throughout the organization. 

In the picture below, the value streams can be seen on the left hand side. Each value stream can come up with new ideas for Business Opportunities. The ideas need to be written up using a short one-screen brief (similar to a DIHB by Avvo). Next, the Business Opportunities are submitted for consideration to the so-called Global Stack Rank meeting (GSR meeting). The meeting takes place every two weeks. The participants of the meeting are the teamplay leadership team members and product owners relevant to the Business Opportunities being discussed. 

For each submitted Business Opportunity, the GSR meeting decides whether it should be included in the GSR and if so, which stack rank it should get. To recap, the higher a Business Opportunity is in the GSR, the more support it should get from all the teams, considering their bounded contexts. 

After the GSR meeting has assigned a GSR to a Business Opportunity, more people can be involved in driving further details. The Business Opportunity owner can involve the product owners of relevant teams. Together they can define the necessary Business Features. 

Once the Business Features have been defined, they can be incepted in the next value stream inception. The value stream inceptions take place roughly every two months. To run the inceptions effectively, we follow the inception playbook by Equal Experts. Crucially, all the teams are required to provide inception feedback to their stakeholders. This closes the feedback loop for the stakeholders in terms of whether their requested Business Features have been incepted and therefore will be worked on in the next 2 months. 

Once the inception feedback has been distributed, the teams start developing the features agreed. They release them to production on their release cadence. Different teams have different release cadences at teamplay. 

It is worth noting that the deadlines to submit Business Features to a value stream (Business Feature freeze) and provide inception feedback to the stakeholders (inception feedback day) are planned to be roughly 10 days apart. That is, if a stakeholder submits a Business Feature just in time for a value stream’s Business Feature freeze, they know they will get the inception feedback 10 days later. If a stakeholder missed a Business Feature freeze, the next one is roughly two months away. This rhythm has proven to strike a good balance of velocity between the stakeholders requesting features and the teams providing feedback on the requests. It is shown in the picture below. 

Finally, the Business Feature freeze and inception feedback day cycles across value streams are planned to be roughly a week apart. For instance, in an organization with three value streams, there will be 3 Business Feature freeze and inception feedback day cycles, one for each value stream. The portfolio planning will foresee a week’s offset between the cycles. 

The staggering of the cycles is done in such a way that the value stream with the least dependencies goes first. The value stream depending on the first one goes second. The value stream depending on the second one goes third, etc. 

Scalability 

The portfolio approach described above scales and descales well. It is easily possible to: 

• add and remove North Stars, Business Opportunities and Business Features 
• add and remove value streams 
• add teams to and remove teams from value streams 
• rearrange North Stars, Business Opportunities, Business Features, value streams and teams 

North Stars, Business Opportunities and Business Features are represented as templated work items. So, adding and removing those is done like any other day-to-day work item handling. 

When new teams are created, they can either be added to an existing value stream or form a new value stream. Adding a team to an existing value stream requires representation of the team in the portfolio management. This is accomplished by merely adding some new attributes in the work item management. Apart from that, the team is “latched” into the existing cadence of inceptions of the value stream. 

Adding a new value stream requires creating a new cadence of inceptions. These need to be staggered properly with other value streams to form a proper wave of alignments (see previous section). 

Rearranging North Stars, Business Opportunities and Business Features only takes some work item rearrangement. This is a pretty frequent use case as the learnings around the Business Opportunities’ assumptions unfold and the feedback gets incorporated. 

Tools

All the portfolio management work item types and work items such as North Stars, Business Opportunities and Business Features are stored in the Azure DevOps Application Lifecycle Management (ALM) system. All the other artifacts for the development teams such as team backlogs, code repositories, configuration and pipelines reside in the same ALM too. 

Using the same ALM for portfolio and development activities has the advantage of cross-linking the appropriate artifacts. A consistent linkage is established from the highest level in the portfolio all the way down to the unit tests created by the development teams. On the one hand, this contributes to fulfilling the departmental quality requirements in a consistent and tool-supported way. On the other hand, it contributes to creating awareness throughout the organization of how a particular item, e.g. a Business Feature, a code component or a test, contributes to the overarching organizational goals. 

In addition to Azure DevOps, we created several Power BI reports. These are interactive visualizations of portfolio data in Azure DevOps. They allow fast access to portfolio data and help quickly answer questions along the lines of: 

• Which teams are working on Business Opportunity A? 
• What are the Business Opportunities team T is working on? 
• What are the Business Features for Business Opportunity B?
• What are the GSR changes over time for Business Opportunity D?
• Which Business Features got done over time for Business Opportunity D?
• How many teams are working on North Star 1? 

Adoption 

The teams welcomed the introduction of portfolio management in teamplay in 2018. Since then, the approach has evolved conceptually and tool-wise. 

Benefits

The product owners enjoy deep involvement of the leadership in the prioritization. They can refer the stakeholders to the GSR that states agreed organizational priorities. If the stakeholders would like to get the GSR changed (North Stars or Business Opportunities), they can talk to the teamplay leadership team. If the stakeholders would rather like to get a Business Feature implemented for an existing Business Opportunity, they can talk to the product owner directly who is empowered to make the decision in accordance with the GSR. 

With the introduction of value streams and value stream inceptions, the necessity for big room planning disappeared. This was welcomed by the teams because the inceptions became very low ceremony, focused and quick. Low ceremony means there is no need to stage a big event. This is in stark contrast to e.g. SAFe PI Planning, which is a big room planning event that requires a lot of preparation - high ceremony. Thus, beforehand, the teams tried to talk to all the other teams necessary within a couple of days full of meetings. The meetings could not go in-depth enough due to time constraints. This left many topics at the end of big room planning in a not clearly defined “half incepted” state. 

Doubling the inception frequency from incepting every four months to incepting every two months was met with some initial apprehension. However, it proved beneficial to everyone over time. The teams only need to plan the Business Features for the upcoming two months, not more. Even for teams releasing more frequently than every two months, the portfolio planning time horizon of two months proved to be reasonable. That is, they do not want to do the portfolio planning more frequently. 

For the stakeholders, doubling the inception frequency meant they have got twice as many opportunities to place their requests than before. Naturally, that was a very welcome change! 

For the teams releasing slower than every two months, the shorter portfolio planning horizon served as an additional reason to accelerate their releases. 

Challenges

With the above benefits, the following challenges emerged. The introduction of portfolio management entities meant that drivers for the topics needed to be assigned. This proved challenging in some cases. Whenever a topic of a North Star or Business Opportunity does not have a natural owner who has been working on it before, someone new needs to be found and assigned the responsibility. It happened that a Business Opportunity could not be put into the GSR because there was simply no owner to drive it. 

Another challenge in this context is to establish a common way of driving Business Opportunity. It turned out that the role of Business Opportunity owner is fairly new, and different people drive their topics very differently. Some identify the Business Features required to take the Business Opportunity to the next level, elaborate them with all the required teams, stay in touch with the teams during the development by providing ongoing feedback, and measure the outcomes in production once the users start using the features. Other Business Opportunity owners approach this entirely differently. They expect the teams to analyze the Business Opportunity, come up with the required Business Features and implement them. 

To level the field, we created a Business Opportunity owner onboarding guide. It describes how a Business Opportunity owner is supposed to drive their topics: 

• How to write a Business Opportunity well?
• How to bring the Business Opportunity into the GSR decision-making process?
• How to manage the relationships with all the stakeholders necessary to implement the Business Opportunity? 
• How to identify the teams necessary to implement Business Features for the Business Opportunity?
• How to engage with the product owners of the teams to discuss the Business Features?
• How to prepare for a Business Feature inception?
• How to check whether the Business Features have been incepted?
• How to stay in touch with the teams during the Business Feature implementation?
• How to track the Business Feature progress?

The guide helped a lot with onboarding new people into the role. However, it remains challenging to operationalize the guide across the board. 

Another challenge turned out to be different sizes of Business Opportunities in the GSR. Some Business Opportunities are much bigger than others in terms of development cost, revenue potential, time to revenue and time of stay in the GSR. This makes it difficult to compare the size of Business Opportunities in the GSR. That is, a North Star with e.g. three Business Opportunities could be more sizable than another North Star with e.g. 10 Business Opportunities. It follows that direct comparisons of North Stars and Business Opportunities based on pure numbers do not work in the GSR. 

A bigger challenge is to make portfolio decisions in a data-driven way, rather than qualitatively. We would like to move even more towards experimentation with measurable evidence and learning. This can be supported by defining hypotheses using Capability - Outcome - Measurable Signal triples. The hypotheses can be hierarchical. That is, bigger hypotheses can be defined at the level of North Stars. Smaller hypotheses can be defined at the level of Business Opportunities. Where applicable, even smaller hypotheses can be defined at the level of Business Features. The measurable signals need to be automated as much as possible. Where applicable, they should be measured directly from production data. We started initial experimentation with the definition of hypotheses in several teams. It seems to be a promising avenue, to be pursued further. 

An attempt towards becoming more data-driven was to evaluate the value of a Business Opportunity with the stakeholders before and after the implementation. We did not manage to institutionalize the practice. However, the couple of times we did that, the exercise was found useful by everyone involved. 

Partly because the data-driven decision making is not yet well developed but also due to some other reasons, the prioritization of the GSR by the leadership team is a challenging process in itself. We attempted to apply the Weighted Shortest Job First (WSJF) approach by SAFe to the GSR prioritization. WSF = cost of delay / job duration. Both parameters turned out to be rather difficult or effort intensive to determine. As a result, the initiative did not succeed. 

The last challenge is related to the size of the organization teamplay has become. We are now at a point where we consider instantiating our portfolio management system by value stream. Setting up an independent portfolio with its own GSR for each value stream might be beneficial to streamline the value streams’ portfolios and making the value streams even more independent from each other while maintaining alignment. These are still early days for us. We are currently weighing the pros and cons, and deliberating options of how this could be done. 

Summary 

Continuous portfolio management is an essential component of making a software delivery organization fast. It is about making decisions on what to build next quickly, in a distributed and aligned manner. This is required to foster team autonomy within the boundaries of organizational alignment. 

“Autonomy only scales if leaders provide high level context”, as per the Spotify Rhythm by Henrik Kniberg. This is exactly what can be achieved with continuous portfolio management. 

Joining continuous portfolio management with continuous delivery results in a high business agility where the organizational value streams, and teams within, can make decisions and deliver software in a highly independent and aligned manner. The necessity for big planning and big release ceremonies becomes superfluous. Descaling these processes leads to higher business agility. 

Acknowledgements 

We would like to thank Marc Schlichtner for originating the portfolio management at the Siemens Healthineers teamplay digital health platform in 2018. Additionally, we would like to thank many other people for portfolio management tool support in Azure DevOps and Power BI.