Enterprise Etc Adventures and Insights of a .Net Developer

I'll go ahead and say this to get it out of the way.  I've never worked on a project that used a purely agile methodology.  I've worked for clients that chose bits and pieces of things usually associated with agile such as continuous builds and the writing of unit tests, but I've never been submerged into a purely agile experience.  So, my comments are coming not from experience with agile methodologies, but rather experience without them.

I've been curious for the past few years about the benefits that an agile approach brings.  I've read numerous books on things like RUP and SCRUM.  As I've gathered knowledge about the subject, I've had the chance to balance the experiences I've had in the projects I've been involved with against the philosophies and practices I was reading and thinking about.  I've boiled all these meandering thoughts down to a list of perennial problems I see in projects and how I think an agile approach could lesson or eliminate them.  Of all the various flavors of agile methods that exist, SCRUM seems to be the one I identify with the most, so I'll be speaking in its terms, below.  If you aren't familiar with SCRUM, you might want to read more about it, here.

• Scope Creep / Late Breaking Requirements - With a SCRUM project life-cycle, the software design is refined before each sprint.  Further, during the course of the sprint, the goal is to write the software to meet the CURRENT requirements only.  Let's face it.  Any developer who has any experience, at all, can tell you that there will always be more features requested after the project has started and that users will always change there minds about things.  If we know this will always be the case, why do we design a whole system up front and pretend it's never going to change?  In fact, we try to insure that it doesn't change by slapping a change request and approval process on the users who change their minds.  To me, the ultimate goal is to put the most useful software possible in the user's hands.  Punishing users for suggesting improvements to the software doesn't seem conducive to that.  With a methodology like SCRUM, these changes are part of the process and thus welcomed. 
•   End Product Not Meeting the User's Needs - I think a majority of the problems that occur in software projects boils down to a lack of communication.  Communication may break down because no attempt is made to convey things like project status and the way the application will work - or it may just be that the business side of the house and the IT department speak is entirely different terms.  If the project is to be a success, the users and the developers have to be on the same page.  The only way that can happen is for the two groups to talk...often and in the same terms.  There are users who never know exactly what they want until they don't get it.  In SCRUM, after each sprint is finished, the solution is presented to the users for approval.  Users can see and maybe touch and use the software in its current state.  This seems to me to be the best way to squeeze those questions and concerns out of a user that they never seem to be able to think of when they're requesting the software. 
• Developer Thrashing - In SCRUM, there is a daily meeting to determine where each developer is with there tasks and what can be done to expedite anything holding them back.
• Pushback From the Business on Length/Cost of Projects - Before each sprint, a decision is made as to which tasks will be completed during that span of time and which developer will be responsible for each.  This decision is a COOPERATIVE effort between IT and the business.  Each task has an estimated amount of time required for completion and a priority assigned by the business.  Accuracy in estimating the effort required for a task and how much effort can be expended by the development team during a single sprint can be tuned over time and this type of metric is very easy to gather from the process.  Since the the business is involved in the scheduling of tasks and would have access to the metrics, a better understanding of what takes time and why can be had.

Though my experience with agile methodologies is light, I can tell you that the apparent benefits of applying them has motivated me to push for there use in my current project.  I'll check back in with the results.