I have been a consultant for some time, having the privilege of working with many great teams and organizations. More than a decade ago I was working with a high performing and empowered team. Challenged with some work in our backlog, we wanted to refactor several objects. Since other teams were relying on our functionality, we had the typical pressure of a delivery deadline. The easy answer was to simply make it work and incur the technical debt, but we all knew the right answer. One of the developers put it in terms that stuck with me, “If we don’t do this we are proving our detractors right. They say that Agile design is no design.” We stepped back and thought about the system, refactored and built a product that was better than the one we would have had, if we had taken that shortcut.
Let’s say a mid-sized company or business unit has five Agile teams working on a product. We could even go a step further and say that the teams are all capable, accountable and self-organizing. The teams may be highly efficient, each team producing results as expected.
How do we know that the overall goals of the organization are being met? Even if all five teams produced product enhancements that satisfied their niche there is no guarantee that the overall goals would still be met. Furthermore, if they employ different technologies, API approaches and test strategies, it might be difficult to believe that they could produce a fully working tested product. Having five teams, each doing well, does not mean that we are executing a business strategy. The easy answer is to just let the teams be Agile and do their own work. The right answer is to manage both the overall product strategy and product development. If we don’t manage both, we are proving our detractors right when they say that Agile management is no management.
Just as a team may need to step back and consider a wider point of view to deliver the right result, we too may need to step back and look at the overall business and technology needs to deliver what a business unit is looking for. Some call this Portfolio Management.
Unfortunately, there are more definitions for Portfolio Management than I would care to count. For now, let’s just consider the need to execute a business strategy and coordinate work across several teams. A brief list of things to consider at the portfolio level should include: infrastructure needs, enterprise architecture, coordinated high-level planning, reporting progress against long-term goals, and resolving cross team dependencies. This is not the definitive list, what your Portfolio Management addresses should serve the needs of your organization.
The classic perception of Portfolio Management has phase gates, design documentation, requirements documents and review boards. How do we reconcile that model with empowered teams, empowered product owners, emergent architecture, and frequent delivery of working tested software? The answer is applying a servant leadership model.
Portfolio Management should be a service to the business unit. A business unit with a strategic plan will want to understand progress against their goals and may even be looking for measures (financial or otherwise) to mark that progress. Portfolio Management serves the business by helping to coordinate and develop a plan to meet the business needs, this plan includes the high-level goals for multiple teams. This allows for the coordination of work to deliver maximum business value, creating a view that does not exist at the team level.
Portfolio Management should also serve the delivery teams. Taking a system view and coordinating infrastructure, enterprise architecture, test strategy, and addressing cross team constraints is work that needs to be done to help teams be successful in the broader view of product delivery. Again, this is a view that individual teams simply do not have. Portfolio Management can help make teams more successful.
Is there a place for Portfolio Management in an Agile world? Yes, Agile Portfolio Management can serve both the business and information technology needs. If we step back and think of a number of teams trying to work together to deliver a complex product to execute a business strategy, Agile Portfolio Management makes sense. I would say that anything short of good Portfolio Management may be irresponsible. Let’s not prove our detractors right.
Steve Fastabend is Senior Essentialist at Trissential/SQS