Product development is not a good analogy for software delivery

In a quick break from my current obsession with Throughput I thought I'd talk about something I often hear from folk theorising about software development, especially those running Agile software development teams - that the process of delivering software bears more similarity to industrial product design and development than it does to industrial manufacturing.

I believe this to be true for shrink-wrap software product delivery. However the majority of software development is not shrink-wrap software products. The majority are software systems that support or enable a business function - things like websites, transaction management systems, scheduling systems, etc. In these cases I believe that the analogy to industrial product design is misleading.

The ultimate goal of all business software delivery is to make money for the business. In the shrink-wrap product case it's to create revenue through sale of the product. For the rest it is to create revenue by enabling or improving a business function. The software delivery process is a business process improvement mechanism; and the software is simply a side effect.

The last point is important - software is a side-effect. If the business could achieve the same improvement/enablement goal, by some cheaper or more effective mechanism than producing software, then that's exactly what they should do. Luckily for us in the software industry there are many cases where software is the best solution!

So given that we're usually not producing software to sell as a product and instead producing it as side-effect of improving a business function, it makes sense to try and provide any improvements as rapidly and efficiently as possible. In this sense, software delivery is less like the design of a product and more like a continuous manufacturing process for discrete business benefits.

Of course, there are differences between delivery of business process improvements through software and traditional manufacturing. The most obvious one is the substantially larger degree of uncertainty in the effort that will be required to deliver a given improvement (benefit). Manufacturing can often predict how long it takes to build a product down to minutes or seconds. We don't have that luxury. As a result software delivery suffers from much larger statistical variation in each stage of the process, which has large ramifications on the way we must manage the process (hopefully I'll discuss this in further detail in future posts on throughput). On the positive side, software delivery often has a simpler process than many manufacturing processes - in many cases it's quite linear with a single chain of clear and well understood dependent stages.

The presence of uncertainty and variation is what leads people to think of software delivery as a product development process. I can really see the attraction of this thinking because it captures the creative nature of much of the work that occurs and thus makes the larger degree of uncertainty and variation implicit. However I think applying this thinking too widely has detrimental ramifications to how we understand and improve our value to businesses. It leads us to think about the end software system exclusively and to create software 'projects' that attempt to build the whole system, rather than thinking about how we can deliver each individual business process improvement separately (and rapidly). This form of batch thinking can severely limit the flexibility and the value software delivery offers businesses. In turn, I believe this to be a clear reason why many CxOs are afraid of IT and look for ways to avoid involving IT in new business initiatives. If everytime the CxO wants to make an improvement or change to their business and asks IT for help, then gets told "we'll need a new XYZ system", they'll quickly learn to stop talking to IT.

In summary, whilst I believe that the design and development of discrete changes or additions to software systems to be a "product design" activity, I consider the software delivery process, which provides for continuous and on-going addition of value (through business process improvement), to be more analogous to manufacturing. It's about moving peices of work (a software system change/addition) through a continuously improving pipeline.