Scrum and Portfolio Management
Often I was asked how to apply Scrum to Portfolio Management, here are a few ideas to help you get started with a more Scrum-Friendly Profilo Management approach.
From Project to Product
Traditional Portfolio Management is built around projects, and Scrum is built around Products, so it would be good to start with the basic unit and see the difference…
-
Success
Time
Purpose
Changes
Development
Team
Project
Scope, Time, Budget
Definite start date and end date
Cost-Saving
Changes should be controlled
One-Off
Resource Utilization
Product
Value(Revenue/ time saved), User Adoption, etc.. Scrum.org/EBM
On-going as long as there is value
Value-Generating
Changes are expected and embraced
Continuous
Dedicated Full-time team
I went through a similar journey, we started with some projects, very often a part-time team, and moved around to different projects a lot, later we started to think more about the Product, how it generates value in either revenue or internal savings, or makes customers/employee happier, or improve quality or time-to-market. Gradually, we move to a more long-term team structure with long-term objectives.
Scrum-Friendly Team Structure
Their differences are huge and affect how we think about portfolios and teams. Traditionally companies would start the project, gather the related people, finish the project, and disband the team, that way, a lot of know-how and chemistry is lost. Transforming from project to product, we form a long-term stable Product-oriented team, you can start small to test out the product-market fit and team fit, once there is initial success, then gradually build up the team.
During the process, you may have to re-think your current product or service approach to build a long-term team, typically team structures are….
A Single Product team (typically more common for B2C or B2B Products when there is revenue ), that can be supported by one Scrum team or multiple Scrum Teams
A Service - it can be internal, a Business to Enterprise (B2E) team serving multiple business units, it can also be a data governance, data science or analytics or marketing/operation service serving multiple internal business units.
A Platform, eco-system, or whatever you call it, provides value to multiple internal or external clients, but still from a Scrum perspective, that’s just the same as a Product.
Scrum Studio Model by Scrum.org
Within the process, you may have to focus and pause/stop some projects that are of lower priority, or have a smaller chance to deliver value, and if the value is insignificant.
Budget Management
Traditionally when we think about budget, we often think about throwing x amount of money into a project, waiting for a few months, and praying for success, usually there are lots of surprises, and possibly delays. Then we have to throw more money into it and yet we don't know whether we would be successful, with that thinking, our approach would be to control and cut down on the cost and hopefully reduce delay.
The new approach with Scrum is that we have something in return every sprint, (our increment), so every sprint, maximum for 1 month, shorter for 2 weeks, 1 week even a few days can shorten the feedback loop. With every single sprint, we have some potential return, from a budget perspective, Product Owners can work with stakeholders and decide whether to invest more money or not, if there’s no value, maybe it’s ok to cancel the product. If that’s proven value, the Product Owners can work with management to decide whether it’s a positive Return on investment to invest more or keep investing. From a Budget perspective, that way it’s more flexible, we can risk manage every sprint, and decrease / freeze / increase investment if needed.
Summary
Portfolio Management applies to Scrum / Products can be quite different and maybe even quite disruptive for teams, we do not suggest you to go to a big-bang approach, and suddenly change all to Scrum / Product Oriented teams, instead, we suggest you try it bit by bit, you can still use projects to fund the team, but hopefully, the measurement/team structure is more product-focused.