Response Article: “Agile Methodologies in Large-Scale Projects: A Recipe for Disaster”

In the article “Agile Methodologies in Large-Scale Projects: A Recipe for Disaster” the author argues that agile methodologies are not suitable for large scale projects.I would like to claim the opposite – that agile methodologies are suitable for large scale projects, and, furthermore, that the larger the project the more necessary it is to be agile. I shall echo the author’s approach of going through the points of the agile manifesto, and shall attempt to refute his arguments regarding them.

Responding to Change over Following a Plan

Regarding this point, I agree with much of what the author says. Changes are certainly easier to implement in small scale projects and following a plan is always better than having a lack of direction. However, just because change is harder to implement in a large scale project, this does not mean it is any less necessary. Indeed, in a large scale project changes will often be far more necessary than in a smaller project.

This is largely due to the length of time large projects take to develop. Whilst a small scale project could reach completion in weeks or months, a large scale project will often stretch on for years. This means that the landscape will be very different when the project reaches completion than it was when the project was envisaged; a new competitor could emerge, or a new technology could come to the fore and need to be utilised (think of the advent of touch screens and smartphones). Change is necessary.

The author does acknowledge this, however I think he somewhat underestimates it. He states “…changes to a requirements specification or a request to modify the behaviour of a range of already-implemented features mid-way through a project’s development I find to be less acceptable.”. This is unrealistic. It is an accepted fact in software development that requirements gathering is hard. A client is unlikely to know the complete list of requirements at the onset of a project, details will be lost in communication between client and developer, and thus requirements are going to change throughout the project. Perhaps in a small scale project all the requirements could be captured perfectly and a perfect plan could be made from the offset, but in a large scale project the chances of this happening are very small, and it is more likely that changes will be required.

The agile manifesto recognises this and prioritises responding to these changes over any original plan made. I believe this is imperative to project success, especially in large scale projects where changes are more likely to be necessary, and to have a greater degree of necessity.

Working Software over Comprehensive Documentation

I think the author misses the point somewhat in relation to this section of the manifesto. Sure, lack of formal documentation could appear unprofessional to clients. Sure, informal means of documentation aren’t the best. But hold on, let’s consider the converse of this point in the manifesto.

Imagine prioritising documentation over working software – you would be setting yourself up for failure! The ultimate goal of any software house is, surely, to produce working software. This being the case, surely said software should be the absolute priority during the development process. Anything else taking priority seems to me to be simply ludicrous.

This isn’t to say that documentation isn’t important, of course it is! Adopting an agile methodology doesn’t mean sacrificing all forms of documentation – documentation will be produced when it is useful for documentation to be produced. This point in the agile manifesto is simply pointing out that the software takes ultimate priority – it is almost poking fun at more traditional forms of development, which produce vast amounts of documentation, not all of which is useful, and often do not produce working software. The Oscar Wilde quote “The bureaucracy is expanding to meet the needs of the expanding bureaucracy.” is illustrative here, traditional methods, the waterfall model for example, often produce a vast amount of documentation, for the sake of having documentation. Conversely, with an agile development style, documentation will be produced for the sake of having the software work.

Again, this is even more applicable to large scale projects. The larger the project, the more documentation can be produced. It is even more imperative that this documentation all be useful, or else anything that is not useful will be lost amongst the massive amounts of junk documentation.

PAUSE: Misinterpretations

I believe the author has, to some degree, misinterpreted the agile manifesto.

While the agile manifesto does prioritise the items on the left, it does not forget about the items on the right. I think the author has a misconception that the items on the right are ignored – they aren’t. They simply won’t be done to the detriment of the items on the left.

The author is not alone in his interpretation of the agile manifesto, however. Some developers claiming to be agile often forget about the items on theright, to varying degrees. This is one criticism I have of the agile manifesto – it is quite vague and often misunderstood. That being said, it is my belief that if the items on the right are ignored, then the developers aren’t being agile, they’re just doing it wrong.

Continuing on…

Individuals and Interactions over Processes and Tools

I believe the author misinterprets this point to some degree. He talks a lot about innovation, and how this can hamper projects. I’m not sure I agree with this, but I also think it is beside the point.

Another quote (this one, as far as I know, not attributed to anyone famous), “A fool with a tool is still a fool”. The agile manifesto believes it is more important to have the right people for the job than it is to have the right tools, and I totally agree with this. The tools are important, sure, but the people have to be able to use them.

Even more important than having the right people, though, is having them talk to each other. Interaction between team members is crucial to the success of any project, be it small or large. It doesn’t even have to be a software development project. Communication is always key. It is absolutely reasonable, in my view, to prioritise this above anything else. Work will get done faster, better, with teams of good people communicating well with one another, even if they have to make do with last years tools.

Customer Collaboration over Contract Negotiation

In this section the author makes a similar argument to what he did when arguing for following a plan over responding to change – namely, that change is bad especially in large scale projects. I feel I have already argued against this, and have shown that change is necessary, regardless of whether it is good or bad.

With changes being a necessity, it becomes vitally important that we work as closely as possible with the customers to making sure we are effecting the right changes in the right ways.

The key point here is that a contract should never substitute for communication, with a contract being probably outdated with regards to requirements (especially in the case of large scale projects), where more communication is rarely a bad thing. The author also talks about developers being exploited when changes are asked for, and that an iron cast contract would protect developers. This is true, to an extent, but it could also doom the project to failure, as change won’t be adapted to.
Additionally, this is not the only way to protect developers. Rather than have one massive iron cast contract at the beginning of the development cycle, the developers could be protected by a sequence of smaller, iterative contracts, which whilst retaining the protection of the developers, also has scope for adapting to change.


I think the author of the article makes some good points for the importance of the items on the right, but he does not convince me that they are more important than the items on the left. I think the author does not go into enough detail and underestimates the import of some the items on the left.

Furthermore I think the authors interpretation of the manifesto is often incorrect, and that this limits his argument. He talks a lot of change in large-scale projects being bad, and while this can often be the case, change is all to often necessary. Agile development practices have been developed to better accommodate the changes that are necessary for project success, where earlier development models were too rigid. The author also relies on getting an absolute list of requirements early on in the development process, which I think is an unreasonable expectation.

I believe the agile manifesto assigns priorities in an entirely reasonable fashion, and that it is absolutely suitable for large scale projects. Further to this, I believe that large scale projects can draw even more from using agile methods than small scale projects can.