Pull Systems

Pull systems are properly cool. Think of it this way, push systems are like The Everly Brothers. They kind of served a purpose at the time but now they’re just dated and a bit naff. You’d never go and buy a record but they did influence some cool people. Well, pull systems are like Led Zeppelin. They were invented a while back, were awesome at the time and still rock hard. Here’s a picture I’ve drawn to illustrate…

The core difference between a push system and a pull system is the process trigger. A push system uses a schedule based on prediction of demand. A pull system responds to real-world demand or orders and forces the upstream process to respond. For more detail on push systems you can check out my previous post: ‘Push Systems‘.

So, a pull system starts with a real world customer order. Let’s work this scenario through in our manufacturing world…

An order is received from the customer and our pull system is triggered. A message is sent to the plant for the complete vehicle to be scheduled and built. We have information on the parts required for each vehicle so at this stage we can send a message to our supplier network to say that we are likely to require these parts soon; a ‘heads up’ to our buddies in our supplier network but not orders. The first components in our critical chain are scheduled for build and the materials ordered from the supplier. These components are passed down our value-chain with the assembly becoming closer and closer to a finished vehicle. Materials and parts are supplied to the points of fit or a local supermarket (marketplace or market area) just before they are required to build this particular vehicle (kanban systems are a great way of doing this - more on those in the future). Finally, the vehicle rolls off the line and will be supplied to the customer who originally requested it as it is already ’sold’.

A new drawing below showing our pull system. Notice that in our pull system we still have work in progress between the points of fit, however the parts inventory is reduced. The inbound warehouse is eliminated and in the worst case replaced with much smaller supermarkets if delivery to the points of fit is not possible. The outbound warehouse can be also be reduced to smaller supermarkets if the distribution channel is correctly adapted.

So how does this crazy pull system translate to our software delivery landscape? Well, it doesn’t, I just think it’s cool…… Actually if we think about the principles at work here we can apply similar thinking to our technology projects…

If we start off by treating each of our requirements as cars that we might get orders for at some point in the future and structuring them accordingly we can start to build our very own pull process. User stories are a great way of structuring our requirements for this as they are just placeholders, each written on an index card, for the detailed requirement that will come later on. So we write a heap of user stories that look something like this “A Sales Clerk logs in to the system” and don’t worry about the rest of the requirement for now. Then we sit back and wait for a customer order. It’s not long before our friendly product manager pipes up and asks if we can build the story he/she has in their hand and triggers the pull process. We send a message to the team, by pinning the card to a visible board, that act as a ‘heads up’ of what is to come. We then start the first tasks in the critical chain. The business analyst expands the requirement by developing the narrative and the test cases, and any domain model impact is assessed. The story is passed through the value chain until it has been analysed, developed, tested and demonstrated to our product manager. Then a few things can happen. If we have a great distribution network organised we can ask our product manager if they would like the requirement delivered immediately to production. If we haven’t sorted out our distribution network yet (production deployment schedule and apparatus) we may need to store the requirement in a small supermarket (pre-production system) until our next window in two weeks. We want our ‘collections’ as frequently as possible because we don’t want finished products on our hands; it’s inventory. The requirement is then released to production.

Here’s some more scribble showing the changes to our software delivery process.

This is still a long way from a perfect process. We are yet to balance the workload (heijunka) to create ‘flow’, we are not yet ‘building quality in’ which is resulting in some rework and we are yet to become masters at dealing with variation. We have reduced our inventory significantly and hence reduced costs and started to improve our ability to respond to change as the impact is lower through our newly found deferred elaboration of requirements (just-in-time).

Of course our pull systems can be applied to any process, including the business ones we often automate as technologists. One of the first actions we should take (there are many!) when we investigate these businesses processes is to look for opportunities for a transition to a pull model. From my experience it’s usually always possible. If I’m struggling for ideas I often ask myself what Jimmy Page (Led Zep’s iconic lead guitarist) would do in this situation, which brings me to Jimmy’s first lesson in systems thinking ‘Always try to create pull systems’. This applies within our software development process and in the business process our systems support.

There are many tools and techniques that can assist on this road to ‘pullness’ such as value-stream maps, supermarkets, visual controls and kanban, all of which I plan to tackle soon…