Building a team is like building Software…

Hi! Are you a Scrum Master? Yes? So how exactly do you answer the most terrifying question of “What do you do?” over family dinner to your dad’s eldest brother who always wanted you to be a doctor or an engineer? Oh and don’t forget you have to explain to your client why exactly they need a full-time Scrum Master for a team that may well never have practised scrum before.

So here’s my two cents. Scrum is really all about teamwork; teams working together towards one goal. So Scrum Masters for a large chunk of their professional lives spend their time building teams. Recently, my response to the dreaded question has been that I build teams that make software. No, not a Software/Technical Project Manager. But a Team builder.

Now, often people management is looked at as an abstract phenomena while building a product (bridges, cars or software) is considered more defined. David Van Rees (@Dave_van_Rees ) , my mentor and coach at Rangle.io, was asked why he switched from development to become a Scrum Master. His response to that was both enlightening and inspiring. Basically he compared building teams to building software…interesting right?

Allow me to elaborate. When you’re building software, you’re faced with the challenge of integrating many moving parts (user interface, processing logic, processing capacity, design, hardware etc.) Turns out when you’re building a team, you’re pretty much doing the same thing! Integrating many moving humans (aggressive people, humble people, submissive people, leaders, followers, Type A and Type B personalities etc.) Just like software, one component may not function very well with another component and to fix that, you either create rules of interaction (protocols) or you replace an incompatible component with a compatible one. Scrum Masters ensure this happens.

Software is impacted by the environment it’s run in. While some software run well on iOS, they may not work very well on Windows or vice versa. Similarly, teams have an optimal working environment too. Some teams may perform well under lack of guidance while others may perform well under a clearly outlined plan. So Scrum Masters help the team realize their potential by creating a suitable environment with the Product Owner.

Software if not maintained will eventually accumulate technical debt. Teams if not continuously maintained, unblocked, motivated and encouraged will eventually accumulate low morale and decreased performance(emotional debt). So Scrum Masters work to reduce this debt.

I could write an endless list of comparisons here but I think you get the point. Funnily, the interesting thing about humans is, that unlike software and in spite of all the studies and psycho-analysis, there is no manual that perfectly defines inter-human compatibility or motivating factors. So if anything, building teams is more complex than building software. Oh well, who knew. ;)