 Hi, I'm Jeff Watts and welcome to another episode of Jeff's top 10 tips This episode is about distributed agile teams and is in response to the request by Dorothy B. Craft Who left a comment after the last top 10 tips video? I think I might try that as a new Tradition going forward. So the first person to like and comment on this video gets to choose what the topic is next night Let's give that one a go In this video, we're going to talk about what the benefits of distributed teams are the Downsides of distributed agile teams and 10 things that you can do to improve things with your distributed teams Well, what is a distributed team first of all? Well for me a distributed team is a team where not everybody's in the same physical location in the early days of distributed teams In the early days of agile in fact and they've got a bad rap simply because a lot of organizations Took the opportunity to try and Offshore a lot of their work to the cheapest possible area. They could find it's where a lot of the stigma came from so There are some common misconceptions one is that in order to be agile you have to have a co-located team Well, that's not the case Personally, I've been involved in lots of teams that have spread across different countries and been able to use scrum To be very agile some people point to the agile manifesto and say well one of the principles is face-to-face communication And it is But it just is the best form of communication the most efficient and effective form of communication is face-to-face Now while I would imagine a lot of the signatories of the agile manifesto would probably agree that co-located teams Are generally more effective as would I doesn't say that you have to be physically co-located Distributed teams generally get a bad rap But they're not all bad and there are some clear benefits to having people in different parts of the world Firstly we get greater coverage so we can use the time zone difference to our advantage as one Part of the team or perhaps one team is finishing up their day Another team is starting and perhaps we can hand over that work for more continual development In terms of coverage, we've also got access to more people more quality people We can fill the team with the best people regardless of where they are rather than just the people who are physically in our geographical area And that will also give us greater diversity So we can have people from different cultures different perspectives different backgrounds Which will allow us to make more rounded holistic decisions and avoid things like groupthink So there are a few benefits to having distributed teams So what are the main downsides to distributed teams? Well, the main one really is in the is in the words that we chose that distributed teams Not a lot of the distributed teams that I've seen or been part of actually feel like a team They're not as close together. They don't get to look each other in the eye. They don't get to Feel connected to one another. They don't have the rapport of a team So given the choice most people would probably like to work in the team where they could see the people they're working with Not always but mostly What is this Happy holidays the way but do not open it till Christmas. So generally morale is lower Issues take longer to resolve things drop between the cracks more often and People leaving it to one another and not really knowing who's doing what and where the responsibilities are So there's more dependencies and less collaboration As well as all that there are the time zone issues Generally, there's going to be little overlap the more distributed you are so that limits the the opportunity for actually working together on things and and Separate us into smaller groups And we tend to focus the work then into areas or patches or batches that individuals can do rather than the team can do It's not impossible But it does make things more difficult So here are a few tips for what you can do to help make things a little bit better But 10 my first tip is to not use it as an excuse What I mean by that well pretty much every team these days is distributed to some degree even even teams where everybody is in the same building quite often are at different parts of the building or different floors and They'll have flexible working hours People working from home quite a lot. So every team has some degree of distribution and disbursement So there's no real opportunity to say it. Well, we can't be agile because our teams all over the place In an ideal work, we probably would have a co-located team But we're probably not in an ideal world so given That this is the case that we find ourselves in would I rather Use an agile approach or a more traditional approach I would always go for the more agile approach because it kind of forces collaboration It reduces the amount of time that things can go wrong and people can not talk to each other Because at least at the end of every iteration We're going to have to collaborate and see where we are and get some feedback and talk to one another So an agile approach allows us to make the best of our situation. It's an easy excuse to put in there But it doesn't really help and this idea I've said this in a few of my videos before whether you believe you can or believe you can't You're probably right and this idea of Getting into our heads that we can't do this because so so is in a different country Means we're generally going to be looking for evidence that backs up that view that confirmation bias So you can't use that as an excuse anymore It's about making the best of the situation and working out ways to make the best use of your time and the people in your team At nine my suggestion is to co-locate as much as you can so perhaps rather than having Two teams where they're both split over locations Have two feature teams that one is in each location If you can't do it by team then then co-locate by triads or pairs or something like that so we there is some element of Co-location at some point some some aspect of direct collaboration all the time That's probably going to be better than having two feature teams split across both those locations And if possible make use of that somewhat provocative term that's coming to the lexicon of promiscuous pairing So rotate people around for a period of time that two weeks working with this person two weeks working with that person That will help spread the knowledge spread the awareness Spread the understanding and the empathy build those connections that rapport and build up that sense of team identity and culture That's going to be a little bit harder to do in a distributed team Tip eight is assume positive intent. What do you mean by that? I hear you ask in general? I find the best teams Give each other the benefit of the doubt They they they work on the assumption that everybody is trying to do a good job They would like to do a good job. I don't know many people that come to work wanting to sabotage the team the organization their colleagues, however The less frequently you see people the further apart you are from them the harder It is to think favorably of them. We generally interpret their actions slightly less Positively if we haven't seen them for a while And so it could be that we need to just kind of force ourselves With a prompt noun again of thinking right this didn't go quite as I would like if I were to give them the benefit of the doubt How would I interpret that? I think that's quite a helpful thing to do for a team So assume positive intent and consciously thinking from a positive interpretation will make those interactions and The sort of bumps in the road that are distributed teams Inevitably going to come across and live a bit easier to tolerate Tip seven is get together when you can this is about getting everybody together and as often as you can Most important times for getting people together with a high band with Ceremonies so things like team kickoff sprint kickoff sprint reviews sprint retrospectives You're going to have such Benefits from that in terms of team dynamics in terms of rapport in terms of understanding it's it's a great way to Build that sense of of team and common ownership and peer accountability Obviously budgets are going to be a challenge find out what you can get as much as you can and then use it in my experience It's never a wasted investment Tip six is to promiscuously pair and particularly around reviews Make sure we're not reviewing our own work, but also make sure we're not reviewing on our own Whatever level we're talking about make sure we're not doing it on our own if we can review together that's much much better feedback and Increases that sense of understanding and empathy and shared perspective and create a common culture within the team over time so Rather than I'll do my bit pass it over to somebody else and they review it pairing as much as you can and then Promiscuously pairing that term of just sharing the pairings around making sure we all get to work with each other And we don't develop little cliques or sub teams Tip five is to agree collaboration times Now I actually I recommend this for teams that are co-located as well as I've already said every team is distributed To some degree agile teams are often quite noisy and that's a good thing Okay, we swarm around a problem. We see what's going on. We hear each other's opinions We're collaborating directly But they can be quite distracting when you really just want to get your head down and do something even the best agile team Even the most agile teams will have quiet time and so the conversation is then around Well, when is the quiet time and when is the collaboration time now in a distributed team That might be less opportunity around that because there may only be a certain amount of time when there is overlap and the possibility For communication and collaboration and perhaps we can flex our working schedules a little bit in in Every every direction to increase that overlap as much as possible And the rest of the time can be our own time But we'll agree sort of interfaces for what we need to hand off to one another as our time zones then split So tip four is invest in tools It might be higher if it didn't make me feel so old Why does that make me feel old because I start I find myself Starting to say things like when I was first doing scrum. We didn't have Slack and we didn't have Skype there was no Facebook. There was no iPhone. I know there was a world before all this stuff kids We had to make it work with rudimentary tools And that's where people start looking at me thinking Jeff. You're you're an old man But it's true and we did make it work then even with with Terrible tools. I mean terrible conference call hardware and software. So teams these days I probably don't appreciate the technology and tools that they have even free or very cheap webcams and iPhone apps and tools and websites and Services out there these days that tools can use Freudian slip there But teams can use to increase their collaboration and actually reduce that feeling of being spread apart Investing in tools to enable the team and that's important enable the team. We don't want to Burden the team with a tool that's going to drag them down bureaucracy and admin But actually enable the teams to collaborate as well as possible Then that's you're going to see the returns on that in terms of collaboration quality morale That sense of team that we were talking about very rarely do I see investment in tools being wasted money? Tip three is to over communicate Basically be prepared to run the risk of sounding repetitively annoying The temptation is to just do the bare minimum because communication is a bit harder when we Distributed in general the tendency in distributed teams is to under communicate not consciously and we kind of make assumptions The other people have got the same interpretation. We've all Misinterpreted an email. Okay, and the more distributed the team is the more we rely on things like email So over communicating things spelling things out at the risk of sounding patronizing repeating things at the risk of sounding annoying Is generally a good thing to do is much better than under communicating when we've made a decision as a team Let's over communicate that let's reinforce that. Let's make sure we're all aware of it and we haven't forgotten it If we've got some standards as a team That's another good thing to over communicate because we need to get into disciplined habits Because we don't have the opportunity to look each other in the eye and and review things a lot more Informally and unorganically as we would if we were sitting next to each other And the third thing which is kind of tied to standards that I think it's important to over communicate is the definition of done Whatever that means at a feature level Perhaps even at a task level perhaps at an individual level what our interfaces are between people if we have any hand-offs within the team It's really important to over emphasize those rather than under emphasize those Tip two is to learn about each other now I'm a big fan of this regardless of how distributed the team is all the best teams that I've seen Know each other as people as well as colleagues that that builds rapport in a sense of accountability and says I care about this person Yeah, but it's even more important than a distributed team because it's very easy to be just a name Rather than an actual person Just a resource rather than actual human being So knowing a little bit about who we are. I'm gonna know what annoys you as well I can use that to help build a relationship and build a successful team that I want to be part of and Building in a little bit of just personal time perhaps into our days and our perhaps our conversations So it's not just all about work again. That that can be seen as a cost, but for me. It's an investment And tip one my number one tip for distributed agile teams is to create some working agreements Coming together and agreeing what what kind of team do we want to be and what does that mean for us? How are our individual values lining up here? So working out what we're prepared to do as individuals to to make that team that we would like to be part of What we're prepared to commit to each other to make that happen what we need from each other to make that happen And of course we'll make mistakes We'll forget things but we can Have positive intent and remember that nobody's deliberately trying to screw up we go again And we'll get better So a quick summary of my top 10 tips then Don't use it as an excuse Almost every team is distributed to a degree Co-locate as much as you can Assume positive intent get everyone together when it's possible promiscuously pair around reviews agree specific collaboration times invest in tools over communicate decisions and standards learn about each other and draft working agreements So that's the end of my top 10 tips video on distributed agile teams Like I said the first person to like and comment on this video can pick the topic for the next top 10 tips video I hope you found it useful and until next time Take care