Life is a marathon. Unless you’re a software engineer...then it’s a sprint.

Put yourself in the shoes of the average individual contributor. What do you imagine their primary goal is during a sprint? If you guessed “complete their assigned tickets”, then you’re probably right.

For years as an individual contributor, I had been led to believe my primary goal at work was to speed through my tasks as quickly as possible. Any time spent in meetings, helping others, and reviewing code was seen as the time taken away from completing my work. If I finished my stories early, my natural response was to pick up another ticket.

What if there was a different approach that could not only help you complete your work but could also ensure your team achieves their sprint goals?

To understand this new way of thinking, we first need to understand how we ended up here in the first place.

Why Do We Work This Way?

As much as we hate to admit it, most company cultures have led us to believe this is how things should be:

• “If I don’t find a way to stand out, then I won’t get that raise/promotion.”

• “If I don’t complete my work quickly, then I might lose my job.”

Some might say I’ve become jaded over the years, but I’m willing to bet I’m not the only one who has felt like this. The truth is that even if they preach the gospel of teamwork, most companies value individual output over team collaboration.

Don’t believe me? Think about some of the metrics that teams tend to track via systems like Jira on an individual level:

• Number of points (a.k.a. velocity) completed
• Number of points carried over
• Amount of time a story spent “in progress” or "blocked"

It’s no wonder that most software engineers tend to want to focus on their own responsibilities when the framework itself encourages fear and competition!

There’s Got to Be a Better Way!

There’s working as individuals on a team and then there’s working as a cohesive unit towards a common goal.

I wasn’t truly able to switch my mindset to working as a team until my team’s architect at my last job introduced me to a different way of thinking about my work.

What was the concept he introduced to me?

Instead of focusing on completing my own work first, I should really be consistently helping unblock my team throughout the day. He referred to this as working from “right to left”.

The Process of Working Right to Left

Picture a sprint board with the following columns (a.k.a. “swim lanes”):

• Todo
• In Progress
• Code Review
• QA/Testing
• Awaiting Release
• Done

In the current way of working, the main focus is to move your own tickets from “In Progress” to “Done”. In the new system, we reverse the thought process. The narrative then becomes how you help your teammates move things that are in “QA/Testing” to “Awaiting Release” or from “Code Review” to “QA/Testing”.

Once you complete the process of going through all of the tickets that currently need to be tested, code reviewed, and no one needs help with something technical, you can go back to completing your own tasks.

This cycle is repeated a few times during the day by various team members (though when exactly is up to the individual). I tend to go through the process about 2-3 times in the workday. Once when logging on, after lunch, and then one last time within the last couple of hours of the day if needed. Most of the time these sessions can take me anywhere between 15 minutes to an hour depending on how much there is to get through.

How Does This Help Me Succeed?

At this point, you’re probably a bit skeptical and I don’t blame you. You’re spending a good chunk of your time helping others and that takes away time from your own work. At first, this may seem like a negative, but over time you’ll build trust with your team and vice versa. Assuming there are no hard dependencies or deadlines within the sprint, it doesn’t really matter when you finish your own work as long as you get it done.

As your team gets into a rhythm of helping each other, you’ll find that you should have longer chunks of focused time to work. Your teammates will now be frequently unblocked and focusing on their work. Once you communicate a blocker of your own, you’ll see that your teammates are willing to pay it forward and help you in return. The urge to help one another so that the team succeeds as a whole will drive them since they’re making an impact towards a common goal.

By addressing the needs of your team at various points in the day, you’ll be seen as a multiplier that enables your team to succeed and someone who is compelled to do whatever is needed to help clear the board. This will lead to your own long-term success faster than working solely as an individual.

Conclusion

If you’re still not convinced that working from “right to left” is the best method, I encourage you to try it out. Propose the idea to your team for a sprint or two and see if it moves the needle at all.

I acknowledge that as always, your mileage may vary. You can always cherry-pick the things that do work for your team and tweak what doesn’t.

If you already work with your team in this manner or you’ve decided to give this a try with your team, I would love to hear about your experience! Drop me a comment below or send me a tweet.

Until next time, go out there and make an impact!