Agile and DevOps have reintroduced the notion of flows and iterations into IT development processes. On this subject, one often hears about pull or push flows as well as Kanban. What exactly is this?
To begin with, I will quote the IT Production Director of a major French bank, who used this formula for the kick-off of a lean Obeya workshop I was running: “We have to stop pushing projects like we push wagons and pull requests from the client instead, so that our projects can all move forward together!”
A good illustration of this pull flow concept that actually comes from Toyota!
Toyota, through its Toyota Production System – Lean – has taken a great interest in this concept of value flow in order to allow employees to concentrate on value-added tasks while abandoning as much waste as possible (one of the best known in IT being retouching). The final objective is to reach the Holy Grail of Just In Time, i.e. to deliver the customer just in time: neither too early nor too late… with the expected level of quality.
And for this, pull flow is the absolute weapon!
The principle is simple, it consists in pulling production from the customer. The customer’s request is the trigger for the production of the part. So we start at the end of the process in order to deliver the parts at the customer’s pace, called Takt.
Examples of pulled flows in everyday life include the restaurant. The preparation of the dish will only begin once you have placed the order. The same goes for fast food restaurants where the burger and fries are almost made on demand. There is usually a small safety stock of 1 to 2 pieces to limit the waiting time.
Conversely, in a cafeteria or canteen, the logic is rather a push flow. Large quantities of dishes will be stored in bins that must be kept warm at the risk that some may not be chosen by the customers.
According to J. Liker and M. Meier, authors of the excellent Toyota Way Field Book, in addition to these principles of customer-driven production, there are three elements that differentiate a pull flow from a push flow. The flow is:
1. defined: there is a precise agreement between the one who provides the service/product and the customer: the quantity, the type of parts
2. Dedicated: the elements are shared between the 2 teams (supplier / customer) and are dedicated to them in terms of resources, locations, storage… They must agree on the Takt rhythm.
3. Controlled: simple and visual controls should represent the agreement between the two parties.
For Scrum teams I coached, this could mean:
1. the team that develops, delivers a tested package including 2 patches and a user story to the team in charge of the integration. Acceptance tests are clearly shared
2. the package is versioned or tagged, ready to be deployed on an integration environment via an integration CI platform
3. The receiving team knows how to install the package and has a checklist of things to check.
What is the point of pulling the flow?
In the pull flow, each person at his or her workstation agrees with the person who will follow “we work as a team to succeed together in satisfying the customer.”
A pull flow is more efficient than a push flow because it highlights wastes such as expectations as well as stock management. These are expectations linked to coordination problems with other teams, internal team problems such as lack of skills on a particular subject or the availability of an environment or a set of data… As it puts the process under “tension”, it will highlight all the weaknesses that will be immediately visible and will be opportunities for improvement (Kaizen) to make the process even more efficient and resilient. In the end, by resolving the obstacles as they arise, the pull flow will enable the teams to improve customer satisfaction because the customer will be delivered when he wants it.
In this context, the Kanban, also known as a “card” (often materialized by a post-it in the IT world), is an avatar that represents the creation of value throughout the process. More commonly, in the IT world, the Kanban panel is used to represent the different stages of the value creation process.
On this subject, I invite you to read the excellent article by my colleague Jean-Philippe Douet, Kanban, a serial killer of the Definition of Done, which explains how to evolve from a simple To do / Wip / Done panel to a panel describing the process.
What about the pushed flow?
On the other hand, in a pushed flow, each person at his workstation carries out his activities for himself alone, at his own pace, without worrying too much about who takes over. To caricature a bit, it is in “egocentric” mode. Pushed flow will result in a lot of wasted expectations, stock management and overproduction. It will tend to hide the problems, particularly by the stock of “things to do”.
I sometimes met teams where developers delivered many user stories “at full speed” (i.e. containing many bugs) knowing that in the process, at the next stage of user tests or qualification, only one person was available. This person was literally overwhelmed with integration and testing tasks, resulting in wasted overproduction and inventory management and then wasted rework because the deliveries were not of good quality. The result is a slow process producing poor quality parts.
To conclude
Surprisingly, we have the same opposition in the French language with these 2 expressions, one with a rather negative connotation: “You push a little too much! ” and the other more positive one: “Pulling someone out of a bad situation”.
And you, in your Agile, Lean or DevOps practices, how do you make things flow? How do you find ways to improve in order to better satisfy your customers?
Original post in French by Thomas Deligny. Translated with Deepl.
Better, Faster, Together - Operae Partners blog 