 Started unless people are trying to go to a different room like feel free to make your changes I'm not offended people walk out on me all the time My name is Z and I'll be talking with you a little bit about My company zinc and how we have moved on to a more asynchronous process for our distributed agile teams All of the things that we do are built on this foundation of what we believe makes an effective team The first of these is trust if you can't trust your team members or if your team members can't trust the executives or your customers Then your team will not be effective. It's a very simple formula And and building trust is the most important part of any any team in our opinion The second is respect People who respect one another do better work If I can respect that you are a diligent person who is doing the best that they can Who can quote the retrospective prime directive right now anyone? Yeah Diana So the retrospective prime directive is basically a very simple statement I believe that everyone on my team is doing the best they can with the skills abilities and experiences that they have And that is foundational to having an effective team having their respect for one another the third is alignment Knowing where you're going is much more important than knowing how you're getting there I Have a travel buddy who I sometimes visit and we just pick a destination and I just rely on them to figure out how we're going to do things and We wind up having wonderful adventures because our ideas never work out But we were aligned on this notion of having a delightful a delightful trip to Thailand or a Wonderful John to Taipei or whatever And so alignment is a really important part of having a productive team having an effective team freedom Being able to express yourself and do things in the way that you are most comfortable Being free to experiment to try new technologies new techniques new ideas And within the context for alignment is is very powerful. It's a this incredibly motivating thing to be able to Take a task and say you know what I'm going to try and deliver this user story Using just purely functional programming idioms like no no object or not no object-oriented design But no state mutation in between function calls or anything like that And having the freedom to do that and to experiment Is a powerful thing because it means you get new ideas and new practices that get integrated into your teammate into your team much more quickly And finally diversity If everyone is a programmer with a background in computer science, then you're going to have a lot of computer science solutions to problems You may be surprised at this but programming isn't the solution to all problems in the world It's hard for me to say that because I am a programmer But there's lots of problems that are solved by just sitting and listening to someone or by writing something or by drawing Something and as a programmer. I'm like well what we need here is we need a distributed framework for developing communications between these two access points and What my lovely writer partner does it says what we need is a haiku And like if you don't have a diverse team, you won't have those interactions And if you don't have those interactions, you won't have a significant part of your effectiveness So synchronicity and asynchronicity, I explicitly did not use versus here. I think that versus is a bad word It's a four letter word in my in my dictionary. What do I mean by synchronous and asynchronous? Those synchronous things are things which happen in conjunction So most agile teams are synchronous you get everyone into a room they work on the same project They work on a very small set of user stories at a time They limit their work in progress they have retrospectors at retrospectives as a group they do release planning as a group They do stand up as a group like and and this is a very powerful thing Because it means you don't need as much trust as much freedom as much alignment as much respect or as much diversity Because you're all in the same spot. You can all kind of like work through your problems and interact more effectively Whereas with an asynchronous team if you don't have all of these turned to 11 Your team is going to fall flat very quickly And the more asynchronous your team is the more freedom alignment respect trust and diversity it needs So My two favorite words in the English language are yes, and They are incredibly powerful I do not believe that you should have only synchronous teams and only asynchronous teams and never the two shall meet You shall never interact synchronously with one another Everyone must send a paper airplane and then wait for response. That's the only way we communicate I think that that's a false dichotomy and it's very harmful I also think that the false dichotomy of oh we always pair we always have stand-up We always have release planning at the same time everyone's in the building from eight to five Like I also think that is very harmful and that you that the most effective teams have a solid mix of these In my experience traditional agile teams are about ten percent twenty percent zero percent asynchronous And about I'm really good at numbers. See I put them out of order And 90 ish percent 100 percent 80 percent synchronous with my company. I'm working very hard to make that the opposite I would like it to be 80 percent asynchronous and 20 percent synchronous And I've got I've got some reasons for that So why why asynchronous you just told me that it's more work like I don't want to do more work No one wants to do more work than they have to right like we want to just kind of like do as As little work as possible to create the best results possible And I really strongly believe that having teams which are founded on asynchronous principles have significant advantages The first advantage I believe is non-blocking Or or if you if you've seen any of the research on any of the progress in the past like 20 years on asynchronous systems If you look at things like parallelization technologies the amount of cores that CPUs are having nowadays Like all of these things on look at networks technologies and how many nodes are involved in many of these networking technologies like These are all like very very big things that are changing the face of technology We're no longer limited by like we have a single CPU and it takes up like it takes up the entire thread And that's all you got right And if you've has anyone heard of Conway's law Yes, we got like three four. Okay, so Conway's law is one of my favorite laws The structure of your organization will be reflected in the structure of your software So if your team is built to be synchronous if your team is built on this notion that everyone has to be in the same room You'll wind up that your code will be in that way as well I was on a team recently that was technically we were distributed, but we were all synchronous The every every process had to run on the same computer like every server had to run every process And I was like what? How am I supposed to scale this like I that's that's that's very difficult to scale And the reason for that in my very strongly held opinions Which I have lots of is because we were we weren't allowed to be non-blocking. We always synced up We had we had everyone committed directly to master. There were no pull requests There was everyone is pairing and because of that our software reflected our synchronous nature of interactions And because of that it was difficult to scale Right, this is a common a common problem. If you have a lot of blocking operations, then how do you scale? Well, yeah, it's gonna be different depending on every single situation And then the third and most important part in my mind is joy I'm here today at Agile India because my team is asynchronous Like I wouldn't be here with all you awesome people if I my team was not was if my team was synchronous Because they would all be depending on me because I am the most technically competent person there according to the job description sheet that I wrote for myself And if if I were a synchronous team everyone would be relying on me and I hate to be relied on I love we wanted hate to be needed, right? It's it's kind of my my thing So let's kind of think about how traditional synchronous teams work There's my colors So if you have a synchronous team Everyone has to maintain these connections with one another That's a missed one. There we go. Is that all of them? Nope And that's all these connections all these relationships all of these these Interactions that have to be maintained because everyone's contributing directly to primary or master Everyone is kind of like responsible for the product And it's like you've got this conflation and this this this very difficult like thing to maintain and what happens is So you might have a developer who's got like a user story and they're like Hey, I'm waiting on a product and I'm kind of stuck. So I'm I'm stopped like I'm blocked right everyone's got the blocker like in stand-up where they say Oh, and by the way, I need this from this person. I'm not I can't do anything until that happens, right? And so the way you solve that in traditional agile teams Is you alert your product owner as quickly as possible who is very likely in some fancy pants executive meeting doing? portfolio management where they're trying to decide whether or not who knows whatever like there's all kinds of meetings That happened I've discovered and it's almost impossible even in even in co-located teams To not have someone be gone right when you need them, right? And so you wait for this product person to come back and then the product person and the developer kind of talk And then the developer makes a change in the product and the product owners like yes That's kind of what I wanted. Okay, great. You got that person unblocked, but what almost never happens is Is back What almost never happens is? adjusting the the artifact itself so that that decision is made easier in the future like you you don't get these situations where The developer updates the principal guideline like oh yes Well, we do mobile first for our design therefore I don't have to get the product person when I'm trying to figure out how many widgets need to be on the screen I can be like well on a small screen I can only support two so I'm not going to add four like you can make those decisions now in your head as opposed to being and synchronizing with the product person Whereas asynchronous teams We we have to focus almost all of our energy and all of our connection into the into the artifact We're working on itself We need to Invest our time and energy into updating the documentation I know the D word is a bad word in agile circles But if you're not like documenting your code not writing good tasks not including your wireframes in your artifacts not you know Mentioning people in your task tracker like you're you're missing out on a lot of information That's kind of like disappearing into the aether and on asynchronous teams You have to shovel all that information into the artifact or as much of it as possible Because then what happens is you get this ability to have discovery and memory We move past tribal knowledge. We move past like this history of well back in the good old days before we had 25 People there were two people on this team, and they built it this way, and that's how we like to gosh darn it I'm sure you've all heard that conversation on product teams that have lasted more than two months You also get this really cool interaction flow where if the expectation is your asynchronous you're never blocked Never ever I notified product that X is pending there and they I need their input on it And so instead I started why which might be maybe I'm gonna read a book about Closures core dot async functions or whatever But like I can immediately switch off of the task that is blocked and switch on to a task That is also valuable, but it's not is not that is not that And the way you resolve those is so the the developer Puts a notification into the artifact in this case. We use a sauna for pretty much all of our task tracking that's our artifact and They mention the product person the product person gets a ping They see that maybe they're in their lovely product landing meeting like oh You know what I'm just gonna reply to this. I am real quick Who cares no one's paying attention me anyway, and then they put the phone back in their pocket And the developer can get unblocked very quickly Or But the but what often happens at that point is the developers like well that was annoying and I'm already right in here Anyway, I'm going to record this somewhere either by updating our principles or updating our design docs or updating our wireframes and And the product owner will we'll see those and can then make a comment on them as well That was an arrow. It doesn't look like an arrow, but I swear it was let's try that again There we go And so you wind up with these richer These not necessarily richer richer is the wrong word you wind up with these interactions Which because they're focused on the work output because the work focused on the product because they're focused on the artifact that you are building together You are consistently and regularly adapting that artifact to allow yourselves to learn more effectively and allow yourself to build without getting blocked and Because of that scaling becomes much easier So let's go back to our lovely first synchronous team Let's start just drawing two connections. We added another team member another developer joined the team. It's great. They're really solid We think they're top of the line graduated at the top of their class and all that jazz But look at all the connections. Oh wait, that was one. I'm sorry there look at all the connections They have to just maintain like we went from To do You got more Yeah, so we went from and I can scroll back Something that kind of looked reasonable from a connection standpoint to something that is pretty much a tangled mess, right? Here. Oops, and I was even missing some Yeah, that one And that one. Oh, no, that one's right And so like just adding one person to a five-person team like I don't I'm not good at math computers do that for me It adds a significant amount of connections to to the amount of relationships that you have to maintain and maintaining Relationships is the hard part of software development Maintaining and building relationships is the hard part. So what happens if you're on an asynchronous team and you add someone? You just add another node into your into your artifact You teach them how to use a sauna you teach them how to use github flow You teach them how to use slack and you're like, okay You're not going to know everyone as closely as you would on a synchronous team You don't necessarily aren't you're not going to be going out for beers after work Or let us are playing games in the middle of the day but you're going to have a very specific set of ways in which you interact with one another and those ways that you interact with one another will be Will will will hopefully facilitate an effective experience for you as a developer Whereas as an additional team member. So let's talk about joy I don't know how much time I've got left. I've intended to start a timer, but then I kind of like freaked out Apologies, I get really nervous when I talk in front of people But the thing about joy is If you can learn more and better you are more joyful in my opinion I am a much happier developer a much happier person when I'm learning new things and becoming a better master at my chosen profession and If you're working on an asynchronous team, there's all kinds of slack right and slack is this critical component to effective Effective like cognition right if you there's a lovely talk called hammock driven development I would recommend you all watch it and then get a hammock for your office Or at least now go home more often maybe But like an asynchronous team is because you the focus is on learning better stronger faster and not necessarily on Communicating like synchronously better stronger faster. You wind up be having a little bit more joy in your life in my opinion You get to be more flexible Like I said, I'm here with all of you wonderful people because my team doesn't depend on me My team wants me to be there. They are they definitely are missing me But they're not less effective because I'm not there even though we're a very like relatively young team and even though We are relatively like Cross-skilled like there's no one no one's no one's upset or freaking out because I'm not there to hold their hand Which is incredible And it's just more fun. I get to go to my cousin's wedding and not worry about it I'm planning a lovely jaunt to Costa Rica with my partner and we'll probably not have to worry about it and there's this so much we're just so much more flexible and more able to adapt to people not being in the room because we don't expect people to be in the room that as a person I can have more fun outside of work and The other the other final thing is we can be more diverse. I don't know about you, but I have a burnout problem I tend to work 60-hour weeks and then flip a table and just stop working for three months and I'm trying to get better at that My partner would like me to get better at that But because I can I can actually scale down to a day a week when I'm getting burned out I mean like you know what I'm not going to be doing six-day weeks. I'm gonna be doing two-day weeks I can hire people who maybe can't get into an office very easily I can hire people who maybe can't who maybe have vision problems or hearing problems because they Because they are not expected to be able to maintain a conversation in like real time, which is very hard for some people They can instead take the time to think about how they're going to respond and think about the words that were said so we wound up with we with a much more diverse team than any team that I've ever worked with from a Skills and abilities perspective the other cool thing is because we can work with people at like a half-day increment And they can be productive is I can hire a writer for my staff like how many of your technical teams have a creative writer on their team None, do you know how awesome having a creative writer on your team is oh my goodness whenever marketing copy has to be written I just pinged them in a sauna when they wake up on Wednesday or whatever day They decide to work that week They open up their a sauna inbox and say oh we need some marketing copy written Z wrote some horrible stuff I'm gonna write some better stuff submit a pull request back in and now I've got this great marketing copy That's 10% more grabby And I can pay them at a half day of a time because they're freelancers there They have a lot of clients already and they're perfectly happy to make 300 bucks a day for for writing and such type of work So that's my pitch. Thank you very much I really believe that the future of computing in the future of relationships and the future of technology teams is asynchronous Even companies that are working together like github for instance is co-located is very asynchronous Slack is very asynchronous despite having everyone in the office And learning how to work effectively as an asynchronous team will make you much more effective as a synchronous team So if you want to chat about this, I will be around the conference center I tend to kind of hallway track and or hide in my room because I'm not really a people person Also, probably why I like asynchronous teams And you can always hit me up on Z Spencer at Twitter. I'm always happy to respond to tweets I'm literally on Twitter all the time So thank you very much. Are there any questions? Yes, they are asynchronous. They are More joyous They do it their own way the scent in the center is the product that is to be Delivered and they all contribute to it, but the only Challenge that I would see is the individual culture and the way individuals would interact So I think the biggest challenge to build an asynchronous team would be is what I feel is Hiring the right people Yeah Yeah, so the question was it was kind of there was a part of it was a statement around like github and open source and like all Of these projects are already asynchronous, right? and there's already a lot of fun that's happening there a lot of freedom around what's happening and How do you ensure that you're hiring and bringing on the right people? That can work effectively in that situation And my answer to any question about hiring is you don't hire for skills you hire for mindset So there's this notion of a growth mindset, which is a lovely book by Carol Dweck Everyone should read that book at least once in their lifetime But it talks about how you can identify and help grow the skills in people in In believing that they can actually learn things and be more effective if you can if you hire someone who thinks that Well, I'm not good at this and I never will be like then they never will be Neuroplasticity is a powerful thing, right? But if you hire someone who thinks I'm getting better at this and I'm willing to learn that I'm willing to be more Effective then they will continue to learn and be more effective And so that's my core criteria for hiring the second thing that I worry about hiring for is is there some amount of valuable skills That they can bring to the table right now So yeah, maybe the writer doesn't understand github, but oh my goodness They can like prevent me from burning two to four hours trying to get the perfect like advertising copy They can just kind of do that and I don't have to worry about it So I'll happily train them how to use github so that they don't that I don't have to so that I can rely on them For the the writing bits So those are really the two ways that I hire growth mindset and do they have a core set of skills and You know not a lot of companies support that And that's why I started my own. I kind of got sick of getting told no by too many bosses Other questions, I don't know how much time we have let me hi Here I have a question. So I think a lot of things which you talked about are counter-intuitive and I don't know maybe I would not use against but I think agile principles. I think Against some of the agile principles also and One another statement which I want to make is that okay, how human beings have evolved I mean they want to work in a community and as a tribe also, right? So does the SNC Teams I mean do they have to be? Very mature teams or is it applicable for the common or Common people also, okay, I'll just I'll just hold the microphone So the question if I if I understand I want to make sure I'm repeating it for you is First of all, this seems like it's like counter to the agile principles So and I disagree with that almost entirely I think it's actually more in line with the agile principles because we value individuals and their interactions more than a set of rules Around how that they have to interact so if you work better by going off into a room for four hours and like Really powering through a problem and then getting some feedback at the end We can support that because we're asynchronous if you work better by pair programming with someone constantly We can support that because we're asynchronous and because asynchronous systems can also be synchronous systems It is easier. I'm not I'm not sure if you've done much node programming But if you take an asynchronous system and make it synchronous, that's far easier than taking a synchronous system and making it asynchronous The other thing of contracting Like adapting over following a plan like we can adapt so much easier because we don't have like this lockstep if you if if you remember the There was a what was a there was this lovely story not really lovely. It was the end of World War two We were flying aid into Germany We're trying to make sure that like people could get back on their feet and weren't starving to death after like war has ravaged their country and Our planes would come in and they would be synchronous every plane would have to land every plane would have to fly back and If we wound up with these log jams that some planes would literally just be like, okay We're almost out of fuel everything just doesn't work and you'd wind up having a significant inefficiencies within the system And so one general was like let's be asynchronous if you don't show up on time You're out. Just go back home It's fine And what that did is introduced enough slack in the system that they were able to land about 30 to 40 percent more planes Because they explicitly chose to turn around when they when they didn't land there on time So because they were able to adapt as opposed to be forced to follow a plan like that's a really powerful thing So I and I could rant about like the agile principles and how like Asynchronosity is actually a powerful tool in the async for the agile to adjoin in the agile manifesto But the the follow-on question was is this for everyone? And I think the answer is yes because I think everyone is capable of learning new skills and learning new abilities I think it's hard work So like I said if you have a synchronous team and you do Like you don't need as much trust and respect like you have like face-to-face all the time like you're building your trust and respect through that Whereas an asynchronous team You kind of have to start with a lot of trust and respect. I'm kind of like blowing into the microphone. It's annoying me So I think everyone can do it But it's hard work and it takes time and I don't expect that we'll be there in 50 a hundred or 200 years But I think that you'll see more and more companies that are doing this And I think that's time so I would be happy to answer questions outside in the hallway and Yes, so thank you all very much again