First confession, I’m a convert of remote teams
I wasn’t always a remote team fan. For those of you that know me, that may be a bit strange. After all, I’m working now as a COO for a company advocating the possibilities of working remotely with software developers from Africa. But it’s true.
Before I started working for Tunga, I worked for an IT company in the Netherlands, in a multitude of roles. One of those roles was that of scrum master. And later agile coach. And I think anyone can attest that if you’ve ever had one of these roles for a longer period of time, it never really leaves you.
Anyhow, as an agile coach, one of the things I was most persistent in, was the issue of co-location. You gotta have the team working together in the same room! There are a lot of good reasons for this, which basically all are sophisticated manifestations of the following. If you’re stuck in the same room with each other, you must find a way to literally live together. So the team goes through the forming norming storming performing phases almost automatically. As a scrum master, your job is to guide them along the way and lead them to Valhalla, self-organization. With these arguments, I battled the IT outsourcing to big system integrators who would divert it to India or Eastern Europe. (There remain other important arguments concerning outsourcing vast areas of application management and software development, something easy to do but hard to get right)
Meanwhile, I had a dream of working in Africa, on something bigger than myself, something that is making a difference. And that was Tunga. And Tunga offers remote software developers to clients all over the world. So I had to adapt. I had to understand what remote working was all about, inspect my arguments against it and see how I could improve. By the way, this is one of the most agile sentences I ever wrote. And, as a consequence, I found something out.
Second confession: being a scrum master of a co-located team is easy
Forgive me. I do not mean to deny your work. But let’s face it: if you have a team sitting together, everything you have to do as a scrum master is so much easier. Making the work transparent with a scrum board, writing the Definition of Done (DoD) and Definition of Ready (DoR) on the wall, stepping in when you see someone struggling and connect them with another team member, ask someone for coffee when you see they are not feeling safe, calling a time-out to spot the team dynamics. And the retrospectives! Oh, how I love the retrospectives where everyone is just there, and you can see all the tiny reactions during the discussion. Working as a scrum master for a co-located team is almost too good to be true, the way it meant to be.
Compare that to a remote team. The big difference is that you do not see each other, hear each other, experience each other as you would do human beings in your immediate surroundings. So every team interaction has to be something you agree on, or otherwise, you just ignore each other. Let’s face it, when I log in remotely and I don’t actively reach out to my team, it’s like they are not even there! Very convenient, I must admit. So as a scrum master, you almost have to push the team through the forming norming storming performing phases. And have you ever tried to push someone who is literally not there?
I often felt powerless, acting as an agile coach for the entire company, having no tools to force teams to form. Yet, there was light in the darkness. I realized that all my actions were in sync with some of the most important agile and scrum features. With everything I was doing I was aiming to make the teamwork transparent (for example, connecting commits to slack channels). I geared everything towards measuring outcomes (deploying features daily and inspecting the progress).
But more importantly I had to radically trust all team members, as I had no alternative to check on their actions. I did this, being totally honest here, not to make the team more agile, but simply to make the team work together as a team. I realized that being agile and being remote is not at odds with each other at all. It just requires more, and different, effort to get it right.
The challenges remain huge. And I still consider it a far greater feat to get a remote scrum team to work seamlessly, than a co-located one. But it made me a better, more agile, coach. And the remote teams that thrived have been super flexible. In addition, they were able to switch projects, clients and team settings far easier than any team I ever had that was co-located. Meanwhile, the challenges have not only hardened me as an agile coach, but also them as agile developers.
Third confession: we know we are offering a sub-optimal solution
No one in Europe or the US is waking up and thinking, ‘you know what I should do? Outsource my development to a remote team of African software developers’. In an abstractly ideal world, I would always recommend working with a co-located team. Yet, as the current Corona crisis is making all too clear, we are not living in an abstractly ideal world. We’re living in a messy, practical, unpredictable world. And the strongest organizations are those that are most agile, most adaptable, to the ever-changing conditions. In those real conditions, having a pool of talented, enormously driven and highly flexible software developers is an enormous asset for our clients. Regardless of their physical location.
Let’s face it, remote working is here to stay. The flexibility simply outweighs any challenges you have to overcome. And the good news is, once you’ve overcome these challenges, you’ll be stronger because of them.
