The Most Efficient and Effective Method of Conveying Information to and within a Development Team is Face-to-Face Conversation

This is Building Better Developers, the Develop-a-Noor podcast. We will accomplish our goals through sharing experience, improving tech skills, increasing business knowledge, and embracing life. Let's dive into the next episode. Well, hello and welcome back. We are continuing our season where we're looking at the Agile Manifesto. We're digging a little deeper into this. We'll start out with the 12 principles, really focusing on each of those, taking roughly an episode per principle to look at how these principles affect what we do today, what our attitudes should be, and a little bit of how things have changed in the decades that have gone on from when this idea started to modern day development. This episode, we are looking at the sixth principle, and we're going to dive right in. It says, quote, the most efficient and effective method of conveying information to and within a development team is face-to-face conversation, end quote. Sorry, I had that dramatic pause there. You think about it, this is actually very interesting when you look at where we sit right now, sitting just after or wherever it fits, somewhere in the whole COVID stuff of 2020 where we have dramatically shifted in the last six months, definitely the last year, from what we'll call what was traditional business approaches to a lot of non-face-to-face conversation. You can, I guess you can sort of squeeze video conferencing and stuff like that into the face-to-face conversation, but there's still lacking in there. There's some things that you just don't get from those kinds of, those video conferences that's just not quite the same environment and attitude and benefits, I guess, that you get from that face-to-face conversation. Particularly now when you look, it's not just those Zoom meetings, but we do a lot more through messaging like your Microsoft Teams or Slack. We do a lot of email. A lot of stuff is, we even text. They're not even voice-to-voice. It's just, we're just sending messages back and forth in some medium. So that becomes very interesting when you look at this principle that says, well, actually the most efficient and effective method of conveying information is face-to-face conversation. And then let's look at this starting from, I guess, as far as we can, I'll get away from face-to-face conversation and look at how we can progressively, what it brings to the table and what some of the weaknesses are that face-to-face will eliminate or alleviate. Probably the farthest thing from face-to-face conversation would be communicating through documents. Create a requirements document, send it to the implementation team. They review it. They put a lot of comments on it. You send it back. I think that's probably as far as you can get from face-to-face because, and it highlights probably the biggest issue, which is turnaround time. You get, however much work goes into this thing, and then you send it off. You throw it over the wall. It takes a while. Eventually it comes back. And it's a very slow cycle, essentially, to go back and forth. It's not really a conversation. It's too delayed to be an actual conversation. I guess it is, but it's really stretching. To me, it feels sort of like the historical, if you go back and look at some of the letters that were delivered 100, 200, 300 years ago where you'd have these conversations via letters, but they went on for months or years. It's not likely that you're going to get stuck doing years of passing these documents back and forth, but definitely weeks and even months. So let's push it a little closer to face-to-face and get to something a little closer real-time. Then you're talking about probably email will be your next step. And that is and has been, I think, probably the primary communication method, the primary way to convey information in a lot of software development teams for quite a while. And we'll improve on that a little bit, but that's definitely something that I think everybody at least utilizes if it's not the primary way of conveying information. In this case, you do get somewhat of a conversation. You can send emails back and forth actually fairly quickly. You do still have that formal somewhat. In most cases, you have that formal kind of feel to the emails that you're sending back and forth, much that you would get with a document. So it's something where people have spent a little more time thinking through what they're going to say and what the information they're conveying. Then you can slide that a little closer to face-to-face and you start getting into things like text messages, messaging platforms like your Slack. And actually, another one that's that has come up that is has a lot of strengths is the idea of a Wiki site or something like that, some sort of a commonly edited document or site or series of documents. This is where you get everybody can be adding and building, but it's still not really. It still can be, but it's not really a conversation, which you tend to have. And this is the biggest weakness that you get outside of, I think, face-to-face conversation is that there's too much. There tends to be too much push is that you're pushing your statements and you're not getting you're not spending enough time with the feedback from the other person. You look at it, you get some feedback and you're going to spend some time and think about it and respond. But you're not. I think it becomes it's hard to describe, but I think it's because we almost do like a point by point assessment or response as opposed to trying to get the general feel of things. And that's what we get to face-to-face conversation. One face-to-face conversation is going to be faster than doc and writing stuff down. It's always that's why sometimes people believe in even just talking, not face-to-face, but on a phone or something like that. That's why you'll have situations where people say, hey, this is just too much to deal with in a text or email. I want to talk to you about it or we want to get several people involved. And rather than all of us trying to sort through what people are saying, let's have a conversation about it. Let's get everybody together in a room and talk through it. Now, the number one thing you get out of face-to-face is that whole idea of a picture is worth a thousand words. There is tone and emotion and things like that that go into and that can be read from face-to-face conversation that you're not going to get in email and things like that. You also get, I will call it initial or knee-jerk reactions in a face-to-face conversation that you may not see in an email. This is very critical, I think, in a development process within a development team, and especially between the development team and the customer or the business managers, the product representatives. Because sometimes what we end up doing is that we have an initial thought, an initial approach that we want to take. And for whatever reason, whether it's politically, internal politics, or whether it has to do with our status is based on the other people we're talking to, whether they work for us or we work for them, things like that. There's things that we do that we will roll it back, we'll walk it back. We'll originally think, hey, this is what we should do, this is how we should approach things. Or if you're a customer, hey, this is something I really want. But then we sort of, I think in a lot of cases, we'll sort of argue ourselves out of doing that because we'll say, you know, I don't know that we really want to do that. I think that's probably going to be too costly. That may be a fight that I don't want to, you know, an argument or a discussion that I don't have the energy to have. There's all sorts of reasons for us to change and, for lack of a better term, moderate our approach. When you're in face-to-face, even though people still do that, the people that are there also can sometimes read that. And so there are situations where you can draw out of them that initial thought. They may say, oh, you know, this is critical, I think, in requirement scanner. Because I don't know how many times I've had somebody where I'm having that discussion of what are your pain points? How should this look? Maybe what's an ideal solution? And you can tell that there's some things that they're leaving out. And so that allows me to go back and ask some other questions. Well, it seems like when you said this, you had something else in mind or you're trying to work through some problem in communicating, you know, some challenge in communicating what you really need and what either you think we can do or what you would like us to do. And usually that will draw out things like, well, we would really like to do X, but we think that it's going to be too costly or too difficult. And that may be the case, but it may also be that they are underestimating what the team can do or overestimating the complexity of the specific problem or issue they want to address. And so I think you're more likely to get it all out on the table in a face to face conversation, particularly if that's what the goal is. The goal is to really talk through things and make sure that the team's on the same page. And face to face conversation helps a lot. There's a big difference between somebody being silent and silent because they just have no idea of how to even begin to ask a question or silent because they completely understand the situation. And face to face, you're more likely to see that. You're going to be more likely to be able to see through body language and things like that, whether somebody seems completely lost and maybe needs to adjust stuff or explain things in a way that fits their understanding or their background. Or you'll see that they're probably nodding and things like that. They seem very comfortable maybe with the comments made. Because sometimes you don't add to the conversation. You don't say anything because you're not adding to the conversation. And sometimes you don't because you don't even know where to begin or maybe because you don't want to look stupid or ignorant or something like that. But in any of those cases, when you're in face to face, you have the ability to read people a little bit better, get more information. And you can, you know, I hate to use the word almost because it's such a buzzword, but you can pivot, I think, better in a face to face conversation where you can talk through topics and challenges and goals and design decisions and things like that. And you can also quickly do little side conversations or ancillary features and things like that where you can pretty quickly say, OK, well, we've talked about this. Let's spend 30 seconds on this other thing. Now you can do all that in email and stuff like that, but it's I think it's just more difficult. It's more time consuming. Now, yeah, and we've talked about this is that face to face is a quick way to get information conveyed. We could talk and emote, I guess, faster than we can write. And sometimes a lot more clearly because then we can send it, you know, we're conveying feelings and concepts that may be very difficult to to put to words. And we can also get that instant feedback where if we say something or we propose something, we're going to see cues from the rest of the people involved, whether it is something that is widely accepted or broadly accepted or maybe distasteful or something. There's something about it that doesn't sit well with the part of the team so that you can you can dig further into that. And this is especially especially if you are a lead type role. Where there is an opportunity for you to have people that would be, you know, quote, yes, man, where once you say something, everybody just sort of wants to go your approach as opposed to the team developing their own. And this gets into we could easily drift into management styles and stuff like that. And that's not the point of this. The focus here is conveying information quickly and effectively. You're going to get that face to face. All of the other ways you do it can be can be very effective, but they're not going to be as fast and probably not going to be insufficient because you've got to put this extra time in. You think about it. It's almost like you have to have a you're basically adding a middleman. If I want to talk to you, I can talk to you. I could do that. You know, like right now I'm conveying information to you. It's not a face to face conversation, but it is a direct line to you. If I want to if I wanted to do this through a post or through an email, then what I'd essentially have to do is I'd have to tell the email client or the blog software or whatever it is I'm using. Through writing, I would have to tell it and then you're going to read that article or email. And so then the email or article is now telling you the same information. You've effectively put an intermediary into the conversation. And the more we're very visual. And so there's I think it's almost goes without saying that when you have a visual. To go along with the audio that is a lot more that can be conveyed. It's a lot easier to get information a lot of information across quickly. Thus, that becomes your most efficient and effective way. And there's there's something to be said for face to face conversation where you. You had everybody's there at that point that everybody's for the most part present. I mean, you can check out in a face to face conversation, sort of mentally check out, but that's not as common as sort of checking out of a of an email conversation. Or some other, you know, particularly think of it because these other things are not built. You can, but they're not really built for instant feedback. They're not built for conversation. There's too much time. And if you look at the extreme cases, like an offshore team, if you're sending emails back and forth. Usually your time shifted, so you're going to send something. You know, many hours later they come into work, they put their response together, they send something, but you're not at work anymore. So it's the next day before you respond. And it's not like everything is that bad, but. The shortcut is to get to face to face conversation. And so this is very important because as we talk about that highest priority of satisfying the customer. I think now you should be seeing that one of the things that we are still focusing on with the Agile manifesto of a primary focus is clear and consistent communication. Is that even though a lot of people say Agile is not about documentation or anything like that, it isn't. It says that documentation is not necessarily essentially here. Documentation is not necessarily the most efficient and effective way of communicating. But here are the things that we need to do to make sure that communication does go on because we recognize that it is a very valuable, critical, essential part of software development. If you don't have the communication within and among the teams, then you're going to be challenged. You're going to have a lot of extra challenges. You're going to miss stuff. And this goes back to almost every principle you're going to see this to some extent. That that's part of what the the unsaid goal is, is that we're going to be communicating developers to the team, the business team, or the customer. Or back to that, customer to the development team, implementation team. And that, I think that's where I'm going to leave it for this one. I want to let you, it's a good one to sort of let this sink in a little bit, that the most effective and efficient method of conveying information is face-to-face conversation. And think about that as we are in a very, a very different world from what it was when the Agile Manifesto was put together, because we do have a lot of ways to communicate. And I think if we hold face-to-face conversation as a gold standard, then we should look at what is lacking in some of the other forms of communication to make sure that we can, where we can, maybe we can try to fill in some of those gaps. Or adjust how we approach those tools, those methods of communication in a way that offsets its weaknesses and emphasizes its strengths. And now you get to go out there and offset your weaknesses and emphasize your strengths with yet another day, another glorious day, if you get out there and have yourself a great day, a great week, and we will talk to you next. Developers, the Developer Noor Podcast. For more episodes like this one, you can find us on Apple Podcasts, Stitcher, Amazon, and other podcast venues, or visit our site at developernoor.com. Just a step forward a day is still progress, so let's keep moving forward together. One more thing before you go. Developer Noor Podcast and site are a labor of love. We enjoy whatever we do trying to help developers become better. But if you've gotten some value out of this and you'd like to help us, be great if you go out to developernoor.com slash donate and donate whatever feels good for you. If you get a lot of value, a lot. If you don't get a lot of value, even a little would be awesome. In any case, we will thank you and maybe I'll make you feel just a little bit warmer as well. Now you can go back and have yourself a great day.