For some background information check out my previous posts on Push Systems and Pull Systems.

In both the business operations and software development worlds it is often desirable to transition from push processes to pull processes; pull processes better support concepts like just-in-time and have long since been proved superior in most contexts within the business world. There are often a number of barriers to this transition, fortunately the Lean operations community have developed a number of tools and techniques to make this transition simpler….

Impediments to Pull Systems

(1) End-to-end processes (value-streams) are usually really big. In a manufacturing context trying to move production, supply chain, distribution, sales and marketing etc. to a pull system in a single step is a very big task.

(2) Book-keeping practices have often been created for the old push system so as well as the physical impact of the change there can often been an economic impact and a short term hit on profitability. For example, automotive companies historically register a sale with the general ledger at the point of gate release (where the car is flagged as finished at the end of the line). This was a big barrier in moving to a true pull system but removing it and registering a sale at the point a vehicle is sold (!) results in a large short-term negative impact on the books.

(3) Cultural barriers; people are naturally resistant to change.

It is important that when we try to introduce new processes we understand and register the barriers we are dealing with and plan to tackle them.

Dealing with our Impediments

(1) When we introduce Lean processes to business operations environments we can make use of supermarkets and minimum/maximum levels to manage the transition. Supermarkets are small storage areas that live at the boundary of push and pull systems with small amounts of inventory, managed with minimum and maximum levels, that we try to reduce over time. This lets us focus on a smaller component of the complete process, say production, and introduce supermarkets around production and the supply chain or distribution network until we are ready to transition them.

(2) We can use the same concept of supermarkets to protect our old book-keeping practices until the organisation is in a position where it is prepared to take a short-term hit to transform to a true pull system. In my experience this can be very difficult as there is never a good time.

(3) Changing cultures is hard, however I’ve noticed that experienced Lean consultants seem to all follow an initial pattern that is very aggressive to send early messages. I remember the story at Porsche when the COO was given a saw and instructed to cut down all of the storage shelving to waist height in front of all of the production staff. A very visible and symbolic gesture; change is coming.

Lean Software Development

When we introduce Lean or Agile software delivery processes we often deal with a lot of similar challenges. The end-to-end software delivery process is big, especially in large organisations. Financial practices are linked to the old ways of working and there are often cultural barriers to change. Wholesale change is very high risk and in the cases where I see Lean/Agile adoption struggle it is often because there is an attempt to change the world in a day. Thankfully, if we understand them, we can apply the same successful patterns used in the Lean operations world to our software development transformation programs.

(1) The concept of a supermarket can be applied to help us deal with the size and complexity of our software delivery process. In traditional waterfall software delivery models there are usually very large warehouses of inventory at two points: the point between requirements being gathered and design/development starting (requirements specs are big warehouses of inventory) and the point between the application being completed and being deployed (pre-production systems are often big warehouses of inventory). Often we are tempted to break these down immediately by moving straight into user stories and very frequent releases, however this is a very high risk approach and I think it should only be used in some contexts. Instead we can apply the supermarket concept and use smaller inventory stores with maximum and minimum stock levels to transition in a more pragmatic and low risk way.

(2) We can also use our supermarket model to act as a barrier to the old funding models and governance process and transition them at appropriate points later.

(3) The cultural change is the most difficult element to deal with. I believe it’s key to have executive level sponsorship and use the sponsors to perform symbolic acts to send a message about the coming change. If we don’t have this support then any transformation will be covert and difficult.

The lesson I’ve learned is that change doesn’t have to be wholesale. We can use tools and techniques to protect and isolate process components, make changes and then extend the change through the value chain. It’s usually a lower risk and more pragmatic approach.