A Tale of two Methodologies: Heavyweight versus Agile

Ali Khan, Department of Information Systems, The University of Melbourne.

Sandrine Balbo, Department of Information Systems, The University of Melbourne.

Keywords

Web development. Agile methodologies. Heavyweight methodologies.

Abstract

Software Engineering is obsessed with methodologies. However, for the last few years, there has been some consolidation and generalization in methodologies and two schools of thought have transpired. On one side, we have heavyweight methodologies, which allege their support to comprehensive planning, thorough documentation, and expansive design. On the other side, we have lightweight methodologies (agile methodologies) which subsume individuals over processes, working software over documentation, collaboration over negotiation, and responding to change over following a plan. This poster, based on an extensive literature review (Khan 2004), exudes the on-going debate between the two divergent doctrines and unfolds characteristics and frailties of each methodology.

The basic difference between agile and heavy methods is the weight. Agilists believe that you cannot achieve agility with heaviness. According to them, “Heavy Agile” is an oxymoron. One has to be light to be called agile, and the reason for this lightness is to counterattack change.

Some critics label agile methods next to hacking or “code and fix” approach. They scrutinize that agility is another fancy name for ad hoc-ism and lack of planning. However, in actuality, there is some planning involved, but there is some limit to planning involved. The reason for why the limit has been imposed is because it is hard to predict future, and if the future is going to change, why plan too much. This lesser planning approach can be a good model in extreme situations, but in predictable precinct, it might not deliver the goods.

Some of the limitations of the agile methods are team and project size. It is hard to form large agile teams, since these methods heavily rely on collaboration, synergism and creativity among team members, and all these traits can mesh together well only in small environment. Furthermore, agile methods provide early return on investment as compared to heavy methods. The yardstick for success in agile methods is early and continuous deliverance of working features and software. In contrast, heavy methods depend heavily on documentation, upfront planning, and close conformance to plan in order to success. Some of the differences are highlighted below.

Another distinguishing factor, between agile and heavy methods is the way software is made. In agile methods, the software grows through each iteration and each iteration adds some business value to the final product. Also each cycle consists of same activities of getting the requirements, building the application against the requirements and then following by testing. Conversely, heavy methods try to acquire most of the requirements early and then build and test the application on those specifications. Figure 1a shows the agile methods approach, while Figure 1b depicts heavy methods approach.

Figure 1a

Figure 1b

Table 1 highlights the applicability of agile and heavy methods in terms of project scope, resources, time, risks, architecture, developers, and customers. Agile Software Development methods can help organizations deal with situations qualified as highly uncertain and unknown. On the contrary, predictability and well-defined milestones speak for heavy methods, if one tries to group in scope, resources, time and risks matrix. Moreover, agile methods focalize on rapid value by designing for current needs. Heavy methods centralize on high assurance by designing for both current and future needs. In case of agile methods, both developers and customers have to be extremely agile and well versed in their area of expertise. Heavy methods demand more compliance and discipline when it comes to customers and developers. Plan execution and plan adherence is what counts most in heavy methods. Similarly, if the cost of change is trivial, then it makes sense to employ agile techniques, as agile methods welcome change throughout the project’s life. If refactoring and change adaptability comes at a heavy price, then management is better off using heavy methods.

Table 1: When to use Agile and Heavyweight Methodologies

Agile Methods are high on team collaboration and iterative cycles. Heavy methods are heavy on documentation and process ceremony. Figure 2 describes this statement.

Figure 2

Heavy methods are process-oriented in relation to agile methods, which are people-oriented. Heavy methods canvass formality and discipline in order to work the intricacies of the project. In opposition, agile methods favor creativity, improvisation, and nimbleness to negotiate with project hazards. In addition, agile methods welcome change and alternately adapt to the new conditions. Heavy methods are more pessimistic at handling change and try to get all things worked out in the first instance, as depicted in Figure 3.

Figure 3

References

Khan, A. (to be published in 2004). Survey of development methodologies for the web. Minor Research Thesis. Department of Information Systems, The University of Melbourne.