That’s often true, but it is not actually an impediment. While frequent releases are an important benefit, it takes time to get to that point, isn’t the right option for all situations, is just one of the benefits, and is not required to get the other benefits. Read more in a series of posts on this subject.
9. “The advocates are overzealous and arrogant.”
9. “The advocates are overzealous and arrogant.”
Yes, some of them are. But not all of them. Many people are overzealous and arrogant, that’s not unique to Agile. It is the concepts of Agile that make Agile worthwhile, not the advocates.
8. “It is all just a marketing ploy. You don’t really believe Agile is any better than traditional development and in fact it is just more of the same stuff in a shiny new package. You just want to hop on the buzzwagon.”
8. “It is all just a marketing ploy. You don’t really believe Agile is any better than traditional development and in fact it is just more of the same stuff in a shiny new package. You just want to hop on the buzzwagon.”
This one is hard to refute. The only way I can dispel that belief is if you get to know me better.
7. “I haven’t tried it, and I believe Agile Development is a good development method, but it is just another flavor. Whatever works for you.”
7. “I haven’t tried it, and I believe Agile Development is a good development method, but it is just another flavor. Whatever works for you.”
You may be of the opinion that traditional vs Agile is just a preference/philosophy/ideology thing, like chocolate vs strawberry, Aristotle vs Plato, Democrat vs Republican. But then in that case, why would anybody go to all of the effort of investing in Agile? Tech folks don't generally make massive switch-overs from one way of doing things to another just for preference or just to be 2% more productive, they generally only switch in order to get an order of magnitude improvement. So, if it is just a preference thing, there's not much to talk about (from my perspective).
6. “Yeah, I tried that Agile thing. What a disaster!”
6. “Yeah, I tried that Agile thing. What a disaster!”
There are any number of reasons for failure. I've seen plenty of cases of Agile failure. But in every case that I've seen "Agile failure" it was either because it wasn't really Agile that was being done, or there was a major impediment. An example of a major impediment would be that the attempt was initiated by executive decree followed by no investment in success and a goal of 100% Agile within an impossibly short amount of time. I realize that saying “it probably wasn’t really Agile” sounds pretty convenient. But, I have yet to hear anybody say "I feel like we were really doing it right, but it just didn't work." If that's something that you would say, I'd love to hear from you.
5. “Yeah, I know a group doing Agile and they are really successful. But they would succeed anyway because they’ve got all of the best people on that team.”
5. “Yeah, I know a group doing Agile and they are really successful. But they would succeed anyway because they’ve got all of the best people on that team.”
All I can say to that is that for me Agile is only worthwhile if it is something that has mainstream applicability. If it won’t work for the majority of teams, it isn’t interesting to me.
4. “I believe that you believe that it is better, but I can clearly see that it is not. I don’t know what your reasoning is, but it is clearly wrong.”
4. “I believe that you believe that it is better, but I can clearly see that it is not. I don’t know what your reasoning is, but it is clearly wrong.”
This is exactly what I was saying in 2005. Well, that works both ways and I’ve been on both sides of it. All I can say is that I believe it is worth your time to consider that if so many people that have devoted so much energy to the software development process believe that Agile is a good thing, then maybe there really is something worthwhile about Agile and it is worth your time to learn more about it.
3. “You don’t really understand how successful traditional development can be, and there are probably a bunch of techniques for success you are not aware of.”
3. “You don’t really understand how successful traditional development can be, and there are probably a bunch of techniques for success you are not aware of.”
My career for the past twenty years has been to contribute to the software process improvement efforts of countless companies. So it isn’t that. By the way, if you haven’t heard of the Niagra method (the best traditional development method), you should take a look.
2. “You have blind faith in Agile. You want it to be better and you will ignore any evidence to the contrary.”
2. “You have blind faith in Agile. You want it to be better and you will ignore any evidence to the contrary.”
Well, you'll have to take my word for it that I'm a very pragmatic person. If something isn't working, and it doesn't look like it is going to, I don't have a lot of patience to continue doing it just because I think it should work. I originally believed in Agile when I realized that it is algorithmically better than traditional development. But now I believe in Agile because I've experienced significant benefits from practicing it.
1. And the number one reason I may be wrong is the one I don't know about yet. If you've got a good one that I haven't covered, please let me know. I look forward to your thoughts and feedback.
1. And the number one reason I may be wrong is the one I don't know about yet. If you've got a good one that I haven't covered, please let me know. I look forward to your thoughts and feedback.
4 comments:
I was a 10, 9 and 7 objector. If you want to maintain your status as an agile objector, then avoid talking to Damon. He isn't a #9 and does a great job of "boiling the frog." Before I knew it I was arguing the pro-agile side. Yikes!
christian
Thanks Christian! :-)
Both Agile and Traditional have their advantages. The problem is when they are employed in an extreme degree. Like, when you reject all changes that the end product is what customer want or when you plan so small ("You not gonna need it anyway") that so many changes need to be applied later on in the process.
Other example is the test-driven development. Tests catch bugs not the lag of them so use massive test cases as safety net and not a tools to give you a conclusive indicator of bug free.
Being extreme in both way are just ... wrong.
Just a though.
Your point about users not wanting so many releases really rings true for me. We're working with a department that is trying to do agile development and the biggest complaint is that they're constantly asking for feedback and new requirements.
The business wants to just throw the problem over the IT wall with one big bang specification. Now they're having to pay the actual price for a real spec and feedback, they're backing away.
Post a Comment