Push vs Pull Work

Push vs Pull Work

0:00

/383.464

1×

Last week I published an internal article to our test team at STELLA Automotive documenting our decision to change how we work. I’m not sure why it’s taken me so long to realize:

1. You can publish blog posts in Confluence
2. Doing so allows you to capture the context around why decisions are made

Capturing why decisions were made is just as valuable as documenting how a system works or what processes are now. They help others get up to speed faster and provide a way to reflect back on why we did the thing. It also makes it easier to change things later because we understand the thought process which established it.

Context for Changes

I started noticing that our test manager would end up as the bottleneck for work. Team members would finish their work but the tickets piled up on our test manager. When she went on vacation and I took over, I saw why. Despite the team's work, I had to review what they did to determine what information to pass along to the relevant stakeholder. Why couldn't they do this themselves? I saw this as a chance to rework how we approach testing and our other supportive work.

The following is close to my original internal post to the team:

Push vs Pull Work

In a push system, teams are given tasks to do. In a pull system, teams pull tasks from a backlog or central place. Both of these systems are useful at times but for the majority of the work we do it makes sense to move toward a pull system:

1. The team becomes more efficient when you choose what and when to work on something. No one knows your capacity better than you do.
2. Team members will be free to grab whatever work is available, even if it’s new and challenging. This removes any possible manager bias.
3. In terms of STELLA this means giving individual team members more ownership and responsibility.

Existing Process

On a daily basis our test manager or someone else says to the team “hey can you test x for me” and the team responds. When the team is done they send their findings back to the asking person. Typically this means a daily list of TODOs from the test manager in slack and when everyone is done, they send the information back to her.

This is what’s known as pushing work.

Pushing work is valuable as long as the requestor of the information is the person who will take action with it. For example: Bob (not his real name) asks us to test a customer deployment because he thinks there’s an error but our testing reveals no errors. When we tell Bob this, he’s able to take that information and perform action (or in this case no action). One-off help requests are good examples of push work.

Stuck in the Middle

Push work becomes problematic if the push comes from someone who can’t take action with it. When team members are assigned release tickets, they go and do their testing. They might find a bug, or discover something during their testing or they might determine there are no issues and the release ticket is good to go. When they finish, they report back what they found in a summary on the ticket and stop after tagging our test manager.

This kind of makes sense in a weird way, after all our test manager did request the work. However she’s not the person who will take action with it. If there’s a bug or issue then engineering needs to take action. If there’s a question about what was asked or how close the current implementation is, then product needs to take action. If everything was fine, it should be marked as Done and no one needs to take action. None of these examples directly involve our test manager.

Let’s look at another example: if our test manager asks the team to do onboard testing for a rooftop, then the team goes out and does their testing. They report back what they found in the ticket. Now if the team gives the results to our test manager that’s not good because it’s our customer success team that made the request (through SalesForce).

All our test manager can do with that information is pass it on but now she’s stuck in the middle and can easily become the bottleneck.

Going Forward

We need to go from push to pull for most of our work. So how will we do this?

A backlog

We now have a refined Test board we can use for grabbing tickets related to releases and onboarding work. This is our backlog of work items.

Each day when we “come into work”, go to the backlog grab the first item available and start working on it. When it’s complete, we move on to the next one. We don’t leave it alone until it is done. We show ownership over the process.

Our test manager and I will work to refine the backlog of new and incoming items. Making sure release items have applicable tickets. As a group we can help create tickets for regression and onboard testing, based on the Templates found in the backlog.

Stand-ups will become a place to talk about what you did yesterday, what you are doing today and if any of your work is blocked and you can’t get it finished.

We’ve written up more specific processes about how this is going to work and documented it confluence. If you find any issues, please fix them or propose changes to make it better. I expect this process will evolve as we try it out.

A few suggestions

There are a few challenges and gotchas when moving to a pull system:

1. Don’t work on too many things at once. In fact just assign yourself to one ticket and then work on that. When you are done, go grab the next most important item. The next person available gets the next most important item and so on.
2. Proactively call out when you get blocked on something or think you might get blocked. That way others can help you.
3. If there’s no work on the board, say something. Then go onto doing call reviews and/or training.

In the end

In the end the goal is to give all of our team members more ownership in the process. As an organization we want more of an ownership culture. Through ownership we will be able to work more productively and learn more rapidly. We won’t have a single person as the bottleneck and (hopefully) we’ll be able to involve more of our stakeholders in the testing process.

Right now it can seem like we exist in a silo. When our team members take ownership of tickets it means greater potential collaboration across groups like Dev, Product, customer success, etc.