As I read the comments for a number of editorials I continue to see folks who have had negative experiences when working on agile projects. I have to say I understand where they are coming from. I also have had negative experiences from time to time. That causes me to wonder, what is it about agile that draws such feelings?
Depending on who you read (and their obvious bias) you find comparisons of waterfall projects to agile projects, and the rates of success for either SDLC (Software Development LifeCycle). The percentages range from 16% to 50% success for waterfall, and 30% to 60% for agile. Frankly, I don’t think anyone has maintained enough statistics to provide percentages with anything much more than an educated guess. Maybe that’s good enough for time travel in star trek. But, I wouldn’t bet my business on it.
From my personal experience, I have had one great experience using Agile, one horrible experience using Agile, and one project falling in between. These experiences covered many projects. What set them apart was how Agile was implemented. I also had similar experience using Waterfall methods.
What made the difference? For both methodologies, the difference for me was the skills and disciplines of the participants working on the projects, and their understanding or commitment to getting the work done. For example, when you don’t have the necessary commitment from the business for their part on building a system, the project is going to fail. The only question is how soon, and how badly.
If success is measured as delivering software, on time, on budget, with the appropriate functionality, how often have you experienced success? One thing I know for sure is that Agile has been nominally adopted as the way to write software faster and cheaper, because it throws out all strategic, intentional design and tracking. So, we don’t like to comment. We don’t like to document. We don’t like to spend a lot of time maintaining time used. We don’t want to waste time with lots of requirements. So, well just throw out all controls, call it Agile, and as long as we can move task cards across the board, we are delivering what the business needs. That is not Agile. I call it Fragile. You will fail.
The exact same thing can be said about waterfall. If you don’t do it right…you will fail. Here’s an example of what I mean. As a Database Architect I have worked with Waterfall and Agile projects. For either project I always create an ERD (Entity Relationship Diagram) of the database. The difference is that for Waterfall, I have a complete logical, and often physical, database diagram completed before development work begins. For Agile, the diagram and implementation evolves with each sprint. That was the MOST difficult transition for me to make. You can’t use the same techniques with rapidly evolving databases as you do with slow moving database change.
I don’t mind when folks blame Agile for many different problems they experience. However, I am pretty certain that they have not experienced Agile in a way that works efficiently. From their perspective, Agile is the cause, and I would agree with them. What I am probably not in agreement would be the processes that failed being titled Agile. Scott Ambler has some great books on Agile processes, especially as they are targeted for DBAs, that are quite helpful. I’ll pick up on this some more later.
Of this one thing I am certain, I would much rather work on a failing waterfall project than any project using Fragile techniques. Fragile is REALLY painful, and people are right to hate it.
Cheers,
Ben