Using Product Portfolio Management to Improve the Efficiency of Teams


Cycle Time: The Key Metric
The value stream provides us with a better metric to guide our decisions than productivity levels which may actually work against us. One way to lower induced work is to remove the delays that cause it. Reducing delays will reduce the time it takes for our work to flow from conception to consumption. We call this the value stream’s cycle time. Shortening our cycle time will necessarily shorten the delays between the work being done. This makes cycle time the key metric to focus on to see how efficient our process is. The value stream highlights where induced work is occurring by making the delays between our work visible. These delays show up as bottlenecks and delays. Looking at cycle time helps you understand when features are too big or when there are too many in the pipeline. Properly managing the size and number in your portfolio will have a significant impact on your cycle time.

Starting an Agile Transition Without Considering Product Portfolio Management
The common mantra in the Agile world today is to start a pilot project—focused on creating team agility. The intention is to scale this process throughout the entire organization after one or two teams have learned it. In many organizations, however, the real problem isn’t so much the teams’ process as much as it is too much work being handed to the teams which keeps them working in a haphazard and inefficient fashion. Oddly enough, this team-pilot approach often has great initial success but is not able to scale to the organization. This occurs because the team selected for the pilot projects is told to work on one project. They achieve much greater productivity mostly because they have created the team to be focused on one-project, are often co-located, and have all of the skills they need to do this on one team. We’ve seen these factors have just as much impact on a team’s efficiency than agile methods.

Of course, they may not truly understand this and likely will attribute it to their new process. As they add more agile teams, the rest of the organization actually gets worse and worse. Eventually, the local improvements of the agile teams is more than balanced out by the increasing burden placed on the other teams. Some point to this as evidence that agility works since the agile teams are doing well—even if the organization is not improving. Ironically, the more the teams as a whole are being overloaded (that is, the more the need for proper portfolio management) the better the pilots will appear compared to the other teams. This is one of the key reasons agile pilots work but then agility at the enterprise level fails.

Ken Schwaber, co-creator of Scrum, has said “I estimate that 75% of those organizations using Scrum will not succeed in getting the benefits that they hope for from it.” While this number has been generally agreed to among software consultants, the reason why is not. I was initially going to say “hotly debated” but in fact, most agilists haven’t investigated the cause for this other than the immediate assumption that the failure occurs due to lack of motivation or discipline within the organization.

Our experience is that team-focused agile methods don’t provide the insights required to remove the organizational impediments that they face. A more holistic, value-stream oriented view geared toward shortening cycle-time provides these insights. Scaling often fails because the root cause of the impediments in the value stream are not observed, let alone dealt with. Agility can be achieved across an organization when the entire value stream is considered—not merely for a lucky team or two selected for the pilot project. 

[1] Note: Features of this type are often called Minimal Marketable or Minimal Viable Features.

About the author

AgileConnection is a TechWell community.

Through conferences, training, consulting, and online resources, TechWell helps you develop and deliver great software every day.