The Agile Manifesto: Principles for Self-Organizing Teams

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. Basically at this point, we're looking at the principles, walking our way through the Twelve Principles and looking at how they are going to deep dive into those basically and how they can apply to us now, how maybe things have changed over the years and how we can take them moving forward as a way to build better software. We are all the way up to the Eleventh Principle. After this, we got one more. So the Eleventh Principle is, quote, the best architectures, requirements, and designs emerge from self-organizing teams, end quote. This is an interesting principle. This is something that I have used in other areas quite a bit to a good deal of success and consider it the secret sauce of being a manager or a good leader or coach or whatever that role title happens to be. It's very interesting that they address it this way and also makes sense when you start looking at things like Scrum and some of these agile approaches. We don't have what would be essentially traditional titles and roles. The functions still get done. So you'll have somebody that does database design or writes code or tests things, but you don't have people pigeonholed, I guess, into that area. So the interesting thing here is it says from start to finish, because we're talking the best architectures, the best requirements, the best designs, all of those emerge from self-organizing teams. So when you let the team do their jobs and figure out how to get the job done best amongst themselves, that tends to be the way to go. What you're doing there is you're taking the shackles off. This is, again, something that we've visited this many times as we talk about agile. It really is, I think, one of the core tenets, basically, of agile, of that approach. We cut people loose, we cut the red tape, we get as many things as we can out of their way and let them go. It's the idea of when people would ride horses and they'd give the horse its head, where you basically would just let go of the reins and let the horse just go. So it didn't have to worry about having the bit in its teeth or any of that kind of stuff. And I'm not a master horseman, so apologies if any of this is incorrect. But essentially, then the horse could just go. It didn't have to worry about anything else. Nothing would possibly slow it down. Nothing. You'd just get the distractions out of the way and you'd go. And that's what agile is about. An interesting little twist, I guess, that they take in this principle is they don't even – at this point, they're basically saying, we don't really need to have somebody manage or assign out or design the team. Let the team do it. And there's a lot to be said for that. If you put people in a situation where they just have to solve a problem, then people tend to sort of step up in the areas that they can contribute and will back down where somebody else has that strength. So that they bring their strengths to the table and they leave their weaknesses for somebody else to address. And although I haven't seen a lot of information about it, it's mostly anecdotal, but the people I've talked to that have done these escape games and stuff like that where you're locked with a group in a room and you've got to figure out how to get out in a certain amount of time, things like that. People tend to sort of fall into roles that are natural to them. And if you've got the right mix in the group, then that usually works out well because you've got somebody to sort of move the team forward. You've got some thinkers or problem solvers. You maybe got a couple people that are just very good at observing. You let the team sort of do what it needs to do. And this goes back to way back. A story I may have shared before, I probably did, or at least if not here in the book, but it's a good example like this. We had a team that went to our high school many, many moons ago. We had a programming team that would go and do a, I think it was a city, county-wide, something like that, programming contest where you'd face off against all of the other or a lot of other high schools around. And we went one year and we had four very good programmers. It was a four-person team. We had four very good programmers. And I think maybe we came in second or third or something like that. But basically what happened is we got done and we realized we had a lot of solutions on the table. We had things that we had sort of figured them out on paper, but we just were not able to get them entered into the computer. And so as a team, we got together, those that I think one graduated or something like that, I can't remember why, but basically there was a couple of us that were going to be on the team the next time and we talked about the makeup of the team. And we ended up swapping out one of the quote, programming roles for somebody that could just type really fast. And she had enough technical knowledge that we could throw code at her and she could type and crank the stuff out and we could get the programs entered in and then sent off for the validation or the scoring of them. And we won, I want to say by a pretty good margin. because the team organized for where our strengths and weaknesses were. We realized that we were, for lack of a better term, overburdened with programmers or problem solvers and we didn't have somebody that could actually implement basically. You had too many designers and not enough implementers, too many chiefs and not enough Indians or something like that. And which is a good example, we see this in many, many, many areas. Way outside of software this exists. You've heard probably the idea of a top heavy organization or the phrase too many chiefs, not enough Indians, too many people that are senior level or even more than senior level that are basically decision makers and leaders in their own right and not enough people to lead. It would be sort of the, I guess, the closest analogy to that. And we'll see where those organizations struggle at times. And it's just human nature to one degree because you just have people that they're going to lean on their strengths and if you have gaps and you have, gaps are hard enough in skills. So somebody has to step up in that situation and fill in the hole, fill in the gap. And of course, they're not going to be as good because it's not a strength. But if you have multiple people that have strengths that overlap and somebody's being asked to essentially step away from their strength to go utilize their weakness to help the team, then you also have maybe potentially morale and other issues that come up because that person is not going to be happy. If you're really good at whatever it is you do and think of something that, you know, just completely unrelated to software, if you're really good at making pizza and there's a couple other people on your team that are really good at making pizza and you get asked to set the tables for the guests, you're going to be feeling appreciated. You're going to say, wait a minute, I'm really good at making pizza. Why are they making the pizza and I'm putting the silverware out? And it's not even, you know, I guess in that case you may think of it as being a lesser job or something like that, but it's more about, it's not what you, it's not your strength. It's not what you feel that you are there for. It's not that you are able to, you're not in a situation where you're able to give to the team what you think you are best at giving to the team. And so this more than, you know, this is more than like the manager asking people what do they like to do and what are their strengths and what are their weaknesses because that doesn't always get the right answers or the truthful answers for a bunch of reasons. Maybe people don't want to highlight where their skills are or aren't. Maybe they don't want to admit that they've got weaknesses. Maybe there's something intimidating about how the manager asks it where they, you know, they're worried that they don't give the right answer. They're going to get demoted or fired or something like that. It's not just a matter of making it a safe space for them. Sometimes it's just, we have blind spots. But when you put everybody together in a team and say, all right, it's up to you to get this thing across the finish line, then you have a, almost like a form of peer pressure essentially that comes into play, particularly with the team that's worked together before where they will, they will push the people with certain strengths to utilize those strengths. Even people that have a similar strength, but it's maybe not as strong, maybe it's a secondary kind of thing, then they'll back down and say, you know, we want to get this done so let's let the person that is the best or the fastest step into that role. Good example I've actually run into just recently, WorkWise, that you probably have seen something similar. I've got a situation where we're working through a, there's a problem ticket. There's a bug in a system. That's not a bug. I guess it's a work request that's come through for the system. And I can do it, but based on my experience and knowledge of that, there's a particular one person and there are probably a couple of people that can do it better than me. They know the system better. They understand the process better. There's nothing, it's not a negative to me to say, you know, I'm not as good as they are at doing it or as fast as they are. And because this is something that has got, you know, sort of been bumped up in priority, then the next time I go to work, then I'm going to sit down and I'm going to be talking to that person that is the, you know, the number one resource for it. And now it also happens that, you know, being in that situation, he's pulled in many directions. So you have to balance that stuff out. But that's where the team in self organizing can actually help quite a bit because you'll have people that you maybe are a second tier provider of certain skills. Maybe you've got your A team and you're, you got some, you know, let's say an A player in one area, let's say design, and you've got this B player in the area of design, but there's also as maybe, you know, a B player in implementation. And maybe they step up for a while in design to help out, to take a couple things off the plate of that A player. And then they've, you know, can focus back on implementation another time. It's, it's not quite the same as everybody pulling in the same direction, generally speaking, because when you allow the team to self organize, they end up pulling in the same direction because they want to. That because of the why. It's not because they're whipped into shape or into position or something like that. This is the team deciding this is what we need to do. And it's, it's even more than that because sometimes when you drive a team, you're going to drive them in a direction. You being the, the leader, you know, the manager, whatever that role is. Sometimes when you drive the team, you're not driving them in the same direction. They would go even to get to the same objective because sometimes you don't understand all of the nuances of how their skills interact and where their strengths and weaknesses are. And this is something you'll see in sports where you'll see in particular American football and because it's because it has such a strategic approach, but even you'll see it in global football and soccer. You'll see it in basketball. You see it in hockey. You'll see it in a lot of different team sports where there's a, the coach has a, an approach. They have a method. They have a system maybe that they drive, that they use. And they've, their goal is to find players that fit the system. And then they plug the players into the needed spots. And then if they've got the best players to do, to run that system, then you have a great team and you, you can see in just about every sport. You can see situations where there's a player that is really, really good for one coach in one system and they're not in another because there's a different aspect of their skills that are being used. That's exactly what's being pointed out in this principle is that if you have a leader, they want, you want to call them, that is pushing the team into a system. It's not going to be as good as the team figuring out the system that works for it and then driving forward. It definitely has an aspect of ownership that we, we take a greater ownership over the things that we have created. If you have a manager that dictates to you how things should work, you're not going to have the same investment, the same buy-in as you do if you, as your team, if your team puts together the approach and says, this is what we're going to do. This is how we're going to do it. Let's go. So this is a neat little split principle, partially with the team taking ownership, but partially getting things like a manager or coach or some of that administrative role, more or less really almost removing it, that's saying that that's not necessary. You don't have to have somebody that's pushing everybody in the same direction and trying to organize and sign them out, stuff like that. I mean, there's still part of that required. There is almost like a sanity check or something. You need to have somebody that their job is to keep an eye out for where the team's going and remove obstacles. If the team's about to go over a cliff, say, hey, we need to turn. But it's almost a micromanaging kind of thing. It doesn't need to have that micromanagement. If you get into the micromanagement level, then you're not agile for many, many reasons. But this principle does take it a step further. They say the best, not good, the best architectures, requirements, and designs emerge from self-organizing teams, which in itself is quite a leap and pretty impressive when you consider that there's, I don't know, the people who put this together had probably combined hundreds of years of experience in developing software, dozens of projects, big and small. And this has lasted the test of time for a couple of decades. And by the time you hear it, maybe three or four decades. But this is a bold principle. I think of all of them we've talked about, this may be, although it's hidden towards the end of the list, the boldest statement and the biggest veering away from how software was designed. And even to some extent how it is today, there's still agile teams that have, where people are pretty much placed in certain holes. They've got certain skills that are needed and people get plugged in. And then they're just assigned to go do their thing. They may have a Kanban board or something, a list of tasks, but you may have 20 tasks and five team members, but you know from the start who's going to do what. Because the team's not organizing themselves, the teams have already been organized and the tasks are effectively being assigned out. And so they go do their thing. That's not to say that you can't be successful that way with strong management, things like that. But this puts a lot of faith in the team itself and asks the leadership to do so as well. And this is not just the implementation team. This as we've talked about before, this is everybody. This is the customers, the business owners, the stakeholders, the implementers, the designers, all of that. Everybody that's involved. If you allow those teams to self-organize, you're going to get the best architectures, requirements, and designs. That's what they're stating. And although I personally am probably still on the fence about that, I'm not sure. That the best is quite a statement. So I don't know if I can back that 100%. But I think they're on the right track. And I have definitely seen teams that have been given the freedom to organize, to self-organize, to figure out how they want to get stuff done and to go do it. And then to help essentially, like I said, is get obstacles out of the way and help equip them to take the approach that they as a team decide on. And in sports, I know of championship teams that came out of this, where they were allowed to do the things and assign things and figure stuff out for themselves, take the team, figure out how they best work together, and then just go execute. And they did it like champions. I've seen software teams that are given a lot of leeway, a lot of freedom to do this, and seen them pull off some really incredible stuff. So even though maybe the best seems like hyperbole, I think this is something that is very worthwhile for you to consider, particularly if you go into any sort of lead or management role. avoid pigeonholing others or dictating stuff without allowing the team to sort of massage the approach, to self-organize and go the direction and take the path that they want to take. And that being said, I'm going to allow you to, I'm going to give you all the freedom in the world to go do whatever it is you want to do today, however you want to do it. But no matter which way you choose, make sure that 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 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 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 developernoor.com. If you would like more information, now go out there and have yourself a great one.