As I have watched .NET mature over the last 10 years, and watch developers get more immersed in the technology that is not so "new" like it was in the early 2000's, a lot of focus has shifted to incorporating more advanced architectures like MVC, MVP, MVVM, and DDD and project methodologies like Agile. I personally think this is all great stuff, and am enjoying the whole community blossom and grow on a broad scale like never before.
Unfortunately where as implementing a new application architecture is a 'behind-the-scenes' decision not having a direct impact to the end client, changing the way we run our projects most certainly does. Enter Agile. This is not new either, but it is gaining acceptance in .NET shops and being used by my estimation at a rapid pace, and for good reason.
The "Waterfall" model or even Iterative development or "Mini-Waterfalls" still have their challenges, a lot of which I feel are solved by Agile Project Management. However as mentioned above attempting to run projects using Agile involves heavy participation by the customer and a paradigm shift in thinking. This change is not as difficult for software development teams as it is for the customers because we are technical and think methodically in nature so it is a good fit.
The abandonment of having that 'bulls-eye' finish date or being able to say "Here is what I want, see you in 6 months!" is too much to digest for many customers. I heard once that if anyone ever asks "When will the project be all done?", the response should be "Next year on May 24th at 2:38 P.M.." This in turn should make a question arise like, "Geeze, how do you know the time so preciously?", and in turn gets "Exactly, we can't and we don't provide that specific of a date."
Shifting from any type of traditional Waterfall to Agile takes total commitment and backing from both software development teams, management, and the customers. If any part of this commitment fails then it will probably not end up in success. As I heard at VSLive! and on some MSDN webcasts, try not to become a "We do Agile Scrum but, ...." team. There are no "buts", just commitment to doing it right. I hear this common theme often, and always present the question: "But how do we get Management and the Customers to buy into this shift in thinking and managing projects?" The answer: "Terrific question, and it's hard. There is no single answer to that." Magic and persuasion I suppose.
Truly technical shops or large IT organizations have probably already adapted Agile methodologies on the software development teams knowing of its success to creating high performance software development teams that are constantly communicating and delivering. However the less technical companies or ones that have a compressed management style used to having things done the old fashioned way will have an uphill battle implementing Agile.
Which leads me to the best part of this post. At VSLive! in Orlando last December the instructor of a TFS course shared a link on YouTube called "I want to run an agile project." It pretty much highlights perfectly the challenges associated with implementing Agile Project Management. If you are a software developer that has struggled with any of these challenges or have interest in Agile development, watching the link below offers a lot of head nodding and laughs. Super big thanks to the creators as they hit the nail on the head and presented this perfectly!