Now that we understand the coordination problem better, and have discussed finance and sourcing, we are prepared to make longer-term commitments to a more complicated organizational structure. As we stated in the Competency Area introduction, one way of looking at these longer-term commitments is as investments. We start them, we decide to continue them, or we decide to halt (exit) them. In fact, we could use the term “portfolio” to describe these various investments; this is not a new concept in IT management.
|The first comparison of IT investments to a portfolio was in 1974, by Richard Nolan in Managing the Data Resource Function [Nolan 1974].|
Whatever the context for your digital products[context for your digital products] (external or internal), they are intended to provide value to your organization and ultimately your end customer. Each of them in a sense is a “bet” on how to realize this value (review the Spotify DIBB model), and represents in some sense a form of product discovery. As you deepen your abilities to understand investments, you may find yourself applying business case analysis techniques in more rigorous ways, but as always retaining a Lean Startup experimental mindset is advisable.
As you strengthen a hypothesis in a given product or feature structure, you increasingly formalize it: a clear product vision supported by dedicated resources. We will discuss the IT portfolio concept further in Architecture, Digital Strategy, and Portfolio. In your earliest stages of differentiating your portfolio, you may first think about features versus components.
As you consider your options for partitioning your product, in terms of the AKF scaling cube, a useful and widely adopted distinction is that between “features” and “components”; see Features versus Components.
Features are what your product does. They are what the customers perceive as valuable. “Scope as viewed by the customer” according to Mark Kennaley [Kennaley 2010]. They may be “flowers” – defined by the value they provide externally, and encouraged to evolve with some freedom. You may be investing in new features using Lean Startup, the Spotify DIBB model, or some other hypothesis-driven approach.
Components are how your product is built, such as database and web components. In other words, they are a form of infrastructure (but infrastructure you may need to build yourself, rather than just spin up in the cloud). They are more likely to be “cogs” – more constrained and engineered to specifications. Mike Cohn defines a component team as “a team that develops software to be delivered to another team on the project rather than directly to users” [Cohn 2009].
Feature teams are dedicated to a clearly defined functional scope (such as “item search” or “customer account lookup”), while component teams are defined by their technology platform (such as “database” or “rich client”). Component teams may become shared services, which need to be carefully understood and managed (more on this to come). A component’s failure may affect multiple feature teams, which makes them riskier.
It may be easy to say that features are more important than components, but this can be carried too far. Do you want each feature team choosing its own database product? This might not be the best idea; you will have to hire specialists for each database product chosen. Allowing feature teams to define their own technical direction can result in brittle, fragmented architectures, technical debt, and rework. Software product management needs to be a careful balance between these two perspectives. SAFe suggests that components are relatively:
More technically focused
More generally re-usable
than features. SAFE also recommends a ratio of roughly 20-25% component teams to 75%-80% feature teams [SAFe 2016a].
Mike Cohn suggests the following advantages for feature teams [Cohn 2009]:
They are better able to evaluate the impact of design decisions
They reduce hand-off waste (a coordination problem)
They present less schedule risk
They maintain focus on delivering outcomes
He also suggests that component teams are justified when:
Their work will be used by multiple teams
They reduce the sharing of specialists across teams
The risk of multiple approaches outweighs the disadvantages of a component team
Ultimately, the distinction between “feature versus component” is similar to the distinction between “application” and “infrastructure". Features deliver outcomes to people whose primary interests are not defined by digital or IT. Components deliver outcomes to people whose primary interests are defined by digital or IT.
In the coordination Competency Category, we talked of one product with multiple feature and/or component teams; see One Company, One Product. Features and components, as we are discussing them here, are large enough to require separate teams (with new coordination requirements). At an even larger scale, we have new product ideas, perhaps first seen as epics in a product backlog.
Eventually, larger and more ambitious initiatives lead to a key organizational state transition: from one product to multiple products. Consider our hypothetical startup company. At first, everyone on the team is supporting one product and dedicated to its success. There is little sense of contention with “others” in the organization. This changes with the addition of a second product team with different incentives; see One Company, Multiple Products. Concerns for fair allocation and a sense of internal competition naturally arise out of this diversification. Fairness is deeply wired into human (and animal) brains, and the creation of a new product with an associated team provokes new dynamics in the growing company.
Because resources are always limited, it is critical that the demands of each product be managed using objective criteria, requiring formalization. This was a different problem when you were a tight-knit startup; you were constrained, but everyone knew they were “in it together”. Now you need some ground rules to support your increasingly diverse activities. This leads to new concerns:
Managing scope and preventing unintended creep or drift from the product’s original charter
Managing contention for enterprise or shared resources
Execution to timeframes (e.g., the critical trade show)
Coordinating dependencies (e.g., achieving larger, cross-product goals)
Maintaining good relationships when a team’s success depends on another team’s commitment
Accountability for results
Structurally, we might decide to separate a portfolio backlog from the product backlog. What does this mean?
The portfolio backlog is the list of potential new products in which the organization might invest
Each product team still has its own backlog of stories (or other representations of their work)
The decision to invest in a new product should not be taken lightly. When the decision is made, the actual process is as we covered in Product Management: ideally, a closed-loop, iterative process of discovering a product that is valuable, usable, and feasible.
There is one crucial difference: the investment decision is formal and internal. While we started our company with an understanding of our investment context, we looked primarily to market feedback and grew incrementally from a small scale. (Perhaps there was venture funding involved, but this document does not cover that.)
Now, we may have a set of competing ideas on which we are thinking about placing bets. In order to make a rational decision, we need to understand the costs and benefits of the proposed initiatives. This is difficult to do precisely, but how can we rationally choose otherwise? We have to make some assumptions and estimate the likely benefits and the effort it might take to realize them.
Fundamentally, we plan for two reasons:
To decide whether to make an investment
To ensure the investment’s effort progresses effectively and efficiently
We have discussed investment decision-making in terms of the overall business context, in terms of the product roadmap, the product backlog, and in terms of Lean Product Development and cost of delay. As we think about making larger-scale, multi-team digital investments, all of these practices come together to support our decision-making process. Estimating the likely time and cost of one or more larger-scale digital product investment is not rocket science; doing so is based on the same techniques we have used at the single-team, single-product level.
With increasing scope of work and increasing time horizon tends to come increasing uncertainty. We know that we will use fast feedback and ongoing hypothesis-driven development to control for this uncertainty. But at some point, we either make a decision to invest in a given feature or product and start the hypothesis testing cycle – or we do not.
Once we have made this decision, there are various techniques we can use to prioritize the work so that the most significant risks and hypotheses are addressed soonest. But in any case, when large blocks of funding are at issue, there will be some expectation of monitoring and communication. In order to monitor, we have to have some kind of baseline expectation to monitor against. Longer-horizon artifacts such as the product roadmap and release plan are usually the basis for monitoring and reporting on product or initiative progress.
In planning and execution, we seek to optimize the following contradictory goals:
Delivering maximum value (outcomes)
Minimizing the waste of un-utilized resources (people, time, equipment, software)
Obviously, we want outcomes – digital value – but we want it within constraints. It has to be within a timeframe that makes economic sense. If we pay 40 people to do work that a competitor or supplier can do with three, we have not produced a valuable outcome relative to the market. If we take 12 months to do something that someone else can do in five, again, our value is suspect. If we purchase software or hardware we do not need (or before we need it) and, as a result, our initiative’s total costs go up relative to alternatives, we again may not be creating value. Many of the techniques suggested here are familiar to formal project management. Project management has the deepest tools, and whether or not you use a formal project structure, you will find yourself facing similar thought processes as you scale.
To meet these value goals, we need to:
Estimate so that expected benefits can be compared to expected costs, ultimately to inform the investment decision (start, continue, stop)
Plan so that we understand dependencies (e.g., when one team must complete a task before another team can start theirs)
Estimation sometimes causes controversy. When a team is asked for a projected delivery date, the temptation for management is to “hold them accountable” for that date and penalize them for not delivering value by then. But product discovery is inherently uncertain, and therefore such penalties can seem arbitrary. Experiments show that when animals are penalized unpredictably, they fall into a condition known as learned helplessness, in which they stop trying to avoid the penalties.
We discussed various coordination tools and techniques previously. Developing plans for understanding dependencies is one of the best known such techniques. An example of such a planning dependency would be that the database product should be chosen and configured before any schema development takes place (this might be a component team working with a feature team).
Many large projects need to announce and commit to deadlines many months in advance, and many large projects do have inter-team dependencies … [Cohn 2005]
Agile Estimating and Planning
Agile and adaptive techniques can be used to plan larger, multi-team programs. Again, we have covered many fundamentals of product vision, estimation, and work management in earlier material. Here, we are interested in the concerns that emerge at a larger scale, which we can generally class into:
With larger blocks of funding comes higher visibility and inquiries as to progress. At a program level, differentiating between estimates and commitments becomes even more essential.
Mike Cohn suggests that larger efforts specifically can benefit from the following coordination techniques [Cohn2005]:
Estimation baseline (velocity)
Key details sooner
Estimating across multiple teams is difficult without a common scale, and Cohn proposes an approach for determining this in terms of team velocity. He also suggests that, in larger projects, some details will require more advance planning (it is easy to see APIs as being one example), and some team members' time should be devoted to planning for the next release. Finally, where dependencies exist, buffers should be used; that is, if Team A needs something from Team B by May 1, Team B should plan on delivering it by April 15.
Finally, risk and contingency planning is essential. In developing any plan, Martin L. Abbott and Michael T. Fisher recommend the “5-95 rule”: 5% of the time on building a good plan, and 95% of the time planning for contingencies [Abbott & Fisher 2015]. We will discuss risk management in detail in Governance, Risk, Security, and Compliance.
Evidence of Notability
Portfolio management in the IT and digital context has been a topic since at least 1974 [Nolan 1974].
IT portfolios (whether conceived as service, project, application, or product portfolios) are significantly different from classic financial portfolios and the usefulness of the metaphor is periodically questioned.