Why Enterprises need distributed Scrum teams

Why Enterprises need distributed Scrum teams

author By abhinavsahai Sep 21, 2016
Submit guest post

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. 


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, you see there are different models. So if you're in a company and you have the same enterprise that has an office in Pune, in India, and it's within your company. While there is a cultural change, it is slightly easier. But the challenge becomes even more when it's outsourced to a company outside of your company, as a services contract if you like.

So what I'm saying is that while working with non-English speaking countries—and I wanted to share an insight here, that I came across a client in Germany who's set up a team in the Delhi-NCR region and I found out that company in Germany which is, I don't know, 200-300 people, and they were saying that they're looking to move to English because their 15-people team that they have set up in India, as a very strategic move for them, is not conversant in German. So they're looking to slowly change over to English.

While that is absolutely fantastic, to adopt a global language, I felt that to build trust and to truly deliver on the services… the spirit of services if I may say, I think it is imperative for the offshore team especially when they're based out of India or Eastern Europe or not in that culture, that they pick up the language of their host country or their host client. Would you agree with that Avi, I think the onus is somewhat on us, right, to pick up the language of the host country?

Avie: Yes, definitely, Rahul. Yeah.

Rahul: And make that investment to build that trust, that, "Hey, look we're investing in this."

Avie: Yes, exactly. I think that's a great point because to get the Agile teams to work, an investment has to be made on both sides, right? So that's a very critical point. If the teams here, which are smaller in number, if we invest for a couple of months and they pick up a new foreign language—it's always interesting to learn new languages also. You get to know a different culture by knowing a language. And it's going to be really helpful in setting a really good communication between, as you said in your example, between Germany and India. I definitely agree with you.

Rahul: Sorry for having broken your chain of thought. We'll have to pick it up again and go onto your presentation.

Avie: No. That’s perfectly fine, Rahul. Okay. Sure. Moving on, one of the… we did discuss this in various parts, but this is just a nut and bolt factor. Nut and bolt factor in the sense that to have leadership on both sides onshore and offshore is super critical to really get the teams going. And with their mindset that we want to make the team successful. There are always challenges, particularly when you have offshore teams—within a company of onshore also you might see some questions raised about why we want to go there. And there are a lot of people who might have questions on those. So it's very critical to choose a team which is really keen to make it successful and accordingly to choose the leader on both sides.

So these leaders are going to work very closely, pulling up the team and addressing all of the mutual, the trust-related issues that will come with time. These should get addressed and really built into something like friendship, which will actually become a really good, successful team. And definitely these leaders need to meet face-to-face. Some travel from both sides is critical, I think, no doubts about that.

The second different piece that we need to work on is, how do we negotiate these time zones? So I'm taking an example between say UK and India. So we can create something similar for when we are starting on offshore-onshore teams. So take a look here. The India team starts on a local standup early in their morning, let’s say, 9:00, then for the next three, four hours are focused on feature development, coding new functionalities. And when the UK team arrives, they all come on together, overlapping time zones and start working as a distributed standup. And continue possibly if there are any design reviews. I'm just giving some thoughts here if you want to do programming together with onshore-offshore developers.

And then India team leaves for the day in their evening, like 5:00 or 6:00. And the UK team continues. But what is really important here is that you define this overlap time zone and effectively use this overlap time to make communications effective, make your design reviews, do your code reviews, do your paid programming. Everything as part of this whole in that time zone.

And the second piece is, whenever you have these distributed teams, if some of you are engineering practices like continuous integration, it is really helpful. Because when the UK team leaves for the day, you want to make sure the build is in green state, and everything that they have committed works perfectly fine. So that when the India team arrives early in the morning, they don't get a build which is in red state. It's in a good state—they can just continue working without doing any waiting for the UK team to come and explain to them what was the reason this was committed.

So it is very critical to automate a lot of engineering practices to make sure that all these things can be easily done. And there may be many more… I’ve written in a lot more detail on my blog on the different ways that we can design these time zones—on my blog at agilebuddha.com.

I just wanted to share a small slide—this is a very simple low cost... you have a team monitor—the team on this side and the other side, both sides are doing a distributed standup together, they're able to see each other, and have a simple wide angle camera and decently sized TV, so you can get a chance to see each other. This is the actual picture and this is the way we've done it in our teams.

And I just want to… this is specifically important when you have multiple large distributed scrum teams, or even if you have only couple of teams—having a scrum of scrums, where all the red ones which are marked are scrum masters here. So these people who come together and discuss, if the team has dependencies, any technical dependencies or business feature dependencies and all of those. And the scrum of scrums usually also has product owners many times. They’re completely aware... the multi-team product owners also I should have depicted here. So multi-team product owners are also part of the scrum of scrums, to address some of those inter-team issues, dependencies or business features.

So this is one of the ways that we can really address communications. And the second piece is whenever you have these onshore product owners, just because of time zones, you might run into challenges if the PO is not there when a team has a specific doubt about a particular story. So what we've done within is, having our own internal product owners, like business analysts with a lot of experience behind them, and actually going from technology and business both. And working along with the onsite product owner so that, he is able to… our PA/Proxy product and he is able to answer some of the team questions, when the product owner might be sleeping at that time.

So this makes this team effective, and why I really focus on this here is I really feel the product owners are like oxygen to the team. If they don't churn out requirements in time, if they don't clarify the requirements in time, it starts suffocating the team. The suffocation leads to slowing down the team, the velocity is suppressed and it even leads to morale issues, because it just leads to lot of rework on user stories and on the features that you're developing.

So it's absolutely critical that you do get into these challenges around the product owner proxy—is he effective, is he able to make decisions when the actual PO is not there? Those are the challenges that you definitely need to address.

Yeah. I think these are some of the things, Rahul, I would think are critical in designing a team, designing some of the specific challenges that you would face and how to address some of these challenges that you usually face while setting up any such new distributed teams.

Rahul: Sure. And then just once again, quick notes that I'm penciling down. So internal POs, in case the onsite POs are not available, proxy POs, BAs who are able to grasp the business on behalf of the business which is onsite. That is one way of designing the team. And then one another important thing I think is the onus on perhaps both the teams to ensure that since they are distributed in different time zones, especially when it is as bad as San Francisco and Delhi or India—we're in the same time zone in India—so San Francisco, with the 12-hour time difference. The onus of clarifying questions and asking questions well in time, so that days are not lost either ways—actually both from the onsite team and the offsite team—days are not lost, and in fact, the time zone is used effectively to get answers to all the questions. I think that was an important point, Avi.

Avie: Yeah. I agree. Okay. So with this I just want to give a quick…some probably I want to recap some of the points which we talked. If you want really set up a really good teams across boundaries, I would say invest in colocation. And define a shared vision within the team, both onsite and offsite to make sure that there both of them know whatever goals that they'd like to achieve to get as a team together. And having scrum masters at the team's sites both sides, having good common infrastructure, distributed standups, overall a videoconferencing tool or Skype or any of these thing that you would like to go for integrate entire team together on a slack list or create one for specific channel for both onsite and offsite to have discussions on project related invest on some basic things, like good headphones, bandwidth, microphones.

And definitely, we would need to…the teams need to do lot of preplanning meetings on both sides, specifically when it comes backlog grooming sessions. So if you have a product owner proxy, he’s working with the offshore team and trying to give the context about the upcoming sprint. This is going to help in building a big picture to the offshore team to both views and proxy view working together with a team.

I would suggest this is super critical, the local retrospectives. Sometimes, personally I've gone for distributed retrospectives varying a team from both sides there together, but in some teams we started with just with a local retrospective and gradually started addressing the challenges and then switched to distributed retrospective and then we see and right level of maturities, we achieved within this team, because sometimes I've seen the real reasons are may not come out or real frustration may not come out, if the onsite and offsite team both do the retrospectives together. So it is a maturity curve which takes time but it can be easily paid with proper introspection and continues improvement we do with sprint on sprint.

And what we've talked about, there are same common infrastructure to both teams using the overlap time zones very well, possibly sometimes team might have to shift a bit of work times to. And hiring a great leaders on both sides to really act as a nut and bolt to bring the team together. And knowledge sharing by colocation, by using communication tools are critical and of course nothing like having great leaders who really want to make this a successful.

I don't see any challenge really, Rahul, in really pending any distribute teams, even if it is lot of time zone differences, there are multiple innovative ways that we can really solve these problems.

Rahul: Sure, Avi. So just another insight that came to me while you were talking. You talked about this—this is great checklist, right? So this sort of a checklist, plus, your question from earlier slides on, finding out what is your culture, especially when you're outsourcing to a vendor and offshore and not in your country, not in your culture, may be to India, say for example, from the US, or India from Germany and so on and so forth. These two checklists you've provided and this question of what is your culture, how do you work—it's not only about saying, “Oh, we are in an Agile team.” Everybody says they're Agile these days. Everyone, right? You talk to your clients, you talk to vendors, companies. It's Agile, but it's really about… I think the differentiation is in the culture.

It reflects about being Agile or are you doing Agile paradigm, if I may say so. I was just thinking that's a great way of choosing your vendor, right? Validating with this checklist and that "what is your culture" question, it's a great way of choosing your vendor. And just not work with anybody who is misaligned with your values or Agile values.

And yeah, that's a very important point about local retrospectives I think you brought up, which is so that there can be some icebreaking within teams and some momentum before you expose the distributed teams to onsite businesses, business teams. Very valid, Avi.

What are the overheads that enterprises should be aware of? You've already touched upon some of these earlier, but maybe if you could summarize some of these—what are the overheads that they must be willing to invest in or they should be ready for?

Oops, Avi. I don't think we can hear you. You’re back.

Avie: Rahul, I'm back.

Rahul: Yes. You're back.

Avie: Okay, great. Sorry. So we did discuss some of these overheads earlier in different ways, as some of these challenges that we felt, that actually comes with a lot of distributed teams. But keep in mind—one thing I've noticed is if there is an inherent challenge, already within a collocated team, it only will get magnified when you go distributed—that's been my experience. You cannot actually keep the challenge under the carpet for long, when you move to distributed, because it just amplifies every problem by a few folds.

So I see distributed teams are just an extension of the same problem that we're already facing with collocated teams. So a couple of things that do we need to be aware that we've talked about some level is added documentation that's required. Probably with a physical proximity team, you might just walk up to someone and share the details of a story without writing anything or with minimal effort on JIRA. But probably with a remote team, you might want to do little bit more documentation around that possibly, and be a little bit more organized also, with proper attached wireframes or designs with a story, clearly defined acceptance criteria and some of those things. But I see that this is critical even nowadays with a lot of collocated teams. I've seen communication challenges happening, and there is no such team proximity. It works very well with a very small team or startups, but as soon as you start expanding, it becomes a major problem.

Then we did discuss about time zones. Of course, the time zone is a challenge but also could be an advantage. If you see there are 24 hours of work that's happening on both sides, and you're really moving much faster towards your goal than you'd have done with only one team being at a local onsite.

And of course, it comes with some level of hardware cost from an offshore team, but I think we've been pretty much... things have been going in a better… in at least some of these offshore locations like India, gradually we're getting better and better with our communications hardware, security protocols. But yes, this is an investment that an offshore team needs to put more money in.

And different processes—particularly if different onsite/offshore teams are both different companies, then you might have different processes. So there is a level of integration that we need to do. So there is an interesting case I might share after a couple of slides, and how we made some of these different process changes too.

And the last one we did talk about—requirements not being clear, vendor selection, the cultural angle are critical while you're choosing your offshore team. And sometimes delivery quality being not on target—address them with good engineering practices. A good continuous integration should be in place, or having clear definitions of terms in your story. There are a lot of ways that we can address the quality issues, and a bit of good investment in test automation—these are critical here. And of course, cultural issues... we did discuss a couple of times on that.

So managing—sometimes off-shoring—I feel is not just about reducing cost. It's about as we talked about—it’s all about scaling, and scaling with increasing value. It's not just scaling because the cost is less on the offshore, but it's also that you're seeing value in that team, trying to bring a different perspective to the product, trying to increase the speed of development. Within a 24-hour cycle, you're able to churn out lot more than with one single team at one place.

Those things I think we should really focus on here. And engage the time overlaps really efficiently, and in a really intelligent manner design those time overlaps. I would suggest a team should actually have something like what I showed—time zone maps created. And then establishing good protocols for communication for standups—when do we do backlog grooming, when do we do design reviews and code reviews, when we should… one of the challenges that comes is the offshore team needs to be good at planning beforehand to ask the right question, before the onsite team leaves for the day. So a good level of preplanning by the offshore team is also critical here.

And then a proxy product owner being placed. Sometimes even the SM might play that proxy product owner, be able to wear that hat. It all depends upon the maturity of the people involved. So to make sure that we do have that level of clarity and requirements.

Rahul, I think these are the… some problems that come up but something that can be easily addressed with the right level of intention in place.

Rahul: Sure. Thanks Avi. Again, as I've been through this deck, it's been giving a few nuggets from my own experience. I just read, you mentioned increasing value versus reducing costs with offshoring or outsourcing, recently the term called Best Cost, which is not necessarily about only low cost. Yes, you do have low cost in non-Western economies but there is also, you've mentioned, speed and time to market and access to more skills, more people, scaling up. And more and more enterprises need this. So really it takes us back to the first and second slide of your presentation.

It's basically about being copetitive in a fast-changing world. And if you do want to be, really there is no other choice than to create distributed teams and experiment with it and learn fairly fast. And really use the tools that you shared, use the insight you shared to help select the right vendors also. Sorry. We have a few questions coming in. And let me see, one is on somewhere early in your presentation where someone was asking, was this related to scrums? Sorry, I think we've answered that.

There is another question which says, and I'm being conscious we're a little over time here, but how does one foster an Agile culture? I'll just read out all the questions and then maybe we can choose what you want to answer. To attain maturity in distributed teams, isn't it important that the team, especially the offshore teams stay put? Attrition can be an obstacle in that, how do you handle that? I'm sure I can share some insights. Primary elements to consider before choosing an offshore team... okay, I think we've answered bits and pieces all of them, Avi. Do you want to take fostering Agile culture first?

Avie: Yes, sure, Rahul. I think it's very interesting. It's quite connected with, if you really create a great culture, you will have longevity of your distributed teams. It's very connected with attrition too. So the question of how do we create this kind of a culture. I think recently we were reading a lot more of how an organization's culture derives from the leadership culture. What the leadership really believes, what is their value system or principles—I think that's very critical.

I think when you meet the leaders, you’ll really come to know what they really value. And you need to probably spend some time with those people when you're engaging with them. I think what's critical is how do you create some of the decision-making structure within the teams. Wherein, how much of the team is involved in say creating estimations, how much of the team is involved in requirement clarifications—how do we create this culture?

I think one of the things that we did with here is definitely investing in an Agile coach. You’d definitely need a coach who can daily work with the teams, and probably start creating a coaching organization setup. Within , there is a coaching organization because we see people are...

Rahul: And learnings…

Avie: Exactly, Rahul. So I think when you go with that mindset where I need to coach, then it starts impacting many things. Agile is not about engineering teams. It's about how do we have our HR—what we call HR can also be questioned—and how our sales team interact with delivery, how do our scrum masters work with the team. Do they really act as a scrum coach when they are working with the team or as a people coach? These, when we start questioning ourselves on these, probably you're on the right track. Even if it doesn't matter—you could have not done a lot—but if you are on that, I think you're on the right track. Start questioning these, every now and then, so that you see a continuous improvement.

I want to live at this level because when you're asking these questions I think you are on a path towards creating a culture which could really lead to what we call an agile culture of mutual respect within the organization.

And we do a lot of other things while people are working on a project, but also we create communities of practice or communities of interest, wherein people contribute in different areas, say things like IOT, chatbots or some of these areas. Or it could also be contributing back to the community, bringing that systemic exchange. You need to give back to a community from which you're actually deriving a lot of value.

I think having these kinds of communication, leadership sessions, speaking sessions... we do have lot of these non-office topic conversations about social issues. All of those will really help in building that kind of a culture.

Rahul: And I think we've answered all those three questions together. There is one more question, Avi, which is pertinent. Is there any particular industry where distributed teams are suitable or is it possible to apply this in any industry? If I may ask you, Avi, with this question, we are a little over time, so it will take two minutes to answer this. And perhaps give one example of a project that you are running from the Goa office which you want to talk about, which touches upon some of these aspects, and then we close the session for today.

Avie: Yeah, sure. I think from an industry-wise... personally I've not seen anything which has any specific challenges for going for distributed Agile. I think it's all possible…and we almost have seen… we don't need any other evidence anymore. We have seen multiple such cases in the last decade and heard more about Agile teams being employed, the Agile way of thinking being applied in different setups, from healthcare to chip-making industries like Intel to banking to insurance, every place. So I think I've not heard anything of that kind definitely. Yes, for sharing an example, I would like to quickly go... now we started an engagement with one of the companies in Australia some time back, say probably now it's already a year… nearly a year now.

So when they started with us... let’s say, in a large travel company flight center which operates across Australia and New Zealand and many parts of the world. So they started very small. We talked about trust. So they were not sure how good we’ll be in actually delivering from a process, technology, communications standpoint, which is understandable.

So we started with a very small team and they said, “We just want to do a couple of sprints with you, and then we'll see how things go.” We said, “It's perfectly fine,” and after operating a couple of sprints, they said, “You know what? Can we do a few more sprints, two more sprints?” And this has led to a more than a year long engagement already, with a larger team now. And constantly innovating. When we started, we had challenges with JIRA because of security issues onsite. So then we thought about having our own JIRA instance on the cloud. And having some sync up done between that JIRA and this. Couple of such small changes that we did. And then investing on good tools for communication, with excellent retrospectives being done.

And one of the interesting innovations that the team did was, we started with scrum initially, with only the engineering team being here and the entire DevOps and business team and some of the engineering teams being on onsite in Australia, in Brisbane. So what we really saw was scrum was working fine, but it never gave visibility till the go live. because we were sure that we deliver the story, but when this story will go on production, that level of visibility was not quite clear many times. Are they stuck at the DevOps level, are they finding any challenges in pushing into production? So the team chose that within the flight center we should have everyday releases from Monday to Thursday. So it was super critical that we deliver whatever it is of real high quality and without any replacement issues.

And what we did was, then we moved from scrum to Kanban to see things from concept to go live, giving that level of visibility. So in our Kanban board we started seeing that we're done from outside but we’re still with DevOps. If there is any issue, then the team here wants DevOps to get it resolved. That's the different innovation. That people went for a local retrospective, then they wanted distributed retrospectives—it plays around with different tools like idea boards for retros and site using some very good, interesting tools built over it, like flow tools to do a lot of efficient coding. So many such innovations have been done over a period of a year. And the team has been hugely successful in building great trust with the client.

And within onsite—people travel, going there, spending time, understanding the culture and coming back and working. That's then… being constantly there is some level of investment that's being done there.

 Rahul: Excellent. I would love to just keep going and talk about more examples and more insights and all of that. But I guess we're way over time. And so, thank you very much for all of this information and being who you are, Avi. Nilanjana, I'm going to hand this over to you, for any closing notes and perhaps announcement of the next session or whatever you like. Thank you very much to all of our audience for listening in. Thank you Avi.

That was the end of the webinar. But if you are looking to plug a distributed team into your enterprise, scrum teams could be just the thing you need. And in case your enterprise is just transitioning to agile, we curated 6 of the best blogposts by agile coaches, to help guide you through a smooth transition.


Write to us

This site is protected by reCAPTCHA and the Google Privacy Policy and Terms Of Service apply. By submitting this form, you agree to our Privacy Policy.

See how our uniquely collaborative work style, can help you redesign your business.

Contact us