Do Less

Many managers use the mantra, “Do more with less.” At the Agile 2010 conference, Pat Reed from the GAP, who co-presented with me, shortened this mantra to “Do Less.” The theme of our presentation was Value Optimization, determining the highest valued chunks of functionality to implement next—whether those chunks were projects in a portfolio or stories in an iteration planning session. By developing in an agile fashion and deploying features frequently (even continuously as being described the emerging agile practice of continuous deployment) value can be recognized by the business early and often.

In an agile project the team always tries to work on the highest-valued story. But what about when the highest-valued story is from the next project in the development queue? Towards the end of a project, or even earlier, the highest-valued story or feature may be on the next project, which means it may be time to stop the current project, and move on. The Agile Triangle emphasizes the idea of a “releasable product,” when the product delights the customer but may not have all the functionality originally considered.

Three studies conducted by the Standish group, the DOD, and reported by IEEE in the early part of this decade indicate that far more that 50% of functionality in software is rarely or never used. These aren’t just marginally valued features; they are no-valued features. Think of the cost, think of the opportunity cost of these features. Think of the benefits from doing less, from eliminating these features. A CIO friend of mine once delivered a CRM application with 25% of the originally requested functionality—and the customer was delighted. In fact, the customer cut off development! The other 75% of features proved to be “nice to have” but not significant contributors to business value.

The premise of allocating value to the feature level (see Agile Project Management, 2ed. For more details on how to calculate) is to both “Do the highest valued chunk of work,” but also to “Do Less,” to eliminate marginal valued features and cut functionality on those features with lower value. “Do Less” has other connotations. Reducing work-in-process, for example, increases throughput by cutting down on time-wasting multi-tasking. Value stream mapping show us where to cut out non-valued adding activities.

In looking at value capture, agile managers need to examine cumulative value delivered versus cumulative cost incurred on a project. Then questions can be posed such as, “do we want 100% of the planned value for 100% of the planned cost, or would we prefer stopping at 90% of the value at 70% of the cost?” Since agile development delivers highest-valued features early, this type of management trade off becomes reasonable, even imperative, to think about. Furthermore, the reason it’s such an important question is the one raised earlier—other projects with higher value need to start sooner. Developing the last 10-20% of marginal functionality one project delays capturing the higher value on the next. So it’s not just development cost but opportunity cost that managers have to evaluate.

Do less: cut out or cut down projects, cut out overhead that doesn’t deliver customer value, cut out or cut down features during release planning, cut out or cut down stories during iteration planning, cut down work-in-process to improve throughput. At the same time, focus on delighting the customer by frequent delivery of value. It’s another aspect of “AND” leadership.

In an agile organization the mantra should be “Do Less”, and maybe use the time and money saved for reducing technical debt, new innovation, and improvement initiatives.


    1. Bill Monroe says

      Excellent advice.

      I would add that, because most organizations are outstripping their Capacity for Quality Work (CfQW) the “Do Less” mantra is even more relevant in today’s environment.

      We should not only look to cut projects of questionable value, but also projects for which the probability of success is not sufficiently high.

      Bill Monroe, Project Portfolio Excellence

    2. Nice article. I agree with your view above and a refreshing thought in your article is the one about moving on to the next project to be able to maximize value. I see and hear more people today questioning the concept of projects; suggestions on moving projects over to maintenance earlier and earlier. Some even propose skipping the project phase alltogether and go directly into maintenance. I’m not convinced that going directly into maintenance is optimal at all times but I do think that having products in a maintenance phase often increases business agility and gives a greater freedom in prioritizing new features according to business value.