A push system is a means of control in a business process that uses predictive information to develop a plan. Push systems all have the common feature of being based on forecasts or schedules of customer demand and are closely associated with ‘batch and queue’ techniques.

Let’s start by putting this in the context of a manufacturing process and then look at how the concept applies to software delivery projects. A push system starts with the development of a forecast of customer demand. If we are building cars we may look at what we sold the previous month, current business conditions, consider any seasonal factors and make a prediction that we need to build 500 small red cars, 45 medium blue cars and 300 big green cars this month. Our next step is to order all of the parts from our supplier network to be delivered to our plant. Once they arrive we move as many of the parts as we can to the point on the line where they will be used and we store the remaining parts in a warehouse with a schedule to take them to the points-of-fit on the line based on our overall schedule for production. The first line operator uses his stock of parts to perform his task and passes the completed item to the next worker on the line; if he or she is busy then the item is stacked and a backlog starts to form. Each line worker takes items from the pile of waiting items, processes it and places it in a waiting area for the next line worker. Typically this process continues with few variations until the product comes to the end of the line where it is inspected, any defects are noted and resolved and the product is placed in a warehouse awaiting distribution. This process leads to large amounts of inventory within the plant in the form of parts waiting at the points of fit and work-in-progress waiting between the line locations or shortages at both locations. Here’s a child-like drawing that has been automatically generated from Rich’s head using the technology of pens and paper…

We can draw a direct comparison with the way we have traditionally run software delivery projects. We start with a prediction. We have a few conversations about scope, we look at yesterdays weather and any lessons that we’ve learned in the past and we make a guess at what is required. This forms the basis of our schedule. We then order our parts from our suppliers (customers) and we store them in a factory (usually a requirements spec). The parts are then pushed to the approriate place (developers, testers, architects) and the production line begins. Architects take the requirements spec and add-value by turning it into a technical design. When this is complete we pass the specs on to the developers who build the application, then the testers, then the customer etc. To make sure that we add a bit of extra waste (waiting) into the system we throw in a few gates and sign-offs as our (highly skilled, highly trained, highly paid) line workers can’t be trusted. Here’s a local primary school kids interpretation of the process…

If we understand that the software delivery life-cycle and online product development life-cycles are business processes just like any other business processes, often following the same patterns, we can apply the same business process re-engineering techniques to make improvements and improve our system. We can look at how pull processes are used to create single-piece-flow, how safety stocks are used to handle natural variation, how supermarkets can be used to embed a pull process within a push ecosystem and just generally use all the cool and clever techniques from a discipline that has a much greater maturity than the software development industry. Next stop, pull systems…