Team Building is Akin to Building Software: A Scrum Master's View

Written by Rehana Rajwani

Building a Team is Just Like Building Software: Reflections from a Scrum Lead - image In this post, our Scrum Master Rehana shares her unique insights on what makes building a strong team comparable to building strong software.

When someone asks me 'What do you do as a Scrum Master?' Or better yet, I need to explain to a client why they need a Scrum Master for a team that may never have practised Scrum before, I now have the answers. The following post shares my perspective on the way I go about answering these questions so that I can show the true value of Scrum.

It's All About Strong Teams

Scrum is really all about teamwork; teams working together towards a common goal. Therefore, for a large chunk of our professional lives, we spend our time mindfully building strong teams. I build teams that make software. I am not a Software or Technical Project Manager. I'm a Team Builder.

Often, the practice of building teams and maintaining a healthy dynamic within those teams is looked at as something of an abstract phenomenon, while building a product (bridges, cars or software) is considered more defined. A recent study by Google showed that the number one character of good teams is psychological safety (i.e. team members feel safe expressing themselves around their teammates and without fear of judgment from management). While this may sound too mushy to some, it is actually not just an important factor in a team's productivity but also essential for employee retention. Feeling safe basically implies trusting people around you and integrating well with them. Think of it like this: When you’re building software, you’re faced with the challenge of integrating many moving parts like user interface, processing logic, processing capacity, design, hardware etc. Similarly, when you’re building a team, you’re facing the challenge of integrating many dynamic human beings e.g. aggressive people, humble people, submissive people, leaders, followers, Type A and Type B personalities etc. Just like software needs an architect to think about the bigger picture and improve compatibility, scrum teams need a Scrum Master to look at their compatibility in a very structured manner. It's possible that one component may not function very well with another component and to address that, an architect can create rules of interaction (protocols). Similary, Scrum Masters can work with several different interaction protocols to allow for better team collaboration. Core Protocols by McCarthy is just one example from the many tools that are used by Scrum Masters to help teams reach their collaborative potentials.


Software is impacted by the environment it's run in. While some software runs well on iOS, it may not work very well with Windows or vice versa. Similarly, teams have an optimal working environment, too. Some teams may perform well under complete autonomy while others will only excel with a clearly outlined plan. Scrum Masters help the team reach high levels of productivity by creating a suitable environment in conjunction with the Product Owner. This can include ensuring there are proper communication tools and channels available to the team (like Slack) as well as being the person who explains to the Product Owner that their lack of availability is reducing the team's productivity.


In his book The Antidote, Oliver Burkeman claims that it's important for people to refelect on one's mortality every once in a while. I know what you're thinking. This went really morbid, really quickly! Now hold on there for a second. Why is it important to think about the natural cycle of life? Perhaps it puts things into perspective and you stop obsessing about really small matters. Or it makes you think about having better focus on items that really matter to you. So here's the deal. Humans have emotions and every once in a while they need some additional care and attention. It's important to put things into perspective and support others to achieve their highest potential. This also means resolving conflict in a timely manner to avoid a build-up of grudges. If negative emotions are not dealt with in a healthy way, they accumlate into something called emotional debt. Sound familiar? Sounds a lot like technical debt to me! If not maintained properly, software tends to eventually accumulate technical debt (i.e. a ton of out dated and incompatible libraries or inefficient logic that increases processing time by multiples). Likewise, if teams are not continuously maintained, unblocked, motivated and encouraged, they will eventually accumulate low morale and decreased performance, which can be referred to as emotional debt. Scrum Masters can use a variety of team coaching techniques and practices like retrospectives to reduce this emotional debt. Coaching techniques can range from one-on-one interactions with different team members to group coaching in cases of conflict resolution. In addition we look at data trends for team morale, recurring hinderances and conflicts to prepare the team for foreseeable situations, or perhaps even avoid them altogether.

To Conclude

I could write an endless list of comparisons here, but I think you get the point. I think many of us can agree that building teams is just as (if not more) complex than building software. However there is a lot of great neuroscience and applied behavioural psychology research to refer to as we build healthy and nurturing environments for teams. As Scrum Masters, drawing on this body of work, we are particularly adept at creating environments where highly performing teams thrive. It's truly a fun and rewarding challenge.

If you're up for this kind of challenge and have the experience, we encourage you to apply to our team. For some additional inspiration, here are some tips from our CEO, Nick Van Weerdenburg on building strong teams in an Agile environment.

You can also sign up to our newsletter to gain insights on our best practices and processes: