Agile is a great way to work but there are some issues that need to be understood before adopting the approach as failing to understand and mitigate these will inevitably result in problems for the project at a later date.
Documentation
The first of these issues is the lack of system documentation that is generated during an iterative development approach. It is not that documentation isn’t produced but more that it is specific to the change in hand rather than an update to a specification of the overall application.
One way to describe it is that the documentation generated using an agile methodology is like producing each piece of a jigsaw puzzle as you go but never actually putting them all together to see the whole picture.
The problem that this creates is that you never have a clear and concise view of the system functionality created outside of the working software. Many projects I have worked on consequently either end up relying heavily on the delivery team and the business analysts to perform impact assessments on a test version of the application to understand what the working software already does or spend significant money and effort in maintaining two sets of documentation.
Testing
Although iterative cycles are great in delivering code early and providing the ability to learn as a team they do provide a significant overhead in testing. This is because as well as testing the changes that you have made to an application you also need to regression test the application. Regression testing, in its’ simplest form, is the repetition of previous tests to ensure that the changes made to the application have had no negative impacts on the existing functionality. This means that the faster you iterate the more testing that you need to do which increases your cost of delivery.
The standard solution to this problem is to automate the regression testing process to reduce the cost of regression testing. This approach can be further extrapolated into BDD (Behaviour-Driven Development) and TDD (Test Driven Design).
Behaviour-Driven Development is the definition of the application by it’s behaviours in a specific syntax (Gherkin) that can subsequently be converted into automated test cases. These are those Given.. when.. then.. statements that you sometimes see associated with user stories as their acceptance criteria.
Test-Driven Development is the definition and creation of automated unit test cases that are developed prior to amending the code to implement the new functionality. The theory is that this ensures that the delivered code will meet the requirements instead of the unit test cases being influenced by the delivered code. This is a common problem in development as human nature is to test what you wrote rather than what you were supposed to write. This approach has a lot of merit and has been in use for many years. Even when I started coding more than twenty five years ago the team leads used to make us write the unit test plan for a program before we started coding to reduce the bias of proving your code rather than the spec. The other advantage of this approach is that it also results in the creation of a set of small, discrete, reusable test cases that can be used for regression testing the application when checking it in.
However all of this testing is a significant impact on the cost of delivery of a project so needs to be recognised in any decision to determine the length of cycles of delivery of an iterative project or program and the type and amount of regression testing to be carried out in each iteration.
Also where a project is to make amendments to an existing system that has no existing regression tests created then this also adds a significant overhead to the cost of the project as there is then a need to create a new set of regression tests for the existing code prior to any work starting on amending this functionality.
The approach taken to mitigate these issues is typically enshrined in the test strategy including the decision on whether or not to automate and the level of risk that the project is prepared to carry.
Business ‘Hostages’
For an agile project to work successfully there needs to be access to business resources (both stake holders and subject matter experts) throughout the lifecycle of the project rather than for a phase at the beginning and then possibly at the end for user acceptance testing. This can cause a significant issue with business as usual (BAU) operations.
The normal solution to alleviate this issue is to hire a professional business analyst (aka product owner) to do as much of the day to day project tasks as possible. The product owner will produce the user stories with input and sign-off from the business and then maintain the relationship with the delivery team on behalf of the business.
Colocation
Colocation (the location of the entire team in a single location) is a pre-requisite for a lightweight agile delivery team where the focus is placed more heavily on continuous delivery of software rather than on a well-documented system. This is because the delivery techniques used tend to be more ad hoc and pairing (where two members of the team share a task) is used to share system knowledge rather than documentation.
Where colocation is not possible (e.g. when working with off-shore development teams) then documentation is required to ensure that the system requirements are presented in a clear and unambiguous manner. These will of course need to be supported with additional methods of communication to deal with the inevitable clarifications.
Conclusion
The use of agile techniques can improve the efficiency of delivery of almost any project but agile is not a silver bullet and each of the above factors need to be either accepted or mitigated if a project is to be successful.