Enterprise Agility – The Big Picture (14b): More on Agile Portfolio Management and the Legacy Mindset

Note: This is part of a continuing series (see the Big Picture Category on this blog) wherein we introduced an overview graphic intended to capture the essence of enterprise agility in a single slide. In a series of continuing posts, we have been working our way from the bottom (stories, iterations and the like) to the top where the enterprise vision and portfolio management resides. This post is one in a miniseries describing the last big icon on the upper left – Agile Portfolio Management.

The Big Picture - Agile Portfolio Management

The Big Picture - Agile Portfolio Management

In the last Big Picture Post, we introduced the portfolio, along with the challenges that agile teams are likely to find as the impact of their new and more productive models wends its way to the Project Management Office (PMO), which in some cases can be the “mother ship of potential agile impediments.” We also introduced the excellent DTE energy case study: Establishing an Agile Portfolio to Align IT Investments with Business Needs. This case study is an example of how an agile enterprise can first recognize, and then successfully address the significant changes necessary to allow the emergence of true enterprise agility benefits.

Since that post, I’ve been thinking that I would expound on the legacy mindsets that called out in the case study. But I’ve decided I can’t. They are just too well done and so symptomatic that I decided just to repeat them here. However, the accompanying descriptions and paraphrasing are my own. These are based on my own experience from two perspectives; 1) then, as an executive, managing portfolios and carrying some elements of these mindsets, and 2) now, as an agile executive attempting to change those very same mindsets!

The legacy mindsets called out in the DTC case study are:

  • Widget engineering – The belief that software development is a repetitive, controlled and manufacturing-like business, rather than Research and Development. “Draw it up and build it like you drew it,” goes the thinking.
  • Order Taker Mentality – Also known as “build what we tell you to build”. Founded on the belief that the customer is always right, seemingly all-knowing and under the assumption that they actually know what their requirements really are. The teams should just build it.
  • Maximize utilization- The belief that if all resources aren’t fully utilized on paper then they won’t be fully utilized in practice. “They’ll just be idlers, wasting their time, waiting for their next assignment.” goes the thinking. “Fully assign them or lose them”.
  • Control through data – The belief that
    with the right kind of data – earned value metrics, design reviews, requirements and test plan inspections – we can tell where we are on the project. And then if we still can’t tell where we are, we’ll just ask for more detailed data until we can.
  • And we can plan out a full year of projects- Conveniently disregarding our last 20 years or so of experience in failing to predict projects a year in advance, we assume it’s a failure of our planning, not a failure of the basic paradigm. “If we only planned in more detail, we could really get it right this year.”
  • Get it Done – The belief that our best case plans can be reality if we only try hard enough.
    Also known as: “That was the plan we agreed to, now execute it.” And “when the going gets tough, the tough get going”. And lastly, the infamous “we know it’s impossible, that’s why we hired you for this job.”

Perhaps it’s obvious from my elaborations that I tend to get somewhat passionate about this topic. Perhaps it’s because my guilt shows through. Surely, I have been on the other side of this fence before iterative and incremental, and now agile, development methods proved their extraordinary worth. So, I know as well as any that if these legacy mindsets are not addressed, they will kill the agile enterprise initiative as surely as a fixed content/fixed schedule 60 hr/week death march.

Here’s why. The table below shows the manifestation of these problems in practice (as described by DTE along with a few of my own) and the real problems they create for the nascent agile teams.

Mindset Manifestation Problems
“widget engineering”
Fixed schedule, functionality planning

Big Up Front Design/Analysis (BUFD)

Long range plans

Resources fully committed up to a year in advance

Analysis paralysis

“order taker mentality” Build what we tell you to build

We are the boss of you

False agreements. No buy in.

Misses innovation contribution from teams

Failure to meet expectations


No empowerment, lower motivation

“Maximize utilization” Resources committed long range

100% allocation before “what if”

Key resources assigned to multiple projects

No time to think or innovate

Dedicate resources to task or lose resources

Thrashing – lost productivity of most valuable resources

Exhaustion, burnout

“we can plan out a full year of projects” Detailed wbs, earned value metrics, fully loaded Gantt charts Plans are immediately obsolete, but not treated that way

Earned value metrics don’t reflect actual progress

“Control through data” Fine grain reporting and overhead

Milestones that are not reflective of process or progress

Reporting overhead slows actual development

Annoys and de-motivates the teams

“Get it done” Belief that best case plans must succeed Deferred recognition of plan vs. actual

Late discovery and re-negotiation

Loss of credibility, mistrust

You’ll probably recognize many of these mindsets, manifestations and the problems they create for the development teams. Many enterprises do. In one recent presentation I made highlighting the DTE case study, one PMO executive said “just delete DTE and put in [our company name here] and there you have it”!

Well enough crabbing and I’m sorry if I offended anybody. I just thought it important to walk through this pain field one last time, making sure we understand the problem so that the imperative for a solution is really, really apparent.

In the next post in this series, I promise to move to a more productive and proactive set of ideas to address these problems. One giant step further to actually becoming the agile enterprise.