Let's talk about using Agile with distributed and international teams. Now I'll summarize this for you. By the way, do you know what this means? It stands for too long, don't read. And it kind of means, this is an executive summary, that's internet shorthand that young people use. And the summary here is that, you've already learned what techniques work with Agile. You already learned how to create an Agile friendly environment that will help you drive towards those Agile outcomes that you want. And all of those same things apply if your team members are abroad or international. So, you basically have three choices, A, get everybody in the same place somehow. B, make those employees that are somewhere else, their own discreet, Agile team, so that they can execute the same plays that you're executing and create their own take on Agile. Spotify does this for example. Or C, you can try really hard to make it work with a couple of the team members within your Agile team being somewhere else. And that's really hard and that's mostly what we'll talk about. In case, for whatever reason, you're in that situation and you need to make it work. I will say this, if you have a team or team members that are abroad, there are a few good reasons for that. Technical talent is really hard to find and recruit. So if that's the only place you could find the talent that you need, then hey, okay. If it's because you are localizing a product and you want a local team to work on that so that they understand the operating environment of the buyer, that's a great reason to have a team abroad. If you're focused on getting the lowest possible day rate per hour then this may not be the case, but there may be an issue where you're focused on output. How do we create the most amount of code for the least price, and that's really kind of counter to most of what we talked about. Our idea here that we're trying to learn about is let's create less code that's more valuable rather than let's just generate a lot of output and hope that somehow we hit on something good. So with that said, lets talk about how to make it work if some of your team members are some place else. And we'll organize this around the four jobs that we have here. On learning, you're going to need to tell and re-tell your stories. There's a lot of cultural context that, these team member will not have. I mean if they're in the mountains of Argentine and you're in Atlanta Georgia, and let's say that it's the H&H people. Well probably H/VAC installation repair and what not works different in the Andes than it does in Atlanta and so things that were implicit in your narrative that were okay for your team in Atlanta are not going to be clear or obvious to the team in Argentina. So one good thing to do is to go there where your team is and see what it's like and talk to them about the narratives. Another good thing to do is to make sure you're documenting the narrative. Now, We will talk about the fact that narrative is only useful as a collaboration tool, and that there's not this perfect spec that you can write up and expect everybody to execute just the way that you wanted. But if the narrative's not available to them because they can't have these informal discussions in the office, you'll need to find a way to make it available to them. Another thing you may find, outside the US, though certainly not everywhere, is that, a lot of the developers will want, more prescriptive, specific inputs. And, this may be kind of deep seated. It may be part of the, way that their education system worked. It may be part of the way they're used to working with teams that are in another country and are hiring them. And that will of course vary from country to country and person to person, but if you're finding that they say hey, can you just give me this back, or can you just be specific about what you want me to do. You're going to have to make sure that you're showing them these principles of Agile and you're not just telling them no, I'm not going to give you specific inputs because we're doing Agile and expect them to understand why and what that means. You can put them on this you can go there and do a workshop for them and show them examples of how you work. But, don't expect them to necessarily know how narrative functions in Agile. It's new to most people even in the most sophisticated operating environments. Now let's talk about deciding, short cycles and seeing finished work early. Well, just like it does for a regular Agile team will suss out a lot of problems early, and help you see those, and figure out which ones are important so you can work on fixing those with the team. It's very important to have some overlap time. I've heard a guideline of at least two hours a day. I would certainly think that's a bare, bare minimum. I mean if you have less than that I think it will be really challenging to make this work. If you have more than that it will make it a little easier. If you don't have the opportunity to do daily stand ups together, try to improvise them some how. Maybe, for example, have everybody write them up over email or after people do them in person they send a quick email. And that's kind of a pain. And there's a reason why it's not part of the standard way of doing daily stand-ups, but you might want to test that and just see how it works out for everybody, particularly with regard to making offshore team more successful. We talked about this already, but automation will certainly help. It's self encapsulated, it's available to everybody without a lot of. Documentation and explanation, and so that'll be an asset that'll help everybody on the team, and help work through a bunch of other issues that you might otherwise have, about coordinating builds, and testing, things like that. And likewise, continuous integration and virtualization will help a lot. And so this applies to development and test environments, so formalizing an environment on the working machines that the developers and testers are using with tools, like currently Vagrant is very popular, and quite handy for creating a standardized virtual build of an operating system on a machine. And then Docker's very popular at the moment, for doing that. On servers, there are a lot of similar tools. The idea is to self-describe and automate the creation of these environments so that you don't have environment-to-environment issues so that it's not a big pain for the people that are offsite to learn how to do this and figure it out because they're not sitting next to somebody who did it a week ago. So that'll help a lot, subtle but important thing. Another important thing is to do that same set of things for test environments. So if there is a interface, or software running for some kind of internal system in your company, make sure they have access to that. Or that you can create a sub service, like a fake version of it, or something, so that whatever test tools you find that you need to have to do your job well are readily available to that team, because they may try to work around those things. Again, they don't want to bother you, but in fact, they're testing against an environment that's not realistic. As you run through your cycles, you'll start seeing that Hey, it's weird that this thing broke. Well, it's because of the folks elsewhere didn't have ready access to the test environments when they needed them and creates a whole big mess and that will take a lot more time to fix after the fact. We've talked about how the whole team is really important in managing And the, really the ways to work around this are probably relatively self-evident to you. Lots of open chats, tools like Slack are really good, lots of video conferences. Maybe even leaving them up for, some cases, for the overlap period. All that stuff will help. Invest in the relationship. So if you're going to go or they're going to come visit you need to take them out to dinner, your other team members and spend time together. You may take for granted that you have a personal relationship with your working team in a way that you kind of do on accelerated basis if you're working with people that are not on the same site. This is an interesting one particularly if you're working with collaborators from another culture a lot another time, and especially if they are on contract and you're working at the company, they're going to want to say yes sure I'll try to do that and so one of the important things is what I call getting the know. Where you know that you have a good working relationship with them if you explain a bunch of stuff and you ask them does it make sense? And they say no I don't understand. Or you ask them do you think you can get this story done by Wednesday? No I don't think I can. I need more time. Well, that's a good sign. It means you're communicating. A team is telling you. What they really think and that you're getting a more healthy correspondence built up. So those are a few tip and ideas and alternatives for getting Agile working when you're needing to find talent in a bunch of different places.
