8.6 State common problems encountered with Agile - Video Tutorials & Practice Problems

<v ->And so what I'd like to do is,</v> I'd like to talk for a minute about some of the, I'll call them Problems with Agile. Another way to say this is, beware of these issues because these are some concerns or some issues that are going to likely come up in your organization when you shift to Agile methodologies. And you have to anticipate 'em. Don't be blindsided by these ideas. Anticipate them and work them in to your adjustments. For example, Agile is time-intensive for the user. Let me say this again. Users in a lot of organizations are content to let you go away and develop a project for them and only on the back end start pushing buttons or start looking it over or start investigating it and then giving you the bad news, that's not what I want. But you see, that's not what Agile is about. And in fact, that doesn't work here. You can't, if you're the user, we don't let you off the hook. You may like the idea of just talking once and then testing later, but of course that's useless because that feeds us right back into that same old cycle of work, rework, work, rework while we're trying to continue to criticize what you've created for us. No. It's time intensive for users because it requires not simply buy in of the project, but a commitment, a time based commitment through the development of the project. So as you are part of the scrum team user, your voice is heard there. You are part of the sprint reviews. You are part of the sprint retrospective. You are on board every step of the way because you are the reason we're doing this. Your goal is to keep us honest, remember? So the way you keep us honest is by keeping engaged with us. It is time intensive for users. We're unapologetic about that because this is intended for you, this project we're creating, and therefore it's important that you get engaged and that you stay engaged. A second, I call it a problem with Agile. It is a function of Agile is its scope creep is common. We talked about scope creep in one of the earlier lessons on project scope and about the potential for a project scope to continue to metamorphosise, to evolve, to grow, to burgeon out sometimes, to get massive in some cases, to creep. And one of the things we talked about there is, we're trying in a directive approach to minimize scope creep. What you're gonna see with Agile is, scope creep in fact is a common feature. Why? Well think about it. If I'm truly engaged with the user, if I'm truly engaged with my external environment, those other stakeholders out there and they come to me with new information, at some point during the project I have to pivot and I have to adjust and I have to make those corrections midstream. That's why we have the sprints and the finite time boxes. And each one of those time boxes folks is an opportunity for us to address scope creep. But remember, it's not massive scope creep, it's controlled scope creep each step of the way. So you have to get use to a steady series of requested changes. That can drive some of us crazy because we love lock-in. I love to be told, here's what I need from you. And then I can just shut out the world, disappear and go do my thing as long as it takes. But we don't do that here. We are gonna steadily hit you with a list of necessary changes as we perceive them over the course of the project. That's what Agile's about. A third concern; Top management sometimes voices this concern and it goes something like this. If I give you carte blanche to make changes to this project from the beginning to the end, what happens to my initial budget? You know, we created a budget at the beginning of this project folks, remember? We have a cost. We sort of focused in and created a budget for this project. And what you're telling me now is that at best that's just sort of a so-so or a sort of or yeah, it's kind of a template, but don't lock into it. And that is correct because it's very hard at the outset to predict what the final product is going to be. And as a result of that and as a result of scope changes, it may be the case that the final budget line, the cost is going to be different than that original cost. In fact, I would probably venture to say that that's pretty much a sure thing because that early lock-in is not long term lock-in. It only says, here's what we're going to start with based on the user's needs, listening to their stories and developing our original project and starting with our first sprint. This is what we think is gonna happen. But as the project changes and evolves and moves from start to finish, that's gonna change. And with it, it's going to be a much different, much harder price tag to fix on the final product. We have to acknowledge that. That doesn't mean that I'm talking about ballooning costs, that suddenly we're going to throw the budget out the window, but it does mean that we have to be flexible about what the final budget is going to be like relative to the initial budget. Another reason costs go up is because we test every step of the way in new products, in software or other IT application kinds of settings for projects. We're constantly in test mode. We don't wait till the end. I did work with a hardware computer manufacturer some years ago. They made, at the time they were called minicomputers and micros. So they were in a different kind of industry than they are today. But the original development of these folks, what they would do is, they would set up a very standard project Waterfall system and they would do all of these software development, the hardware development et cetera, and all the way down at the end were two things, testing and final documentation. So they did all of the heavy lifting, then they did the testing and finally documented what was going on. Well, you can't do that here because we're not waiting until everything's done before testing. We're testing every step of the way. And so the test is part of each one of those time boxes. There's a part of the burn down chart should include some testing features or activities as part of that specific sprint. We do it every step of the way. We don't wait till the end. This will increase project costs initially, but think how much better it will be than waiting until the very end of the process to present this to a customer only to have them say, "I don't need it. I don't need what you created for me." If I can test it, I can fix those problems. If I wait till the end and there's a bug or there's a problem, or worse, it doesn't fulfill user needs because remember, they determine success, not me. If I wait till the end of the process before I do the testing, I've wasted a lot of time and a lot of money. So the cost will go up, but the testing will ensure viability every step of the way. It can get messy. What I say that is, if you look at the fifth bullet point, I say there's a frequent delivery of project features, okay? We keep going through our backlog. We keep fixing things or we keep creating things. We keep developing project features. Doing that means we're spending a lot of time testing and a lot of time in sign-offs. So we're constantly in this mode, folks. When I say it's messy, I mean there's a lot of activity going on here. You can't wait in Agile system. You can't wait as a member of one part of the organization's project team. You can't wait until someone tosses a finished project over the fence to you and says, now you do your part of it. The value added is continuous amongst ourselves. It's not a series of linear steps of tossing it over the fence to the next person downstream. It's us working as a cross-functional team. And in doing that, I say it's messy because we're constantly interacting and we're constantly creating something and immediately testing it and immediately feeding it back and immediately adjusting all in that one time window, the one sprint, getting it all done there before moving on to the next one. Another issue, Agile project management is not a magic bullet. It's not intended to be a magic bullet. It's not somebody who finally spoke up in 2001 when they created the Agile manifesto and saying, "Aha, I have finally figured out the truth." It's not a be-all end-all, we finally solved our issues. First of all, not every project needs Agile. There's many classes of project out there for which Agile, for which these frequent finite sprints simply aren't necessary or they're not applicable. For example, large scale construction or infrastructure, building a tunnel. We get all the specs done early on. But let's think about it. If I'm building a tunnel, I don't look every three weeks and say, "Is it still heading in the right direction? Should I shift it in this?" You see what I'm saying is, certain types of things like a large office building or infrastructure or whole classes of other projects simply may not require an Agile methodology. So for a company to say, "Aha, let's go Agile," in certain industries is not useful to them. Waterfall for them, maybe a perfectly legitimate project methodology because it doesn't require those kinds of constant adjustments and changes and sprints and scrums and modifications and backlogs, fixes and all these other things. They're not needed. So when I say it's not a miracle cure, another way of saying that is, it's not necessarily useful for all classes of project. There's some classes of project out there that are doing just fine with Waterfall. But ask yourself a question. If you are working for an organization, if you're a member of an organization, and if you're honest with yourself and when I start asking you uncomfortable questions like, tell me your failure rates for your projects right now, tell me about user involvement, do you really talk to the people how much, how often? Tell me about your methodology. When I start quizzing you on things, if the answer to those questions is not positive, if the failure rates are high, if users are really more of a pain in the neck than a partner, if we don't really have a good methodology in place and we've been making mistake after mistake again and again, if any of these things are part of your answer to me, one of the reasons for that may simply be the case that you are not employing the correct methodology, that for your organization, maybe Agile is the way to go. Maybe there is some benefit, some advantage to doing this. Now, the other question that I get asked quite a bit is, does Agile work? And I love that question because these are people who are looking at it and giving it some serious thought and weighing the commitment to shifting to an agile environment. So the obvious question is, does it work? I mean, is it really something or is it just the latest fad? Well, let me answer the second question first. Agile is not a fad. Agile and its offshoots, extreme programming, other forms of Agile have been very popular for the last two decades. They would not have remained this popular if in fact organizations using Agile weren't gaining successful projects as a result. So 20 years downstream or more and Agile is still extremely popular, tells you something right there about its usefulness, not perceived usefulness, but actual usefulness in a lot of organizations. Also, recent research, you can see that we've done surveys, we've looked at this. We found the top reason for moving to Agile is: Number one is to accelerate product delivery, is getting new products out the door faster with the features that customers want. Recognizing that priorities change. There's a lot of what we originally thought we were gonna do that we can't do now. Now, I recognize in our, where I'm sitting right now in 2022 for example, that the external environment for business, the social environment, the international environment is very different than it was five years ago. It's likely to be very different in another five years. That's the nature of life. That's the nature of commercial enterprise. And so we have to recognize priorities are going to change. Customer taste will continue to change. Technologies will continue to advance. And in the face of this we need to recognize the ability to pivot, to adjust, to exploit, and Agile allows us to do that. It's used to increase productivity. We also use it to improve software quality. So why are people using Agile? They're in settings or in environments where they need to pivot quickly. They need to be mindful of the user. They can't treat the user as that person out there. They have to make them part of the team because the user ultimately is who determines success. Just like in other projects in new product development, it is the customer that determines product's success, not me. A recent survey of over a thousand projects in a lot of different settings, folks, what we found was that Agile improves time, budget, and scope goals. It definitely improves stakeholder satisfaction. The customer really gets more satisfaction out of Agile and it is positively related to project success. So not only do we have a theoretical assumption that Agile is going to be beneficial to organizations, we have empirical evidence to suggest that shifting to Agile, employing agile methods is not only useful for the user, the person at the end of the pipeline, it's useful for the project organization. It will save us money, it will save us time, it will improve project success and it will improve our relationships. With those ideas and those goals in mind, remember, Agile requires us to be comfortable with change. That's what it's all about. Agile is a methodology that's predicated on change. Change in customer tastes, change in technologies, change in business environment, change in all of its settings and in all of its manifestations. Agile is a methodology that allows us to capitalize on a changing environment.