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.
In this post, I’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 focussed 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:
- To build new products and features (innovation);
- To 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)
- The ability 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:
a. Use a prescribed framework and tune it to your environment (e.g. the Scaled Agile Framework (SAFe): http://scaledagileframework.com/portfolio-level/), or;
b. 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 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.
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.
In future posts we intend to examine some approaches to some of the curlier problems in this domain including:
- How to identify and prioritise features to take into delivery teams
- How to make sure that you’re getting the right balance between delivering new products/features and delivering enterprise capability
- How to manage dependencies between plan-driven and change-driven programs/teams
- How to fund agile delivery streams and solve the capitalisation problem.