OnPoint, LLC

Beware of Assumptions – They May Bite

Those of us who work with projects are always making assumptions.  We think about them briefly when writing the project charter, and they seem so reasonable at the time.  Certainly the customers will use the new product and will tell all their friends about it.  And there is no question that we will get our product to market faster than our competitors – even those competitors that are not currently on our radar.  So, we spend the next 3 months, 6 months or more working on the release only to find that our assumptions have bitten us in the … leg and make us look foolish. 

The agile frame work, with the reliance on the judgment of product owners, may help prove or disprove the assumptions before we launch the new product.  But product owners are proxies for the real customers in the market and may make incorrect assumptions about priorities and product features.   The customers are the ones who are most able to either prove or disprove our assumptions, but how do we engage them?

Eric Ries, who wrote the book, The Lean Start Up, proposes a systematic management process that calls for validating product strategy assumptions via the development of a “minimum viable product (MVP)” that can be used by potential customers very early in the product development process.  The metrics resulting from the use of the MVP provides input into decisions to either “pivot or persevere” with the original product strategy.  Here is a link to a website that discusses the book, the process, and the movement in support of lean product development http://theleanstartup.com.

If you are contemplating a new product or service and would prefer not to be bitten in your assumptions, it would be worthwhile to investigate the lean start up process.

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.

« Previous PageNext Page »

OnPoint, LLC