#30 - The Power Of Pulling
Insights we can draw from Pulling (Kanban, TPS, Git) to our day-to-day tasks
TL;DR
The Pull concept, integral to Kanban and the Toyota Production System, emphasizes efficiency and continuous improvement by only moving tasks or products forward when there is a demand.
Implementing practices like limiting work-in-progress, managing workflow, and aligning team efforts can enhance productivity, reduce bottlenecks, and foster a culture of high-quality and effective communication.
Emphasizing ownership and collaboration through peer reviews and internal testing ensures that everyone contributes to incremental, demand-driven improvements, leading to more effective and user-focused product development.
Introduction
In this post, I will discuss the Pull concept, as referenced in Kanban, TPS (Toyota Production System), and Pull Requests. Rather than pushing something (a task, a machinery part, new code), someone (or something) needs to pull it. I will then draw insights we can apply to improve our day-to-day tasks.
Using some of these practices can make us more efficient and focused and build better products.
Overview
I am fascinated by the Toyota Production System (TPS) and how shifting a company's focus can significantly impact its outcomes. Jumping straight into Kanban, which is one of the TPS’s twelve pillars, Pull is at its core. Instead of manufacturing a car door, for example, and sending it to the next station, I’m waiting for the next station to need a door. In Product teams, instead of telling an engineer, “Do this task,” or a QA engineer, “Please test this,” each has a workflow where he pulls tasks when idle.
Another interesting example is the Git flow. Imagine you are working to design a house and have the main blueprints. If each one on your team would draw on top of his or her ideas, it would become a mess. In the Git flow, one can “copy” the blueprints to his desk (creating a feature branch). He works on the changes and, once ready, sends them for the team to review and get feedback (pull request). If the team approves it, his design is “pulled” to be the new blueprint. This methodology shifts the ownership and accountability to the maintainer (who needs to pull changes) and allows a more dynamic workflow.
So, what can we learn and apply to our day-to-day routines?
#1 - Continous improvement
The Pull method and Kanban are focused on continuously improving the process, finding bottlenecks, and improving the overall efficiency. Here are some practices we can apply to other areas as well -
Limit WIP (work in progress) - by limiting work in progress, we can focus on “getting fewer things done” instead of “getting more things almost done.” Implemented correctly, it encourages a culture of high quality and closing open loops. For example, we can set a policy with only one big cross-functional effort at any given time or deprecate one feature each quarter.
Managing the flow - sometimes, you need to visualize your work's flow to assess better how to improve it. By doing so in the product workflow, we can find where ideas spend the longest, if we have gaps in alignment, and optimize feedback loops. As engineers can quickly assess if they are over-committed or if the QA created a bottleneck, we can drive similar insights from visualizing the product life cycle.
Alignment - to keep a solid pace and improve over time, we can use ceremonies and policies, like handover in different stages, approval workflows, and metrics. For example, we can agree that compliance should review features that deal with new markets, or that security must test new endpoints developed. Such policies can reduce friction and miscommunication down the line.
#2 - Demand-driven
One of the revolutionary methods in the TPS was changing the driver. Before, manufacturers produced parts that turned into vehicles and eventually shipped to stores. There, they sat and were sold based on the market demand. After the change, it was the market that drove the change. Toyota set a rule that, for example, a particular dealership should have five vehicles. Once one was sold, it signaled the manufacturers to ship another, signaling to build new parts, etc.
Similarly, we can think of alternative approaches to developing products -
Segment demand - prioritize a specific segment and always keep the line of work of features and improvements for it.
The weakest link - strive to improve the product's weakest part while validating its demand. If we see demand for a weak part of our product, we must improve it. We might want to deprecate or iterate if we have little to no demand for other parts.
Team capacity - if the team has a specific WIP limit (e.g., can work on two big features at a time), we can start working on the next one once they finish one feature. This approach can improve alignment as there are shared rules and policies.
#3 - Ownership and collaboration
Kanban and Pull set the ownership and collaboration on top. There are clear owners, and they are usually the ones close to the factory floor. Middle-line managers have their input, but not as strongly as the professionals.
Following up on that thread, we can apply some concepts to the product routines as well -
Peer review - within the team, each product has some area he knows better than others. A peer review practice can help make better choices as a team, foster a culture of feedback, and challenge one another.
Internal testing - nothing beats using your product. In the same way Toyota tests its vehicles and engineers test their code, PMs must test their product and use it like their users, and promote a culture of “dogfooding” (if it’s not good enough for us, it will be bad for our users).
Incremental changes - I had cases where a feature was introduced in one code change. The team declined it and worked together to build it incrementally. The reason was that the team, not a single engineer, owned the code. Similarly, the organization (and users) should feel the product evolves gradually and incrementally, not in a blink of an eye.