OnPoint, LLC

Lean – Agile Program / Portfolio Management – What’s New?

As organizations begin to scale the use of lean-agile methods, they soon identify impediments in the area of program & portfolio management.  Following are three major categories of impediments, as summarized below:

  1. Funding - Project-level budgets established 12-15 months in advance cannot accurately predict agile funding requirements
  2. Capacity / Change Management – the flexibility of agile scoping and delivery will quickly overwhelm granular resource capacity plans
  3. Governance – Traditional metrics regarding (time, cost, quality) and phase-gate reviews do not accurately depict the health of agile projects, so more meaningful metrics are needed

Clearly, the movement toward  agile development will require some significant rethinking of program and portfolio management.  The Scaled Agile Framework (SAFe) provides a unique perspective on lean-agile program portfolio management.  Among other things, SAFe proposes a continuous flow of epics rather than discrete projects with specific start-end points.  It also proposes lightweight business cases and rolling wave planning among other changes.  Following is a link to a SAFe abstract on lean program portfolio management:


The SAFe abstract also references a case study on agile portfolio management from DTE Energy.  It can be viewed by clicking on the link below:





Risk Management and the Lean / Agile Frameworks

Here’s a link to a AgileHood KC post on the application of risk management practices within the lean / agile frameworks.



PMO positioning – Is the current state good enough?

So, what do PMOs do anyway? Since PMOs have been around for years, it seems like this would be a simple question.  However, as recently as 2012 the Project Management Institute (PMI) found that there was considerable confusion among executives, managers, and even project/program managers around reporting relationships, functions and types of PMOs.  To help address the confusion, PMI initiated a study and published the results in late 2013.    Following is a link to the study:


The study identified five PMO frameworks:

  1. Organizational Unit, Business Unit, or Department PMO
  2. Project-Specific PMO
  3. Project Support/Services/Control PMO
  4. Enterprise/Organization-wide/Strategic/Corporate/Portfolio/Global PMO
  5. Center of Excellence/Center of Competency

The study identified “PMO domains of work” that included:

  • Standards, Methodologies and Processes
  • Project/Program Delivery Management
  • Portfolio Management
  • Talent Management
  • Governance and Performance Management
  • Organizational Change Management
  • Administration and Support
  • Knowledge Management
  • Strategic planning

The report goes on to analyze PMO survey results against multiple criteria, of which a couple of points are worth noting.  While the PMOs self-reported good results for the typical PM measures of goals, time and budget, they were less sanguine about their leadership in strategy formulation and project alignment with strategic objectives.

So, back to the original question, “what do PMOs do?”  This report seems to reinforce the perception that PMOs are focused on administrative and tactical outcomes but are not positioned to drive strategic business results.  Is the current state good enough?  Or does this report identify a growth opportunity for PMOs?

Rethinking the PMO Mission in an Agile World

Here is a link to an Agilehood KC blog on re-thinking the mission of the PMO to support an agile transformation.




Collaboration Issues – Is there an iceberg nearby?

Agility requires collaboration.  You will not hear many arguments against that statement.  After all, one of the four agile values is “individuals and interactions over processes and tools (www.agilemanifesto.org).”  Collaboration enables quick feedback, allowing teams to solve problems faster, and increase velocity.  High-performing, self-directed teams cannot exist without collaboration.  And yet in many organizations, even those that have been on an agile journey for some time, there are built-in barriers to collaboration.  Here are some examples. 

  • Hierarchical organizational structures that hinder horizontal communication
  • Leaders who promote “us vs. them” inter-departmental rivalry
  • Managers who behave as if their sole mission is gatekeeping
  • Office floor plans that prevent team co-location because they were designed to allow line managers to “keep an eye on” their developers
  • Line managers who insist on “no surprises” and being the first to know everything


These barriers are remnants of the command and control culture in which many of us built our “pre-agile” careers.  Some barriers are so ingrained in our thinking that we may not notice them anymore, but they will manifest directly or indirectly in the form of impediments raised by our teams, such as:

  • Product owners who are disengaged, delaying needed decisions on priorities or sign-off on completed deliverables
  • Toxic behavior (e.g. back-biting, gossip, emotional outbursts) by team members
  • Miscommunication regarding success criteria, resulting in challenges integrating deliverables from other teams
  • Subject matter experts who do not have sufficient band width to consult with the team when needed


So what can we do to remove barriers to collaboration? We can chip away at the problem by attempting to remove impediments as they are raised up by our teams, but that will be not be sufficient.  Since these impediments exist because of legacy beliefs, values, and behaviors, the real solution lies in the cultural change that must accompany any agile transformation. The subject of changing culture is beyond the scope of a single blog post (or even an entire book) but for now it is helpful to understand that collaboration barriers are merely the tip of a pretty large iceberg.

Product Development – “Are we there yet?”

Those who sponsor software product development are frustrated by the time it takes to go from a great idea to the first trickle of revenue.  The months slowly pass and the sponsors adopt the refrain of children during a long road trip, asking “are we there yet?”  The product development team provides the parental response, “we’re almost there” and continues the usual product development practices.

The book, “The principles of Product Development Flow” by Donald G. Reinertsen, proposes that the sponsors are justified in their complaints that teams are taking a long and tortuous path to market.  Specifically, he points out that product developers focus too much on capacity utilization and not enough on cycle times.  As a result, the developers create large batches of work that result in large queues of work that are invisible to the product developer’s dashboards.

Reinertsen proposes a new flow-based product development framework, adapted from lean manufacturing, that seeks to measure and reduce the size of queues by reducing batch sizes and applying WIP limits. He proposes a prioritization method that takes into account cost of delay and the size of the job being scheduled.  Underlying this framework are some 175 principles that complement those of agile software development.  The book is quite deep and may require a couple of re-reads before the concepts settle in fully.

Per Reinertsen, this framework results in product development process improvements of 5 – 10 times, thus allowing product development teams to honestly tell their sponsors that, “we’re almost there.”

Agilists – watch your language!

It appears the agile principle that “business people and developers must work together daily throughout the project” is often not followed in practice.  When practioners share their experience with agile transformation they frequently complain that the business is not fully engaged.  Perhaps we agilists are complicating matters unnecessarily.  We produce metrics that describe things such as story point velocity and wonder why our executive sponsors appear catatonic.  We schedule meetings with odd names like “scrum of scrums” and wonder why business people do not attend.  We have developed language and ceremonies that are completely foreign to the business and have therefore created the impression that this agile thing is for IT.

If we are serious about agile at scale, we need to adapt our communications to the needs of the business.  Don’t make them learn our secret handshakes and gang signs.

Respect – it goes both ways

At a recent workshop, the instructor noted an animus among agile teams towards managers and executives.  Perhaps it is inevitable that, with the focus on self-managed teams, agilists would discount the importance of those outside the teams – particularly “management types.”  After all, managers are the ones who set impossible deadlines, implement bureaucratic controls, and resist change.  However, it is also helpful to remember that managers fund projects, help remove impediments, and sign paychecks.  If we agilists like these things, we should begin to appreciate the people who provide them.  Otherwise, the agile movement could stall at the team level and fail to achieve its full potential at the program and enterprise levels.

We should approach managers with at least the same respect that we demand of them.




It’s a tough life for a purist

As the agile movement has grown, there has been a corresponding growth in the lamentations of agile purists.  They weep over teams that perform manual acceptance testing, saying that they are not “truly agile.”  They grieve over teams with programmers who are split between new development and production support duties, and call them “scrum-buts.”  They mourn over organizations with formal change control processes, labeling them as “waterfall clingers.”

Perhaps it would be helpful for the purists to cease rending their garments, relax a bit and remember that the transition to agile should be driven by the needs of the business and will be constrained by existing culture and processes.  A mature organization in the financial services sector will transition at a different pace than a start-up software firm.   The agile principles (www.agilemanifesto.org/principles.html) should provide the vision for the transition and the practices should be allowed to evolve at a reasonable pace.

The agile purists will persist in their anguish while the rest of us find our own path to success.

Getting in touch with your inner control freak

We like to criticize managers who have an excessive need for control.  We refer to them as micromanagers, control freaks, and the antithesis of organizational agility.  Rarely do we refer to them as the person in the mirror.

I have observed far too many of these “hands on” managers over the years and have identified a couple of common traits.  First, they tend to be very conscientious.  They are driven to perform their duties to their utmost ability.  They are willing to put in as many hours as it takes to accomplish a task.  As a result they are quickly promoted to the ranks of management.  A second, far less endearing trait is that they speak with disdain about others.  They accuse one person of being lazy and another of being stupid.  They question the judgment of one peer and the honesty of another.   After a brief conversation with a micromanager, it becomes clear that no one is up to his standards.  This prideful attitude is the reason they are unable to delegate.  After all, how can one delegate to someone who is incompetent?

So, returning to that person in the mirror, how often do we fall into this pattern of thinking ourselves?  A little humility may be in order.  That humility may result from getting to know a team member well enough to understand his areas of expertise.  It may come from an embarrassing, public mistake of our own.   A sure cure would be to assume management responsibility of a function for which we have no experience.

From time to time it is good to get in touch with your inner control freak.  And then knock some sense into him.

« Previous PageNext Page »

OnPoint, LLC