I am just an undergraduate, so what the heck do I know about agile in big project. Please feel free to critique. What do guys from big projects have to say? He

I am just an undergraduate, so what the heck do I know about agile in big project. Please feel free to critique. What do guys from big projects have to say? Here is how I imagine people arguing about agile vs water fall. WF: It probably will take the same amount of hours and people to hash system together in agile, making sure all components are integrated properly without a strong and detail system requirements. AG: But you don't wait until the end to test your software and wait until the end to discover shit and changes. You can iteratively change stuff. WF: Ah. Fine. I will just tell my co-workers to test more often. Now, you agile people just want everything to be short-term. How do you ensure people don't block other teams from completing works? you see when blockers appear, the time requires for completion is the same as everything done at once. AG: But if you finish 80% while waiting on the 20% to block forever, you still have 80% done. Plus, in agile you have some short term and long term goals. You order them by importance and blocker. When the whole sprint is blocked, just do more testing and making sure existing systems are working as said. WF: Fine. Now what about people going monkey on their own? The point of water fall is to ensure no one is outside the design and minimize risk. Now everyone goes agile and shit going to come because some teams are not playing nice. AG: This is a tough problem. But the only way out is by scrum, well, at least meeting daily or weekly. The benefit of agile plus regular meeting is that everyone knows what the heck is going on and changes can be made. Once you made a specification forever, it's hard to change. WF: But it is the same in agile that a chance can be tough to make because people didn't make the right decision at one of the early sprints. AG: Yeah. That certainly is. I won't lie agile people don't make that easier. But I argue it is easier if you just work on smart parts. WF: Are you sure it will work for multiple-billion dollars project? With a lot of legal blockers and a lot of other software to work with? You need to do a thorough analysis. You need to conduct research how existing healthcare registration works, find out the pros and cons. That's a lot of time. Now if you go agile, you will just keep doing research. AG: .... YEUKHON: I will fill in the blanks, but hey what the heck do I know about big project software engineering. I think agile doesn't require people to start right away. Agile just ensure nothing blocks forever and that goals are more or less short-terms. it is always required one to have good knowledge of how existing solutions works. So if you need to find out how to integrate the new healtcare.gov with the rest of the solutions out there, do that research first. Obviously you can't just develop a site like a baby punching keyboard, hoping the baby compose some legendary music. It takes real talent to do that. So I say myth buster, agile still requires professionals to do priori research, have lengthy discussions about how to go about implementing the system, give a pretty good sketch about how things supposed to work, and then go off and start implementing something. But don't come up with the full solution so detail that you ought to obey that contract. WF: Yeah, but your client is spending 100 millions and this is impacting tens of millions of people. Any example out there like healthcare.gov did finish on time and running successfully using agile? I know WF sucks, but real examples of agile out there? You know, people tend to do a lot of talking and sketching when they are working with so many people and so many things involved. "Oh Bob and his teams are doing research on existing solutions works and my team is working on consumer APIs? Okay, let's talk about what fields we want, what schema we want in the database, etc"