Improving Team Collaboration in Software Development: Proven Strategies for Success

Welcome to Building Better Developers, the Develop-a-Nour Podcast, where we work on getting better step by step, professionally and personally. Let's get started. Well hello and welcome back. We are Building Better Developers. We are Develop-a-Nour. We are with AI this season. We're taking a prior season. We're going through the topics and we're basically just kicking those topics into AI and we're discussing what it tells us would have been great things to talk about. Sometimes we get exactly what we talked about. Sometimes we get stuff that is out there, but guess what? We talk about it this time around. So we're going to see what happens this time around. First, I'm going to introduce myself. I am Rob Brodhead, one of the founders of Develop-a-Nour, also the founder of RV Consulting, where we help you do technology better. We sit down with you. We learn what your business is, what's your secret sauce, what are your pros and cons, what are your good things, your bad things, the positives, what are the challenges and the pain points, what kind of technologies do you have, and then we take our knowledge of technology and business and look at ways to allow you, to help you, to guide you to do it better, whether it's through simplification, automation, integration, innovation. We sit down and find you a way to go forward, where it starts with a technology assessment. Figure out where you're at, where are we starting our journey. Get a roadmap, where are we going to go and how are we going to get there. That's our roadmap. Then we're going to either point you to the places you can go to execute it yourself or we're going to work with you to execute on that roadmap as well. Good thing, bad thing. Good thing, bad thing. Bad thing, a couple of weeks ago, wife gets a call out of the blue, son got into a car accident. It was one of these where it was like, okay, what's going on? What's happened? Things like that. The good thing is nothing happened to him. This is a combo because there's a bad thing. It was a hit and run. The good thing is the first thing that my wife said, Natalie comes in and says, you know what? Take a picture of all of the cars, including their license plate. My son gets out of his car within the first, I don't know, 30 seconds, 60 seconds, starts snapping pictures and he gets the picture of the license of the person that is driving away. So they get caught and they are going to, you know, it's hit and run and they're going to, their insurance is going to cover all this stuff. So good thing, bad thing, good thing, bad thing. There's a couple of those in there. Sometimes it's nice to have somebody that can like think on the, you know, during a season or recession of stress and be like, hey, take a picture of the bad guys before they get away. I'm going to have to take a picture of the bad guy on the other side because he's on video. If you've never checked us out on the developer channel on YouTube, go for it. But first, Michael is going to introduce his bad self. Hey everyone. My name is Michael Mollash. I'm one of the co-founders of building better developers, also known as developer. I'm also the founder of Envision QA where we help companies unlock their software potential through a comprehensive software quality assurance assessment review and test services. We help you discover how assessing all the areas of your software development teams from sales to QA can ensure customer satisfaction and improve the software quality right from the initial conversation with your users. We don't just do that. We also help with assessments. We help you actually walk through your applications, do a full assessment of your software stack and understand your processes and procedures within your company to make sure that you have the right software working for you, not you working for your software. Good thing, bad thing this time. It's kind of one in the same. I am a bit of a gadget geek and a project I'm on, we had to go buy a new printer for them to print labels for this particular project we're on. I've never worked with this before, but it is a new gadget. So I'm like really looking to get my hands on it. But the bad side is I have to figure out how this works under a deadline. So that's kind of the good and bad. I'm going to have a lot of fun with this, but it's going to be a little stressing in the process. But, you know, hey, that's what gadget geeks are all about. You know, if it's not Raspberry Pi, it's a phone. If you like gadgets, you know what I'm saying. So this episode we're going to talk about, we're going to spit out to AI and see what it spits back at us, maximizing efficiency in software development, individual, small and large teams. Now one of the things I'm noticing as we're going through this is that there was probably some AI involved in creating the topics that we the names of the topics that we did back in the day. So it's really interesting because it's almost like back when you used to tell Alexa to ask something to Google and then Google would ask it back and forth. And the next thing you know, they're getting into an AI war. Well, this is maybe what we're going to get into. Now this topic, we threw it in there. And interestingly enough, it didn't get all friendly and like, you know, rosy cheeked and sunshine and rainbows. It just got right into it. It's like, you know what? Okay, this is what we're going to do. We're going to talk about how developers and teams of all sizes can improve efficiency, blah, blah, blah. Let's get into its points that it recommends. First thing is define efficiency in context. What efficiency really means in software development, not just speed, but value delivered per effort, avoiding rework, tech debt and burnout. Efficiency is not the same as rushing or cutting corners. Now we didn't actually define efficiency. I don't think at the time we have definitely talked about some of these topics along the way. But I think this is probably this is like the nut of it. Basically, I think I'd like us to talk about a little bit is efficiency where you're avoiding rework, tech debt and burnout. So it's really a couple of different, very big areas. It's rework, so it's doing that solving the problem correctly, not having to go, not having bugs, not having to go back and change the requirements or get clarity on the requirements or anything like it, but getting the product, the problem solved the first time for lack of a better term. Now, tech debt is the kind of thing it's like not only getting it solved, but getting it solved in a way that you're not saying, all right, we're just getting it done right now, but we know there's some other things that we want to do. It's actually getting it solved essentially the right way the first time. And then burnout is yes, it's burnout of your resources, your developers. But I also think of it in this case, this a little bit more of like without going through all the resources you need to not making your developers have to stay up 24 hours straight, not having to not pay people or cut your budgets or all these other things. So it's really time, quality and resources. This is really looking at efficiency in all of those areas. And so I'm going to throw this out to you and let you talk to any one of those to get us started on this. Sure, I was trying to pull up the podcast episode to see some of the highlights we did. Interestingly enough, a lot of the things we talked about and I'll touch on this is. The main point of this episode before was to really talk about efficiency of your team, like individual developers, small teams, large teams, how they work together, how to make them work efficiently together. And interestingly enough, a lot of it was talking about like code committing. Is everyone keeping track of their code? How are people communicating? But the main thing is, you know, define efficiency and the contracts within your team. These are those points, right? Commit code regularly, commit your code, create reproducible builds like we were working on today. Create containers that you can share with your teammates so that you have a smaller time for bringing new team members up to speed. You know, it's all about efficiency. You want your teams to work faster. You want them to work better and you want them to basically be working and not be constantly blocked, hitting roadblocks and kind of arguing amongst themselves across technology. You want to make sure things run smoothly and efficiently. Now they move right in and I think we're going to talk into some of these as I'm looking at some of the other things. So they break it. This these results come back. They're going to break it into a couple areas. So first, they talk about working solo. So the independent developers. So this is being efficient as a solopreneur, solo developer. So the challenge is wearing many hats, you know, dev, QA, ops, support. There's not, you know, having feedback loops. It's just you in your head. And they have some efficiency tips. Use opinionated frameworks, which I've never heard that phrase before, which is pretty interesting. For example, Rails, Next.js to reduce decisions. So. I like that because some of these a lot of times we talk about the negatives of a framework being too restricted, too constraint, having too many constraints that you have to solve the problem this way. But the bonus of that is that you don't have to think about, do I do it this way? Do I do it that way? One of the things that I just was playing around with, like building a new little application the other day. And I wanted to do it in Python because I was like, all right, I want to do it in Python. I had a couple of things set up for it already. But then it was like, do I do Django? Do I do Flask? And there's things like that. I was like, OK, which way do I go? And then what I do for the front end? Do I do just like straight HTML? Do I do React? Do I do, you know, do I maybe instead say, well, I'm going to do like Django on the front end, but I'm going to have a node on the back end for an API? There's a lot of different ways you can go with these things. And that's going to take you time if you're going to sit there and think about it. So these tools that are much more like this is the way will help you get there faster. Now, automate everything possible. This is we talk about this all the time. But as a single person, as a single developer, I find this a really big challenge is that you just you don't feel like you have the time, or at least I don't feel like I have the time to step back and go automate it until I've done it several times. I'm like, I am wasting time on this. So instead of spending the five minutes now and then five minutes tomorrow and five minutes the next day, I'm going to go ahead and spend 15 minutes right now and just take care of it for the way out. But you have to it's one of those that I think you're a little biased in your calculations of what kind of time are you spending and what kind of time are you going to save yourself. It always helps to have that second set of eyes. Set time box goals with clear deliverables. That is so crucial, especially as an independent, especially as a side hustler. And then use journaling tools like Obsidian or Notion to track progress. So I think also other tools out there like your Trello's, your Asanas, your Jira's, all of those things, those kinds of things are, I think, just as critical for a single developer as they are for a team. So covered a lot of ground there. What do you want to tackle? Efficiency for the solo developer. So efficiency for the solo developer. One thing I don't think you really touched on, but it's kind of we've talked about many times, is make sure you have good like code commit. Make sure you keep the quality of your code clean. You know, make sure that you have good code commit documentation that you keep track. Like you said, using Jira, things like that to make sure that what you're working on is tracked, that you have snapshots of what you're doing so you can roll back. And then automate, automate, automate, automate. Get that continuous integration pipeline going as fast as you can, because the less time you have to spend maintaining your pipelines, getting your builds out there, the more time you can focus on getting the work done and keep moving forward on features. The other thing is even as a solo developer, it may still be worthwhile to build those containers for your development environment so that you can drop something and build it right back up very quickly versus, oops, I broke my database. I have to spend three days rebuilding my database on my machine. Whereas if you had a container for that, all you would have to do is drop the container and bring it back up. So starting a project or starting out as a solo developer, you might not think of these things, but these are things that if you can kind of plan ahead, what am I going to need for what I'm working on? What does this project need? And you kind of lay out the things that you can automate or structure in such a way that you have minimal downtime. Yeah, and I think that I was taken back to a project I did years and years ago where I was the only developer. It was as a consultant, it was for a company, but basically rebuilding an existing application. And I was given the time and the bandwidth to quote, do it right. And it was really comforting to have a broad range of unit tests and automation so that when I would go through it, at that point, it was a locally developed application. It was a Tomcat application, stuff like that. But the nice thing was that when I would do build, I had, and it was automated scripts that could build it, run all the unit tests and make sure that everything tested out, and then it would actually deploy it out and then hit all the pages so you would get your initial cash kit. And it was a great way for me to be able to save time because instead of me having to, I would do that if I was going to go to lunch or if I was going to go take a break for a few minutes or something like that, then I could kick that off. I could have all that stuff run and I could do the testing in the background while I was doing something else. So having those automations helped a lot. Another thing is containers. I think when you're doing a solo project, especially one that you will probably get pulled away from, it is very, very helpful to have containers for that, to have everything built into it. Particularly, there's going to be things like data. I don't know how often that I've had issues where I've got a database that I was working on years ago, a year ago, and I forget where was I at. Maybe some of the data has aged out and things like that. So having a fresh build process and things like that you can do. And the documentation around it is really valuable because you don't want to be cussing at yourself six months ago. You're like, man, I wish I'd really documented this piece. There's a lot there. But let's move on to the small teams, as they say, there's two to 10 developers. So strengths, fast communication, tight feedback loops. Resource, the challenges are resource limitations. Informal processes can cause confusion as the team grows. Efficiency tips, daily standups, but keep them short and focused. Share development environments to reduce set up friction. Adopt lightweight, agile or Kanban boards. Invest early in testing and CICD to avoid scaling pain. Leverage pairing or mob programming strategically for knowledge sharing or onboarding. I'm going to take that last one. I think that that is as someone who has been in a lot of different development environments and particularly in the last 10 years or so, done a lot of siloed. It's just me, even if I've got a I may have Slack and other people around, but I'm in a room by myself effectively doing coding. It is very different from being in the bullpen set up or some of those kinds of things. We've got people around you. You can lean back in any second and say, hey, I'm running into this problem. And I think the people that embrace the technology that we have out there like Slack and things like that, message boards, to be able to quickly throw something out to the team and have them respond back and say, oh, yeah, I ran into that thing. And, you know, this is how I solved it. Or, hey, let me help you out with that. Or, hey, let's jump on a call real quick and let's see if we can walk through it. The getting lost in your own head and getting stuck in your own mindset of how you're solving a problem is probably one of the biggest challenges that we have. Honestly, it's one of the things I've liked about AI in the last six months is because I will throw something out at AI. It'll give me a completely different direction. Sometimes it's useless. Sometimes it's very useful, but at least gets me off of the track. You know, we get on this track like, OK, this is this is a bug. This is a problem. This is how I fix it. And then we realize that it's not the bug or it's not the problem or it's not how we fix it. But we're stuck in that track already. Other people can help us out in a nice, nice size team, you know, two to ten. It's actually really good because you've got somebody available, but you're not going to be overwhelmed by the team. That's my two cents. Your thoughts. So I'm going to take the one you always talk about. I'm going to go with Agile. So for small teams, two to ten and even larger teams, but Agile, as Rob has preached for many, many years, is a great way to manage teams and ensure that everyone is on the same page with the project. It also helps avoid duplication of work. Where you don't have two people in a silo working on the exact same thing at the exact same time. The other thing that this really helps that I like about the Agile approach is it also helps share information across teams. I could be working on one thing and say, hey, I ran into this problem, but this is how I solved it. And someone else could chime in and say, oh, hey, can you get with me after this stand up? Because that is exactly what I'm running into. How did you solve it? And it is a great way to kind of break down your projects into smaller sprints and really take small chunks out of the code. And so trying that big waterfall approach where you try to do everything at once. This is also very good for testing of the application because hopefully you have a tester on your team. But if you don't, the other thing that you can kind of work through is someone's got to be testing the code, be it the manager, the project manager. There's UAT. As you are going through these sprints, you can talk to these people and understand that, hey, in my stand up, I'm running into this. I'm doing this. But the other person can say, hey, wait, that's not quite what we need for the requirements or how is that going to work for the user? So it's very good for collaboration. It keeps everyone on the same page and it keeps your project from going too far off track. It can still go off track, but at least you go off track together instead of in a silo. We all go over the edge of the cliff at the same time. That's so not really comforting. Anyways, let's move along. The next one I want to I'm going to skip the large teams, mostly just for lack because of time, because the next one I talked about is common bottlenecks and bottlenecks and solutions for all sizes of teams. So it has a nice little four bullet points. So one and these, I think you probably all will be able to relate to in some way. Slow code reviews, use review SLAs and rotate reviewers. Unclear requirements always start with a 15 minute clarification huddle. Testing paralysis, use test pyramids, prioritize integration tests that catch regressions and context switching batch work, block out focus time hours. So I'm going to throw this one right back to you is where where do you want to go with that? Sort of your favorite that every size team seems to struggle with. So. It's very interesting. All teams, I think. Wow, this bullet points at testing process seems to be the biggest one for me. It's like, especially early on with projects because you don't have something there. You're still building the foundation for what you need to test. It really relies on the developers to test their code, but they're too busy trying to get the foundation in place to get something stood up that they can physically see and physically test. So a lot of times early on, either testing is really good or it's really lax. And then when you get into the more midsection of the development of the project, you run into problems where there's not enough testing, things break. You make one code change here, break something here. So that test paralysis is really something that. Kind of is personal, where you really need to be testing your code from the beginning as you get something stood up as your teams get something a little more sustainable, you can actually stand up that server or you can actually run the application on a desktop. At that point, you need to start having regression testing or at least user acceptance testing. And then once you start deploying to a QA server, you need to start having that more refined regression testing or smoke testing of that system. I am going to. I think I want to talk about the blocking out focus time hours because even with small teams, I've seen this particularly in agile. This can be a problem because you have your daily stand up. Sometimes you'll have a lot of breakout meetings and stuff like that. You'll have a meeting here or meeting there. And the next thing you know, you've you've ended up essentially breaking up your day by a bunch of meetings and you're not able to get focus time to get stuff done. This really becomes an issue with sprints when you're getting to the end of a sprint and you've got that mad dash that is Microsoft implied it where you're like getting all your code committed. But then QA is doing all this testing. There's this frenzy of testing and there's a frenzy of feedback that comes at it. And so the developers are trying to like scramble to get all their bugs fixed and everything just goes haywire for a couple of days. And it's hard to keep moving forward through that. Now, that's not, you know, obviously it's the end of a sprint. So it's not every part of a sprint, but I think there definitely should be sometimes whether it's waterfall, whether it's agile, however you approach it. And no matter the size of your team that you have some hours that are just like we're going to go get work done. Now it may be that you're, you know, the lead of a team and you've got to deal with a lot of other teams and you've got to go be busy all the time. That's fine. Make sure that if you do so, you're not dragging your developers into everything. Make sure that you can, you know, that's part of what your job is, is to deflect from them so that they can go get their job done. You're going to go, you know, listen to all the people you need to listen to, get the stuff, communicate it back to them and do that in a way that is efficient instead of them having to sit there with you. Now you can do stuff and this is something we've done. You can do death by recording so you can record everything and tell people here you go, let's go to it. Go listen to the recording and you can grab whatever you want. Don't do that to your team, particularly if you're like a, you know, a lead and you've got developers, things like that. You should distill that out, give them the bullet points that they need to know and then move on. Don't make them sit through that for a while. A pro note is if you have to sit through it, kick the speed up to like 1.5 or 2, however fast you can do stuff and you can always pause as you go through that. Trust me, it makes very long recordings a lot faster to go through and it will allow you to like jump through the stuff. You can also use AI. A lot of times it will give you summaries and synopsis and you can take those and maybe go figure out where in the recording if you need to actually get specifics. But also it allows you to get an outline a lot of times. So there are a lot of ways. There are a lot of things that as a team grows that are small, but then they become very big very quickly because you add more people. And so the little problems become bigger as you go. And so I think that's something you have to watch out for. And it's one of the things that it talks about as far as principles of scale. But we're not going to get into that because we are bumping up against our time. It's like, you know, ready for a commercial break or something like that. So we've got to wrap this one up. We will come back next episode. We are going to continue this because we're getting a lot out of this as well. I hope you guys are as always shoot us an info at developer nor email can send us an email at info developer nor.com. I'm sorry. I mixed all that up didn't come out quite right. It was one of those like word scrambles. So this is an email. Let us know what your thoughts are. What did somebody recommendations? What are some things that you'd like to see us talk about maybe some things that we want to throw at AI as we get further into this future episodes future seasons. If you want to if you're an interviewer and you want to talk to us or if you know some that you would like us to interview we are open to that as well because hey we're agile just like that just just because we can be that being said. I want to just thank you again for your time. Go out there and have yourself a great day a great week and we will talk to you. Thank you for listening to building better developers to develop a new podcast. You can subscribe on Apple podcast stitcher Amazon anywhere that you can find podcasts. We are there and remember just a little bit of effort every day ends up adding into great momentum and great success.