Efficiency and Effectiveness

Most software teams and organizations waste 40% or more of their resources. I can’t prove this assertion, but most of us know it to be true in our current situations. Just ask your team. In larger enterprises and in organizations with compliance requirements, the ratio of productive activities to waste is even more pronounced.  Waste comes in several forms: unnecessary overhead, unnecessary rework, unnecessary features, and building the wrong thing.

Better business outcomes demand two key advances:

  1. More effective steering through earlier and continuous feedback.
  2. More efficient execution through lean transformation.

Effective steering is enabled by shift-left practices and more honest measurements. This is a well-established theme of agile methods and lean startup practices. Early and continuous feedback from users helps us steer toward higher value. By shifting-left the highest risk and highest value decisions earlier in the life-cycle, we can reduce waste in downstream rework. The simplest way to stimulate shift-left steering is to plan for integration testing to precede unit-testing. Integration testing exposes the bigger uncertainties (usually inherent in the design) and the more valuable behaviors (usually system level features). Resolving these big uncertainties earlier results in less downstream rework and less time wasted building the wrong things. Objective instrumentation of the product pipeline (instead of activity pipeline) leads to more honest progress and quality feedback. Measuring the bottlenecks, throughput, volumes and wait times of testable product increments enables more objective steering toward more predictable outcomes. The process measures of the past have proven to be easily gamed and too subjective to accurately measure execution progress. More effective steering is enabled by prioritizing the highest risk and highest value decisions earlier in the life-cycle.

Efficient execution requires lean thinking. Let’s loosely define value-added and non-value-added work by looking at the essential product (what users buy) and the non-essential supporting artifacts (what we need to build the product).

  • The deliverable product is code, data, test cases, build/deploy scripts. Productive activities like designing, coding and testing directly transform the product.
  • Supporting artifacts include the secondary process-oriented information that keeps teams unified – Plans, requirements, models, progress reports, quality assessments, traceability, procedures, and compliance data. Producing and changing these supporting artifacts is largely overhead and non-value-added. Some of it is necessary, but much of it can be streamlined or automated.

With this stark and simplified definition of what is value-added and what is non-value-added, we can then reason better about where we can improve efficiency. Minimize rework in the primary product and minimize the overhead resources expended in supporting artifacts.

This is the essence of lean thinking: maximize time in value added work and minimize time in non-value added work and unnecessary rework.

Be Sociable, Share!

Tags: , , , , , ,

Leave a Reply

CommentLuv badge