Co-location has its perks. Everybody knows what everyone else is doing, sprints and demos are easier. So are the retros. Communication happens effortlessly, and everything is easy to manage, for both the product owner and the development team.
But we have already establishedwhy distributed scrum teams are essential for enterprises. So you cannot play safe and insist on co-location anymore. Enterprises have to take the plunge into working with distributed scrum teams. And yes, it’s fraught with challenges. But there are also ways to resolve those challenges and ensure success of these distributed teams.
We take a look at the various challenges, and how to get past them:
Information Exchange:When the product owner and the development team are co-located, the exchange of information is very smooth, and not always formal. A lot of information is passed on in an informal manner, in chats or general conversation. These could be termed as Coffee Machine Thoughts, and are not always documented.
Now with a product team working out of a remote location, this exchange of information goes completely missing. Not everything gets discussed on the conference call, and offshore teams might miss out on minor, but critical, information.
How to Solve It: The first step is to acknowledge that there’s an offshore team working towards the same goals. All the dev teams, onshore and offshore, and the PO have to be brought onto a single communication platform (Slack works great at ). The PO should also take care to share all pieces of information, like user survey, feedback, etc, with the teams, on this inclusive communication platform.
Visibility:With offshore teams, visibility of work is an issue. While a co-located team can catch up with each other on the state of work (though that’s not really an optimal way), it’s not possible for offshore teams. Time zone difference can also crop up, when the offshore team and the PO cannot find a suitable time for a demo.
How to Solve It: Recorded videos are a great way to solve the demo problem. A complete screencast of demos can be shared between the PO and the teams. This means everyone can check out the demo, even if it’s not in real time. Also, videos are a great way to avoid unnecessary documentation. All information, like technical diagrams, images, demos can be captured in a video, instead of trying to explain it in a 100 page technical document. There are also project management tools like JIRA that are suited to the scrum way of working, and can be used to ensure collaboration and visibility.
Managing time zones are one of the most critical balancing acts to get right, when working with offshore teams. The benefit here is that there is round the clock work on the project, with one team starting work even as another team is wrapping up for the day. But there are certain obvious problems here:
Depending on the time difference between the remote teams, it might be difficult to come together for con-calls and demos With the PO and dev team in separate locations, it might be difficult to clarify certain points as and when they arise
How to Solve It: Here are a few things you can do to resolve the time zone issue:
Appoint a proxy PO in the offshore team, who works closely with the onsite PO, and understands both the business and tech aspects of the project. Any adhoc issues for the offshore team can be then handled by the proxy PO.
It is also advisable for both teams to build their schedules in a manner thatensures a few overlapping hours of work. This makes it easy and discuss sprint objectives and catch up on progress and problems at both ends.
Collaborating, especially on a tech project, can be difficult if onshore and offshore teams do not share a similar infrastructure. There are times when a piece of tech, or software is working great at one end, but the other team is unable to view/use it. The onsite team might be working on high-end systems, good internet bandwidth, and a closer source code repository. On the other hand, the offshore team might be working in the exact opposite conditions.
And this is will lead to greater challenges in the future.
How to Solve It:The only way is to make sure that both onshore and offshore teams are working in similar development environments. The obvious thing is for the team with lower quality infrastructure to upgrade to a better setup.
Difference in Skill Set:Offshore teams, especially those in Asian or Eastern European countries are comprised of young people. So someone with 5 years of experience could be collaborating with someone on the onsite team with 20 years of experience. So there is obviously a skill gap that you will run into.
How to Solve It:Firstly, a common coding guideline should be agreed upon by both teams. There should also be some initial training and coaching when the offshore team is being on-boarded on the project. Regular peer code reviews are also a great way to ensure quality and pull up the skill sets of the offshore team. Even if the roles are reversed, the issue of skill gap can always be resolved in this manner.
Trust Issues:In the distributed scrum model, an offshore team is an unknown entity at the start of the project. So there is obviously not a lot of trust to begin with. But persistent trust issues are a problem because any work done by the offshore team is suspect. Instead of getting work done faster, product owner is always trying to quality check the offshore team. This also impacts effective flow of communication.
How to Solve It:The key is to start small. Start off the offshore team with tasks that are not too complex. The PO and the onsite team should slowly get them acquainted to the code base, the product domain, and the engineering practices. As the offshore team starts committing and delivering, the trust starts growing. This, along with the constant communication and setting up matching infrastructure, will lead to rising trust.
Work Culture:The work culture in the East is very hierarchical, while in the West, even if corporate hierarchy exists, interactions are very informal. So an offshore team from the East can find it difficult to talk or discuss with an onsite team or scrum master (SM) from the West, on an equal footing. This might run the risk of some potential issues not getting raised at all.
How to Solve It:Both teams should be sensitive to, and acknowledge, these differences in work culture. POs and SM in the West should try to ensure a peer culture when onboarding offshore teams from the East. It is also important to have SMs who will work well with both the onshore and offshore teams, and be instrumental in building camaraderie.
Language Barriers:People think better in their native languages. But when working within a distributed scrum model, it’s imperative to at leadst have a common language. A PO and an onsite team in France working with an offshore team from India, will have to fall back on English to be able to collaborate. But there’ll always be some things that could have been better communicated and understood had they used their native languages.
How to Solve It:It is wise to invest in some kind of training and coaching, to resolve some of the articulation issues. This is more important when the teams do not have a common language to fall back on.
Holidays:Holidays for the onsite and offshore team are never going to match. The onsite team may be working on a day when the offshore team is off celebrating something.
How to Solve It:There is nothing much to solve here, except being cognizant and respectful of cultural holidays, and plan the work accordingly.
At Srijan , this is how we have been working with enterprises, building experienced scrum teams that can remotely plug into your projects. Challenges come up, but we have devised ways to resolve them, and deliver value to our clients, with the distributed scrum model.
You can also check out our webinar session on finding success with a distributed workforce, with Harrison Dahme from Pantheon.
If you are looking to plug a distributed team into your enterprise, scrum teamscould be just the thing you need. And in case your enterprise is just transitioning to agile, we have curated6 of the best blog posts by agile coaches, to guide you through a smooth transition.
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.
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?
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.
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.
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.
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?
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 atagilebuddha.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.
As enterprises strive to stay lean and efficient, outsourcing a part or all, of your development process has become a common practice. But it requires a lot of coordination and collaboration between in-house and outsourced teams, to build a great product. And the first step to reaching there is making sure both your onshore and offshore teams have the same method of approaching and handling the project.
One of the industry-wide best practices for software development is to adopt the Agile Scrum Methodology. The team that you outsource to will be, more often than not, an offshore agile team. And so, it’s best that your in-house development team is also well versed in agile. And the best people to aid you in this process are agile coaches, who will understand your business challenges and help you transition accordingly.
And so, we got down to bringing together six great agile coaches, and their take on the various aspect of the transition process. Their ideas and strategies will help you kickstart and manage agile at your enterprise:
Transitioning to Agile
Breaking set patterns and adopting a new way of work can seem difficult at first. But onboarding your team to agile and scrum can actually be a fun exercise.
Stefan goes into greater detail, laying down the exact steps to getting your first scrum team. And while the post outlines what he did for a fast growing start-up, the steps wouldn’t be different when you are trying to form the first scrum team at your enterprise.
Evolving Project Managers
Most enterprises have a team of project managers who make sure that all projects are on track. From addressing roadblocks to ensuring delivery, they see to it that the team is working as well as it should. But with agile teams, things work a little differently and so the role of the project manager changes as well.
Mike Cohnadeptly addresses this in his post “The Roles of a Project Management Office in Scrum”. Adopting scrum does away with a lot of a project manager’s conventional responsibilities; assigning them to the ScrumMaster, product owner and the team. But Mike explains that project managers still have a very critical role to play here, especially at large enterprises.
Since enterprises will have a few different projects running simultaneously, there will be various scrum teams in place. Project managers now have the role of facilitating training and ensuring consistency across all teams. Mike’s post is a comprehensive list of all the new responsibilities that project managers now have, to make sure that scrum teams can function effectively.
Managing Scrum Team Challenges
As an enterprise, if you have just started working with the agile scrum methodology, challenges are bound to crop up. It is a new way of work, with new tools and requirements, and there will be a lot of questions and unforeseen problems.
Luis Goncalvesshares a great way to address these challenges in his post “How to Manage Organisational Scrum Impediments?” He shares a framework that enables organizations to continuously learn and improve with each project. He shares a tool termed as the ‘Organisational Improvement Board’ and outlines how to use it. Luis shares every step of effectively using this tool, in great detail.
Pivoting at the Right Time
Enterprises usually go large when they start off with a product, investing huge amounts of time and money. There is obviously a lot at stake and building the wrong product can be disastrous. But when you are so involved in building the various parts of a product, it is possible for the team to lose sight of the big picture.
But just in case teams realize that they are indeed headed towards the wrong product, Avienaash describes a phase termed the ‘Pivot’. He takes you through the steps of the ‘Pivot’ phase, that will help teams realign their actions with the desired end-product. No new features without validating markets and choosing to hard code some things are a few steps that can help teams get back on track.
Running Effective Retros
In the agile way of doing things, retrospectives are a way of taking stock after each sprint. It’s an important learning tool and helps the teams improve the way it works. Agile coaches can’t stress the importance of this often enough. But the catch is, retros are useful only when done the right way.
AndBen Linders'post on “Retrospective Exercise: Few Vital Actions”, shows you the right way to do it. First up, he lists out some of the critical things that retros should cover. Besides that, Ben also takes you through the value of each of these retrospective actions and how it helps the team become more streamlined and efficient.
Ben also shares another post, “Getting Business Value out of Agile Retrospectives”. This post focuses on how retrospectives can help create value for businesses and customers. Ben lists a set of pointers which will ensure that teams come out of a retro with a set of doable actions for the next sprint.
Agile teams work well because they are quick to respond to changes. Changed requirements are accepted, non-performing strategies are fast discarded, and teams start moving in new directions. But it is a legitimate fear that too many changes, and responding to those, might delay the delivery of anything usable.
Stephanie Ockermantakes up this issue in her post titled “Balancing Emergence and Delivery”. While admitting that it is a tight-rope walk, she looks at three key factors that can cause an imbalance. She then goes on to provide a set of possible solutions that scrum teams can adopt, to ensure that agile development and delivery go hand in hand.
So, this is what some of the best agile coaches have to say about transitioning your enterprise to the agile way of project delivery. If you are already reading up on agile, are there any agile coaches whose ideas you like, but we missed? What are some of your favorite posts on agile?
From the brick and mortar stores or catalog sales a century ago to the multichannel sales and marketing of today, businesses realize the importance of getting the right and precise product information to their customers to influence decision and final sale. This has gained serious momentum in the last decade or so with the disruption caused by online stores and marketplaces, and the easy availability of information about a product on a shopper’s connected devices.
Today, sellers are trying to make sure that the experience that they provide to their customers on all channels is consistent, whether they come through a web store, a point of sales device, or a mobile app. Apart from the look and feel of these experiences the biggest contributor to making these experiences consistent is the ability to provide clean and consistent product information through all channels. Customers of today visit more than one channel to find out about a product. They compare products from multiple brands and variations before they buy. So it is now critical to ensure that the customer gets access to the right information across all channels.
This is a point Jim Lecinski delicately made in “ZMOT: Winning the Zero Moment of Truth”. He spoke about how the increase in accessibility to information has made it a mandate for product information to be always clear and fresh on all channels.
“....determined shoppers would go to the library to see what Consumer Reports had to say about cars or washing machines. There were other unique research tools: ….. But for most items, the barrier was easy access. Fresh and detailed information about a given product was the exception. That exception is now the rule.
There are no barriers to access. Today’s shoppers carry access in their pockets. They create their own consumer guides a million times a minute with reviews, tweets, blogs, social network posts and videos for products of all kinds.”
So what seems to be abundantly clear is that rapid growth of e-commerce and online stores have created this huge opportunity for sellers to sell much wider variety, multiple variations, multiple brands compared to what they were selling earlier through only the physical stores.
This huge opportunity has obviously come with a huge challenge as well. That of making, easy to understand consistent product information available, with agility, across all channels including web, mobile, tablets, retail stores, distributors, marketplaces, point of sales, printed catalogs, flyers etc.
However, even today, the best of the marketing teams at the best of retailers or manufacturers are trying to meet this challenge with spreadsheets, homegrown archaic applications, and manual processes over email.
It’s like going to war with a giant and taking only a matchstick and a spoon as your weapons.
At Srijan, we realised this as a major challenge that is faced globally, and specifically observed it as a pattern with our clients and prospects. We knew this needs to be solved by a tool which is simple and intuitive to use, and fits seamlessly in an existing or a new architecture.
Enter PIM or Product Information Management system. It’s your perfect partner in this war to keep your product data up to date on all channels. And it simplifies the marketing team’s work manifold, significantly improving productivity and reducing errors.
After much research, we zeroed in on akeneo, an open source tool that puts a check in each box for an ideal PIM system. We put akeneo to test, with our first implementation of the tool in a marketplace that we were building. This will see 600,000 - 800,000 products as it goes live. Impressed with the capabilities that akeneo provided we are nowimplementation partnerfor akeneo.
So to explain how PIM helps solve the challenge that is been talked about, let's pull a leaf out of akeneo's way to explain the same :
Product information is collected from various different sources at one place. The sources can be many: ERP systems, warehouse systems, procurement systems, product suppliers, and so on.
Once collected at a single place the content team/marketing team have access to this information. They can enrich the product information, upload images, demo videos, 3D/rotation videos, user manuals, and add various taxonomies like brand, categories to each product.
PIM now helps share this information to various channels. The marketing team can choose to share only the required attributes for products per channel instead of everyone getting everything.
Apart from these basic features, a PIM tool can also provide features for authentication and authorization, access control at an attribute or attribute collection level, and basic approval workflows.
In summary, today’s retailers/manufacturers require an efficient way, a great tool and a set of processes to collect and manage massive amounts of information for products to push sales. The tool also needs to withstand ever increasing number of products being added to a seller’s portfolio almost on a daily basis and always keep the latest and freshest information available for all channels to consume. Product Information Management System addresses all these questions.
At Srijan, we transformed our methodologies from a classic waterfall approach to semi agile process, and now we are implementing a full-on agile Scrum inspired approach to work on Drupal projects. In the ongoing DrupalCon Barcelona, there was a session on Waterfall and Agile.
Agile for clients who still don't understand the concept.
Though I had a fair knowledge of Scrum, I never had an opportunity to practice it before and never felt the heat of being a Scrum team member. But recently, I got a chance to work as a Scrum Master for a team in Srijan’s Goa office.
When I joined the Goa office, Avienaash (our Agile coach) gave me three books on Scrum to read in my spare time. I read the one that looked the thinnest and started practicing it. Srijan already has mature Scrum and Agile practices, all thanks to Avienaash. Hence, it was easy for me to get started.
I had two challenges in front of me, even before I took the role of ScrumMaster (SM). One of not having practised Scrum before, and another that I did not have a technical background. As I come from an entrepreneurial background, I did have the advantage of understanding the market and product easily. Getting into the shoes of the customer has always been very easy for me, but as a Scrum Master my role demanded me to domore.
“Many who are new to the Scrum Master role struggle with the apparent contradiction of the Scrum Master as both a servant-leader to the team and also someone with no authority. The seeming contradiction disappears when we realize that although the Scrum Master has no authority over Scrum team members, the Scrum Master does have authority over the process.”
Different people can have different sets of challenges as per their ability and mindset. I came across the following challenges:
Fear of not knowing something, which could be obvious to the team- The only way to deal with this situation is to read as much as you can. As an SM, I should have complete knowledge of Scrum, so I started with reading a book written by Mike Cohn called Succeeding with Agile, and it gave me enormous confidence. Trust me, when you practice along with reading, it becomes easier to connect the dots and the learning curve becomes shorter. Technical jargon are still a problem for me, but I do try to go back and read about that.
Understanding Impediments- This has been a problem for me especially in the case of technical bottlenecks, because I don’t have a tech background. As an SM, I should know the impediments, but it is even more important to understand how to find the right solution. There may be a chance that team members have not given enough thought to other consequences. So, asking questions is an important aspect of being an SM to help the team understand the real problem.
When to seek help outside- The ‘never give up’ attitude of team is good, but it can be a hindrance when strict timelines of the project is also a factor of success. At some point of time, external help becomes unavoidable, but to take that call is not easy. External help can dismantle the team morale because when team solves a problem by themselves, they get a sense of achievement. A good team tends to get closer to each other at the time of crises. So trusting your team’s ability is important here, and let the team decide when they need help.
Having an effective daily standup- Daily Scrum meetings at start of the day is important as they bring discipline into the team and sets the tone for the day. Some usual problems are:
Connecting with distributed team members
Low energy levels
Not attentively listening to others updates
Team tends to face the SM while giving the update instead of the team
The essence of a daily standup is not just to give an update to the SM, but to sync up with each other on how we are doing as a team. As a Scrum Master I play the role of a moderator in this daily standup meeting. Most of the above mentioned problems got resolved by consistently bringing them up in our retrospection meeting.
Sharing my update in a daily standup meeting in the format of “What I did yesterday” & “What will I do today”- I work on multiple things throughout the day. But to filter out what is relevant and valuable in the daily stand up is tricky. Committing a task for the day in the daily standup has not been as easy for me as compared to my fellow team members. They can see the sprint backlog to choose a task, but for me as a SM, I have to go with the flow, as per situation demands.
In Scrum, everyday unfolds something new, hence identifying tasks and prioritising them is quite challenging. I am not convinced that a SM should give the updates in the same format as the team does, since SM has a completely different role. However, a SM must give the update on the impediments identified on the previous day, change requests, budget, new developments, product backlog, status of sprint planning, UAT, etc.
Writing user stories on behalf of PO, who is far away- Acting as proxy PO is not easy, because the team expects SM to have 100 percent clarity on user stories. It requires intensive thinking to ask all the probable questions to a PO before the implementation starts. I could manage this problem by setting up the team’s expectations in beginning of the sprint by telling that 20 percent ambiguity in stories are recommended to make them negotiable at the time of implementation.
You can also gain clarity by discussing with the team while writing stories and involving the QA in writing acceptance criteria. Doing the story estimation exercise with the team also helps, and the team gets an idea of the backlog in advance. The point that needs to be understood by the team is that discussion is valued over the excessive documentation (detailed story) in Scrum.
Engaging the designer- Designers always work one sprint ahead of the team, hence it is important to plan the dependencies early. Sometime you don’t realise which user story will trigger a change in the UX, so it is important to evaluate every task from a designer’s perspective. Cohesion between development team and designer is also very important.
Focussing on my work and keeping an eye on how we are doing as a team- This becomes even more difficult when team members are not co-located and working across different time zones. To deal with this, I created a checklist for myself. This helped me to keep an eye on every aspect. Later, I foundScrum Master’s checklistwhich is very useful to evaluate myself on how I am doing as a SM.
Estimation vs committing- Whenever we could not finish all the committed stories in a particular sprint, we would blame estimation. However, it was not always the reason because estimation and commitment of stories in a sprint are different things. So, while committing to stories, the following things are important to be considered:
Actual productivity fluctuates due to external factors, hence 70 percent is the maximum output we should expect, not 100 percent
A good mix of tasks between developers and QA, which depends upon the ratio of developers and QA in a team
Considering offs and holidays, because sometimes we tend to forget this while planning for sprint
Nature of Stories/Task and dependencies
Frequency of Deployment/Release/UAT
Better Sprint Planning- It becomes cumbersome when you try to do it at the last moment. So, planning two sprints in advance is important because it takes some time to get clarity on the stories. For example, some user stories require POC to be performed even before estimation, hence it is required to pick that POC at least one sprint before. Understanding such dependencies is key for a smooth implementation. It is important to involve the team to do the backlog estimation from time to time. I kept 10 percent of my team’s time in each sprint to plan for the next sprint. This helped the team to deal with last minute surprises. Consistent grooming of product backlog is key for better sprint planning.
Effective Retrospection- To do an effective retrospection, it is important to understand what we want to achieve as a team, and what needs to be done to achieve that. For example ask yourself, "How are we doing on XP practices?" "How can the team be more productive?" etc. My contribution in the retrospection meeting got drastically improved when I learned how an ideal agile team should be working.
My constant endeavour of finding theroot causeof every problem has helped me to come out of most of the problems. I would retrospect my performance almost every day. It kept me on my toes to improve. I think when you know the exact problem statement then solution comes easily. Avie has played a great role by providing constant feedback to me on where I lag. I am still learning and trying to improve myself.
We start off with your online product idea. We listen to your idea, accept it. But we also believe that the right product has to find some real users who put it to some real use. So we challenge your idea to identify the real business value. We spend hours and hours exploring the product idea with you. We go into great details to understand your business, the financial model, the customers. At the end of it, you will know how good your idea is (we are a bunch of people well versed in online businesses, we do know our way about this). Either you will end up with an idea that transforms into a higher potential product, or you will know if you must go back to the café napkins for ideation.
We sign up for a contract with you to work on concepts and wireframes. We work on the workflows and give you a very good picture of what the product would be like. We create low-fidelity wireframes which show the process and content. Then you see a high-fidelity wireframe which is a very close visualization of the end product.
We list out the features and flesh out the functionality and create the product backlog. Now we work with you to identify those features and functionalities that need to make your product what is generally called a Minimum Viable Product. Just those minimum things you need in the product that will make a user sit up and take notice of your product because it is useful. We help you zero in on the sweet spot made of features and viability.
So why don’t we go the whole hog and make the complete product for you?
When we don’t know if you will find real users for your product (and make money), should we be wasting your money, just so our cash registers can ring? We don’t believe in that route at all. We are here to help people like you build the right products. And if that means less revenue for us, or more heartache for you (after all you do love your idea, don’t you!), so be it!
We hate money being wasted on unnecessary development. Spend on what’s necessary.
So we identify what is necessary, break it down into several bits. You choose the bits of the product that you need to see first. We figure out the parts to be included in 2-week sprints, and give you a demo. You give your feedback. We continue with our 2-week sprints which lead to demos and your feedback. What this means is that we release design-ready, feature-ready, quality tested market-ready software every two weeks, using continuous integration.
Our development efforts show that you get to see a first working version of your product in about 4-6 weeks.
4-6 weeks? Yes. That’s what we mean by focusing on developing what is necessary.
At this point, we release the product to a server where your end users can start using it. As they use the product and share their feedback, you will learn about the features that work and those that don’t. You come back to us with a revised feature set. We revise the features in the Minimum Viable Product. And get back to more two-week sprints and demos. We also have extended sprints to implement the feedback received in demos. This process continues till your user set is happy with the product you have developed. The Right Product!
And once the right product is launched, our support team at Dharamshala takes over and maintains it for you. As simple as that.
Srijan as a company have now fully embraced Agile as THE methodology for development projects. Journey has not been smooth in any way! Spill-overs, bugs, managing sprints, bugs, story points breakdown, bugs, daily stand-ups, bugs.... you get the drift! Amidst all the mini failures and successes the most important piece that has been the biggest factor in our slow growth are the bugs that keep coming up in every sprint!
Why are bugs a nuisance!
We are having a hard time figuring what to do with them specially in an agile scenario where right after the demo we were to spend time in Sprint Retros and then the very next day prepare for the next sprint! UAT from client usually takes a couple of days. By that time developers are nose-deep into the next sprint tasks. How do we THEN handle the bugs that might be reported by the Product Owner/Stakeholders. Bringing in bugs in the new sprint could be suicidal. Developers might lose focus and worst lose velocity of development. Keeping bugs for the next sprint (Our sprints are two weeks long) could frustrate the stakeholders for lack of responsiveness!
What the community is saying
The Agile community is divided on whether the bugs should be part of the sprints or they should be handled entirely seprately.
While George Dinwiddie, Agile Coach suggested “I would start to ask the question why weren't they found and fixed within the sprint that they occurred? My focus is on reducing the time it takes to discover (and then fix) problems. After all, if we discover a bug in the story during the sprint it is written then the PO shouldn’t accept it as being done. In addition early discovery will make it much easier to fix as the code is still fresh in the mind of the development team.”
On the other hand,Mike Cohnfrom Mountain Goat Software suggested that the bugs be added to the product backlog and left to PO's discretion as to whether the bugs warrant immediate attention or can be tackled later.
Picking on the idea we realized that making bugs part of the sprint where they have been found, is what stakeholders/PO can agree upon and developers love too!
Here is a snapshot of somewhat similar (but tweaked for Srijan) approach
The cycle is self-explanatory but the point of deflection is the time for the demo. A couple of days before we ACTUALLY used to do them.
What this approach does neatly is to allow the Product Owner and/or stake holders to do a good UAT and come back with loads of bugs. Developers on the other hand arent yet busy stressing about the next sprint and can certainly and very quickly put there heart, mind and souls towards fixing the bugs. Development team can also raise flags during the same time on any enhacements (scope changes) or bugs that might take too long to be fixed. Product Owner can be informed about the need to push bigger bugs to be solved in the next sprint and yet all smaller, quick-to-resolve bugs can be put out of the way in the same sprint rendering the release more stable!
Out of the trap?
We had a client who very recently asked us if they have to pay for the bugs that come up during the sprints. The question being loaded and very subjective, we had to think through before answering.
Developers do believe that bugs only exist because usually the requirements may not be clear in the first place. Or they might be different in PO's head and translated differently to the development team. But they also agree that some times the code is the culprit and does not deliver what wa expected of it. Providing some time to the developers during the sprint to fix bugs means everyone in the team can concentrate on hard UAT (alongwith the client) and hevay bug-fixing. This doesnt look out of place, being in the same sprint and it also fulfils the Agile idea of 'done' in terms of a sprint end.
Curently the stake holders on various projects are sold on to this idea and developers seem happy too! The measure of success would be sturdier sprint releases and of course happier clients!
As aforementioned in the last blog, hiring a developer isn't a great idea due to the numerous hurdles that crop up in the maintenance journey. Keeping all the factors in mind we will now discuss the benefits that a team is capable of producing. The Drupal Team model brings in efficient and effective solutions to any support and maintenance related problem in your site.
Once again coming back to the requirements of maintaining a mid-sized Drupal website that requires the following professionals:
The above roles are the genesis of a strong Drupal maintenance team that proves to be advantageous in a long run. Advantageous- because it is adequately staffed and assures better performance.
So, what are theadvantages of a Team offering support?
A Drupal super hero is certainly unavailable however a skilled team with the right kind of resources can definitely do wonders. Here's why:
1.Knowledge retention: This is an essential component within any team that brings in success. Constant engagement with codes ,bugs, security, enhancement et all gives way to better ideas. A team is the spine of any organization that’s looking for simultaneous website maintenance.
Business Analyst: who can understand and document the business needs and help translate these into a measurable set of feature requests; often the same resource can double up as a client-interface manager as well.
Technical Architect: Someone who has experience designing and architect applications across technologies, with several years doing so with Drupal applications. The key role this person performs, in application maintenance scenario, is that of a mentor and troubleshooter.
Deployment Manager: There is a need to have extensive and carefully controlled deployment processes in place, specifically in cases of mission-critical websites involving payment transactions or high-uptime scenarios.
Muti-skilled Professionals: A team that has a myriad acumen with the ability to go into the nitty gritties of a project proves viable for the client. Issues such as absenteeism of one team member do not hinder the work progress.
New Features: Along with the repair work/support and maintenance, the additional features and updates for the website come complementary for the client. This is a lot more advantageous since the team recurrently reviews the codes and other essential structures.
Time Factor: A team solely dedicated to maintenance shall deliver the service within the given time frame. For instance, suppose the team has a around 700-800 hourse roughly dedicated to support and maintenance, a hundred hours can easily be carved out for your site support without any hurdles.
Therefore, replacing a single resource with the team proves to be cost effective that guarantees a better occupancy which in turn instills High Morales leading to low attrition. Srijan has successfully implemented the Drupal Team model for it's clients.
Srijan's unique service offering
Srijan has come up with unique offering of blocking billable hours across an adequately staffed support and maintenance team. This offers significant advantages to our clients. They get the benefit of availability of all desired roles and processes to maintain a software development lifecycle, yet at a fraction of the cost of internally or externally positioning such a team.
Making functional enhancements - which further requires work across CSS (Drupal theming), Site-building, and Development
Roles required in maintaining a Drupal website
Maintaining a mid-sized Drupal website requires the following :
Site configuration expert: this is a Drupal developer who canconfigure modulesand often knows enough CSS to implement new functionality
Drupal CSS/theming expert: more complex enhancements such as major feature enhancements requires deeper and thorough knowledge of CSS / CSS3 / HTML5 and Drupal themes to ensure maintainability of the Drupal theme
Drupal Developer: this is someone who writes Drupal modules, and preferably has some modules contributions on the drupal.org contributed projects (which ensures that the developer writes code according to Drupal coding standards)
Quality Assurance: Cross-browser testing across Chrome, IE, FireFox and their various versions is most crucial for you to maintain a reasonable internet image of your organisation; if your website is somewhat large, maintainaing a Test Plan or/andautomated Test Cases(we work on "Selenium") is immensely important
Project Manager / Business Analyst: to ensure that the above roles work like a well oiled machine and deliver what you asked for, normally you need someone who understands client's requirements well and communicates between the team and the client effectively
Drupal super-heroes are not available!
Expecting one person to perform myriad roles that are required for a professional Drupal maintenance, is often asking for too much.
Firstly, it requires years of experience in Drupal coding and site-building to work across all these roles, and maintain high-quality of software. And even if you are able to locate one such person near you, there is little reason for this rock star Drupaler to be working with you.
If you have found one, most likely (s)he is a mediocre Drupaler, but excellent smooth-talker who has managed his way through the inability of an an internal IT/HR team to shoot holes in his story.
CAN YOU REALLY HIRE SUCH A GUY?
Are you a software company?
Assuming you feel your Drupal support needs are limited and you could do with a medium level Drupal person, perhaps you should still ask yourself if you are a software company?
The above are the problems that a software firm generally faces. They are equipped to deal with these problems, and have systems to deal with them. You are not a software company, and chances are would find it very frustrating to deal with these retention and morale issues.
So what is the solution?
We believe hiring a Drupal agency which offers a team and can carve out optimal hours from this entire team's available hours, is the right model.
This is a unique offering that Srijan has. Read more on this unique offering in our next blog post.
We are accepting original, innovative and industry perspective ideas for an audience of developers, designers, content strategists, information architects, or similar. We are also open to articles with tips and tricks, how-to and step by step guide as well.
What are we expecting?
An average piece of around 1000 words.
Content ideas in the industry perspective for an audience of designers, developers, content strategists, information architects, or similar.
Ideas on current and cutting-edge topics in the web industry.
Multimedia reach content with stats, tables, and infographics.