Where to Find Your Next Task in a Pull System

Where to find your next task in a pull system? The answer to this question seems simple at first glance. Often it is answered by members of agile teams in such a way that they choose the task on the task board that brings the greatest fun factor. This approach is understandable from a human point of view, but violates some agile principles and values. This article shows why it makes sense when choosing the next task not to rush to any task, but to select it according to specific criteria.

The Pull Principle

Production Systems Back Then …

At the beginning of the 20th century, Toyoda Sakichi introduced the famous Toyota Production System in his company. It was developed further over decades. One of the driving engineers behind this development was Ohno Taiichi. In 1978 he published his book “Toyota Production System“. His techniques initially revolutionized the manufacturing industry and, to this day, the way in which numerous other industries develop, manufacture and deliver their products.

The central aspect of the Toyota Production System is the elimination of all types of waste. Production should not do anything that does not add value. This includes, among other things, the unnecessarily long storage of intermediate products, stock production or unnecessary production of rejects. The core elements of the TPS are omnipresent today: Kanban, just-in-time production and the Kaizen principle.

A central principle in the application of these elements is the pull principle. Up until the introduction of the TPS, many companies produced in a push system. Here, technical innovations were pushed down the value chain, regardless of whether there was actual need there or not.

… and Today

Today production chains work on the opposite principle. Nothing is produced that was not previously ordered by the customer (whoever that may be) at the end of the value chain. This not only results in highly efficient value-added streams, but also in the just-in-time principle. If the non-value-adding part of the production time is to be reduced, then there must be no more intermediate storage and each component must arrive at the workplace exactly when it is needed. (Today’s automobile manufacturers have extended this principle to their supply chains, and so the intermediate storage facilities are now in the form of rolling trucks on the highways.)

With the introduction of agile development methods in product and especially software development towards the end of the 1990s, the methods of lean production also moved into focus. Kanban in particular is used in many implementations of development processes. The development process is interpreted as a value stream which work packages have to go through in order to get to the customer after their publication.

Intransparent Task Boards

Teams often use Kanban boards to visualize their work packages and their workflow. This is an excellent way to create transparency. The question now is how a team member can recognize which work items are ready to be propagated down the value stream, because in practice, the boards often look like the following picture.

Individual states of the workflow, and correspondingly of the work packages, are shown as columns. The work packages are written on post-its or magnetic cards. These are then assigned to the respective statuses on the board so that you can see at a glance how far a work package has progressed in its processing.

Unfortunately, you can’t see that on a task board designed like this. What does “in Review” mean? Has the development part been completed and the review can begin? Is the review in progress? Has the review possibly even been completed and quality assurance can begin its work? Who knows …

Pushing Work, Instead of Pulling it

Since it cannot be seen how the processing status of the individual work packages is, it is also impossible for team members to pull work down the value stream. The only way a package can be propagated on such a task board explicitly is the push principle. The developer pulls the work packages from “ToDo” to “In Development”, but after completing his work he pushes this package down the value stream to “In Review”. This puts the subsequent process chain under pressure, because it may not be able to process the work quickly enough.

So there is a lack of transparency regarding the processing status of the individual packages. This lack of transparency makes it impossible to implement or operate the pull system efficiently. This automatically turns the system into a push system. Now, the workstations tend to be overloaded, the system gets clogged, production times increase and thus the non-value-adding part of the cycle time of a work package increases as well. The team has deprived itself of the opportunity to implement and optimize the workflow in the sense of lean development.

Increasing Transparency With Split Task Columns

There is a simple and effective solution to this problem. This solution not only increases the transparency in the development process significantly, but also allows the development work to be implemented as a real pull system. The solution is a more transparent visualization of the processing status of the individual work packages. To do this, we divide the columns on the task board in a way that it is clear which work packages are actually being processed (“Doing”) and which packages have already been completed (“Finished”). The term “Finished” is used deliberately, because the term “Done” only refers to the final processing step, especially in Scrum teams.

This division of the columns now allows a concrete, transparent statement about the status of the individual work packages. A package in the “Development Finished” column is now ready for review. A package in “Review Doing” is currently being reviewed. When this review is complete, this package moves to “Review Finished” and is ready for quality assurance.

Since it can now be seen which work packages are ready for processing by a subsequent working station, they no longer have to be pushed down the value stream by their processors. It is now possible for workstations to pull the packages from the stock of available work.

Where to Find Your Next Task in a Pull System

In a production company, the question of where a workstation can find its next parcel usually answers itself. Normally, these come one after the other on the assembly line and there is no need to think about priorities and processing sequences.

This situation is different in cross-functional development teams. Here, developers often take on several different tasks in a team. After completing a task, they are faced with the question of which task to work on next.

As already described, it is the central aim of lean management to eliminate the non-value-adding time from the production chain. This also applies to lean development systems. In order to reduce this time, it is necessary that work packages are pulled down the value stream as quickly as possible after completion of a working step in order to be processed further. The result is a simple but effective procedure when looking for the next task. A team member looks for his next task from the end of the value stream in upstream direction. The first task for which he has the necessary knowledge is then his next work package. This not only reduces the cycle time of the work package, but also delivers quick results and therefore quick feedback.

A Simple Example

Let’s apply this method to our exemplary value stream. Based on this value stream, the following image depicts the starting points of the “task search” for the different team members:

• the Product Owner: checks whether new work packages have passed the QA and can be accepted
• a QA engineer: checks whether new work packages have passed the review and can be tested
• a Developer: first checks whether new packages are ready for the review and then carries out this if necessary. If this is not the case, it checks whether new packages are ready for development

This approach not only leads to shortened lead times for the various work packages, but ideally also prevents the system from clogging due to the personal preferences of the team members. If the system is still clogged, this is due to a bottleneck in the development process at the corresponding point in the value stream.

Final Thoughts

In practice, many agile development environments are planned as a pull system, but actually implemented as a push system. Increasing the transparency in the workflow itself, but also in its visualization, can help here. This makes it easier for team members to select the “right” work packages.

Furthermore, it reduces the non-value-adding portion of the lead time of a work package. This enables faster feedback of downstream work steps to the upstream suppliers. The often prevailing push systems can thus be transformed into real pull systems. Additionally, this leads to a reduction in pressure and errors along the value chain. Implementing these guidelines should help you to answer the question “Where to find your next task in a pull system?” effectively and with respect to agile and lean values.