Strategy and execution in information intensive organizations is hard to handle because the nature of these businesses is abstract. Information is a slippery quantity at the best of times.
If only the software development industry had the hard characteristics of manufacturing industry: visible raw materials and measurable transformation processes. We might then be able to apply some of the wisdom used to reinvent traditional businesses for the modern competitive world.
In fact, software development is not so very different from factories. Manufacturing industry has much to teach us, especially in the area of “batch and flow”. In their classic work on "Lean Thinking" the application of Japanese “lean” techniques, the process describes how altering production processes to single-piece flow improves profitability, productivity, flexibility and time to market for companies large and small.
Can software development looks like a classic batch industry? Developers organized into specialized departments, trained staff process materials in a kind of production line. Workflow techniques make the manufacturing analogy explicit. Internal systems act as a conveyor belt, shifting work from station to station.
From another perspective, software development is also characterized by the most visible inefficiencies of the traditional batch approach: re-handling and holding. In batch manufacturing systems, parts or assemblies are frequently moved, stored, retrieved and reworked. Much of a product's period of creation is in fact spent sitting waiting. The same applies to the product design process. Software industry shares these characteristics, spending much of their time in queue or transit and with much staff and partner time dedicated to querying the current status of items.
Batch manufacturing takes its cue from the supposed scale economics of heavy machinery. If it takes several shifts to reconfigure a machine tool, then it makes sense to produce a large number of items between changeovers. However, the “lean thinking” movement in manufacturing targets faster turnaround of machine changes, reduced inventory and smaller, more frequent, deliveries.
If you know a structured development language, you'll appreciate that the bread-and-butter of the earliest business information systems was moving data items in and out of storage. If you can imagine a world before ubiquitous computing, you'll quickly conjure up a vision of file folders being pushed around in carts, dropped in in-trays and stacked on shelves.
If you could control every single aspect of a piece of business from inception to completion, then there would be no reason to delay that piece of business. It would occur in real time. You might, for example, design an product for a client, built it, and sell it in one continuous action. The reason you don't do this is most likely because you don't own all the pieces of the jigsaw or because you are set up with barriers that block such flows.
A difficult question. Your software development shop is tooled with heavy machinery (version control software, databases, development tools and existing code, processes). Is batch better for certain areas? Can you improve areas of your development shop by removing delay? How do you retool?
Thank You for listening.