There are two aspects of Lean Portfolio Management (LPM) that are often overlooked, but are the real key to the success of any large-scale agile adoption. Everyone knows that effective Agile and LPM implementations require high levels of decentralized decision-making, with empowered teams iterating towards cost-effective and profitable solutions.

The expectation is that the LPM Team can take a hands-off position and rely on the teams to be able to address all their impediments by themselves. Just give them the money, point them in the right direction, and get out of the way. But there's two particularly important aspects of Lean Portfolio Management that require frequent, hands-on input from the LPM Team.

In the first part, we looked at LPM’s ability to improve decision latency. This month, we will examine the elimination of ‘dark work’.

As Jeff notes, amongst the root causes of Dark Work are:

• A lack of direction that causes staff to make up work.
• An unwillingness to prioritize that proliferates useless projects and products.

As we shall see this also chimes with my own personal experiences.

As we can see from the figure above, Jeff believes that typically 30% of our effort is going into things that don’t support our mission or our vision. People working on pet projects and things that don’t align with the overall goals and vision of the enterprise. I find this easy to believe, as it aligns with many of my own experiences.

A long time ago in a galaxy far, far away, a young Smalltalk programmer was recruited to help build a next generation finance system. Things went well for a while – major vendors were engaged, cutting-edge frameworks were produced, potential customers were engaged, MVPs were produced, leading developers were head-hunted by the competition – but unfortunately it turned out that the senior vice president sponsoring the initiative had literally embezzled the funding. Possibly the darkest of dark work, but the kind of thing that can easily happen in organizations where people feel entitled to develop whatever they want, regardless of the provenance of the funds they are consuming or the strategic direction of the company they are working for. In this case it really was the ‘field of dreams’ business case – “if we build it, they will come” and unfortunately, they didn’t come fast enough to save the vice president from ‘redundancy’.

You may think that this could never happen in your organization, but variants of this behaviour are more common than you might think, particularly in many ‘agile’ organizations where there is a culture of empowerment without any alignment.

It can also occur in a subtler form in more controlled environments.

More recently, a not-so-young Agile Coach was challenged to help with the introduction of Lean Portfolio Management practices for the IT side of a FinTech company with a track record of over 20 years of successful agile development. Whilst presenting the Dark Work slide above as part of the business case for adopting a leaner portfolio management approach, the IT Leadership took umbrage to the suggestion that there was any Dark Work going on. “Everything we do has clear business sponsorship and approval; how can it be Dark Work?”

Well, once the current work in progress was visualized and quantified, the numbers showed that less than 5% of the IT Department’s effort was being directed at the most important (top 10) initiatives². The figures also showed that there were over 120 large initiatives in progress, many of which had not had a single story done for them in over 6 months. Even then, new initiatives were being approved every month – sadly, this is just what approval bodies do. With the adoption of leaner portfolio management techniques, the overall focus and numbers quickly started to improve, and it was a ‘red letter day’ when the approval body started to cancel some of the previously approved initiatives.

So even highly successful agile development teams can suffer from Dark Work. The problem of Dark Work is not specifically an IT problem, but one that often permeates the whole organization.

The cost of Dark Work is also higher than you think. It’s not just the cost of the developers doing the Dark Work that impacts your organization. There are other huge indirect costs, as Mark Zuckerberg noted when talking about the impact of Meta’s recent down-sizing: “Since we reduced our workforce last year, one surprising result is that many things have gone faster. In retrospect, I underestimated the indirect costs of lower priority projects.”³

Our goal with LPM is to achieve a laser-like focus on our top business priorities without compromising our overall agility.

This isn’t about top-down control but the continual adjustment of the direction of the portfolio as a whole. This requires the active involvement of the LPM Team and their Guiding Coalition - not a single gathering of the overall decision makers once a quarter. Ideally, they would meet at least once every two weeks, if not daily.

The overall portfolio cadence is key to limiting the amount of Dark Work within the portfolio. As well as establishing a foundation of transparency, the best policy I know for balancing alignment and empowerment is ‘trust but verify’. The trick is not to leave the verify until it’s too late to affect the outcomes. In a truly agile organization, if people embark on some dark work that's not aligned with the overall strategy the worst they can do is waste 2 – 4 weeks of effort, one Sprint, before the review process will shine a light on it.

By eliminating the Dark Work within your organization, the successful adoption of Lean Portfolio Management practices can easily produce a 30% improvement without anyone having to work any harder or change their other working practices.

Combine this with improved investment decisions, reduced decision latency, and the benefits of agile product development and the sky’s the limit.

Sadly, it is not always an easy change to make, which is why I’ll attempt to illuminate the challenges and some of the hidden pitfalls of LPM in future blogs.

The SAFe Blog

Interesting thoughts and insights from SAFe Fellow Ian Spence