13, 2001, at The Lodge at Snowbird ski resort in the Wasatch mountains of Utah, 17 people met to talk, ski, relax and try to find common ground. What emerged was the Agile Software Development Alliance. ” (Martin Fowler and Jim Highsmith, 2001 ) This new approach redefined our vision of software development- giving rise to a work culture focussed on human resources, mutual trust, interaction and productivity - radically going against the long established approach based on detailed structuring and modelling, documenting etc..What 17 people envisioned in a light-hearted manner became a norm in software businesses (Martin Fowler and Jim Highsmith, 2001 ). However, there have been debates on the application and viability of Agile Manifesto, particularly from the proponents of process-oriented approach.
The critics have often questioned the outcome of Agile Manifesto’s emphasis of certain concepts over others. The corresponding debate with evaluation of agile and process-oriented software development methods in terms of Agile Manifesto are given below. Individuals and interactions over processes and tools:Agile Manifesto gives more value to human efforts than existing framework and detailed methodology. It has truly identified that it is people whose performance and output matter over industry-wide tools covering modelling techniques, documentation etc.
. Agile believes in a small group of people constantly interacting to find the feasible, quality solution to business aspects forming customer requirements (Bahli and Abou-Zeid, 2005 ). Giving lesser emphasis to the supporting processes and tools gives programmers focus on implementation ensuring faster delivery. The impact is a tress-free environment for motivated, creative teams to transform vision into reality.
They possess liberty to propose, test their ideas after group discussion and consensus.Reducing design and modelling efforts may have some negative aspects. A development-oriented, people-focussed approach is suitable for small projects, but not large, complex ones that are difficult to cover without entire architecture design. ( Turk et al. , 2002) Also, building safety critical systems is risky due to rigorous testing strategies and environment to combat unforeseen failures ( Turk et al.
2002) proving that Agile Manifesto is not effective in all scenarios as its supporters thought.Agile methods e. g. scrum, XP support the manifesto by identifying human factors - communication skill, team work, collaboration, business and technical knowledge ( Merisalo-Rantanen et al. 2005 ), trust, respect and responsibility for decisions (Martin Fowler and Jim Highsmith, 2001 ), pair-programming as crucial development aspects.
Coding and testing activities are more intense against supporting processes like design, review, discussion, documentation ( Germain et al. 2005) and relevant tools. Conversely, the process-oriented methods like RUP, Waterfall model are use case driven, central architecture-dependent and role-based.All the processes and tools of software development like requirements engineering, design and implementation, testing, release and maintenance are utilised greatly and output from one process goes to next process after quality checks. Working software over comprehensive documentation.
The ultimate goal of the customer is to get a software system completed within time, budget.The user is not interested in documentation, diagrams and tools. True, these are essential in supporting business but developing incrementally, a small chunk of code at a time, testing, implementing, integrating it iteratively is a superior alternative reducing development time. More importantly, there is a continuous value addition as the modular approach guarantees that higher priority codes can directly be put to production without waiting for remaining coding to complete (Petersen et al. , 2010 ).While concept of iteration was already available, Agile Manifesto has taken it one step further by reducing the time span for each cycle (timeboxing) and further specifying requirements scope.
Also there can be many internal releases for learning from previous release and developing further before final delivery to customer (Petersen et al. , 2010 ). The Agile Manifesto also encourages simple solutions to complex problems that incorporate dependencies, are easy to understand and minimise risks.Simple, clear purpose and principles give rise to complex, intelligent behavior," (Dee Hock, former CEO of Visa International as cited in Martin Fowler and Jim Highsmith, 2001). On the downside, the above scenario may be specific to only smaller projects as in larger, more complex systems, absence of critical architecture and documentation reflecting core functions makes it difficult to map coding with exact requirements introducing risks of costly changes ( Turk et al.
2002), as it is troublesome for novice programmers in understanding the enterprise operations and necessitates all team-members with immense experience, dedication and skillset. Difficulty in identifying organisation structure becomes paramount when development is distributed hindering smooth communication and opinion exchange. Designs, models and documenting each phase’s result remain only options to bridge the gap; clarify requirements, objectives; validate them ( Turk et al. , 2002 ).Hence as observed, carefully maintained documentation may be a vital criteria in building software, contrary to what Agile Manifesto reflects.
Agile methods support developments in iteration, increments, timeboxing - developing small units of code in short cycles, creating flexible and working software with little documentation. Reduced overhead makes the product faster and easier to develop. The process-oriented approach differs as it needs thorough documentation for reference, review and validation reducing delivery speed and adaptability to change.Customer collaboration over contract negotiation. Agile Manifesto’s main motto is communication and sharing of ideas. This includes frequent communication and discussions between developers and customers.
This is more important in identifying business aspects due to lack of structured graphical representation. The necessary customer feedback is repeatedly used in product re-evaluation. (Tessem 2003; Svensson and Host 2005; Karlstrom and Runeson 2005) There is also one representative of client organisation at vendor’s location controlling and advising on the project.However being committed to the development process for long period is quite stressful and demanding in terms of knowledge to this person (Martin et al. 2004). When judging software development, contract negotiation obviously has lesser significance as it provides only the boundary condition for business, while collaboration is a way to address to the task of solving problem.
In agile methods, the work culture depends on customer interaction, feedback and programming efforts of a skilled team. (cf. Svensson and Host 2005;Karlstrom and Runeson 2005; Bahli and Abou-Zeid 2005).Whereas in process-oriented approach, the detailed requirement specifications, setting up standard environments prior to development ensure greater efforts on contract negotiations.
Responding to change over following a plan. IT development using some specific requirements and objectives set by the customer at a particular moment and developing in small cycles makes system more flexible. When changes are required due to varying market trends and new innovations, they can be easily incorporated into the next iteration. (Schwaber 2004; Larman 2003; Koch 2005).However if we do overall analysis to draw detailed design and plans at the initial stage, a lot of efforts are wasted in correcting and redesigning (Tomaszewski, 2006).
People in an organisation often resist change to their normal workflow because of cost, need for new skills and fear of irrelevance of current roles in new system. ( Martin Fowler and Jim Highsmith, 2010 ). Again, a bridge built without proper support has the danger of falling down. Similarly, successful individual components added in each cycle may fail as a total system if there is no overall plan as how to integrate them in an optimised manner.E.
g. , code redundancy is a flaw which cannot be addressed unless we plan of using same module for different business purposes beforehand. In agile methods development work continues by adding few prioritised needs in each iteration without an initial broader specification allowing adaptive planning and reprioritizing our requirements under changed circumstances (Schwaber 2004; Larman 2003; Koch 2005). Specifications at holistic level, standard environment setup, structuring and documenting in process-oriented approach ensures more planning, huge reworks and time to incorporate changes (Tomaszewski, 2006).Now, the process oriented approach and agile approach can be evaluated on four fundamental principles stated in ‘No Silver Bullet’ by Brooks (1986) – complexity, changeability, conformity, invisibility.
Each principle considers software development more difficult compared to hardware development, construction etc.. Although agile has addressed some development challenges, it has many problems and hence is far from being an effective silver bullet (Cohn and Ford, 2003).
