Agile development methodologies have become the in vogue thing in software over the last few years. Hardly a month passes when an article concerning agile development does not appear in a major software development magazine or journal. An entire career path has even sprung up – the "Agile Coach".
There is little doubt in my mind that agile development is better than a more traditional, waterfall type methodology. When properly followed, agile development methodologies seem to keep programming teams more focused on the end goal. A large, up front design effort tends to grow out of control and lends itself to focus on unimportant details that could easily be put off until later. Estimating such efforts generally end with deadlines that are not as near to reality as management would like.
With all of the goodness to be had with the agile way, there are persistent myths that seem to surface. The most common myths I hear are:
- Agile development is faster
- Agile development removes the need for documentation
- Doing Test Driven Development (TDD) means doing agile development
Agile Development is Faster
The most common reason I am given for why an agile development methodology is chosen is because it will be faster than a waterfall methodology. I believe this idea manifests itself because of the agile development practice of iterative releases.
In my experience, agile development is not necessary faster than waterfall development. In fact, during the planning process, agile work plans often end up longer than waterfall work plans. Why is this? Because iterative development forces you to think in a more detailed fashion about the features being delivered, the testing time required for those features, and the integration time for these features after the development team is finished developing them.
Waterfall planning does not force this level of thought on the planner. I have rarely seen a project plan for a waterfall development project that didn’t have 2 big items at the bottom: Test and Release. Next to Test is a large number of hours (or days) and is generally pulled out of the air and "seems to be correct".
Testing, integrating, and releasing software is like paying tax to the IRS. Generally, tax is taken out of your paycheck (if you are an employee) and paid to the IRS at that time. Since it is taken a little at a time, you hardly notice it. Paying tax a little at a time is like testing and releasing often in agile development.
When I became self employed, I had to pay 4 times a year instead and I really noticed the large payments much more. If you pay at the end of the year in a lump sum, the amount would seem much larger. Not only that, but you have to make sure you have been saving enough over the year to make the large payment. Borrowing money to cover a shortfall can be expensive and draw out the payment process. This is similar to testing and releasing at the end during waterfall development. If you haven’t allocated enough time to test properly, you end up extending your testing time and probably missing your deadlines. The real problem is that you generally do not find this out until close to your deadline and users are not happy with the late news. "Borrowing" from quality by cutting testing short always ends up with disastrous results.
Agile development might not be faster, but it is more predictable and more reliable for planning purposes. Generally you end up with a much better product from a quality perspective.
Agile Development Removes the Need for Documentation
The second most common reason that I hear for using an agile methodology is that agile development removes the need for documentation. Most of the time, those who give this reasoning have only heard about agile development and not actually taken the time to read up on it.
There are agile methodologies that promote less documentation than is traditionally recommended. Closer examination of these methodologies will show that documentation is actually not necessarily removed, but instead moved around. Sometimes the documentation appears as note cards or post-it notes on a wall. Often times the documentation appears as an actual user, placed full-time on a project, who serves as the requirements specialist for the new system.
I am not very found of low documentation methodologies, with one exception. When the solution being developed is pure technical solution, I believe it is more acceptable. In other words, when the developers themselves will be the users of the end product I think it is acceptable to go with a lower documentation methodology like Extreme Programming (XP).
Even when a user is present on the team full-time, I believe that some documentation still must exist. There is too much opportunity for miscommunication between developers and the user when nothing is written down or diagrams are not drawn.
I often see projects that wish to pursue XP, or a similar methodology, but balk at the thought of dedicating a user full-time to the effort. Most of the time, they will dedicate the user for 25% and sometimes up to 50%. The allocation is generally less in reality than what is agreed upon because it is too easy to ignore something if you are not allocated full-time.
If a user is not present on the project team full-time, a portion of each iteration should be allocated to document the details of that iteration’s feature list to prevent unfilled expectations on both sides.
Doing TDD is the Same as Doing Agile Development
I could also replace TDD with several other agile development practices and the topic would hold true.
TDD can be pursued while using many development methodologies. I have seen it work well on waterfall projects as well as agile projects. TDD is a quality control mechanism to make sure components meet their expected functionality when completed and I recommend its usage on all projects.
TDD has become popular because of the promotion of its usage among agile development advocates, but the goodness can be shared by all.
In my opinion, the main practices that separate agile development from more traditional methods are iterative development and releases at the end of each iteration. If you are not following those practices, I do not believe you engaged in agile development. Iterative development forces development teams to constantly focus on features of the software and iterative releases focuses the team on quality. Those two practices are what drive the agile methodologies to deliver on their promises.