This is the debate of the century. Waterfall or agile? Everybody has an opinion, emotions run high on both sides of the line and those who don't have an opinion are confused. It looks like everyone must have an opinion to be respectable. OK, I want to be respectable too so here is my opinion.
The first and IMHO, most important point is that the debate makes it look like there are only two alternatives for the "right" software development methodology. If it's not waterfall, then it must be agile. If it's not agile, then it must be waterfall. I say "not so". There are more alternatives. For me it's not waterfall, nor agile. Or should I say "both"? The closest methodology to what I like (and try to do) is Iterative Development. Yes, many of you will say that iterative development is a fundamental component of agile development and they will be right. However, agile development also has several things that I don't like. So, I cannot honestly say that I support agile principles.
Let me say up-front that, in my mind, classical waterfall is completely out of the question. I think that this methodology is so defunct that there is no need for me to explain and justify this position. So, in regards the question "waterfall or agile?", one half of the answer is straight forward: surely not waterfall. But if not waterfall, then what? Well, for me it's not agile either.
Let's cover briefly the major principles of agile and see what I think about them. I will take the principles directly from the original Agile Manifesto:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
This I like. At the end of the day, customer satisfaction is the ultimate goal. I also like the important principle of useful software. With regard to rapid and continuous, I like that too, but remember that it takes two to tango. Meaning, the customer needs to agree and work with us to accept our deliverable and rapidly test and provide feedback. You might be surprised, not all customers will want that.
Which brings me to the an important point. Agile experts agree that full customer cooperation with the project team is essential for the success of the agile methodology. This means that the customer must:
- Thoroughly understand agile techniques.
- Agree to work with the project team by the agile principles.
- Do their part in the "deal".
The above requires significantly more involvement, commitment and resource allocation from the customer. So, not only you need all of the above from your own company, you need the customer to deliver too. Double challenge. My experience:
- Rarely will the customer deliver on the above requirements.
- Most companies that try to implement agile methodology fail to secure the customer's cooperation but still go ahead with the methodology. In this tango you dance alone and the results are accordingly.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
I have a problem with this. Change is usually unavoidable in software projects, but welcome? No, I don't think so. This is engineer talk. Project managers call it Scope Creep. I am not saying that change must be blocked "at any price". I am saying that change has to be controlled carefully and allowed only under the right circumstances. Both the project team and the customer (again the customer) have to answer the following questions:
- Is the change really necessary?
- Is it necessary now?
- What will be the benefit?
- What will be the cost?
If the answers show that the change must happen, then so be it. But welcome? Changes are a necessary evil. Sorry, I am the old fashioned type.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
I like that. It's a good technique and it works of you are disciplined enough. Agile is even more strict. It requires timeboxing - even better.
Business people and developers must work together daily throughout the project.
Absolutely. But I think this is true and critical in any methodology. Show me a methodology that will disagree. So, even though this is true, it's not unique to Agile.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
There are two parts here:
- Support the team members. Again, true but universal. Not unique to agile.
- Trust them. Well, where I come from, we had a saying (crude translation): "Respect him and suspect him". As an experienced project manager, I like that better. Not that I think that team members are evil or anything. Just that they are human beings. And that includes me - the project manager - too, of course.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
This one probably irks me most. Not because of what it says but because of what it does not say. What it does not say is: "we hate documentation". Yes, I know. We all hate documentation. More precisely, we hate to write the documents. I have never met a project team member that did not like (and actually appreciated) documentation if:
- It was good quality
- Other people wrote it
It's much easier and more fun to communicate verbally. But verbal communication has serious drawbacks. This is a significant issue that deserves its own post, so I will not go into detail. I will just note here: face-to-face conversation has no records (other then in people's minds) and, therefore, no memory. Again and again, experience shows us that there is no escaping documentation. The big trick is to cleverly decide what documentation, how much? how? etc. But there is no alternative to good documentation. Don't get me wrong, face-to-face conversation is a great and vital means of communication but, sorry, it cannot make documentation unnecessary.
Working software is the primary measure of progress.
I agree assuming the working software does what the customer wants.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
OK, this is not really a guideline. It's more of a promise. I do not have enough statistics to make a determination if this has proven itself. I will be glad if someone can enlighten me on this.
Continuous attention to technical excellence and good design enhances agility.
Again, this is not unique to agile. All methodologies support this, even those that do not call it out specifically.
Simplicity--the art of maximizing the amount of work not done--is essential.
I like this. The KISS principle is a good principle.
The best architectures, requirements, and designs emerge from self-organizing teams.
Here again, I do not have enough insight to make a judgement. Let me know if you have any concrete info about this.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.
This is what the PMBOK calls Lessons Learned and is basic project management. It's good and again not unique to agile techniques.
So this is a brief summary on how I feel about agile development. I will sometime write about my own technique for which there is no formal name but I will characterize it as a combination of iterative and flexible waterfall.
Let me know what you think.