8.5 Use Agile in practice - Video Tutorials & Practice Problems

<v ->How does Agile actually work in practice?</v> Well, like anything else, the opportunities for Agile to improve product and project delivery is massive. If you think about and reflect on some of the things I've said and think about reflecting on engaging users, shortening down the project into little increments, bite sized chunks that we bite off and each step of the way we do that, we then look around to make sure everything is still good before moving on, that there's a lot of value here, but there's some keys in order to make Agile work. There's some keys to its success. One key for Agile success is the use of cross-functional teams. Now, I can say that objectively and you can hear me say that and some of you perhaps are nodding your head or you're hearing me objectively. But in reality, if you or I think about this in some detail, we realize that this is actually a more challenging concept than we give it credit for, the appreciation of multiple perspectives. You see, if I'm working in an organization in a specific functional area, like for example, marketing or in the software side, or in some industrial application side as an engineer, or something like that, the point is I go into an organization, and we know from research and our own personal experience, that very quickly we become siloed. We start thinking in a certain way, our interactions generally are with people around us of a similar mindset, we start talking in our own language. In fact, that's kind of the irony, isn't it? That engineers have their own acronyms and their own terminology and marketers have their own acronyms and their own terminology and software people have their, you get the idea, everybody's got their own personal language within that organization. And very quickly, in some companies, it becomes actually increasingly difficult to engage with these other groups because we hold them either in suspicion, well, they don't really understand what we do, or in some cases, hostility, you know, every time we try and get something done, those guys do something else, you get the idea. We think about cross-functional situations a lot of times more suspiciously than perhaps we give ourselves credit for. I know this because I've done a lot of research on cross-functional teams and I know that there is some residual underlying concern for people working with people on other sides of the fence. In order though, for Agile to work, we have to recognize that it's these cross-functional teams that give us our maximum advantage. Because when we're trying to talk to a user and understand what a user needs as if I'm a marketing person, I have one perspective, but I don't understand the technology. If I'm an engineer, I have one perspective but I don't understand commercial application, et cetera. Everybody's got their perspective, their expertise, but what we often lack is an appreciation of what other people bring to the table. And for Agile to work, we have to develop this appreciation for the quality of a cross-functional team. And appreciation is a very important word because it simply says, I acknowledge that you bring something of value and expertise to the table and us jointly can create something more powerful. The second key for Agile success is we have to give team members the empowerment to do their job successfully. I used to joke that the mushroom principle of management, some of you have heard this story before, that there's certain project managers who apply the mushroom principle of project management. They keep everybody in the dark and they feed 'em a steady diet of manure. In other words, just the way you grow mushrooms is the way you treat your people. You don't tell them anything, you keep them in the dark, and feed 'em a steady diet of manure. Mushroom management doesn't work here, because as you can see, the whole idea of empowered team members is to make sure that everybody maintains enthusiasm, everybody's willing to make the changes necessary, everybody's engaged with the user and with each other. And that only happens when we give them the power to make decisions at their own level as opposed to kicking everything up and keeping them in the dark. Shared accountability is a key for Agile success. Shared accountability means fixing the problems rather than spending your time fixing the blame. When things go wrong, it's not pointing fingers out there to see who I can finger for the blame, it's recognizing that we jointly share ownership of this project, therefore, we jointly share ownership of the problems, just as well as the successes. And so when we share accountability, we're looking to find ways that you and I mutually can fix the problem. The fourth key, I cannot emphasize this point enough folks, so I know I buried it in here, it's the fourth bullet point, but I really wanna pull this one out because I want us to hear what I'm saying, please. The user determines the success of the project The user. The point of this idea of user determining success is that rather than assuming the old traditional models where project success is the schedule, achievements, or the budget or some other way that we think of project success, we now are throwing that determination into the lap of the user. So if I could go back to the example I gave before as a software applications team, when I go into the hospital admissions department, and I present those folks who are doing admissions with a new screen or a new set of screens for how they register patients they look at it and they give me either a thumbs up, a thumb sideways, eh, or a thumb down, that's the determination of success. Not what I did behind their back or in some corner of the room, but their determination. Users determine whether that project succeeds or not, not me. Agile is difficult because it requires a different kind of leadership model. If you think about Scrum Masters and if you think about product ownership and if you think about traditional project management you recognize that we're pushing more and more authority and responsibility lower down onto members of the project team rather than us simply controlling everything way up here someplace, okay? This is not waterfall. So we don't lock in early, we don't direct the activities of others, so much as we facilitate their activities. The term we use here is servant leadership. Servant leadership simply means that to lead a project here involves providing the resources necessary to allow my team to succeed. I'm doing what I can to make sure that they have the ability, the technical resources, the human resources, the time, the energy, et cetera, to make this happen. That's my job here. It's not to be this former directive project manager It's to be part of the team and letting them shine. Another key to project success in Agile is the continuous flow of value. What I mean by this is our goal is to keep moving forward, just like playing rugby, the goal is ultimately to cross the finish line with the ball. Along the way, there will be a lot of times that we come together in a scrum, pushing and shoving and moving around, but the scrum has a purpose, the plays have a purpose. All of this has a purpose of moving us inexorably further downfield ultimately to score. Likewise, this continuous flow of value here, through scrum, through the sprints, and the reviews, to make sure everything's working, is all about moving us forward. Another key for Agile to work, notice this idea of early feedback and adaptation. Two things. Early feedback means keeping everybody informed. How's it going? Make sure that we're moving in the right direction. And when we start getting warning signs that we're moving off course, that we're changing, either some external change, the user has some new need that they're just informing us of, or something has changed in the marketplace in general, we adapt to it. So we move to a sprint point, we finish the time box, we look at the field around us, and see do changes need to be made here necessarily? And if the answer is yes, we make sure to make the necessary changes. We mark out what has to be done for the next sprint. You see here, the old idea of git 'er done isn't correct anymore. It's git 'er right, that's where value comes in, is making sure that the final product we create is what is needed. Not getting it done fast, but getting it done right. Now, there's a problem that some of you are probably thinking of at this point, and I wanna address it head on. 'Cause some of you're thinking, the problem with Agile the way you're describing it is, it seems like there's a lot of opportunity here for change, for us getting to a certain point and being told, no, that's not right, we want you to do this now, or we want you to change this or this. Basically, what you're telling me here sounds like a situation where there could be a potential for a lot of rework. The answer to that question is you're absolutely right, agile does allow for rework, Agile encourages rework. But here's the point, I've studied rework in construction projects and in new product development projects and in a lot of situations, I've looked at rework, and the causes of rework, and the implications of rework on projects and project teams over the years, and I've found some really interesting points about rework. The longer you wait before you conduct the rework, the more expensive it is going to be. That makes sense, right? If you finish building a building and then you go back at that point and you see what has to be reworked that may involve tearing things out, reconfiguring all sorts of things to get it correct this time, that's expensive. However, with Agile, rework is not only expected, but in many cases it may be required. But the kicker, the important point is, it's okay, because remember, those sprints are finite chunks of time. We're not just simply developing the project like waterfall. Imagine if we were in a situation with waterfall where we waited until the very end of the process, when we turned this over to the end user and they said, that's not what I want. And now think how far back we have to cycle to get it right and how much time may be have been wasted, and more time has to be spent to do it correctly. That's expensive rework. But if we're doing rework, on the basis of those incremental sprints, those finite time boxes, then rework is not necessarily our enemy, rework can actually be a friend, because rework allows us to continue to adjust, to continue to be Agile and shift and be responsive to the end user as their concerns arise or as new needs come up. So is rework going to happen? Absolutely. Is rework work a bad thing? Not at all. Rework allows us to make sure that we're getting it right, not just getting it done. The other key is being transparent. I can't tell you how many times I've worked with companies that have problems, that are failing in their project management for relatively simple reasons. One reason that pops up again and again, folks, in failing project organizations, is that they look at the customer in a competitive, antagonistic way. The customer is paying the bills, yeah, but all they are is a roadblock. They basically just get in our way. They just challenge us. They don't allow us to make progress. They're continuously on the phone complaining. They're this, they're that, they're the other thing. So their whole focus on the customer is somebody who pays the bills and someone we have to do this for. But we would really, really prefer to keep them at arms length for as long as possible. We don't want them engaged more than they have to be. Why? Because every time they talk to us, they disrupt what we're trying to do. Well, what does that tell you? If this is your relationship and they're quote, disrupting you, it's because you don't understand how you're supposed to interact with them. And Agile is all about the customer is part of the team. The customer is not a roadblock. The customer is the person who's keeping us honest. The customer is the check or balance that we need to make this happen. So one of the final keys for project success here, is recognizing the customer for what they are which is a valued member of the project team, not a roadblock, not a pain in our rear end, not somebody who's constantly picking at us, but somebody who's keeping us on track for what we're attempting to do. Well, you've heard me talking about the process of Agile, the advantages of Agile, and some of the keys to making Agile work successfully in your organization. But it's also appropriate to give you a balanced view. And I do this on purpose because I know for many of us we listen to me and we say, okay, but what's the catch? It sounds like everything you're saying is almost too good to be true. Or you know, in my own brain, I start formulating objections because I listen to you and I think of my own organization and how we do things and certain things that you're saying I'm not too sure about or I have some reservations about them and that's fair. And in fact, I would expect that that would be the case. Because what I'm talking about here is for many organizations, is a radical re-adjustment from the way they're currently running projects. This is not a minor tweak, let me be clear, this is not a minor adjustment to how we normally run projects. Agile flows completely different than waterfall project management. And for many of you that use waterfall even if it's not appropriate for the way your projects are currently running, even if you're experiencing high failure rates right now, and even if your top management knows that rework is a problem, but we factor that in because that's just part of the nature of our business, even if we have those things in mind, we still have to recognize that Agile does bring a lot to the table with some provisos.