Agile Portfolio Management

Mention of an Agile PMO or anything close to that to many Agilists will often result in them scoffing at the mere notion that a Project Management Office should even exist in an Agile organization.

And though I will agree that a PMO constructed to manage waterfall software development will cause your organization to struggle with being Agile (if it can be at all). There is however a need to ‘manage’ how work flows to teams, more so for larger organizations, but it won't look anything like the way you fund and project manage work in the waterfall world.

One of the biggest changes to anything looking like a PMO relate to how we fund work at an organizational level. In moving to an Agile Delivery Model, you are changing the way that work flows to teams and inherently how you fund that work must change as a result. You can’t have high levels of overhead related funding new work if you want to be Agile. If it takes you 5 signatures and a month or more to get things approved, you aren't Agile.

If you look at the Agile Manifesto and break down the principles you will see the following breakout:

1.      How we work – Eight of the principles relate to how we work. These relate to the frameworks that we utilize to 'operationalize' Agile. When Agile coaches speak about the flow of work they are invariably talking about the way that work flows in the context of whatever framework you may be using in the organization. For the frameworks to be effective you have to have a consistent flow of work.

2.      Technical Excellence – Three of the principles relate to delivering value via high quality and technical excellence. Value is enhanced when we make the right thing, the right way, at the right time. Nothing more nothing less.

3.      Business – One of the principles relates to the business, continuously delivering value to the organization.

Now how can we deliver high levels of value to the organization if we keep our annual project funding process in place? The answer is we can’t. 

Unfortunately this is exactly how many ‘Agile’ organizations continue to operate. Historically the organization has an annual planning period, so work for the coming year is discussed, planned for, documented, ROI’s calculated, ‘resources’ identified (I hate the word resource), Project Managers assigned, project plans created, kick off templates are filled out, sound familiar? It’s a prescribed process and extremely disconnected from the people who will actually being doing the work.

In many Agile organizations this funding model still exists and is the cause of many of the delivery issues we have, basically you have a waterfall delivery model operating in two week sprints.

There is a simple motto that I coach leadership on –

Those that do the work plan the work 

You cannot hold people accountable for work that they weren’t involved in from a planning perspective, yet that is exactly what we do still today in some Agile organizations.

If you truly want to change how your organization operates, then you will need to change three primary components regarding how work is identified and how it flows to your teams:

1.      Move to Team Based Funding – I’ve covered this in my most popular blog to date previously, but to summarize – You will no longer have any projects that are funded individually, but will identify the total investment you are making with respect to the people who form your teams. From this you can identify an average cost per team, can be broken down to a cost per sprint. So at this point you have a fixed cost line item on your balance sheet irrespective of the number of teams you have and the Finance guy in me likes that simplicity over having to track, manage potentially hundreds of projects happening in a given year. At this point you aren’t talking about how much a ‘project’ will cost since the cost question has been simplified, the cost is the average sprint (typically in the $30k range). The question then becomes how much are you willing to invest in ‘x’ to get ‘y’ value? This changes how leadership talks very quickly as you can quickly identify that a feature that is deemed valuable, but will require at least 10 sprints, may have an investment cost associated to it of $300k (assumes avg sprint cost is $30k). All of a sudden you may have a harder time defining the +$300k in value you expect to receive for making that investment decision. 

2.      Develop a Portfolio Valuation Model – Though a popular method of defining Portfolio level prioritization is found in Weighted Shortest Job First (WSJF) this is, in my opinion, not sufficient when you are looking at making larger investments. Instead you need to define a valuation model that identifies the ‘things’ that the organization deems valuable be it market growth, cost savings/avoidance, regulatory compliance, etc…and then weight them based upon how the organization views the value component. For example if you are a startup you may value any initiatives that drive market growth, whereas if you are a healthcare organization, regulatory compliance and security may be two of your higher value components. In taking a Portfolio approach we are expressly saying that each of our initiatives, much like securities (stocks, bonds), has a return profile and with that we will also need to have a risk component to apply against our value. Something may be extremely valuable, but if the Product teams have limited ability to deliver that value, then there may not be a reason to make a large investment right now.

3.      Move to Value Based Prioritization – We focus quite a bit on value with Agile, but in reality we have done a poor job in helping organizations understand what value is to them. To build this capability out the organization is going to have to get their leadership to agree to definitions regarding what types of software development investments can deliver the highest value related to their value streams and organizational strategies. What also changes in this process is that value is broken down now to focus on Needs not Wants, small deliverable's over large big bang ones. I want a Ferrari, however what I really need is a mini-van with an in-flight entertainment system, wants versus needs. Value based prioritization will help change the conversation when it comes to what work will flow to your Product Development teams.

In moving to value based conversations we also start talking about what is the minimum viable product or smallest amount of usable functionality that we can deliver for a customer to use. Probably the biggest miss we also make in Agile is that Leadership must be engaged at a much more granular level than they ever would be in Waterfall. Why? Because we need them to be involved in continuous decision making that is inherent in Agile.

In Waterfall you ask for and fund the Ferrari, but in fact your customers may not want or need the Ferrari, but since you paid for it you continue to try to deliver it. In essence you are spending money on something that may not be needed, but you wanted it, sometimes if only to ensure that you continue to get money for your individual part of the organization.

With a value based model, you will have the ability to make decisions to either continue on with the Ferrari because that is where your new market is at and you will deliver incrementally to get there or you can stop investment when you realize that you have failed to realize the expected value (fail fast) or that you have realized sufficient value to stop and focus on something more valuable, continuous decision making.

Agile is about delivering enough value in the moment over attempting to continue to deliver a fixed set of features, each assumed to be all of equal value (they aren’t). At one organization we were asked to rewrite an important part of the website and in working with the business we identified an MVP and set to work on that first. At the end of the MVP development effort, the business said ‘You know that is good enough for now, we have other higher priority work that we want you to take on instead of starting on the next set of features for this initiative.’ In your waterfall world this project would have been laid out with no MVP, so the work that we had completed would have not been promoted to production, meaning that it couldn’t be capitalized and would become just more tech debt that litters your technology stack.

By moving to a value based prioritization Portfolio Management process, we move the PMO from managing work to ensuring the organization is delivering the highest value work at the right moment. This is a huge shift for everyone associated in a waterfall organization, you are no longer focused on developing large upfront project documentation, getting approvals from multiple parts of the organization and managing a budget that was assigned to the project.

Instead the Agile Portfolio Management group works with leadership to ensure that they are flowing the most valuable work to the teams, in short you are moving from ‘managing’ work to influencing the organization regarding to focus on value. Additionally the Agile Portfolio Management oversees the valuation scoring and high level sizing efforts to ensure that we aren’t making a large investment in something that isn't supported by a value score that tightly aligns to the organizations strategies.

If you would like to learn more or work with me on helping your organization move to Agile, please reach out to me via www.soundagile.com or [email protected].