Although I’m not a great fan of taking concepts from the manufacturing sector and bending them so they can be applied to the IT sector, the idea of “push” versus “pull” processes is one that is worth considering. The concept of push versus pull comes from the field of lean manufacturing and is used to identify who in a chain of manufacturing processes is requesting work to be done. In the factory environment work is broken down into discrete processes which are linked together in a chain. Raw materials enter the factory at one end and move through the different process steps. Each process adds value and when all processes are complete, the raw materials have been transformed into an end product.

The idea of push versus pull refers to who it is in the chain of processes that is requesting that work be done. Factories have traditionally used push processes. In a push processes a manager forecasts future demand and makes a decision to make a batch of product. Raw materials are ordered and when the materials arrive they’re fed into the first process. Once that process is complete, the work in progress (WIP) is passed onto the next processes which completes its work and then passes it onto the next. Each new process is only initiated when it receives a batch of WIP from its upstream process. Once the last process is done the completed batch of product goes to the warehouse for storage until sales are made and the product is delivered to its buyer.

In pull manufacturing things work in reverse. Rather than a manager forecasting demand, it is the end user who initiates the build process by placing an order. That order initiates a chain of events that in effect “pulls” the raw materials through the manufacturing processes so that the demand can be satisfied. One of the subtle differences in this approach is that rather than a downstream process pushing WIP into an upstream process; it is the upstream process that tells the downstream process that it needs some more work to do.

The idea of “push” versus “pull” has been adopted by some IT organizations as part of their agile implementations. In the context of software development “push” versus “pull” discussions often focus on who it is that is determining the pace at which the development team is working. In many organizations a “push” process is used. In the “push” approach managers push requirements into the development team who then work as hard as they can to keep up with the demand. In a “pull” arrangement the opposite occurs. Rather than a manager deciding how hard to push the teams, the users generate a prioritized list of high level requirements and the development team decide the rate at which they are able to take on a new piece of work (so the developers “pull” from the prioritized requirements list when they are ready to do so). Only when a piece of work is pulled does the process of fleshing out requirements and designs begin.

It’s an alien thought to IT managers who are used to arbitrarily cutting the schedules project teams ask for and then pushing the team into ever higher levels of overtime to meet the dates. It is however an idea that in principle makes a lot of sense. By allowing developers to work at a pace at which they are comfortably, a few things happen;

1. Because the development team is setting their own pace, stress levels are reduced
2. Less stress allows the team to focus on maintaining the quality of the work they produce
3. Higher quality reduces the rework inherent when quality levels drop
4. Less rework makes the team more efficient
5. Higher quality reduces the number of fires managers have to fight
6. Fewer fires means managers are better able to focus on helping improve the team’s skills and the overall effectiveness of the team
7. Increasing capabilities improve the overall productivity of the group still further
8. High quality and lower stress levels reduce staff turnover thereby further improving the overall situation

Unfortunately too many organizations fail to understand these cause-effect chains and continually push their teams to try and get higher and higher levels of productivity. All that pushing is unfortunately having the opposite of its intended effect and all the organization ends up with is high stress levels, constant fire fighting, poor productivity and high turnover rates, the effects of which are unfortuantely evident in many of the IT Project failures I’m called in to review.

Of course in practical situations shifting from “push” to “pull” would be a major structural change for most organizations. A lack of trust between groups and years of neglect in terms of quality practices could seriously undermine the approach in some organizations. Despite the problems, it’s a part of the overall knowledge every manager of an IT department should know and understand. Perhaps with time more organizations can mature to the point where they can shift to a more enlightened approach to software development.