Building Better Developers

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 talking about what started as the Agile Manifesto and we've progressed into Agile processes and ideas to try to be better via the Agile approach. This episode and a couple episodes ahead, we're going to talk about some anti-patterns. We're going to focus on a couple different areas, different area each episode, because I really want to wrap up this season with some best practices and ideas on how to do this right. Agile has been around for quite a while, a couple decades now, and there are still people that don't do it right. I think, I don't know if it's the majority, but there's definitely a substantial amount of teams and groups that just don't quite get it. There's a lot of different ways that you can go wrong with everything. There's always anti-patterns. I think those are a great way for us to avoid at least repeating the mistakes of others. These are probably more important than the Agile world, which doesn't really lay out necessarily things that these are the things to do that are successful. It's really more about avoiding doing things that are going to create obstacles or slow us down. This episode, we're going to focus on anti-patterns of the development team. This is not by any stretch an exhaustive list. We're going to talk about a couple of key anti-patterns that do pop up and that we need to make sure that we work around those, that we find ways to avoid them. One, which I don't think, I think if you were asked, the first one we're going to talk about, if you were asked anti-patterns of a development team, what do you think some would be? I don't think this would come to the top of the list, but it's one of those that I think if you've experienced it at all, you would realize that, yeah, this is an ongoing problem. We'll call this the work in progress limit, or more specifically, the anti-pattern would be not having a work in progress limit. With a sprint, we should, we being the development team, should be working on a task, complete it and then move on to the other one. However, in reality, in actually implementing that kind of idea, sometimes something happens that there's a pause or you're waiting for something or maybe there's a couple of things that are suitable to an individual and, or possibly even the team within a sprint. And instead of getting something started, do it, complete it, you get a bunch of things started. It's like, we know we want to tackle these 10 tickets, so we're going to jump in and we're going to get started on each of those. The problem is, is that if you don't get them done, now you've got something that's in progress. You've got this half thing that's out there, or maybe as bad or worse, you have something that some reason you need to hand it off to somebody else. And so now you've got work that's been started and that next person has to adjust and figure out where did you get to, what's been done, what has not been done. This is a time consuming process and one that is often frustrating. So when you're thinking about just, I guess these would be like general guidelines as far as anti-pattern is concerned, to avoid this, maybe you say nobody should be working more than one or two tickets at a time. And it's funny as I read this, when I was looking at this anti-pattern, my response was exactly what I set the table with. I don't think I would have thought of it, but I know I've had discussions with teams where we've talked about not having everything in progress. Leave stuff, get something done and then move on to the next thing. Don't get it most of the way there and then go tackle something else. And this is really critical when you go back and look at some of the problems we've talked about like waiting until the end of a sprint to complete stuff. So QA really doesn't, they get a flood of stuff in the last couple of days as opposed to a steady stream of tasks for them to do. So just as a team, you're going to work better if people work as close as possible to a ticket at a time so that you focus, get it done, sign off, push it forward, whatever you need to do and then you move on to the next one. So I would say not only does there need to be a work in progress limit, but it needs to be, you really need to keep it a small number. People should be focused on a ticket and then get it done. You may have two, maybe three in flight basically because you may have some interaction and some downtime or whatever, some waiting time where you're waiting on somebody else to respond to something. So you can't really move that ticket forward. You've got a little bit of time. Okay, then maybe you pick up another ticket. And we've talked about this before in a productivity sense where you make sure that you have the natural dead time that we have or I don't know if it's dead time necessarily, but definitely waiting time that occurs in our life, whether it's literally waiting in a line or something like that. We have this professionally too. We send an email off to a teammate, but they're in a meeting or maybe they're off for lunch or off for the day or whatever it is. In those situations, I think it's perfectly funding to have and to help be most productive. Maybe you have two things in flight so you can switch back and forth. Once you start getting four or five things in flight, it's really, something's not right there. Maybe that those four or five things are all related, but then that probably, that is to some level, I think a little bit of a problem as well. You should probably be able to focus on one, get it done, and then move on to the others. If not, if there's a lot of interrelated requirements, then maybe you need to look at how you built those tickets out a little differently. The next anti-pattern I want to talk about would be probably well-known and this would be cherry picking. We see this in a lot of different ways. The cherry picking is, since we're as a dev team, we're picking the tasks we're working on, you get different things that people do as part of their cherry picking. Some of them, they'll grab a bunch of the quick fixes, the quick hits, because that's just what they want to work on. They don't want to get stuck in a long ticket. Or maybe they want to see more tickets done as opposed to points. They just feel better getting more tickets done. You may also have situations where there's certain, I don't call it either cool or otherwise desirable types of tasks, that people sort of jump on those first. This is not necessarily bad in a sense, but as a team, you need to be able to make sure that everybody has a shot at each of those tickets. You got to think about things like cross training so that people are working tickets that maybe stretch them a little bit. Also from a size point of view, if you've got a, and this goes back to the prior work in progress limit, if you've got a very large ticket, a large point item ticket, then the that there's going to be some downtime or some ability to squeeze in a smaller ticket is going to increase. You want to be able to leave a couple of those quick things early, or instead of grabbing them all up early, leave a couple of those for later on so that they can be addressed by people as you're going through the sprint. It also in general, and the cherry picking, it can offset our desire to do those three priorities we talked about. Things that we need to have, we have to have, we really want to have, and then the things that are nice to have within a sprint. You want to make sure that you don't have people cherry picking that tier two or priority three items over getting the priority ones done. Next one is so common. It is such a, is a recurring frustration with pretty much every team. Maybe not every team, but a lot of the teams I've dealt with. And it usually is more of a frustration to the product owner and the scrum master than it is the dev team. And that is the board being out of date. Whatever your sprint board is, whatever your tool is, is that somebody has, as we've sort of talked about, they haven't really, either they haven't completed something and then updated the board, or maybe they started work on something, but they didn't assign that ticket out to themselves properly. You may have things that are completed, but they didn't get moved over or released and they didn't get moved over. That kind of stuff just, it's, you have to, and this is a, I think this is a scrum master thing is that you have to be really diligent and pushing. And unfortunately you do end up having to review the board a lot. Now over time, I think you get teams that are habitually will grab a ticket, will assign it, they will update it. They will, they will go back to the board to log work essentially by moving things around in the board. Early on, that seems to be a regular struggle is the developers are working on stuff. They know what their, sort of know what their tasks are. So they move to a new task, but they don't update the board. And then you've got stuff that's sort of out of, you know, out of whack. Now in a daily standup, that may be something that is, that's probably the best time to essentially address it. They don't want to lecture the team on it, but it's something that, you know, maybe you bring that up every day. You know, what did you get done? What are you working on? Take a look at the board. And if something looks like it's been sitting there longer than it should, then bring that up and say, Hey, is it, is this up to date? Or you said you got this done, but the board doesn't say that's done. Where does this actually add? Is it ready for testing? Is it not ready for testing? You will see trends within the board that will help you identify that as well. If you know that the development team is knocking stuff out and you don't see a lot of stuff that's been moved over to the, you know, for QA or testing, then you may say, Hey, I thought you guys were making some pretty good progress, but I'm not seeing a lot of stuff that's sitting there ready to be tested. And so the, you know, get the team to, you know, to generally prod them on a regular basis to say, Hey, you need to update, update the board, make sure that we've got a place that we can look at, that we can all see where we, where we sit and what's going on, you know, that you should theoretically that the board should be essentially real time. So if you complete a task as a dev dev team member, that's, that should be part of the completion is that you, you know, commit your code and then you move the ticket. You update the ticket as you need to. And this does include comments and things like that as well. So there may be some decisions made, email sent, something like that. You probably want to make sure, well, not probably, you should make sure that the tickets are up to date with those so that somebody's working something they have in front of them, the latest and greatest design decisions or requirements decisions. The next one, depending on your team may be a very, a very big issue or maybe a non-issue. It seems like it, it tends to be one or the others. And it's, I think it's just the general nature of the project you're working on and the team itself. The anti-pattern is referred to as side gigs. What this is, is work that's being done that the dev team is working on that doesn't exist on the board. There are a couple of reasons this may happen. Sometimes that the work is close to, but not really called out in a given card. It may be, maybe it's some scripting for deployment where you have deployment stuff, but there's some couple of extra scripts that you got to deal with that aren't really, at least they're not defined within that card. So if you look at the work you're doing and you look at the board and you don't have any other information, you can't tie the work that's being done to a ticket or to an issue that's on the board. And that's to some extent there is a, well, this is where this is a challenge. To some extent it's, we'll say it's okay, it's acceptable because it's close enough and it's not, the work is close enough to something that you, as a developer, as a dev team member, you're comfortable where that work belongs. And it's either sort of obvious, which is sometimes a bit of a stretch, but where it's something that at least for the dev team and hopefully for the product owner as well, really for everybody involved, it's somewhat obvious that that would be a part of it. But when in doubt, it's better to put those details into, either put those details into the card or create a card for it. And then again, there's a lot of examples, but here's a, I think a pretty common example I've run into with a couple of projects I've currently been running. And that would be the idea of release notes. We do a release every sprint and we don't have a specific item that, a specific task that is create the release notes or, and depending on the release, sometimes we have a ticket that has to do with the run it, creating and running scripts for a release, but we don't have actually a ticket that relates to the doing the work, you know, actually executing the scripts and putting together the release notes. We have a place to hold those, but we don't actually have that as a ticket. Now that we get away with it, it's not that big a deal because it's a small-ish amount of time. You know, it's maybe an hour or two in a sprint and we do have a ticket that's where we store those. So you can at least see, even though there's not necessarily a billable bucket per se, you do see that, oh, here's a task and this would be what people are, you know, somebody can be working on. And you can put notes in it. You'll also see this moderately regularly with assumed items. So there's, and particularly small assumed items. So if it's, let's say it's install some sort of application and that application has maybe a primary software, maybe there's a database that's got to be installed and you're pretty much just out of the box. So it's a short effort. It's a half hour here, half hour there, something like that. You may essentially just wrap all that up and just say configure development environment, you know, something like that, or QA environment or set up production, things like that. You may have these umbrella type tasks. The key is to make sure that the, if you have an umbrella type task, that it's not too big of an umbrella. So you don't just suddenly have a bucket that a lot of stuff is essentially thrown at or included into. And also you don't want it, if it's tightly defined, then you need to make sure that tasks that don't really fit under that umbrella get called out and are pushed into, you know, other tasks. Another thing is that it may have to do with, and this is particularly with like umbrella type tasks, if you've got two or three members that need to be involved in doing that, a deployment will be an example because, you know, you potentially have somebody that's, maybe somebody's scripting the database side, somebody's moving code over, somebody else is doing server refreshes or something like that. You know, you may have a couple of different members that are working on, technically would be working on a single ticket. And so you get this side gig approach where maybe the ticket is really driven towards the, let's say the developer side, but some of the DevOps work that needs to be involved is just sort of assumed and not called out in that ticket or addressed in a separate ticket. And what the acceptable side of this stuff is if it's not, if it doesn't really impact the team, if the points, the efforts, the effort points and estimates are not impacted by it, and it's not something that is a decision will say or something that needs to be brought to the level of the product owner, then you can probably get away with it. But if these side gigs either circumvent the product owner, so you suddenly have the dev team, but you have the dev team effectively making design decisions or product decisions, or you have something where effort points are being lost. Maybe you have something that's set as an effort two, but it really ends up being as three effort one items or something like that. That stuff's all going to be very important for velocity and planning and design and making sure that everybody knows what's going on. So you need to, where you can, avoid the side gig. If you have to create a little more granular tickets or call out within the tickets, what are the key items, the key requirements and validations for that ticket to the point that it is essentially that it is possible to look at the board and know what everybody on the team is working on at a given point. If the board's up to date, then you should be able to look at the tickets that people are having progress and say, okay, so you're working on this, which means you've got these three things that you are working towards. And that's it. There shouldn't be any other additional work. If there's work that's outside of the board, then you really do need to find some way to incorporate that in because it's hidden work. It's stuff that ends up messing up your numbers because you've got this stuff that's off books and you don't really know what the true effort is. And you get these things that impact your sprint and there's no accounting for it. It just impacts the sprint. It would be like an off budget item financially. If you're spending $100 a month and you bring in $100 a month, it's like, great, that's awesome. But if you've got this off budget, $10 of stuff that you don't have on the budget that you do every month, you're going to wonder why you don't have money at the end of every month because your budget and your outgoing funds are not the same. It's the same way with side gigs. The last one I want to talk about is called gold plating. I think we've talked about this sort of anti-pattern before when we've talked about a couple of different things that developers can run into. This is, I would say it's common enough. I don't know how common it is, but it's definitely common enough in development. And it really is. It's essentially it's adding, it's gold plating as it's referred to, but it's adding bells and whistles or scope when that was not agreed upon. That typically the gold plating side comes from developers. There's extra time spent working on something or adding to something that was not requested by the product owner. And so it may actually get to the point where the product owner looks at it and says, wait, why do we have that? We didn't ask for that. We don't need that. We're not going to use that. But more importantly, it needs to be clear who's driving the feature set. If there's something that a dev team member looks at a ticket and says, oh, it would probably be useful for us to do X, go the extra mile for this thing, for this task, that needs to be bubbled back up to the product owner. And then they need to say yes or no. And it's really, if we go back to the 80-20 rule, this is where we allow the product owner to define what that 80 is if we're shooting for that. So we may say as a dev team member, we need to really complete this all the way out. And here's these things we need to do so that it's rock solid and done and scalable and maintainable and all that kind of good stuff. The product owner may say, no, we don't want to do that. We don't have time for it or we don't have resources for it. And this goes back to estimates and things like that as well. Your estimates need to include whatever additional details there are in that ticket. And they should be highlighted. So it should be something that somebody that picks up a, should be configured in a way that if you pick up a ticket, you know what should be done and what are the limits. If you have questions about it as a dev team member, if you're not sure how quote far you need to go with it, bubble it back up to the team so that the product owner can make that decision and they can do as they should, which is own the scope of the project. If you don't, then that would be gold plating. You need to have that kind of communication. And it doesn't necessarily have to be even a formal, you know, signing off or something like that, but it does need to be something where the product owner has that, is able to keep their finger on the pulse of what are we doing? How far are we going? What are we finishing out, you know, to high quality and what are the things where we are hitting that 80% point and moving on? There's a couple of, a few anti-patterns out of the, for the development team, at least in the agile world. I think you're going to run into most, if not all of them relatively often in varying degrees. Sometimes it's a big problem. Sometimes it's a minor issue, but like everything anti-pattern wise, the important thing is knowing it's out there and finding ways to avoid making mistakes of those that have gone before you. Challenge of the week. Which of these anti-patterns is most prevalent in your current situation and more importantly, what are you going to do to fix it? What can you do to address it? That's a rhetorical question, of course, but how do you take that knowledge of an anti, of the anti-pattern and then bring that up to the team, to the scrum master, the product owner, or whoever needs to go to so that it can be discussed and addressed within the team to make sure that you guys do not follow that anti-pattern anymore. If your answer is none, we haven't run into any of these, then kudos to you. That's awesome because like I said, these are actually fairly common. You're probably doing pretty good. If you're avoiding these, you're off to a really good start. And that being said, I hope that you're off to a good start in your day and you go out there and have yourself a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the Develop-a-Nor 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 developanor.com. Just a step forward a day is still progress, so let's keep moving forward together. One more thing before you go. Develop-a-Nor 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 developanor.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.