Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

The first thing to check is that we are not reading the principle too quickly, but actually reading it and absorbing the detail that’s written.

Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale

1. Deliver working software 

2. frequently, from a couple of weeks to a couple of months, 

3. with a preference to the shorter timescale

The 1990s

The measure of success was on time.  Every project manager was employed to deliver a fixed scope on time and on budget.  The experience that most software projects ended with was a load of software that didn't work and was late.  The UK government's answer was more controls.  The free market of the US came up with a better way.

The intent of this principle

If the software doesn't work, then what was the point.  Then again, the meal can taste like heaven, but if it's late then what is the point in that too?  This principle is central to customer service, constantly delivering things that work.

Today (+20 years on)

On time and on budget is still in the job specs of so many technology project managers and so many will care less about the quality as long as the measurable metrics are met.  This is a sad state of affairs and led to things like the Horizon scandal in the UK.  The very best software is built to this principle and it shows.  What to avoid

• Stacking features before releasing

• Linear build test test test processes

The main point here is to measure that you deliver frequently, aka lead time, and that defects are minimised.