Agile Manifesto and Agile Patterns

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're continuing our season where we're looking at the Agile manifesto and essentially all things Agile. And we have talked about scrums, we've talked about sprints, we've talked about any patterns, we have worked our way up to patterns for the Agile process. And we're getting pretty far along in those and we're going to continue today. We're going to start with the swarm pattern. This is a pattern that is, harkens back to the idea of the development team being a team and not a bunch of individuals with specific or siloed, we'll say, skills. You cannot swarm if you do not have a team that has the ability to essentially to come together and focus on a problem. If you've got, for example, a team of three members and one person only knows databases, one only knows front end, one only knows the middle tier, and something goes wrong in the database, it's really going to be limited what you can do if you put everybody working on that database problem because the other two resources just don't have the skill set. So when you're building out a team, you want to have overlapping skill sets where you can. That's going to make a sprint much more effective. It goes back to the idea of the team being an essential piece of whether or not your agile approach is successful or not. This is not necessarily on your initial set of skills. You can, over time, build a better team by looking at cross-training and things like that. Maybe you early on put together some tickets or tasks where you have maybe some pair programming or some sort of mentoring built in so that you can have people that are essentially learning new skills, expanding their ability to help the team, but they're also not thrown to the wolves. They've got somebody that's leading them, mentoring, or that they can lean on to help bring them up to speed in that specific area. Now, depending on your application, this may or may not be, this may be easier or more difficult, and it also runs back to the size of the team. If you've got a team of three developers and you've got a couple of tickets that you're trying to cross-train people on, you can have some very slow, low-velocity sprints. But, if you consider that an investment in the future, then maybe that's going to be okay. Maybe you do a couple of simple things or do bug fixes. Another way that you can learn other areas is maybe you have somebody test an area that's not necessarily their forte. Maybe they'll, you know, by osmosis get some more information and some more knowledge about that area or maybe even that set of technical skills. So we've gone a little bit away from the pattern itself. The swarm pattern is when we have the ability to take essentially all of our resources, focus on an issue, and get it done as quickly as possible. You could also consider this all hands on deck, but the agile approach typically is, I think I've seen it always referred to as swarming, essentially. You get everybody focused on an issue, maybe it's a single meeting. Maybe you bring everybody in and say, okay, I guess you have to bring them in, but you get everybody together in a meeting, realist, in-person or virtual, and say, here's the problem, let's get it solved. We're going to stay here and we're going to get this thing addressed. And it could be a technical solution. It could also be things like maybe a status reporting or estimation. Maybe you're finding that your estimates are really off. And so you say, you know what, let's get everybody together, then we're going to talk about how we're going to get better at estimating our work. Let's look at what's going on and how can we make this better. retrospective, although a retrospective could spawn a swarm session. There's a lot of different uses for it. The key here is, and really the key is to keep this as a, probably as a scrum master and also as a product owner, essentially keeping this in your hip pocket as a sort of a secret weapon. If you've got something that really needs to be dealt with, then you can look to implementing a swarm. This could be, for example, this may be a bug. Maybe you get some sort of bug that comes up that's been dogging people for a while, whoever's working on it for a while. You may have something, it's a special request from the CEO that you say, okay, we've got to drop everything and deal with this. Usually you want the swarm to be something that's already in the sprint. And then it's basically to make sure that we get this done in the sprint. But hey, you could use it for special cases as well when there's some sort of scope creep or something like that that says, okay, we've got to deal with this right away. This is something that's a, maybe it's a blocker for others in the team or external people that we just need to get this blocker out of the way. So again, the effectiveness of swarm is going to really be directly related to how well team can work at cross-functional challenges. Next one I want to talk about is, this one's not a sprint. This one actually, I think, goes outside of agile, even though, but I want to talk about it within the agile concept. And that is a pattern of test-driven development. You can do agile and sprints and scrum without test-driven development. However, when you think about things like utilizing your resources properly, making sure that you don't have, for example, a sort of a blocking issue where you're waiting for stuff to be implemented, and then you get into testing, a way to address that issue and to avoid that, essentially that race condition is to use test-driven development. So you're actually working on building out tests and designing tests while you're maybe, this is actually before you're even doing implementation. Now there is a little bit of a, let's say a column A and a column B, a little bit of, yes, we're going to do this and we're going to also do a slightly different approach that I think works best in the agile world. The way that works is that we start with test-driven development. And this may be a little bit of a backing up here, but when you're looking at the test-driven development pattern, what you're doing is you are actually, essentially before you implement, but after you have requirements, and maybe as part of the design, depending on how you do it, you're actually building out tests. And these tests that you're writing out are the things that are going to be the validation of whatever it is that you implement. So you're saying beforehand, which normally we do, your requirement says, I need the software to do A, B, and C. What test-driven development does is says, okay, you need it to do A, B, and C. That means we will have these tests that will run against the code when it's done that will verify that it can do A, it can do B, and it can do C. Now that allows you to have the QA team and the QA resources involved from the start. They're actually building out tests, and the implementation team can be doing this as well. They're building out tests that are going to be part of validating and essentially saying something is done, is that you've got the test and it has passed those tests. Now these are typically going to be unit test level things because you want to have the tests contained within a ticket. But you can have some system level and integration level testing as well that would be triggered, I guess, essentially that could be run once you've got a couple of those pieces built that are going to be integrated. So that at least gives the implementers, it puts in their mind that, hey, this is something we're going to have to be able to deal with. And it's really important, really valuable actually when you consider things like error messages and exception handling and things like that. Because those tests in that test-driven development piece, you're not only going to do happy path testing, you're going to be setting up situations that say, okay, when this fails, this should happen. When this fails, that should happen. And those things are built from requirements and help drive the implementation because now there's a very specific requirement that the implementer is going to have to address. And I said that this can be sort of a split method. Now you can do test-driven development for unit testing and then come back around so once something is completed, test it as a, and this is where you get into maybe an integration or system test or something along those lines, or even some smoke testing and things. So your test-driven development does not mean that all of your tests are done before you develop. It just means that your development is driven by those tests. Those are the things that your code needs to address. Those are the tests that need to pass. Your code needs to run through and pass in order to be considered done, which covers some of the other things we've talked about, like the idea of what is done. Usually there's going to be some validation or verification steps that are included as part of, should be, should be included as part of a ticket that says that this is what needs to be done. And these are the things that are going to, will be able to use to confirm that it is complete. And so the test-driven development gives you really one step further on that. And it does not have to be strictly, it doesn't have to be an agile thing. It's just a very useful pattern within the agile development life cycle, the agile process. So, I think that that's it for the test-driven development. Let's move on to a couple others. We're going to actually pick up space a little bit because these are some things that are, for the most part, we're not going to go as deeply into. Mostly because we've talked about these to some extent. First one would be pivot. Pivot is a pattern that you'll hear a lot in the agile world. It's spilled out into the business world as well. You'll hear it a lot with startups and stuff where they do something and then they pivot. Pivot is just a changing course. And so this is a pattern that we want to use a lot and we need to use a lot because we are adapting to changes and that may be in requirements or changing environment. This is, remember all the way back, one of the values we get, one of the values we provide as a implementation team, as a dev team, is that we're ability to adapt quickly, adapt to changes and that becomes a competitive advantage. Another one that's changing, at least in the way it looks, and this is why I'm going to move through this quickly, is the idea of colocation. Colocation pattern typically has been done in the past in agile teams because it just makes it easier to communicate. You eliminate emails and phone and stuff like that and the non-real-time nature that some of those can be. Instead have people working in the same room then, and we've talked about this in other areas, you've got sort of like a bullpen. Team members will learn by osmosis. They'll be hearing what's going on. They'll be able to jump in. They'll be able to adjust what they're doing to help other teammates. It's really a great way to learn. The modern approach is starting to change this. You do have things like Slack and Microsoft Teams and tools like that that allow you to virtually feel like you're in the same room. It's not the same, but it may be something that's useful. And particularly as we've grown more able to have remote workers has become something that's starting to be adjusted away from. Refinement is another one that we see a lot, which is similar to really, we see this a lot as a pattern, but it's also, I see it very similar to iterate. The whole purpose of iterating is to refine. We talked about sort of like walk it, you know, like a mortar fire, you sort of like walk it in. Well, this is what we do here. You should try to get a little closer, a little closer, a little closer. That would be your refinement pattern. Another one we've mentioned, but I don't think we've really mentioned this, a pattern is time boxing. And this is where instead of a rough estimate saying we're going to get this done and we think we're going to get it done in X amount of time. This is changing the constraints and saying we are going to work on this for X amount of time and that's it. That's the limit. Once we're done with that, where that's how we consider that task done is that we run out of time. Now we may get stuff done beforehand. We may not, but time boxing is where we say, look, we're, we are not going to spend more than X amount of time and then we're going to get that done. And this, this is used. We talked about that with reviews. We talked about it with retrospectives. You may use it for grooming. There's a lot of different things that you can, a lot of different places where you can use time boxing. Sometimes it's used for, and I think very effectively for, what we'll call research related tasks. This could be bugs and some other things where you really don't, you just don't know. You just don't know what your scope is. You don't really know what all of the pieces are. So you really need to dig into it a little bit to get a better feel for what it is in order to maybe estimate it or decide if it's worth, maybe even if it's worth doing. And so that's where time boxing becomes very valuable. As you say, you know what, we're going to spend some time looking into it, but not too much time. And we're going to find what too much time is by saying, by time boxing it. So this, this becomes a very useful pattern that we'll see a lot. Especially as you get further into sprints and getting comfortable with the agile process. Another one that we haven't really talked about is, which I did want to touch on, is the idea of a trade. We've talked about moving stuff out of scope and we've talked about moving, I really haven't spent much time talking about moving stuff into scope. Typically, and that's because that's typically what happens is you have a sprint that starts getting close to the end and you have some things you say, you know, we're going to push those back to the backlog. We're not even going to, we know we're not going to get to them. So they're going to go back to the backlog. Occasionally, we have mentioned the idea of something that gets put into scope because maybe it's a high priority or a critical bug or something like that. Something that pulls it into the sprint outside of the normal backlog process. I haven't talked about a trade. This is I think not uncommon, particularly for that second situation where you have something that's brought in to scope. Let's say the product owner says, we really, this thing on the backlog has got to be addressed. We need to pull it into the sprint. And so instead of just pulling into the sprint and changing the scope, that's usually when you do a trade. You say, okay, we're going to bring this in and we'll, you know, let's say it's an eight point estimate. So we're going to basically trade out eight points worth of stuff so that we're going to keep the, theoretically keep the size of the sprint the same, but we're swapping out, we're trading one set of work for a different set of work. And that allows us to, it does allow us to be, you know, stay flexible, but also to not overloading a sprint and getting ourselves in a situation where we've just, you know, we agreed, we said we're going to get X done in the sprint and then stuff started to change. And we just piled more stuff in the sprint without making any other changes, thus reducing the odds of success for that sprint. So that's where you get a trade. I think that's more often than not, that's what's going to happen. Like I said, some stuff gets pushed back to the backlog because we just realize it's not going to happen or it's a pivot. You know, it's something that we realize that we don't really need to deal with right now or don't want to deal with at this point or maybe at all. But when you bring something in, it's usually going to be through a trade. So that's, we're going to offset that stuff we bring in by stuff that we're going to push back out of the sprint in order to try to keep the scope level the same. There are plenty of other agile patterns out there. We really don't touch, I guess quickly because we've talked about stories per sprint. I think it's worth it just to mention epics, which are, it's a story of stories. So you will have things that are going to take multiple sprints to deal with. For example, reporting in most applications is going to be, there's going to be a lot of different reporting things that need to be done, particularly with a larger application. So it may take you four or five sprints to get through reporting. And you may have a, let's say you've got a business type application. So maybe you have some account reports that's a sprint. Maybe there's another one of the story is about financial reporting. Another one, it's about administrative reporting. Another one is about end user reporting. Those stories would combine under the reporting epic. And that is where we allow ourselves to tie together bigger chunks of work, which is going to be usually going to be large features and functionality within the application. An epic really should not be, you don't think of the, it is, but it's not the product is not one big epic. I mean, it is, but we don't need to actually define it as that because we already have all of those pieces in place. Epics are probably going to be major pieces of functionality within the application. So you would not have one epic that drives the application. You will probably have multiple epics. So you'll have a series of stuff that you work with and you don't have to, you may have several stories that are shorter sprint stuff. And then maybe a few epics and epics also do not have to, they didn't have to be contiguous. So you may have an epic that has five stories in it and that may not be five sprints in a row. That may be sprint one, sprint eight, nine, sprint 15, 16, something like that. You can split those things out as you need to. But that's the idea of epics. You'll run into that and so on and make sure we at least touch on that. And I guess I do want to, this is not an agile pattern, but one more that I want to bring up and then we'll wrap this part up, the patterns up for agile. And that's the idea of a minimally viable product. We've talked about this a lot when we talk about getting working software on a regular basis, delivering working software on a regular basis. We've talked about outside of the agile world, we've talked about the Pareto principle, the 80-20 rule, where we get that 80% that's probably 20% of the effort. We get that done so we can get something in front of a customer or a product owner or somebody that can review it and help us refine that last 20% and how we really want to focus on getting it over the hump if we need to. Because a minimally viable product doesn't even reach the 80% point. It may be down at 40 or 50%. That's enough for a minimally viable product. And thus, that allows us the ability to have working software. So don't forget these other patterns, we'll call them, in software development that also can apply in the agile world. Which of the week, which of these patterns, we've now covered almost two dozen patterns that we've talked about briefly or not, which of these have you not used that maybe you should take a look at using it? Maybe you should try to implement that in the next sprint, the next couple of weeks, something along those lines. Maybe there's one of these patterns that you're not making use of that would be very valuable, and help you improve velocity, improve productivity, improve quality, or just come together as a better team. Or maybe something like Swarm, it'll allow you to get over that hump that seems to be dogging you quite a bit. And that being said, I hope that you get over whatever humps are dogging you and your day moves on very quickly and nicely. And as always, you 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 Developer Noir 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 developernoir.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 Developer Noir. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noir site. You can also find it on Amazon, search for Rob Rodhead, 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 developernoir.com if you would like more information. Now go out there and have yourself a great one.