Why Developers Should be Customer-obsessed

Push and Pull models are used in manufacturing for production planning. These concepts can be used to measure how self-sufficient your developer team can be and how deep your software specification should be done.

What is Push or Pull in manufacturing?

Let’s say your build cars. At the beginning of the month, you get an estimation of how many cars need to be built. You use these top-down figures to order the raw materials that you will be needing: how many tires, screws, speakers, and so on. You are pushing material in the production line.

Using a pull model you would have daily orders with a list of cars to be delivered by the end of the day. Something like 5 cars of model A in black, 3 cars of model A in blue, 1 car of model B cabriolet in red. With this, you need to steer your production plan so that all parts needed for the requested cars are picked from your inventory system and assembled. This is pulling material from the production line.

In manufacturing, Pulling is the way to go and is how the complex Just In Time processes are set up. In optimal cases, Enterprise Resource Planning (ERP) software are connected from the manufacturer to its suppliers, and the daily batches of material are ordered electronically

The reality in production is way more complex. I am oversimplifying to make a point.

Push and pull is actually also applied to software development as follows:

• When a feature is just a use case and you let the development team workout the implementation you are pulling implementation details from the team.
• When you document a feature until the last details including Mockups, API definitions, and other details you are pushing implementation details to the team.

Here is where having a team that “can think like a user”

can make the difference.

Why Should Developers think like Users?

I have lead projects at both extremes. One memory springs to mind. We had to implement a daylight savings time feature in an embedded consumer device. This was to be done by a team in a place where daylight saving time is not used. The team had successfully programmed a leap year algorithm taken the complexities of every 4 years, but not every 100, yet every 400. They were good and motivated developers.

The PO and testers were going crazy because the team was doing the "one step forward two back" kind of progress. The situation escalated so that I had to go onsite to our development center. I remember the team leader taking me to the side after lunch and asking me: "Can you please explain daylight savings to me?" The PO had assumed that by just writing that in the requirements everything would be clear.

Offshore, Nearshore, and in my Backyard.

A Product Owner can throw a not fully defined feature to a local team that can think as customers and expects a sensible implementation quickly. Especially if you are using an iterative software development with regular reviews of the work in progress.

The hidden cost of this additional need for detailed specifications to a remote team is often ignored. In bad cases it can lead to an expensive "bring it back" action.

So the question is what can you do:

• If you are in charge of evaluating moving development offshore, make sure you calculate the additional specification work that will be needed to Push the requirements to the remote team. Maybe your calculation would show that keeping development in-house is more efficient.
• If you are a Product Owner that has to work with a remote team, make sure that the requirements you are assigning the team are understood. Having well-managed scrum refinement and good communication with the team could help.
• If you are a developer working on a remote team, be sure to ask questions early. If you need an introduction to how a piece of equipment, a process, or a workflow works ask for it. Be proactive, your PO will appreciate that.

First published here