Why Enterprises need distributed Scrum teams

Most software development today follows the agile methodology. It’s faster and more efficient. But what happens when you are looking to scale your operations, without compromising on the pace of development, or the level of expertise?

Rahul Dewan hosted an episode of our  Wednesday Webinars, and had a conversation with agile coach, Avienaash Shiralige, exploring this concept. The session examined what distributed scrum teams are, how they work, the challenges to expect and how enterprises can solve them. 

Here's a look at the video and the complete transcript. 

Transcript

Rahul: Right, thanks Nilanjana. Thanks everyone for joining in. So let me quickly introduce myself and Avi here. I am the CEO of and have been on the Agile journey for five years or so, which actually started pretty much with Avienaash, who is presenting largely the slides on the deck. Avienaash was a Director of Agile Transformation at a company based out of the Delhi NCR region about five years ago, when he conducted the first training for us at . And eventually he actually became a consultant to us and then went on to join us, and he now heads our Goa Office. And we call Avienaash Avi, and that's how I'm going to keep referring to him through the course of this discussion. 

This is meant to be a discussion, as I said, between the two of us. I'm going to be asking Avi some questions. Very often, I also have some insights into those questions, but we've set this up in the format of a question and answer session. And so Avi is the expert here and I'll be picking on some thoughts and perhaps delving into more ideas or sharing some experiences from my own perspective, especially through this conversation. So Avi if you're all set and ready to go, then we'll just get started.

Avie: Yes, Rahul.

Rahul:  Excellent. So really the first question that perhaps comes to one's mind is what are distributed agile teams? And after all isn't scrum about colocation, so why have distributed agile teams at all in enterprises or otherwise?

Avie: Okay, yes, valid question Rahul. Welcome everyone. So whenever we're talking about any distributed teams—we're only mentioning this out here—if the teams working on a particular product are distributed in nature from the time zone perspective, from the physical geography perspective, that's what we call as distributed teams. Now, why would an enterprise really want to go for distributed teams is a natural question.

Every one of us, we're looking at scaling our businesses, and particularly when we're looking at scaling these businesses, we run into the challenge of skills. Sometimes, some of the skills that we're looking for are very rare in the same geography.

And this scaling up is many times driven by pretty fast-changing market conditions. We don't have so much time to really sit down and look for hiring locally and build a team. We rather want to be in a place where the team is ready, comes on board and gets things started. So the skill, and the speed at which we can onboard a team—these are the reasons that we would really like to scale the teams. And these are reasons why we need to have teams where we go beyond borders and start looking in other locations to bring such a kind of team.

Definitely, there are multiple challenges that you'll face with taking this route. I always think integrating different cultures is the biggest challenge. So we'll spend some time today during part of the session, focusing on some of these challenges and how we could address them.

And interestingly Rahul, I saw this one very interesting quote by someone I would consider a "pessimist." I would just want to quote that here. So it was written as, “There is a perfect world, then there is our world." And I'm finding for most people that distributed virtual teams can work and do work. But you need a leader that knows how to enable virtual teams.So this is not a skill that most people have, so colocation is highly recommended. 

So this is true typically for a lot of teams. They are unable to build a good distributed team because of the lack of that level of leadership. Just reverting to colocation and not building that leadership is not a solution that the current market needs or really requires. So you need to apply some really proven emergent practices and patterns that are coming up with more and more teams actually trying out this model. And doing continuous rigorous improvements, sprint by sprint, is the way to go, going forward, to build this kind of a distributed team.

Rahul: Sure. So what you're really saying is that basically you're not going to find all the skills that you need to scale up your enterprise and all the projects that you need to do without having to go out to different geographies, perhaps within the same country. Even within the same country in different time zones, different cities and may be even going offshore to perhaps India, or maybe nearshore to Eastern Europe, or I don't know, South America and Ukraine and so on.

So I mean it's inevitable because the business demands it, right? And the second thing I'm hearing from you is that colocation is the easy answer, but distributed teams is, yes, more difficult, but you need excellent leadership within the organizations, within the enterprises, who can or which can make this work, which can make distributed teams work.

So there is a lot of bad name that India gets, and a lot of offshore companies. I, in fact, came across an enterprise, a client of ours in Australia, in Sydney, who was outsourcing to Perth. And they said, "Oh we're done with outsourcing. Even within Australia it doesn't work for us, just a two and a half or three-hour distance." And so outsourcing as such gets a bad name, and off-shoring to India or say to Ukraine or Eastern Europe is even worse. But I guess it's two ways is what you're saying. You need strong leadership on the other end as well to make this work and it cannot be outsourcing...

Avie: Exactly, Rahul. Yeah, definitely. I think we're going to talk about some of the patterns very soon in this session.

Rahul: Excellent, Avi. So I mean really the next question is then, how do you structure such teams, Agile teams and scrums teams, POs and SMs and their architecture, and of course, where do they reside? So two questions together really for you to answer.

Avie: Yes. I think one of the... we start treating Agile and scrum as more of... or probably many times we know Agile is all about the cultural transformation of a company. The way of working, everything needs to change, but sometimes we start putting scrum in the bucket of... like a pure process, but I would always think scrum is an organizational design framework. And how would you design an organization to achieve agility within our teams, within our mission making, how do we respond to the market—that's critical.

So if you look at a very typical team, say... let's take an example, you're building a big product and you have a long list of features to be built, and you do have multiple teams. Now take an example. Let's say, Team B is not onsite. Team B—because you wanted to build some new part of the product, you want to build something from scratch that needs a rare skill, you go out to different locations, like any offshore location, and you start building Team B. So now this Team C is a distributed team because you don't have not only physical proximity—you don't have that, plus, you are in a different time zone. Say something like India. It would be anywhere between four to 12 hours of difference from your actual onsite.

So this is important. We know that this is the way to go, but how do we solve this problem? One of the things that teams do is organizational… as part of organizational needs, how do we give up the product management teams? You do need multiproduct owners, because as you see here, one of the product owners might be working in Team A and B. Because it could be for us that if a product owner is quite experienced, he can easily work with two teams. And on the second product, one is working only with Team C—maybe the reason is it's a very high complexity product. These are the multiple reasons.

So based on the effectiveness of these POs and the effectiveness of this conversation with the client, we design this model. But when you do have multiproduct owners, you run into a problem of conflict of interest, when it comes to making larger decisions—when it's released, what needs to go, what part of the product should take high priority, and all of those.

So that's the reason we usually have—chief product owner people, you might refer to them as in normal companies—they are usually called VP Product Management by title. So these people really helping in at least addressing a lot of these conflicts within these teams.

So if I now... if I say this is a generic organizational design, now let's try to zoom into one of these teams in which we're saying that we need to offshore Team B. Because we need to build it quickly, so let's see how these different models exist within Team B—you need to build it. One of the models...

Rahul: So Avi may I interrupt you?

Avie: Yes, sure.

Rahul: May I interrupt you and ask the question on the earlier slide. So just curious that you said that there is a chief product owner. So say for example there are scrum masters in all or some of these teams—I don't know how you've thought about it. But how does the team, okay, forget these scrum masters, but how does a team here manage multiple stakeholders, getting them on—multiple product owners, sorry. So is it that the product owners may have parts, the team is handling a part of the project which is with one product owner, or could it be across different product owners—then how do they coordinate? Do they talk to the chief product owner directly or is it like a group workshop or how does that work?

Avie: Okay, valid. So usually in this model is the PO who is actually working on that particular team; he has got all the context. Because this particular team is working on a specific aspect of a product. Say, the team is working—let's take a scenario on a video streaming party product. And another team is working on a… let's assume on a web part of the product. So it could be multiple such teams working. And the PO is the one who is very critical here, who interfaces with Team B and also interfaces with the chief product owner. So I don't see a reason why Team B needs to really connect with a chief product owner, except there could be the overall demo of this sprint, where you might have all of these stakeholders, and a few others in the company might also be part of it, where the team has a chance to hear from all these people. But most of the communication here is critical for the PO on the team to handle it, within other product owners and even with the chief product owner.

One of the challenges in all you face here in these teams: inter-team dependencies. And that's very critical to handle, because not every time is it a business dependency, there could be a lot of technical dependencies also. So I'll talk about that when I speak a little bit more on the communication side of it, how we address those challenges. Is that fair?

Rahul: Yes, absolutely. Sure Avi. So I mean just a quick thought here and maybe just summarizing—so basically you're saying that the product owner teams at the client sites, including the chief product owner, needs to actually work like a very well oiled team if I may say so.

Avie: Yeah.

Rahul: Yeah. And if there are dependencies that teams face which is a different part of the product, it’s the responsibility of the product owner on that particular team to solve that.

Avie: Yeah.

Rahul:  …or however, he or she may do that. Okay, excellent. Sorry for interrupting you, let's move on. Thank you.

Avie: No, that's great. So now let's try to zoom into one of the teams, say Team B, and let's try to see how if this is distributed in a different location, what are the different models that we can work with.

So take an example. I have taken here—definitely one of the models is the PO being onshore and the team being offshore. So whenever there is an offshore team, I would always... what success we've seen is definitely to have a larger part of Team B having a scrum master next to them. So here the scrum master sitting next to the team is very critical from a cultural angle, because you also need to know the cultural aspects of the team, how to work with this team to get the best out of the team. Plus, trying to solve infrastructure, communication challenges, process issues, requirements not being in place, working with the PO—there are many such roles that these SMs need to play.

The other aspect of this model is hiring a technical lead on architecting. Definitely working with a team, possibly you might start with a full time architect, and gradually with the team building its own technical expertise, you might want to reduce it in a service business. So those are all possibilities that we can always explore. But one thing that really we need to do in this model is the PO and the team's cultural integration. The PO and team meeting the people in offshore locations at periodic intervals is very critical to build a rapport with the team. If not, because of multiple... what you call reasons, that a team can never have more than a professional relation with a PO. And it gets very tough for them to really open up and question things and probably brainstorm along with the PO.

So I suggest we should go for as much as possible real time meetings, all real time meetings to be in audiovisual format. So that you get to know the person's body language, which we could see in face to face, often is very critical. And no doubt, standups being at the team's side with the PO attending them—you choose your standup time, either in the morning or in the evening whatever works for you. And if the PO is not available, at least have one or two couple of real calls with the PO and the team once in a week at least. And the virtual teams, we need to go for lot of more electronic tools, similar to like in , we have been using JIRA extensively. We have quite a bit of customization, using JIRA, Confluence, Slack... that has resolved a lot of these communication issues within the company.

So this is one of the models where you have only the business sitting in the onshore and the rest of the entire engineering team is offshore. Rahul, you might know that we've worked on this model for many different clients. And it has been working really well with this team structure.

Rahul: Yes.

Avie: And the second model is we already have a PO and also an engineering team—a full-fledged cross-functional Indian team already. Now they are looking to scale up quickly. We go for finding another team in a different location, which is Team B. So this is a very interesting challenge, because the team may have a lot of business and technical context already sitting next to the business, compared to Team B which is just on board and may not have so much business context, and what decisions has been made earlier to lead to this current setup of technology choice and everything.

So definitely here we need to address those challenges, and one of the ways is that we make this Team B travel, sit with Team A, run a couple of collocated sprints together, understand the process, get our process, engineering practices, everything, then come back to the offshore location to continue working on it. And in this kind of scenario, you need SMs on both sides. And if the time zone really permits, then I would always suggest, we should go for a joint AD stand-ups, what we call distributed standups. And by any chance if it's not two timezone friendly teams, West Coast and India scenarios, a few times—either you can have it once in a few days or every day, the scrum masters of both sides come together in the evening time, talk to each other and give each other updates and how the teams have been focusing.

And this is very, very critical. And then later what we discussed in terms of scrum artifacts being electronically shared with both the teams. Both teams are using the same set of tools—these are all very critical in actually making these teams productive and efficient. So yes, this I would think, are the two major models that we've seen. Buildup changes here and there in a few places but mostly these are the models we've been working with, and it has been working really efficiently for us.

Rahul: Sure. This Model B is very interesting, and as you know, at we've worked on a few models, and for our listeners here, we'll probably be sharing a couple of examples towards the end of this presentation. But we have a sense on both ends that it's most effective when that is there. And Avi mentioned something very pertinent for the offshore or the distributed team which is not collocated with the business team or with the POs, that it's important that they go onsite spend some time in aligning on technology, on processes, and spend a few weeks. And then only come back and become part of the distributed company. I think that's a very important point you mentioned, Avi.

So the next point that comes to one's mind is that in these models, then, what are the challenges, and how do you design such distributed teams for success? What are some key things that enterprises or leaders must be conscious of?

Avie: Sure. Many challenges, we already discussed about some of the top challenges today. So I would actually focus more on dividing them between product owners, people, and you can say cultural—people/process and cultural challenges. So let's look at some of the product owners. We’ve talked about product owners not in physical proximity to have an offshore team, and this really now creates a lot of business and technical context. It's what we call sometimes "coffee machine thoughts", that's not there when you're not sitting next to the product owner. 

And this creates... I've seen, my personal experience has been... the PO's just going to grab a coffee and he sees a developer and he just gives a piece of information, which probably people may not even realize was so critical. This is what an offshore team is completely missing.

And this happens—even this doesn't matter if it's only the project teams. Even within an modernization, which is divided between say, something like —we're divided between Delhi, Bangalore, US—it does happen within us also, where we pass on some information, but the remote offices don't even come to know.

So the only way that you can address this is really being conscious about the fact that there is a remote team which is also looking for information, so I would be careful about sharing all this. So tools like Slack—actually in all these things, provide tools, and everyone being together on that same channel really addresses this. And the PO meeting face-to-face with a team is the other way definitely of trying to give context about the business. And sometimes the PO might be churning out some user surveys, connecting with users, sharing all those outcomes and the results of those along with offshore and onshore team together. These are the things that really start creating a one team feeling.

Second is... it's also on the other side. The PO and stakeholders being onsite, there's a lack of visibility to them regarding how the offshore development team is actually making progress. And that's understandable. Sometimes because of the sheer time zone difference, you don't get to see a probably five minute demo which I could have seen if the person was sitting next to me, with the developer on the onsite.

So we too, definitely, we've been doing lot of those informal demos throughout the sprint. After then one formal demo at the end of the sprint, along with all the rest of the stakeholders. But at least many such informal demos in between with the PO, just share the link and put your product on the staging and send over a URL to the PO.

And using tools like JIRA very effectively definitely reduces a lot of those visibility issues. And also a lot of these informal demos will start reducing even the feedback cycle. If not, in distributed agile teams, you might run into elongated feedback cycles, which is just a sheer time zone problem.

And one more critical point—when you're collocated a lot of verbal communication can happen, but in a remote team, there is a lot of documentation overhead that might come. But interestingly, there are some creative ways that teams are solving this, by POs, say, if he has to convey some design, just doing the sketch, sketching it out with pencil and sending it across to the team. Sometimes we need to do documentation from a user manual or how the product works, how a demo works.

So, we just do screen casts of the demo and share it with the team with stakeholders. Or even with technical documents—instead of writing 100 pages of technical documents, we just record everything, pictures, diagram, everything in that piece of video—and share it with the team.

So these are the ways that we can really address some of these challenges that we have been using for some time now.

So the second thing which I wanted to talk about was regarding the people. Here what I'm really… what I want to focus is on the common infrastructure that we need to have with the teams. Common infrastructure in the sense, say for example, when I started with a lot of teams between different locations, I've seen the onsite team working on high-end laptops, good bandwidth and probably a source code repository very near to them—all of those compared to remote teams having some of these challenges.

So I would really address some of those infrastructure challenges right away. At least we should have a similar development environment, so that we don't run into… "I got this problem on my mission but it doesn't replicate on an onsite team." So some of these things we should definitely address, and bandwidth all these things have to be addressed. Even if is doesn't fall into the clear slot of being a real challenge for people effectiveness, it creates more issues that magnify into a different challenge altogether to solve.

And then differences in skill sets. Many times we see that in India, we have a five years experienced guy working with the 20 years experienced guy onsite—so we do run into that skill set gap. And one of the ways that we can always solve this is that we could do some paid programming techniques. Along with the distributed paid programming, set up some kind of coding guidelines at the start. And having frequent peer code reviews and also investing in training and coaching the people—that really starts addressing some of these differences.

And the third that I see is lack of trust. Whenever you start with any offshore team, the trust is critical, but we don't have any past relationship to say that we can start with high trust. So what we've done in our past is, we start small, with probably not very complex things on the offshore team's plate, and slowly let them get on track with the code base, with the product domain. With engineering practices. And as the team makes commitments and they deliver it, gradually the trust starts building up. And as we start addressing all infrastructure, communication, bandwidth issues and everything.

So this is critical for us to make sure that people don't run into any of these challenges. But there are a few other challenges that come up. Either way, I have to pick it up as part of cultural challenges: different ideas about authority.

In Western culture as compared to Eastern culture, there is a bit of the hierarchal in the Eastern side. So we have to be careful about some of the team members not opening up to to the scrum masters, on to their onsite team many times. So one of the ways is we definitely need to create a culture of peers, and we should be really careful about hiring some of the people like SMs, product owners, who really gel very well with the team, and who don't bring that traditional mindset back into the team.

And this is also a very interesting selection process for many of the onsite teams, when they want to choose their offshore team. What is their culture, how do they make decisions, is it command and control on which their decision making relies, and then the collaboration quadrant? That's critical when they actually make some of these choices.

The next challenge I see is from a language perspective. You might see most of these things when you're working with… let's take an example, you have teams in France and India, both of these countries. Their native language is not English, but the only way that you can connect is in a global language like English. So we do have our own challenges in articulating our thoughts on both sides. So I think the team needs to invest some training and coaching on these, and trying to resolve accurate articulation issues faced by both sides. So this is an investment usually… we need to do this for Agile teams, particularly when they have some kind of language barriers.

And the third one is on the holidays. I think it's all about respecting the different cultures. It's very similar to Independence Day—July 4th in US, everything is closed. The same thing you should expect when August 15 arises in India too. So the teams are not working, people are not available and there is a sharing of different sets of holidays, different cultures—I think it's also going to be very interesting for everyone to learn from each other. How different cultures co-exist in a global world.

And the last one is definitely time zones. I’m going to talk a little bit more about how we can address or negotiate on time zones in the coming slide.

Rahul: Avi, I hate to interrupt your flow, but I was making some notes while you're talking. And I probably want to repeat some of them for our listeners and also share some insights that occurred to me while you're talking. So just a few thoughts going back three or four slides, you mentioned something on documentation overhead. While it is considered in scrum teams that you want to minimize documentation, Avi, now you're also saying that with distributed scrum teams, there is a little more need for documentation. Especially for the teams which are not collocated with the business. In quick sketches, quick wireframes and sending it out for clarifying stories.
So the onus I'm hearing you say is also on the distributed teams to clarify from product owners. That was one insight, yes?

Avie: Exactly, Rahul.

Rahul: Then you mentioned, touched upon a very important point on senior devs and difference between them. If somebody in the US would be a senior dev and would have spent 15 years already in the industry and would still be programming. And a senior dev here in India, where largely because of the services industry, the trend in general—and I hate generalizations, but I like to do it here—is that people want to see progress when they move from being developers to managers. And that starts happening pretty... that switch starts happening between five to seven years.

So a senior dev here may be somebody with four, five years, and a senior dev in the US would have 15 years’ experience, and they could be sitting together and writing code together. Of course, the US is not always the best parameter for measuring who is a senior and junior, especially in the context of for example—we ran into that a lot. People with three years, who typically wouldn't be considered senior, are more terrific and produce more than people with 8-10 years out there in the industry.

Just for our audience, this is an important point: that the senior dev onsite, in Australia or in the US, versus a senior dev here—the designation may or may not say enough about the qualification... not qualification but the skills of the person in programming in that job.

So really I think… the next point Avi, you had mentioned is on trust. And these are interconnected things. If a person feels that... take this company, especially in an outsourced model where it's not your team within your company, and culturally a different company, you can start with a lack of trust, if you say, "Oh, you guys give us a senior dev but this guy is not able to do X, Y, and Z in comparison to our senior dev."

Those kinds of comparisons I think could be detrimental to the team, and I think the good way to start off is with the right expectations and the right understanding of the skills of developers in the team. And I think the best way to do that is by doing a group chat session, or if you want to call it an interview, sure. Perhaps look at the distributed teams, contributions in the open source community especially. We're coming from Drupal; there is a lot that developers can contribute, are encouraged in our communities to contribute. So one can look at that.

Avi, you may have talked about cultural impediments as well in distributed teams. And once again, I'm repeating myself but especially, when the distributed team is not of the same company, y