The header is a wonderful sketchnote, by Laurens Bonnema, drawn during the masterclass.
I recently visited a Scrum masterclass on working with (geographically) distributed development teams. The meeting was professionally organised by Prowareness and was attended by over fifty people, ranging from coaches and scrum masters to entrepeneurs, managers and developers. Overall, the masterclass was interesting and educational and I highly recommend going there if you’re from the Netherlands.
I’m interested in distributed software development because I’m curious about the benefits. From what I’ve read and experienced, there are several reasons to take this road. The most prominent reason seems to be cost. Hiring a remote development team (in India for example) is significantly cheaper than hiring a local team simply because of the lower wages. Another reason seems to be a desire to continue development around the clock as teams pass on work to teams in other timezones. This can certainly be a competitive advantage. Third, you can presumably easily scale the size of development teams by hiring additional remote developers. A final reason is that it’s often pretty hard to find sufficient skilled local developers, so hiring remote teams circumvent that problem.
I blurred out the faces because of privacy.
Another interesting argument that was made at the masterclass is that distributed software development can presumably improve the quality of the Scrum cycle. This is easy to understand if you consider that working with distributed teams (like 2 developers in The Netherlands and 4 in India) requires high-quality communication and coordination in order to work effectively. The Scrum framework is of great help here, as Rini van Solingen (professor in distributed software development) convincingly explained. After all, Scrum prescribes very frequent feedback through sessions for planning, reviews and retrospectives. It separates roles and responsibilities and puts down a solid (social) contract for communication (every day, at a specific time on a specific location). But I’m not convinced that this argument is in itself a reason to start with distributed software development. All it proves is that distributed software development is much harder than local development and puts more strain on communication and coordination. It does not prove at all that this also increases the quality of the software and the business value that is delivered. There is a subtle assumption underlying this argument that strict adherence to a process like Scrum improves software quality and delivered business value by and of itself. This is good news for Scrum trainers and consultants because it is their job to implement such a process. But this argument does not tell us much about the quality and cost effectiveness of what is delivered by that process.
In fact, a presentation by PGGM (a large Dutch pension administrator) during the masterclass made me wonder about just that. They presented two projects that involved distributed teams (the Netherlands and India). A recurring theme in this presentation was that although everything worked out well, it took a lot of blood, sweat and tears to get there. Although the teams obviously had a lot of fun working together, the impression that I got was that the team in the Netherlands was mostly tasked with performing code reviews, repeatedly answering similar questions and - basically - keeping the Indian team on track by holding hands. Although this is just one story, I have heard of many similar stories from different people in the industry. It does not seem to matter if remote teams are from, say, India, the Ukraine or Poland. In almost all cases, the responsibility of the local team shifts from development to quality management and control.
There is really nothing wrong with that. Remote teams are considerably cheaper than local teams, so it may be more cost effective to go down that road. If the remote team can do the development work, a local (skeleton) team can control quality and provide guidance. But I have two potential issues with this. The first one is that it feels like we’re just introducing new kinds of functional silos; the ‘smart people’ here and the ‘cheap workforce’ there, or ‘quality managers’ here, ‘developers’ there. And here I am, thinking that the whole point of breaking down silos is to promote agility, creativity, innovation and collaboration through self-organization. My second issue is more concerned with the business perspective. Is this whole venture still cost effective if you take into account the overhead required for communication (strict adherence to Scrum), the need for a local ‘quality control’ team and the quality of code delivered by remote teams? And what about the cost of losing local ace developers that are simply not interested in handholding other developers? After all, ace developers are ace for a reason; they love writing high quality code, not continuously reviewing code written by others.
So, what is the actual cost effectiveness of distributed development? What’s in it for me, as a business? Or, how we do decide which approach is better; local or distributed? Because this was a masterclass, I decided to propose this very question for the ‘world cafe’ setup. Most people agreed that this was a pretty important question, but there did not appear to be a decisive answer. This surprised most of us quite a bit. I went into this masterclass with the assumption that I would get a sales pitch to convince me of the need for distributed software development, but I didn’t. Everyone did agree that remote teams are cheaper. But everyone also agreed that doing it just for the money is going to result in shoddy code. If you pay peanuts, you get monkeys. But if it’s not for the money, then why bother? There must be some measurable benefit? Or are companies really jumping on the bandwagon without having any proof that it actually works? My questions actually made someone wonder “why this measurement of cost effectiveness is so important for me”. Well. I would certainly hope that such crucial decisions as whether or not to outsource software development is based at least partially on facts. I would really hope that CEO’s, CTO’s and the like are also interested in these questions.
I’m sure that it’s actually really about money. And that’s ok, because we’re talking about businesses. Remote software development is cheaper, even when people at a masterclass tell me that that should not be the primary reason. But if it’s about money, how do we know if it’s really cheaper? If businesses arguably make these kinds of decisions based on financial reasons, where are the numbers that compare the ‘total cost of ownership’ of software delivered through distributed teams with local teams? I truly hope to find some good answers to these questions. So if you have any tips, let me now.
Despite these questions, I also did learn a lot as well and got some questions answered. The masterclass provided me with several good tactics and tips on how to manage the difference in culture and communication. I also got to meet a lot of interesting people with different stories about distributed development. Some positive, some not so much. The general atmosphere was also very friendly and open, which I appreciate a lot. But in the end, for me, the ultimate question was left unanswered and I am still not convinced of the need for distributed software development. Maybe some other masterclass?
More information on Scrum masterclasses can be found here.