An important dynamic of becoming a fluid and well-functioning Scrum team is when team members are continuously pulling. As opposed to being pushed or waiting to be pushed, the team is in constant motion, pulling from a queue of features that should deliver value to customers. The product owner established the queue of features by pulling from the overall organizational vision and strategy and a backlog of stories are created and prioritized.
The team pulls from the top of the backlog to decide what will be accomplished in a sprint. Team members pull from the task board throughout a sprint, regardless if its their speciality or within the scope of their role. Status is not pushed to the team but rather, they pull their progress from task walls and burn down charts.
Like many of you I imagine, I have worked on teams that were oriented to pull and I have worked on those that were pushed. This post is not meant to debate the merits of one over the other but for me and others, being a part of a team collectively pulling is much more satisfying and exciting than the alternative.
What I have experienced on teams who are being pushed (as both the pusher and pushee) are the ones doing the pushing are usually managers, supervisors, or project managers. They are expected to deliver results and they may very well obtain them but often at the cost of long-term team and organizational health.
You can always add more pushers and use brute force to get something done. Eventually the people doing the pushing will wear out and you’ll run out of pushers. Those being pushed may, at some point, have had enough of being pushed and move on.
It is also hard to change directions when in a constant state of pushing. You have probably tried moving a string around a table. Push it and it becomes a ball. Pull it and it goes wherever you want.
If you have made the decision as an organization to focus on pulling rather than pushing, here are a couple of things to consider when transforming or building your team:
Establish a compelling reason for people to pull. A pulling team requires a vision and a target – without one they will just keep themselves busy or they will create their own target until one is supplied to them.
Design your workflow system around pulling vs. pushing. Your system should make it obviously painful when someone within the organization begins to push. Pushing occurs when a common vision has not been established or communicated effectively. Many Scrum mechanics will help reveal when pushing occurs so treat any push events as impediments.
Teach and encourage the system. People will be hesitant to pull when they aren’t sure what impact their pull will have. Before coaching pull, make sure leaders and team members understand why pulling is so important to the overall health and success of the organization.
Latch on to strong pullers. You will be able to spot the strong pullers. They are the ones at the front of the line asking what’s next. They are not comfortable waiting and are often an expert within their role. They don’t mind blazing new trails for the team. If there is someone struggling with proactively pulling, have them shadow a strong puller for a couple of weeks.