No need for him: In a pull system,
decisions are made by the responsibility
and commitment of experts doing the work.
Pull was adopted by software development in the 1990s. Before, traditional software development dealt with its process like Toyoto in the pre Ohno era. There were several stages in a software development process, e.g. analyzing requirements, designing, implementing code, testing, and deployment. People were assigned to the different stages, e.g. 2 analysts were analyzing, 3 developers were implementing code, etc. Usually they ended up with a huge inventory similar to the aforementioned balance weight makers for each of the stages.
In the last 15 years, Agile Software Development revolutionized the way developers work similar to the way Toyota did within the automobile world. e.g. pull within Extreme Programming (XP):
“XP uses a ‘pull’ model … Stories are specified in detail immediately before they are implemented. The tests are pulled from the specifications. The programming interface is designed to match the needs of the test. The code is written to match the tests and the interface. The design is refined to match the needs of the code as written. This leads to a decision about which story to specify next. In the meantime, the rest of the stories remain on the wall until chosen for implementation.” — Kent Beck in Extreme Programming Explained 2nd Edition
Like the Toyota Production System, XP wants the later process to indicate its demand to the earlier process, so that the earlier process can exactly deliver what the later process needs. In a pull system, you “read” a chain of processes not from the beginning to the end, but the other way round. You put the cart before the horse. Beginning at the end, you ask: What is it that the later process needs that the earlier process has to deliver? After you identify this need, you’d be able to produce exactly what is needed.
But pull is more. So far, we saw that pull regulates the satisfaction of needs in an economically better way than push systems. But pull also changed how the work which has to be done finds its way to the people doing it. In a push environment, tasks get assigned to workers, whereas in a pull environment, workers sign up for tasks.
Toyota’s balance weight problem, as a complex system, showed the unpredictability of the consumption of balance weights during the wheel balancing process. Unpredictability is an attribute of complex systems. Similarly in software development, there’s a certain kind of unpredictability when it comes to accomplishing tasks, like developing a certain feature for a software.
You call it a push system when the manager decides who’s going to do the next job. Work gets assigned to workers, it gets pushed to them. Push has several disadvantages:
- The manager has to decide, who is the best person to do the job for a given task. But he often lacks the knowledge of whose skills fit the best to do a given job.
- The manager has to distribute the work load appropriately, so that every developer is neither overloaded nor underemployed, and all the tasks for the feature are finished at about the same time. But often he does not know the capability of the developers and his assumptions are based only on estimates (which, by the way, are always inadequate in a complex system).
- The manager is the only one who assigns work to the developers. But that makes him a single point of failure.
- The manager has to control when persons finish their current task all the time, so that he can push another task. But controlling consumes a lot of time (i.e. costs a lot of money), and it demotivates people due to decreased autonomy.
- If the manager does not control the whole time, then he could assign batches of tasks to people. But batches of tasks require inventories for every person (i.e. costs a lot of money).
Like XP, Scrum uses a pull system, and it makes clear who decides on what to work on next:
“Development Teams are structured and empowered by the organization to organize and manage their own work. […] They are self-organizing. No one (not even the Scrum Master) tells the Development Team how to turn Product Backlog into Increments of potentially releasable functionality …” — Ken Schwaber and Jeff Sutherland in Scrum Guide (v. 10/2011)
No one tells the people how to do their work. Period. Amen. Do I hear a hallelujah?
In daily work, this means: The list of open jobs/taks, in Scrum called the product backlog, serves for the team as the source to pull the next few items from for the upcoming period of working time, in Scrum called Sprint:
“The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. Only the Development Team can assess what it can accomplish over the upcoming Sprint.” — Ken Schwaber and Jeff Sutherland in Scrum Guide (v. 10/2011)
Let’s see what this means regarding the push system problems I mentioned before:
- The people doing the work decide who is the best of them to implement the given task. They decide, because they are the closest to the work and have most of the relevant information available to make the decision who’s best for the job.
- The people doing the work distribute the work load appropriately. If they pull the tasks, nobody is forced to do more than she can, nor get her potential underestimated.
- The people doing the work are pulling work collaboratively. There is no single point of failure anymore.
- The people doing the work know when they finished some tasks, and can then automatically pull more work. They control themselves.
- The people doing the work don’t need batches of work. They simply pull one work item at a time.
Of course, mistakes happen, even if no (!) manager is involved. But there’s a remarkable difference between a manager or a worker making a mistake: the worker can’t blame the manager. The worker can only blame himself if he makes a wrong decision. No one else but the worker is responsible for his own decisions.
And even kanban has arrived in the software development world, unfortunately with the same name, but with a different approach. To distinguish between Ohno’s invention at Toyota and the method used in software development, it’s called Kanban (capital k) or software kanban.
Software kanban has different components, like visualizing the work flow, limiting the work in progress, or continuously improving. One of the most essential parts of Kanban is its pull system:
“Scrum and Kanban are both pull scheduling systems…. This means that the team chooses when and how much work to commit to, they “pull” work when they are ready, rather than having it “pushed” in from the outside. Just like a printer pulls in the next page only when it is ready to print on it (although there is a small & limited batch of paper that it can pull from).” — Henrik Kniberg and Matthias Skarin in Kanban and Scrum – Making the Most of Both
Again, the persons doing the work are in the centre of pull systems. XP, Scrum, and Kanban are all part of the method family called Agile Software Development. And so it’s no surprise that the human itself is part of Agile’s DNA:
“Individuals and interactions over processes and tools” — Agile Manifesto
Two of this value’s creators describe the idea behind it like this:
“Agile development focuses on the talents and skills of individuals and molds process to specific people and teams, not the other way around.” — Jim Highsmith and Alistair Cockburn, Agile development: the people factor
Work assigned to people is a push process with people having to follow the work. People signing up for work is a pull process with work following the people. In a push system, decisions are made by authority in titles and hierarchies. In a pull system, decisions are made by the responsibility and commitment of experts doing the work.