Response article: Being large and agile


This post constitutes a response to the article entitled “Agile Methodologies in Large-Scale Projects: A Recipe for Disaster” posted by the user s1044415 on 14/02/2014 [1]. Starting from the agile manifesto [2], the author questions the feasibility of agile methods in large-scaled software. More specifically, for every of the so-called “agile values” presented in the manifesto, the author provides arguments which make the agile methodologies look problematic when implemented on real industry scenarios and support traditional heavy-weight development practices. Here, we argue that agile software development is something more than a bunch of guidelines and that it has its place (to a different extend) in every large-scaled project.

Client wants software not documents

The first step to become agile is to realize that, in the end, the customer wants an efficient piece of software which does what it is supposed to do. No one (maybe except from archivists) find diagrams and extensive documentation any useful given that the software works correctly and efficiently. There is nothing unprofessional in not providing extensive documentation. On the contrary, it is the definition of professionalism to provide the client a prototype as soon as possible and receive early feedback which could have a strong impact on the future development decisions (this is one of the core agile recommendations). The fact that many old-school businessmen feel secure when surrounded by diagrams is a result of habit and does not consist by itself an argument for not being agile.

At this point, it is important to emphasize that the power of agile practices derives from the fact that there are not strict rules to be followed as opposed to heavyweight processes. A direct consequence of this is that maintenance documentation is not prohibited but encouraged. Maintenance documentation records the architectural patterns after the completion of a module and provides information for further expansion capabilities but does not function as a guide during the construction. It is also much smaller in size (less effort for the developers) because it contains one (final) version and not multiple. Finally, the author provides an example in which extensive documentation is exploited as a proof in the hands of a government in the case of a project failure. Again, revised UML diagrams are unlikely to persuade other parties or individuals that their money were not wasted. On the other hand, clearly defined aims of the project combined with honest reasons of failure may have better luck. None of the above is discouraged by the agile standard.

Do processes and tools really work ?

It is claimed by the author that the reason processes and tools are used in large-scaled software is because they work. Let’s stand a minute and think of what we mean when we say that something “works”. If “works” means that, in the end, the client paid for a piece of software that was useless after a short period then yes, these processes and tools actually work. But if the objective is to provide the client with a piece of software that he can actually depend on long-term, processes and tools are not capable at all. The reason is rather simple: every project is unique in terms of aims and (possibly) of technological combination. These peculiarities demand innovative approaches and cannot be expressed in recipes. Software engineering is not cooking. At the same time, the re-use of an existing block of code is not something that is necessarily non-innovative. For various reasons the development team may decide that some repository code can be utilized in order to accelerate development without sacrificing code quality. The elegant combination of existing code still requires innovative minds since it is not by any means a trivial task. Moreover, the author claims that innovation and originality brings chaos. It is our opinion that chaos is brought by practices which promote isolation and competition among the team members (a common characteristic of the traditional methodologies). Agile recommendations considers communication as a crucial factor for success. Innovation comes through continuous collaboration among all the team members thus eliminating any danger of chaos.

Client as a co-developer

In his article, the author makes the assumption that the client knows what exactly he wants from the very beginning. This could be the case if the client is himself a software engineer but unfortunately this is not the case in most situations. Changing requirements is the most common cause of project failure. By agreeing on a contract from the very beginning the developers commit themselves in a target that in many cases may be infeasible or not what the client has in his mind. Human mind is able to acquire a much larger amount of information from something that it observes compared to a description. Agile standard exploits that property by recommending the construction of a prototype as soon as possible in order to receive an initial feedback from the client and then a continuous flow of releases where more feedback can be acquired. By this way the developers are in a position to identify possible misconceptions on time and change their plans accordingly. Continuous integration with the client do not expose the developers in any danger of exploitation. This is because there is a distinct line between the core functionality of a project and additional features which an experienced programmer is in position to identify. After all, if the client is willing to wait and pay more for some added functionality then so be it! Finally the author argues that a clearly defined plan increases the chances of a good estimation on time and budget. We strongly disagree with this notion because we believe that an early prototype offers an invaluable insight to developers regarding the projects peculiarities (because it exposes them directly to implementation rather than chatting while looking diagrams) and thus a much more accurate estimation would be possible.

The one who adapts survives

Given the current fast-changing business environment it is our opinion that following a strict plan from the very beginning is simply not an option anymore in software industry. Things change rapidly and along with them the clients requirements. If a software company wants to be successful (by providing their clients competitive software) it should welcome late changes in requirements. This is the main reason that agile methods are becoming more and more popular. We agree with the author in that the information flow in large-scaled project is a very important factor for success and requires rigorous procedures if confusion is to be avoided. But in this moment is where the “loose” nature of agile recommendations shines. No-one says that in order someone to be agile must follow by-the-book all the principles. Intentionally these principles are vague because their goal is to provide a high level way of thinking, not a look-up table for developers to use. Project managers (yes, there is not a rule which forbids managers!) can use hybrid approaches which on the one hand are conventional in terms of communication among separate teams but on the other hand utilize all the benefits agile standard has to offer in all other aspects of the development software process. Manager is tasked the weight of defining the threshold of where agile stops and typical procedures start.


In this article we tried to give justified counter-arguments in response to [1] regarding the application of agile methods in industry. Agile recommendation have much to offer to large-scaled project development and any limitations can be overcome by utilizing hybrid approaches. The intentional vagueness in the agile principles as presented in [2] is the key which makes them applicable to all software projects.


[3] Get ready for agile methods, with care. B. Boehm. IEEE Computer 35(1):64-69, 2002.
[4] Software development methodologies. A. Clark. University of Edinburgh, 2014