Release early, release often

Comments (1)

Print This Post Print This Post

Email This Post Email This Post


The first time I heard that particular phrase was probably Jim McCarthy’s Dynamics of Software Development in the mid-1990′s. Not only is it still the right guidance, but now we can more provide more mature reasoning about what that means and why it’s the right goal.

Determine the minimum deployable feature set, and then build that as fast as you can

If you’re in the car building business, and the design of your transmission isn’t done yet, then you are simply not ready for production. On the other hand, if you are waiting on the dashboard navigation system or the retractable cup holders, then the opportunity cost of delay probably outweighs any incremental value those requirements will deliver. Ship now, and when those features are ready, roll them into production.

If you ask Marketing what the minimum deployable feature set is, you aren’t likely to get a very helpful answer. The minimum feature set has to be about logical completeness. A car without a transmission is illogical. A car without a motorized heated cup holder is not. When you can’t take anything else away without making the system clearly nonsensical, then you’ve found the minimum set. Some of the matrix-based design techniques like Axiomatic Design can help you figure this out more formally. We’ll get to some articles about those shortly.

For every feature that you add beyond the minimum deployable set, but without deployment, your costs now include all of the revenue that you are not generating from the product that you could have released, in addition to your ongoing operating expenses. If the goal of your business is to make money, then you want to start realizing those earnings sooner rather than later.

Even if a competitor has launched ahead of you with a larger feature set, don’t try to compete with them on scope. Compete on productivity. If your business produces new features at a faster rate, it won’t take you long to overtake them. If that faster rate is also steadily increasing (an expected outcome of a Lean process) at a faster rate, then you will quickly leave them in the dust. Know this and manage accordingly.

When you’re designing your design process, first visualize the Ideal Final Result

TRIZ1 is a treasure chest of useful ideas, and one I have found especially fruitful is the notion of the Ideal Final Result. The Ideal Final Result (IFR) is the perfect action or outcome in the abstract. It is free of any mechanism, and it is free of any constraints of the solution domain, in a world without friction, without entropy, and without costs. If you can imagine your ideal state or your ideal function without any of this extraneous noise, then you can start to introduce real mechanisms in a way that facilitate that outcome with the least interference. At the very least, the IFR gives you something to be dissatisfied with in your inexhaustible quest for perfection.

In microprocessors, the Ideal Final Result might be an infinite number of infinitesimally small transistors with zero energy consumption. Moore’s Law describes how real microprocessors evolve in the direction of this ideal.

In pull scheduling, Single Piece Flow is the ideal result. A Value Stream identifies all of the processing steps that are applied to component materials in order to make the desired product. The word stream implies that there is a smooth, unbroken flow between a sequence of processing steps. Part of this can be achieved by allowing downstream states to pull work items from upstream states when capacity becomes available to do work. This can be implemented with a Kanban system, like the one we’ve deployed at Corbis. Another part of this can be achieved by partitioning workflow states such that each is of a similar duration. Another part is defining work item requests so that they are of similar size and therefore require a similar duration to complete. Still another part is pulling quality assurance steps earlier into the process in order to reduce backflows between workflow states. When these things have been done, it is possible for work requests to flow smoothly through the development process with a predictable lead time, cycle time, and resource utilization. A continuous smooth flow of valuable new features into deployment is the Ideal Final Result.

A Feature is defined as the minimum testable unit of customer value

What constitutes testing should ultimately derive from something that represents customer utility. Quality Function Deployment describes in exhaustive detail the kinds of transformations that yield specific tests from a model of customer needs. Of course, we’ll say much more about this in the future.

By identifying a feature as both something small and as something a customer could identify as having specific value, we enable a scheduling discipline where work can always be quantified in financial terms. Furthermore, that work is mostly additive, where every time we complete a work item, we have a measurably more valuable asset. Document- and plan-heavy processes often dig cavernous pits of sunk costs before they begin to deliver a single nugget of customer utility. That is a very risky, and ultimately quite irresponsible, way to run a business.

Minimizing Work-In-Process always applies, even when the deployment set is large

Deployment batch size is a function of two independent inputs: 1) the production capability of the supplier, and 2) the consumption capability or preference of the consumer. One of these is probably the limiting factor that governs the total batch size. Good customer service means that you’d prefer to let the customer determine that size rather imposing your own limitation upon them. Which means that you should develop the capability to deliver smaller, more frequent deployment packages than your customers are currently asking for. Once your customers realize that they can take more targeted and incremental updates, then they may start to choose that option, likely to their advantage over customers that do not.

But even if they don’t, controlling your own internal inventory will yield large and increasing improvements to your own business efficiency. Lean production is probably the single greatest enabler of continuous improvement. Most development organizations struggle to achieve even linear productivity growth, but Lean development is all about compound productivity growth. Successful implementation of a Lean production line is likely to yield a dramatic boost in the first year, as capacity is balanced against demand, and the easily identified waste is driven out of the system. A 100% first year productivity improvement would not be unexpected from a successful Lean launch.

1. Teoriya Resheniya Izobretatelskikh Zadatch, or Theory of Inventive Problem Solving