Software Development: A Team Sport Built on Trust

Software Development: A Team Sport Built on Trust

Basketball & Software Development

While watching the documentary The Last Dance I saw the similarities between Phil Jackson’s relationship with the bulls and a scrum master’s relationship with their dev team.

Like basketball, the success of software projects comes down to getting key players in the right roles and having them trust each other.

The Importance of the Team Relationship

Before Phil Jackson became the head coach of the Bulls, Jordan was coached by Doug Collins.  Collins coached the team with the philosophy that Jordan was the star and everyone else was just secondary.

This did create wins but it wasn’t long before Jordan was the single point of failure and opposing players could just double-team him.  This also meant that if Jordan got hurt or sick, the team would surely lose the game.

This is no different than software projects that have a heavy reliance on a star developer.  When that developer goes on vacation or gets sick, all work stops.

This all changed when Collins was replaced by Jackson, who brought the Triangle Offense, as an effort to build up the resiliency of the entire team.

How to Create Resiliency and Trust in your Team

Jordan was initially against the triangle offense strategy.  Jackson’s style of play meant Jordan would have less control over the outcome of the game.  Jackson worked with Jordan to elevate his teammates, turning the entire team into an unstoppable force who dominated basketball in the 1990s.

How do you incorporate Phil Jackson’s approach to your software team?  Much like Jordan, your star developer may initially brisk at not getting the juiciest parts of the codebase but overtime as the rest of the team levels up they’ll realize it puts less pressure on they having to be the hero of every sprint.

Swap Stories and Pair Up

A great way to build resiliency is to have your star developer work on stories that don’t match their strength.  If they’re mainly a front-end developer, then have them work on back-end stories.  If they’re mainly a back-end developer then have them work on front-end stories.

This prevent the scenario where all front-end work or all back-end work goes to a single developer.

Once your developers take stories that don’t usually go to them, have them pair up with another developer with the expertise.

This may hurt your velocity over the sprint but it builds up resiliency in the long run and makes the team stronger as a whole.

Create a Process of Peer Review

Doing peer reviews will enable your developers to communicate best practices in a regular manner.  Through GitHub or Bitbucket they can discuss specific lines of code and different approaches to accomplish the same task.

They can also regularly make sure no bugs have been committed into the codebase.

Utilize Retros to Build an Environment of Trust

Much like basketball players review footage of their most recent basketball game, you use retros to review the last sprint.  Retros are a great place to discuss what went well, what didn’t, and what steps the team can take to improve overall.

People & Processes are the Key to Successful Scrum

Just how the bulls never won a championship until Jordan had the right teammates you may not getting the best out of your software development team.  Scrum is much more about people than many organizations realize.

To implement Scrum successfully you’ll need the right people and processes and then the right tools to aid them.

If you found this post helpful to your software journey, please subscribe to my newsletter where I talk about my experiences building software for myself, others, and helping aspiring product managers do the same.