Has your organisation successfully implemented agile at the team level? Have you got multiple agile teams working successfully together in a Program (e.g. Scrum of Scrums)? Great work!
However, it’s likely that you’re now uncovering new challenges, such as working out how to:
- Get your traditional teams to work with your agile teams
- Obtain and manage funding for your agile programs
- Decide what to take into your delivery programs
- Manage features that need to be delivered by multiple programs/teams
- Maintain visibility of how projects are tracking
In this post, we’ll look at how to set up an agile portfolio management framework and fine-tune it for your organisation’s needs.
It’s important to note that my aim here is not to prescribe an approach; rather, by using analysis first principles, I will try to help you better understand the problem domain and then look at some different approaches for developing a solution.
It’s crucial to state at the outset that it’s very difficult to define a one-size-fits-all solution for agile portfolio management. Your organisational culture and ways of working will influence your requirements and likely pose some unique challenges.
Nevertheless, some aspects of portfolio management are consistent in all environments, so we’ll start with these.
What portfolio management problem am I trying to solve?
This is a surprisingly complex question. To provide a place to start, I’ve mapped out some of the more common portfolio management requirements you might uncover in your own organisation.
This is only a generic list and I’ve primarily focused on consumers and enablers of IT teams here, rather than including team level requirements (as these are usually the primary concern of agile methodologies).
Business units (customers) want to:
- Inject feature requirements into delivery programs to improve their technology platforms, in order to:
- Build new products and features (innovation)
- Enable staff to sell and support products and features (enterprise capability)
- Understand order of magnitude feature costs (both in implementation and ongoing maintenance), to help with prioritisation
- Prioritise features for delivery (or at least know why they haven’t been prioritised)
- Get a degree of predictability around feature delivery, so that they can:
- Reliably inform customers when new products or features are coming available
- Ensure marketing campaigns and IT delivery are aligned
- Keep investors informed about progress and expected completion of major IT investments
Finance / Procurement wants to:
- Predict the cost of the IT projects and programs to forecast expenditure and cash-flow
- Predict and measure the return on investment for IT projects and programs to ensure funds are used in an optimal fashion
- Flag capital activity for addition to the balance sheet to recognise the difference between asset improvement and ‘keeping the lights on’ activities
- Fulfil existing contractual obligations with vendors on long term contracts for Service Delivery or Service Management
The PMO wants to:
- Understand and manage the performance of different work programs to optimise the IT supply chain
- Manage dependencies between teams that are potentially using different delivery methods to help teams to remain productive
- Receive timely information on program/team performance to optimally deploy resources and people
Enterprise Architecture wants to:
- Influence whole of organisation architectural direction (platforms, products, integration patterns, etc.) to manage total cost of ownership and retain control over the landscape of platforms and vendors used
- Ensure that non-functional requirements such as performance, scalability and flexibility are considered
- Enforce whole of organisation security standards and patterns (e.g. OWASP) to protect against misuse and fraud
- Maintain enterprise architecture visibility as it changes to efficiently undertake impact assessments and lifecycle programs
- Ensure some capacity is retained for architectural and hardening activities to ensure platforms are maintainable
- Work with teams to define architecture in a timely fashion for feature delivery so that architecture emerges in a managed but just-in-time fashion
Legal, Security, Risk and Compliance want to:
- Understand, quantify and mitigate the risks arising from feature delivery to minimise consequence
- Introduce and manage cross-program initiatives to handle legal or compliance related requirements (e.g. PCI DSS, prudential authority or government regulation)
- Establish and maintain business continuity plans (BCP) to protect the business during times of disruption
Infrastructure and Environment teams want to receive timely information about:
- Projected compute, storage and network capacity needs so that they can efficiently meet the demands arising from IT programs of work
- Environment needs so that they can provide development, testing, staging, migration and production environments at the right time
- Integration requirements in order to provision secure transmission capability and manage security (e.g. firewall rules and public key infrastructure)
- Environment use so that environments can be decommissioned when no longer required
They also want:
- The ability to support BCP with appropriate levels of service continuity planning and infrastructure
How do I ‘solve’ my portfolio management problem?
Now that you’ve gone some way to defining your requirements, it’s time to work out how you’re going to solve the problem. Agile has a great many benefits, but two I consider key are: the ability to deliver value more rapidly (incremental delivery) and to reduce variance (early detection of errors).
Unfortunately, in delivering these benefits you’ll also introduce some costs. For example, let’s look at the predictability requirements described earlier. In traditional methodologies, such as Prince2, there’s a (perhaps misguided) perception that you can more accurately define and manage delivery dates. Additional effort is spent at the start of the process to uncover complexity, rather than dealing with complexity as and when it arises.
If you didn’t take into account the added variability in traditional methods you could reasonably say this is a more ‘predictable’ way to do software.
By contrast, agile methods take a considerable amount of planning but commitments emerge far later in the process. Variability is reduced but the ability to provide long-term forecasting is also diminished.
What this means is that you may need to work with your customers to slightly reshape or pivot their requirements rather than building processes or frameworks to explicitly solve them. This will require a great deal of education, coaching and patience. You might also discover the best solutions to some problems exist outside of IT.
For instance, consider a traditionally run marketing department. It would be challenging to define an elegant solution that provides alignment between your emergent agile IT portfolio and a 12-month marketing/campaign plan. If, however, your marketing department considered moving to a leaner model, they might reduce their need for long-term predictability and potentially eliminate some waste of their own.
Keep in mind, though, that if technology has traditionally been a basket case in your business, you’ll need to get some serious runs on the board before you can convince anyone else to change.
Should I “build or buy”?
When building your agile portfolio management system, you’ll need to decide whether to: use a prescribed framework and tune it to your environment e.g. the Scaled Agile Framework (SAFe), or use a more minimalist approach and let your portfolio management practices evolve over time. Both options can be equally applied, there is no “right” way to do this.
Option A: If you’re starting with a framework and then optimising, it’s worth defining your requirements before you select and implement that framework. Make sure you’ve got good coverage from the prescribed solution and then incrementally fill in the gaps.
Option B: Conversely, if you’re going to let your framework evolve (probably the more ‘agile’ way to go about it), you won’t need to do as much up-front — you can discover your requirements as you go.
Note that as with software development, even if you are using an evolutionary approach, you should at least uncover the breadth of the problem that you’re trying to solve before starting to solve it. This will allow you to effectively prioritise problems for treatment and also help to ensure that in solving one problem you’re not creating others.
How can I maintain transparency and visibility of how projects are tracking?
The trade off from empowering and delegating decision making to agile teams is that it becomes more difficult to see how projects in the portfolio are tracking to delivery timeframes, and audit whether a project should continue or not.
By delegating decision making to the teams we’ve also lost direct sight of what is being decided. This can put the Portfolio Manager in a very difficult spot. It’s hard to sit in a meeting with senior leaders and have to say, “I don’t know how things are going”. Without the right reporting and governance structure though, it can often feel like that is the case. So, if we need to develop this new structure, where do we start?
The good news is that we can use the agile delivery teams as inspiration. The agile ceremonies these teams use are designed to help provide visibility, transparency, and the ability to ensure that the highest priority work is actioned first.
For instance, sprint planning sessions enable product owners to be accountable for the priority or work. These sessions also enable the team to determine what work will be actioned in the next iteration, providing guidance on when work items will be delivered.
At daily standup, the team discusses what work is being actioned, the progress made and if there are any issues, providing transparency of progress and issues. Standups also enable auditing that priority work is being actioned on a daily basis, while Kanban boards provide visibility at any time of progress and what is in flight.
From a portfolio perspective, we can use some of the same concepts and adapt the agile team ceremonies to achieve the same value.
Providing visibility of the portfolio
Agile teams use agile boards which can be both physical and digital. In the Scaled Agile Framework (SAFe) the high level collective work of all the teams is captured on a program increment board.
To provide visibility of the portfolio we can build a portfolio board which captures:
- The potential projects in the portfolio pipeline
- The current 3/6/12 month plan on which projects will be delivered
- Which projects are currently being flight for development by agile teams
- Which projects are released
With an agile board, we can also capture additional information such as the rules we use to determine the project priority and what criteria are used to select projects to pass to the teams. Boards also enable to identify and highlight any bottlenecks or delays in delivery.
This also provides an opportunity for portfolio managers to audit what work is in flight to ensure that strategic alignment is maintained.
Providing transparency on progress and issues
Agile teams use daily stand-ups. Scaled agile is a concept of Scrums, where each team lead is present to provide details on how work is progressing and any issues. A Portfolio “standup” using the portfolio board can be used as a mechanism for project managers to discuss project progress, current issues being managed and likelihood to achieve timeframes.
How do I implement continuous improvement into my portfolio management system?
Write this down and commit it to memory: your agile portfolio management system is never ‘finished.’ The best systems are always introspective and should continually improve based on data driven decisions.
If you want to continually optimise the way you manage your agile portfolio, use agile ceremonies such as retrospectives and ‘inspect and adapt’ as well as metrics derived from program and team performance.
You’ll be building a stronger, more effective system that’s perfectly in tune with your customers and your organisation’s needs. Remember to consider:
- The information or metrics you’ll need to measure the performance of your portfolio management solution
- The source of that information and how regularly you want to collect it
- The level of burden you want to place on your programs and teams while collecting the information
Any time your team spends on reporting-related tasks is time they’re not adding value to your customers, so aim to automate the capture and dissemination of information as much as possible.
Wrapping up
This blog clearly won’t solve every problem you’ll face while building a solution to your agile portfolio management needs, but I hope I’ve given you some insights into the different ways you could potentially tackle the problem.
Keep in mind you’ll often find you’re trying to fit a square peg into a round hole. Traditional approaches to portfolio management are built around a different delivery model — sometimes the optimal solution might require a major paradigm shift.
