The Agile Manifesto, Agile Processes, and Scrum

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. We're talking about the Agile manifesto, Agile processes. We've really covered to this point the Agile manifesto. We've talked about the 12 principles they lay out, the eight, we value this better than over this items. I think it's worth it as part of discussing that is talk a little bit about where it has gone. Some other things that are usually tied to this, correctly or incorrectly, and we're going to lean towards mostly correctly. And we're going to talk about some things, some ways, some processes, some frameworks that we can use to implement Agile, to turn it into something other than a thought process. This episode, I want to focus on Scrum. Now, Scrum is often used as an Agile approach, a framework for it, but it actually, essentially, was created way, way, way before the Agile manifesto was put together. The Agile manifesto came out around 2000, and actually Scrum was first posed as a software process in 1995. And then the first book on Scrum was actually published right after the Agile manifesto, basically in 2001. And it has become probably the most recognizable approach to using, to implementing Agile or to as an Agile approach to software development. And I want to talk about the team and the roles first. And that's really the focus for this episode is what are the roles and how do they fit? How do they interact within a Scrum team? And this is using the, more or less, the official Scrum process. Every group that I've dealt with, everybody that I've talked to, they put their own touch on how to approach it. And that is more or less by design. I think Scrum is a framework. It's not something that is hard and fast. It's not something that you have to stick to. It's not something where you have to follow all the rules and the labels and the approaches. It's not rigid. It's very loose in its approach in order to allow you to adjust to your situation, your team, and even the product that you're building. These are, I hesitate to say even best practices, but I think these are things, these are more like underlying requirements. Even though you do not label them necessarily as such, there's certain things that have to be done. There's certain responsibilities and certain roles to some extent that have to exist, even if they're not individually labeled as such. And that's what we're going to talk about this episode. The first one, without further ado, is the product owner. Now, at some point, every product, I think it's understandable that there has to be a product owner. There has to be somebody that's, or by somebody, it could be a group, that is responsible for the vision of the product, driving the product forward, making sure that the solution that's being built is moving towards the solution that we, the customer, wanted to build. Somebody needs to have it, or some group needs to have it as part of their job responsibility to satisfy the customer. Otherwise it's going to be easy for that to get lost in the shuffle. Your role helps determine what your focus is, what you're measuring, what you're aiming for, what you are pushing the team to do. And so we've got to have somebody or some group that their role, their focus, their job is to make the product successful, to make the product satisfy the customer. And so the product owner is that person or group. Now typically, and my personal bias, I guess, towards this is that it is an individual, that the product owner is a single person that is the representative of the customer or the customer that is the speaking representative. So you're usually going to have more than one customer or more than one user, but this is somebody that understands the situation, that understands the problem, that understands the goals of the solution, and is there to help direct work and discussions and even decisions so that the product that we as a collective group set out to build gets built, that the solution that we set out to create actually gets created. And so this person, I'm just going to say person going forward just to avoid constantly saying or group, this person is responsible for the vision of that product. They see what that product needs to be. Like I say, they really understand the problem, which is probably one of the most critical things is they really understand the problem and how it needs to be solved, I guess. What are the requirements? What are the constraints? What are the various things that affect how you create a solution and measure it against success? And so that means the product owner is helping to drive the feature set. Now in Scrum, I probably should back up a little because there's an assumption. In Scrum, you do sprints. You do regular pushes to deliver some amount of work. And these sprints may be typically there are two to five or six weeks per sprint. I think more often than not, it should get closer to the middle. So a lot of them are three to four weeks. It can be shorter, it can be longer, but you have to be able to fit a reasonable amount of work in. You want to be able to get a deployment done each time, things like that. And we're going to talk a little bit more about sprints in future episodes. At this point though, we're looking at the team members. So I just want to give you a rough idea that one of the things we do in sprint is that we have a backlog of tasks to do. We've got things we've got to do. And we say, OK, in this period of time, this sprint, we're going to get these tasks accomplished. And so we lay those tasks out, put them up on a board and say, all right, this is what we're going to focus on. And we start, we pull stuff off the board, do it, and then we're done with the sprint. We move on to the next one. So the product owner is the one that says essentially in or out. They're building that backlog. They're saying, yes, this is a task we need to do or it's not. Now, that doesn't mean that the product owner has to be technical because there may be tasks that are very technical. But that's where there's going to be communication with the product owner and the team to say that, OK, yes, this is something we need to do as part of building out the foundation for our product or to allow us to address these other features that we know we want to have in the product. But particularly as you get closer to the actual features and implementing those as part of that backlog, the product owner is the one that's going to say, yes, that feature needs to be in or no, it doesn't. They're also going to be able to provide prioritization and say this feature is more important. So if you can get them both, great. But if one has to go, this is the one that has to go. And then also adjusting to change. So if there's one feature that we can't implement the way we want it to, what's the workaround? And so the product owner would help to say, yes, that's a valid workaround or no, it's not. Those features you're adding into the backlog will suffice for what we need or they won't and we need to go design a better solution or find a different workaround. So that's the product owner. They are responsible for the product vision and making sure that we deliver value, that we satisfy the customer. The next role is the scrum master. Now, this is the person that is responsible for making sure that the team, the scrum team and the sprints work as well as possible or as efficient as possible. So in doing so, they are going to coach the team. Basically as a coach, they're going to talk to the team, whether that's the product owner or the development members, the dev team. The scrum master is working with them to help them do a better job, to help them help themselves. Now, one of the ways they do that is to help them understand how the sprints work and how things need to be filtered through, how they need to go through design and implementation and testing and deployment and how communication needs to be done, try to keep meetings on track and then they also just generally are looking for ways to remove obstacles for the dev team and the product owner so that they can be as efficient as possible. The goal of the scrum master is, the term is velocity. They want to be able to produce as much work per sprint as they can. This is an ongoing challenge or calling or goal because each sprint you're going to be, and particularly the early ones, you're not going to do them that well. But that's what the scrum master does. They're going to look at the sprints, they're going to see what did we do right, what did we do wrong, how do we do more right and less wrong. And that's where they're going to turn around and they're going to coach the team. They're going to say, hey, here's some things that we can do better. Here's some things we can adjust. And it's the, so they don't, they don't drive the solution, but they do drive the process. So where product owner will help, will focus on building out the backlog and prioritizing the tasks to get done. The scrum master is sort of observing how the product owner and the dev team interact and how the backlog is being built and things like that. And we'll say, you know, we can do, how about we do this or how about we approach that? And that may include working with the product owner to, to, to groom the backlog or to, you know, to move things from the backlog into tasks that are done in a way that makes it more efficient to get those tasks done. A good example would be tasks that are similar. A product owner may or may not understand what, what tasks are natural pairs because of the, maybe the section of code you're working on or the mindset of developer while they're, while they're creating that, while they're solving that problem, the scrum master's there is to help say, hey, you know, let's, let's do it this way. We're going to focus on this section of the product for a little bit. And then we're going to focus on that section and do that in a way that allows the, a little more, a little less cost of switching gears, mentally switching gears for the dev dev, dev team, the development team. So it's things like that, that the scrum master is going to be sensitive to. And then they're also going to be looking at how are, how are things recorded, how are things communicated? So they're going to make sure that the dev team doesn't do any duplication of efforts, that the product owner understands what some of the goals are and where do we want to end up and how do we want to approach this and how do these, these things interrelate as far as the work that we're doing. And then there's things like, you know, meetings and things like that, trying to make sure that they're efficient. Another one is prerequisites. I think that's a lot of what you'll find with a good scrum master is they can, they get a sense for or understand where certain tasks need to be done in a certain order. And they find ways so that the dev team is always productive and they find ways to avoid issues where you've got a, you know, maybe a member or members of the dev team that are essentially waiting for another process to get done so they can move forward again. A simple example would be that most work needs to have, let's say especially front end interface work requires several steps. So you're going to sort of figure it out, you know, put together some basic requirements for that interface piece. And then there's some sort of a design and then you want to make sure that, you know, there's a review of the design that the product owner most likely would do to say, yep, that's a good design, that's usable, it's going to be a good user experience. And then there may be some sort of a backend work that needs to be done to make sure that you've got the data stores or the middle tier calls in place and then you can do the front end. So that means for a front end developer, for the front end development piece, you've got all those other steps that need to be completed really before the front end person does any work. And so that's what the scrum master is doing. They're going to look at those kinds of things, those prerequisites, those steps that need to be followed and find ways to layer tasks within each sprint so that they are preparing for some of those tasks that are going to be done in later sprints while also accomplishing some tasks in the current sprint. So your scrum master is your coach. They find a way to get the team to work better. They get things out of the way so that the team can be as efficient as possible. Scrum master is going to be almost always an individual. I don't know that I've ever even come across a situation where there is more than one scrum master. Sometimes there are people that sort of step, multiple people that step into that role, but it tends to be confusing. So the best ones are where there is a scrum master. Even if it's somebody that's not a full time scrum master, I think I've seen situations that sort of like part of their job. They also do some other things as well. For example, they may do some development as well as be the scrum master. But the word of warning is you don't want to take away from that the responsibilities of the scrum master. If they end up serving two masters, working, trying to improve velocity, but also are doing work on it as a dev team member, then it ends up being extra challenging. So now the third group is the dev team. Dev teams are typically recommended as probably about three to nine members. One member, you're just too much serialized. You can't work on multiple things at a time, so it almost doesn't make sense to do a sprint. There's uses for it, but it's not really scrum at that point because scrum requires, the concept of scrum is that you have a team. The concept of scrum comes from rugby where you have everybody working together to try to push the ball forward across the goal line. And so if you don't have a team, then scrum doesn't make sense. You're not a team of one. And typically you want to have more than, really as I said, three or more because then you're allowed to do multiple paths of parallel development. And two is just usually not enough just because of the various tasks that are required for software development. And once you get a larger team, once you get eight, nine, 10 and more members, it just a managerial challenge that require that the product owner and the scrum master are going to be probably overwhelmed. Now product owner can actually sit on, have multiple teams that they work with because they can be coordinating those teams. The scrum master, I guess they could, scrum master could have multiple teams as well. But you want to make sure that you've got enough time that you're able to remove the obstacles for all these different teams and different teams work differently. So you're going to have a very different mindset trying to improve velocity for one team to the next, to the next, to the next. So there's a, it's just an ability for most human beings to manage a certain, it's just a limit. There's a certain number of people that you can directly manage and work with and coach. And that's where that limit comes from. Now the dev team does the implementation. They are the workers for each sprint. They're the ones that are, not that the other product owners and scrum master aren't, but they're the ones that are actually working on accomplishing the tasks that are, that make up the sprint. They are skilled. They have the technical skills needed to deliver the product. And they are, you know, it may seem that the product owner, the scrum master drives what work is done, but it's really the dev team that is the most responsible for that. The scrum master helps the dev team understand how to measure the work that they think they're going to, you know, they estimate that they can accomplish and how to translate that to the product owners. The product owner can get a feel for how fast things can get done. But the dev team is the one that they're going to put together the estimates. They're going to put together the, more or less the plan. In a given sprint, the product owner and the scrum master help define what's in a sprint as far as what's going to be put into a sprint. But that's with feedback and discussion with the dev team to say, you know, it's essentially what do you guys think you can do, guys and gals, just to be correct, I guess. But what do you as a dev team think that you can do looking at these tasks? What makes sense? Then the product owners scrum master sort of push, okay, can we put this in the sprint? Can we put that in the sprint? Where do you get, and maybe it's a focus. So if there's a focus, the product owner says, hey, for this sprint, I really want to work on the front end. I really want to get a couple of screens so we can have something, we can start thinking about the user experience. And so they go to the dev team and the dev team says, okay, well, here's in the backlog, here's some tickets that address this. And maybe here's a good grouping that fits for what we want to get done. And so it's a, they're all a team, product owners, scrum master, dev team, all of these work together to fill out a sprint. Now before I move on and sort of wrap this one up, as far as a dev team is concerned, it is a team. Ideally, the members of the dev team can do all sorts of different types of development. Now some teams have dedicated QA or design or database or various development implementation roles. That's workable because you could have a front end, middle and back tier developer. And so you've essentially got three parallel tracks that are running from sprint to sprint to sprint. But when you do that, that means if that's your three tracks, if for example, the front end person gets done early in a sprint and there aren't backlog items that are front end work because of prerequisites and things like that, then they're stuck. And they're sort of useless to the team until the sprint's done and then some of the other work gets done. If they've got multiple skills and they could shift over and say, oh, I'm done, so I'm going to help the middle tier person. I'm going to take a couple of their tickets and do that. That ability to flex and cross train and utilize team members across a wide variety of tasks is really going to help your velocity because it's going to allow you to do an all hands on deck if something's falling behind and bring extra resources into it from your existing team. You just shift their focus and now they can make up for that thing that's falling behind. So those are the three roles that I wanted to cover as we start going a little bit more into implementing some of these agile things that we've talked about and implementing them in the real world. And we're going to talk more about how these roles and some of the things that we apply. We'll tie these back to some of the principles as we move forward. But the bottom line for this one is there's really three roles in a Scrum team. The product owner, the Scrum master, and then the dev team. So your challenge for the week is what's your team look like? Do you guys use Scrum? And if you do, do you have a well defined or maybe specifically defined product owner? Is there a Scrum master? What does your dev team look like? How is that viewed? Is it as a dev team where you can plug and play different members to different tasks? Or is it a team that has developers that have very specific roles? And then maybe what are some opportunities to make some adjustments to increase the velocity of your team? Once you're thinking about that, as always, 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 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. There are two things I want to mention to help you get a little further along in your embracing of the content of Developer Noor. One is the book, The Source Code of Happiness. You can find links to it on our page out on the Developer Noor 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 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 developernoor.com if you would like more information. Now go out there and have yourself a great one.