OnPoint, LLC

Means vs. Ends

I’ll start this post with a comment by Dr. Alan Weiss:
“The entire point of bureaucracy is the triumph of means over ends. The results don’t matter, only that the rules are strictly followed.”

Do those of us focused on lean | agile practices run the risk of setting up new bureaucracies to replace the old waterfall bureaucracies? Do we pay too much attention to the means (stand-ups, Kanban boards, story-points) and not enough attention to the ends (business results)? Do we focus so much on following rules that we lose sight of the external business environment, strategy and objectives? Do we understand the “definition of done” for implementing lean | agile practices?

I raise these questions because I am starting to experience déjà vu. Nearly two decades ago, a friend worked at a company that went all in for Six Sigma. The Six Sigma initiative took on a life of its own. Strong leaders were pulled out of line functions, became Master Black Belts and sponsored projects that were only loosely aligned with the business strategy. My friend, who was an English major, was required to learn Mini-Tab in order to retain his executive position. The change management program took hold and people at all levels began using acronyms such as DMAIC, DMADV, CTQ and VOC in normal conversation. Those who resisted change either left the company or their careers were derailed. The Six Sigma effort became bureaucratic and “enforcers” ensured that all the Six Sigma rules were followed to the letter. When viewed from a change management perspective, the transformation was successful. Unfortunately, the business failed and it was eventually sold to a competitor. The problem was not Six Sigma per se. The problem was that Six Sigma became the end.

As we embark on efforts to scale lean | agile principles and practices, we need to remind ourselves that we are seeking to improve business outcomes and the principles and practices are merely an effective means toward that end.

The Business Value of Speed

When we think of business value, we often think in terms of Return on Investment (ROI).  We may undertake a project with an eye toward reducing head count or otherwise leveraging the productivity of employees.  This view of business value has some inherent limitations.  The project costs often exceed the original budget, thus diminishing the ROI calculation. When the system is implemented, the anticipated headcount reductions are rarely taken.  Instead, the efforts of the employees are shifted to other activities which may or may not be more valuable.  More importantly, we are not increasing business value by more efficient work on products or services that our customers no longer want.

In today’s rapidly changing competitive landscape, speed can be far more valuable than squeezing the last ounce of productivity from administrative processes.  Consider the business value of launching a new software-based product six months earlier, responding to a customer question immediately rather than requiring a call back, or completing a customer project in a month instead of a year.

Should you adapt your metrics to focus on speed over mere efficiency?


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.

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.



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.




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.”

Is it Agile Decision-making? Or Inadequate Planning?

Even in a well run organization, it may be necessary to cancel a project in response to new information. A new competitor may have already introduced a game-changing product. Market pricing may have changed, making a new product economically infeasible. It may be necessary to reduce capital outlays to keep the business afloat. Cancelling a project under these conditions may be a great example of agile decision making. But it could also be a sign of inadequate planning.

Whenever a decision is made to cancel a project, it is worth taking some time to reflect on the project and ask a few questions:

  • What were the flaws in the original planning premises?
  • Do these flaws indicate shortcomings with access to market intelligence?
  • Was the project clearly tied to a strategic objective?
  • If the project was tied to a strategic objective, should that objective be evaluated?
  • How was the decision made to launch the project?
  • Would there have been a different outcome with a different project team?

Cancelling a project is a very painful decision and it is human nature to want to move on quickly. An agile leader must ensure that the organization first learns from the pain, and then moves on.

On time and on budget, but did the business benefit?

The project finished on time and on budget, therefore it was a success. From a project management perspective, it would appear that this is a true statement. As project managers, we are obsessed with reaching milestones. We monitor our project burn rates with greater scrutiny than our personal bank accounts. To a project manager, schedule slippage and cost overruns are signs of poor planning or sloppy management. On the other hand, it may be a sign that the project manager is thinking like a business owner.

When faced with a decision to delay a project implementation until quality concerns can be addressed, a business owner would consider the longer term impacts. A year from now, what would be the impact of a delay? What would be the impact of a flawed implementation? The proper business decision might be a brief delay.

Some projects, particularly new product launches, are inherently risky. Success criteria may not be clearly understood and the initial project approach might require a few corrections. From a project manager’s point of view, it would be preferable to undertake a thorough project planning process until all planning premises are clear and the budget estimates are solid. From a business owner’s point of view, the business benefit of being first to market might outweigh the risk of cost overruns.

The discipline of sticking to deadlines and budgets is critical to effective project management and, in most cases, the business benefits from such discipline. However, when there is a conflict between project management discipline and business benefit, the project manager must think like a business owner and promote the best interest of the business.

Becoming both a quitter and a winner

Agile organizations must be prepared to adapt quickly to changes in the market. To pursue a new opportunity, they must be willing to re-deploy scarce resources by abandoning a product, service or activity that already exists. The decision to abandon is painful and is typically delayed far too long, thus depriving the new opportunity of resources.

In his book, Management Challenges for the 21st Century, the late Peter Drucker proposed that abandonment decisions must be practiced systematically. Drucker described an outsourcing firm that scheduled abandonment meetings on the first Monday of every month. At each these meetings, all levels of management complete a comprehensive review of one aspect of the business and identify what should be changed or abandoned. Twice a year, all levels of management must report on the actions taken as a result of these meetings.

Without a formal review process, unnecessary work and unprofitable business will drain resources and impede progress. If you periodically review your operations, you will find projects that should be canceled, services that are no longer profitable, and reports that no one reads. Such work should be identified and eliminated. Your competitive edge could very well result from the work you don’t do.

Life in the fast lane

You see them on the freeway, driving in the left lane, 5 feet behind the next car, staring at their cell phones and eating breakfast.  Their driving style limits their ability respond to changes in road conditions or to react to the actions of other drivers. They take an excessive amount of risk in order to save a couple of minutes. There is a good chance that, if they make it to the office safely, their driving style will carry over into their work.

Excessive speed is standard operating procedure in business today.  Staff levels have been cut but workloads have not, leaving no resources to maneuver around obstacles and pursue new opportunities.  There is an excess of activity and a shortage of results. As the Eagles (the band, not the football team) would say, life in the fast last will “surely make you lose your mind.”  Is it time to back off the throttle? Following are a few thoughts how to slow down and still improve performance.

  • Challenge the thinking behind deadlines. Is there a business need for to hit this particular date? Or is the date merely a means to create a sense of urgency?
  • Adjust your project portfolio to make sure it is complete and matches your capacity. It is common for people to work on projects that have not yet been identified, approved and prioritized. Even if they are working on approved projects, the sequence of those projects may result in bottlenecks while awaiting the availability of key subject matter experts. Try to stagger project start dates to minimize the risk of colliding priorities.
  • End a project and declare victory. When employing an agile project approach, business value is delivered incrementally according to priorities set by the business owner. After a point, the incremental business value for a given project may be lower than that of a competing project. You do not need to complete every deliverable on the backlog list. Take a look at the entire portfolio of projects and identify those that can be considered complete, then close them out and free up the resources for other work.

« Previous PageNext Page »

OnPoint, LLC