The Negatives of Agile

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. Continuing our season where we are looking at the Agile Manifesto and software development using the Agile framework and processes. This episode, after singing its praises for so many episodes, we're going to actually take a step back and look at some of the negatives of Agile. This is something that I think some people spend a lot of time on. There are definitely the naysayers and those that say that Agile is no good, it's not development and pick on it, things like that for various reasons. Some are well-grounded and some are a little bit more opinion. But I want to look at the things that are struggles that I have seen with teams implementing Agile or trying to implement it and trying to make progress with it. First and foremost, Agile lives and dies, particularly when you look at the Scrum process. It's sort of indicative by the name. It lives and dies by the team. And there's two things in there that really drive your ability to succeed in Scrum and using the Agile approach. One is how the team interacts. If you don't work well as a team, you are going to struggle to get anything going well in the Agile world. If you look at the 12 principles, there's a lot of, we'll call it trust that's built into that, as well as teamwork. So you need to be in a, we'll call it, the popular phrase, I guess, is a safe environment. You need to be in a situation where you can bring up the pros and cons of what's gone on. You can talk about mistakes made. You can talk about where we're doing things well without there being some sort of other agenda going on there. Where you don't want to be in a situation where you say, well, we did this wrong and then somebody blasts you for it. Or you take some sort of penalty because you weren't as good as you should have been, or they thought you should have been. But on the flip side also, it shouldn't be something where you get all kinds of, you don't have somebody getting kudos because they did a great job this sprint and then somebody else does kudos because they did a great job the next sprint. And that's not to say that you don't want to have feedback, individual feedback, and that you don't want to have situations where the team is managed and they are led to do things better. But in the team situation, there needs to be a freedom to look at what's going on and look at ways to address them. And if there's things that are wrong that are not the team, but there are certain individuals that need to understand the process better or get stronger in a certain area or something like that, then it needs to be a team effort to make them better, to bring them along, to do what needs to be done. It doesn't need to be something where that person's just sort of set aside and say, okay, well, you need to go fix this or you need to just do this better as opposed to giving them a way to get that done. And then, that's the team, intra-team piece of it, how the team works together. But the individuals within the team are really asked to do things that I think are not, they're definitely not entry-level developer kinds of things. I'm not sure they're really, you can have mid-level resources, but you have to have some strong senior resources to do it right as well. You can make it work other ways, but this is where we start getting into some things. Maybe you have a bigger team where your core is that three to nine people that are seniors and mid-level. And then maybe you do have another half dozen junior developers that are really just, they almost are a single, almost seen as a single resource as opposed to six more members to the team. And I'm thinking particularly when we do the blended onshore, offshore teams and things like that, where you've got maybe a core team that's onshore and then you've got, or actually might even that, is it maybe as employees and staff. And then you've got this secondary group that is maybe not as skilled, definitely not going to be as knowledgeable about the product and the project and the process, but they are typically they're offshore or outsourced in some way. And so they're given very specific, detailed instructions on what they need to do. And it's limited more to coding. So they're there to handle the coding tasks. Most of the tasks that exist in Scrum and Sprints is more than just coding. Most of those tasks are going to involve, if you do it right, they're going to involve some time doing design and gathering requirements and understanding the business side of what is being built. If you have a team of coders, not developers, but just coders, that they can write code and that's really about the limit of what they understand of the problem and the solution, it's not going to work because it's just going to be too implementation heavy and you're not going to be able to let the development team just go develop, which is really where they're going to do best is when you have the product owner and the Scrum master, the product owner basically driving, directing where we want to go as far as features are concerned and things of that nature. And the Scrum master coaching people on this process and how to get better. The dev team is everything else, which includes really interacting with that product owner to really nail down requirements, to talk about design, to do the design and then also discuss it and share it and grow it as needed based on feedback from the product owner in particular. And this is where I've seen things fall apart is where you don't have that, you don't have a core in the team that can handle that design and requirements gathering in that. And again, this is not to say that you can't have entry level people, you can, it's just you're going to end up having the more senior members of the team are going to have certain things they're going to have to do to maybe to prep or to help along the entry level people. It's almost like a, I think it was like a cross training. An entry level is not just entry level skill set in general. It may be essentially entry level into the company, the organization, the line of business. It can be very difficult to bring somebody in even highly skilled in technology if you bring them into something where they don't really understand the business yet because the design and the requirements and some of the, I will call them the nuances of software development they just haven't been exposed to yet. So they're going to be ignorant of some things that are very valuable in making the team work. So you may have situations where you bring somebody in and your focus for them for a sprint or two is maybe not their technical strength, but tasks that help them get up to speed on the business side of stuff. Maybe they come in and they just don't do, they don't actually do any tasks per se within a sprint or two, but instead maybe they sort of ride shotgun with the product owner to help understand, get them up to speed on what the product should do. Maybe they sit in testing a lot and they do a lot of the testing sites that they can see how this thing should work. And they're going to maybe have to catch up something to some extent on requirements and previous designs and the foundation of the application and the business itself. So this is not, I think that's a, and it's really a big con. That's a big negative to Agile is that if you don't have a fairly above average skilled team, a little top heavy, a little more design and requirements gathering, then I think you're going to struggle quite a bit. If you have a fresh team, maybe a bunch of guys, girls out of college and you're starting up a company, so you've got a young team and they haven't really done sprint before and there's sort of new software development. Agile is going to kick their butt because there's just going to be too much laid on top of them that they're not going to be able to do. Those design pieces that actually crafting the software, creating a solution is probably where they're going to struggle. And without having enough people to drive that, they're going to be in trouble. And that's where, if you look at like the waterfall model, you can do that. You can have brand new fresh coders because they've already had this very thorough requirements gathering and design step. And so they're just, they're coding at that point. Now that's obviously a negative there is that you're not utilizing more advanced and experienced coders or developers, but that's not our focus this time. The biggest negative to Agile is it lives and dies on the team. It is not, definitely is not universally applicable. There are teams and there are environments and there are situations where Agile is just really not going to be a good fit for the resources you have. And almost a bigger negative is I think this is becoming more and more an issue because you've got these tools that can do so much. I'm seeing more and more, and it may just be me and where I'm at. Maybe this is not a universal thing, but I'm seeing more and more cases where you have these technology people. They're not even really coders, they're customizers. They can go in, they can work in a very specific and well-defined environment and they can be very effective there, but they didn't, they've learned the tool, they've learned the environment. They haven't learned really true software development. They're not really problem solvers, they're not really developers as much as, like I said, configurators. They go in, they configure stuff, they can set some properties and things like that, but they haven't done a lot of actual programming and understanding logic and flows and databases and all the different things that are, all the facets that add up to software development. So you have to have the right team. I think that's the, maybe like I said, that's I think the biggest negative. The other thing with Agile is, and it's sort of related to this, is that it has to be, it goes back to sort of the team thing. There has to be buy-in. If you have a team that is, I would call it anti-Agile, or not comfortable with it, or they don't really believe in it, and they're not really driven to or motivated to follow the guiding principles, then I think you'll see things will fall apart. You can't, I almost want to say you can't halfway do Agile. You have to, to really get the benefit out of it, you need to embrace all of the principles and how it works and what its approach to software development and what it puts in place for us. But if you can pick and choose a little bit, but that's part of, I see that as sort of pick and choosing, we're going to get better at this thing right now, but we're going to come back around and get better at something else. More importantly is if the team doesn't buy into that, if they're not willing to do the right things to address some of these principles, then you're going to end up having huge gaps. For example, part of doing, grabbing a task and doing work during a sprint is clarifying requirements and designing what you're going to do. There's an implied document as you go of some sort. There needs to be some sort of notes or comments or something that basically say, here's what I'm doing. You don't have to, but it is definitely something that you, if you don't do it, then documentation may be non-existent by the time you're done. If you're not really a designer, if you just jump in and start coding, then you may end up with some really nasty stuff when you get around to trying to actually organize and gather all these disparate parts together, whether it's for a sprint or maybe further down the line. If you don't have a plan how you do it, you may do several sprints without really integrating all the pieces. Then you come to a sprint where you do sort of an integration sprint and nothing integrates because nobody really designed or documented things in a way that allowed the team to work as a team, to design as a team. If you don't have members, and it does go a little bit to their, speaks a little bit to their experience and to their work ethic and drive and things like that, but really just in general, if they've got a different method or process that they use and they decide to go to that as opposed to embracing what the team has decided to do for how they're embracing agile and sprints, then you're going to have struggles. You can think about it in simple things like the daily standup. If people aren't contributing to it or if they come in there and it takes them forever to get through their standup portion, then it impacts everybody. If they get to the review and they essentially refuse or do a really poor job or just don't want to put the time in to be able to handle their portion of the review, then it's going to reflect negatively on everybody. If they don't participate in the retrospective, then their value as a team member is zero during that time. They're not contributing. They need to be and say, okay, this is important. We're going to work on this. I'm going to come in and I'm going to talk about what I've seen that's good and what I've seen that needs more work. You can think about it in a, that would be something like, I think about grade school, sometimes when a teacher will ask a question and nobody raises a hand. Everybody's just silent and just stare straight ahead. In those situations, if we get that in a retrospective where you sit down and you say, okay, what did we do well? And everybody's silent. Okay, well, what needs more improvement? You can hear a pin drop. Then that's not going to get you what you need. So you need a team, not just some members, but really each of the members needs to buy in. they become a weak link and that can quickly become a major issue in really definitely in getting the most out of agile and the agile approach. But it can, sometimes it can be weak enough that it actually cripples your approach and there would be something better. And so that being said, that is, I think one thing I want to throw out there that is an is to try to find ways to, we'll call it agile eyes, your current processes. If you're not used to agile, if you have different ways of approaching stuff and you want to essentially dip a toe in, then maybe you can take one or two little things out of agile and try to incorporate it into what you're doing to build the habits and to exercise those skills. And then maybe pick a little more later and a little more later to get to the point where you do build a team that does have the skills it needs. And that's not just the agile things like being able to do retrospectives and reviews, but it's also the technical things. So maybe you've got a team that's a lot of entry level coders. You want to get them to sprints and scrum, but they don't have the skill set to really do that yet. Or you don't have the skill mix maybe even to do that. Then push them to bring them in and get them designing and gathering requirements, involve them in more parts of the software development process so they've been exposed to it so they're more comfortable with it when that becomes part and parcel to what they do every day. That's a negative of agile in a sense is that it expects you as a dev team member to be part of everything, all of the software development and gathering requirements, design, implementation, testing, deploying. You can have specialists, but I think everybody in a well-functioning agile team, everybody has some knowledge of all of those pieces. And they're able to speak the language and interact and understand the weights and the costs and the return on investment involved in all those various steps. Because there's prioritization, there is task selection, there is technical debt, there are all these things that the team needs to have enough of an understanding to be able to select what is it that they do next, what is important, and what can wait until later. So bottom line, you've got to have the right team to do agile, which is if you've got a great team, it's a huge plus to go the agile route. You're really unleashing the power of the skill set of the team members. But if the team doesn't have, if the members don't have a lot of skills, they don't have a lot of experience, then your agile is not going to be, it's only as good as their skill set. They're not going to be able to magically make them do that. And like I said, there's an entry level of skill set that they just may not be able to do it because they just, you don't have enough team members that have a high enough level of experience and technical skills to get the job done right. Challenge of the week. Where's your team at? Are you in a team that is well suited to agile, that's got some really talented, experienced individuals and this thing just really lets them shine? Or is it something where it's highlighting the flaws where you've got team members that just they don't have the skill or the experience yet and it's really highlighting the weaknesses of the team members. And from there, I think it's one of those knowing is half the battle kind of things. So once you figure that out, then maybe that's it's time to make some adjustments or maybe you've made all the adjustments you need and this is you're perfectly suited to move forward. But however it is, I'm going to let you go. So go out there and go forward and having a great day, a great week, and we will talk to you next time. Thank you for listening to Building Better Developers, the developer in your 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 developerneur.com. Just a step forward a day is still progress. So let's keep moving forward together. There are two things I want to mention to help you get a little further along in your embracing of the content of Developineur. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developineur site. You can also find it on Amazon, search for Rob Brodhead or Source Code of Happiness. You can get it on Kindle. If you're an Amazon Prime member, you can read it free. A lot of good information there. That'll be a lot easier than trying to dig through all of our past blog posts. The other thing is our mastermind slash mentor group. We meet roughly every other week and this is an opportunity to meet with some other people from a lot of different areas of IT. We have a presentation every time. We talk about some cool tools and features and things that we've come across, things that we've learned, things that you can use to advance your career today. Just shoot us an email at info at developerneur.com if you would like more information. Now go out there and have yourself a great one.