The Pragmatic Agile Coach’s Approach to Product Thinking and Portfolio Governance

When does a transformation often hit the wall as it looks to make additional progress within an organization that’s seemingly eager to embrace Agile ideals and principals? Look no further than the Program Governance Board.

The Governance Board

Depending on your organization, this board may have different names—a Steering Committee, Oversight Committee or even Board of Directors. Whatever its title, the Governance Board is made up of executive-level stakeholders with strategic insight into the company’s goals and objectives, technical knowledge, functional responsibilities, operational accountability, portfolio management responsibility, and the ability to represent important stakeholder groups. 

In traditional organizations, funding for projects may be via a single source or through multiple Portfolios. The governance of the project will vary to meet the needs of the stakeholders in the project and the lifecycle chosen.

In this way of thinking, all projects require funding in some way. In most situations, money needs to be provided to implement the project. It is the business case that provides the justification for this funding and the Governance Board doles out the money.

My mind always goes to the smoke-filled rooms of the past. With the Governance Board making decisions, in most cases, it is not based on empirical data, but instead heavily influenced by the pervasive organizational culture. If the culture is conservative and risk averse, they allocate funds with an eye dropper. If the organization has an “old boys” network, bargaining goes on – “I’ll give you the money for the infrastructure upgrades you want, if you give me what I need to implement the new CRM tool.”

What is often a detrimental part of this process is the way it denigrates the teams which are the cornerstone of any IT organization by making them “grovel” for funds each year; and more significantly, the colossal waste of time that comes from all parts of the organization having to annually “justify their existence.”

When is a Product a Product?

Make a Wish was an American children’s television series which ran in the 1970s. In it, the host would introduce a word and discuss the many various meanings it might have. “What is a ball? A ball can be something you toss to a friend. A ball could be a dance Cinderella attended. You could ‘have a ball’ meaning a good time. Or a ball could be a type of jar.” As a young child, I remember being utterly confused by the end of the segment and wondering, “so what the heck is a ball?”

The same is true when we as Agile Coaches introduce “Product Thinking”. Exactly what is the Product we are managing? If we are working with a bank, a product could be the “Everyday Checking” product they offer to their customers. A product could be the AI-based loan qualification system. A Product could be the Financial Advisor services they offer as an additional revenue stream.

Weeding through the confusion

My mentor in all things Product Agility, Anne Steiner sums it up this way:

“Product Agility is having that ability to get common alignment with what we’re building, why we’re building, who we’re building it for, and then bringing that all the way through that process: shortening those delivery cycles so that we can learn faster by having real code in the market real validation of our assumptions, and then adjusting. Product Agility is unlocking a company’s ability to learn to maneuver and pivot.”

I have had success framing the discussion of Product in this way:

A Product:

• satisfies a business need

• delivers value to the stakeholders (internal or external)

• has a clear boundary and customers

• achieves some measurable value

These examples might help to provide leaders with a pragmatic way of thinking of their products:

The next step in having leaders from both the Agile transformation and traditional PMO move forward with a more flexible funding approach is finding a way to help them comprehend how the two seemingly disconnected concepts of Project Funding and Product Agility are intertwined.

The example of the “Website Project”

Something virtually every organization can quickly wrap their head around is their web presence on the Internet. They all will have a website which ‌serves multiple purposes. It falls squarely into the Business Products category we defined for Product Agility. The benefits the website provides will be readily known to these leaders and easily understood:

1. Create a global presence 
2. Act as a point of contact 
3. Sell products
4. Share the latest news 
5. Learn about customers
6. Market your organization to potential employees 

So, if we agree the website should be treated as a Product, we can then move into the more challenging cultural shift of how we budget for the work. 

In a traditional Governance Board model, we would be required to go into that “smoke-filled room” with our funding requirements for the following year. We may be expected to provide any or all of the following:

• Project Plan
• Business Case
• Project Schedule
• Risk Register
• Scope Statement
• Project Budget
• Business Requirements Document (BRD)
• Resource / Capacity Plan
• Project Proposal
• Project Brief

All of this to justify the existence of a team (or group of teams) who is already acknowledged as providing a technical solution which is integral to the organization. The Project Packet with the aforementioned documents is taken to the Governance Board looking for a Go / No-Go decision.

Is it really in the realm of possibilities that the Website Product will not be funded?

There is a better way—Lean Portfolio Management

In our example, Leadership may come to acknowledge that traditional methods of portfolio management are not aligned with the needs of their Agile website product. An alternative approach is to adopt Lean Portfolio Management practices. Lean Portfolio Management (LPM) describes how senior leadership applies lean principles to connect strategy to execution. Portfolio management teams learn about an enterprise’s strategy and allocate a budget towards the execution of that strategy.

Like any portfolio, an LPM portfolio of investments is creatively determined and actively managed across the investment life cycle. The primary emphasis of LPM is to align Agile development with business strategy, with a focus on driving the delivery of value to customers through the creation of products and solutions. Combining LPM with Agile development practices offers a path to improving business agility.

While traditional Project Portfolio Management focuses on creating a set of tightly structured project plans and building short-lived teams to execute those plans, LPM focuses on:

• Bringing loosely structured value opportunities to long-standing teams-of-teams
• Asking teams to define the needed work
• Monitoring emerging solutions to iterate toward market fit

One of the biggest benefits of moving to a value-based funding model (in our example based on the value the website returns to the organization) is that much of the decision making is pushed down the organizational structure to the team themselves. Your development team has the information to make the best decisions. 

Additionally, value-based funding improves the quality and working environment of your teams. For example, projects often start and stop, and teams get reallocated. But with this value-based product-centric approach, you maintain the same knowledge on the same team and keep development flowing continually. You also eliminate the demoralizing exercise of “justifying one’s existence”. This gives your developers deep subject matter knowledge on their software and lets teams build a natural rhythm based on working with one another over an extended period, thus improving their productivity.

When a budget overrun happens in a project, it can cause major development delays while the entire project is recalibrated. Setting annual budget boundaries for the team, aligned to the value they provide, helps to eliminate such delays.

Achieving an outcome where a traditional organization embraces the concepts of Product Agility and Lean Portfolio Management is no small feat. It will require patience and the ability to “sell” leadership on the value these changes will bring to their organization. But as LPM becomes more pervasive in the marketplace of ideas, it will allow Coaches to focus leaders on the benefits of keeping development teams aligned and working uninterrupted, maintaining an openness to change and empowering development teams while keeping the focus on bringing the greatest amount of business value to your organization.

If you’d like to dive deeper into a solution to the portfolio management conundrum, consider our white paper, “Getting Started with Portfolio Management” or our webinar, “How to Get Started With Lean Portfolio Management”.

Dan Gilio