Abstract
The conventional software development methods also called Plan-Based Models, were modelled over engineering practices where most of the project’s life cycle was centred on the planning stage. This method has been used for a very long time. A community of programmers who have worked with Plan-Driven Methodologies (PDMS) have identified some drawbacks, especially, the strong dependence on the “Iron Triangle” which connects quality with scope, resources and time. In the delivery process PDMS is noted to resist change even though the customer’s requirements might have changed. A group of programmers have evolved a strategic way to accommodate the lapses in the traditional methods. They advocate for flexibility in change and people oriented as opposed to process oriented approach. This has raised eyebrows in the industry sparking a lot of debates on the suitability of any of these methods. This article seeks to address the pro and cons of the new and old methods.
Introduction
This article will develop arguments by first explaining Agile and the conventional Plan-Based Methods (PDMS). I will consider arguments for and against the two camps and decide if any of them can be favoured. We will look at the basic principles that drive software development or project contracts and also what pertains in reality. Project delivery, change management, risk management, requirements, development, scalability and collaboration, design customer and communication. We will also consider Extreme Programming’s principles as the representative for Agile Movement.
What is Agile Method?
Agile represent new approaches in the spectrum of software development methods. The aim of these practitioner-oriented software development methods is to make a software development unit more responsive to changes. These changes are imposed by rapidly evolving technology, changing business and product needs [8]. 2 There are different schools of thought in the agile community. Popular examples are Scrum, Crystal and Extreme Programming (XP). Extreme programming has had the lion share since its inception in the late 1990’s [4] and so specific references to Agile methods will be centred on Extreme Programming. XP presents an attempt to reconcile humanity and productivity, a mechanism for social change, a path to improvement, a style of development and a software development discipline. XP boasts of four values which are communication, simplicity, feedback, courage and respect. XP describes the software development process into four activities; coding, testing, listening and designing [4]
Plan-Driven Method
See designing as the most important thing after initial consultation, then coding and testing. Here, customers and developers establish a document which defines every detail. There is extensive documentation on every step taken in the delivery process.
A New Project
We need to get a vivid picture on what happens at the start of a new software project. Customers or Stakeholders present three common things for all projects: Scope, Time and Cost. By scope we are referring to the problem they want solved, by time we are referring to the time they want the problem solved by and by cost they have a sense of how much they are prepared to pay for the product.
The specific problem or requirements are communicated informally in email, meeting, or proposed by a project sponsor. In a traditional planning approach, this stage is very crucial and a lot of detail work is done on this as that is going to form the term of reference no work starts until it fully documented and agreed on by all parties. This might create some anxieties, since clients might feel they might have left some important things out. The technical team typically wants to “cement” on the requirements as soon as possible in order to provide their estimate for delivery. In most cases this creates issues as the business wants to know how much the project will cost, which the development team can not give outright till they know what going in. This often leads to some sort of tug of war between the technical teams and the business as opponents try to outwit each other. Technicians determined to avoid 3 “Scope Creep” later on and the business trying to protect what they might have missed out in specifications.
Quoting a pro-agile activist “By the time everyone is finished, the project usually is expected to take much longer than anticipated, and has a much larger scope. Meanwhile, the business users need it sooner than the developers think they can build it. The date is artificially moved earlier to accommodate the business, and the feature set remains the same. Small wonder that according to a study by the Standish Group (1), only 1/6 of all software projects in the U.S. were completed on time and within budget. The same study found that 1/3 of projects were cancelled outright due to time delays and cost overruns, and over half were considered to be challenged”. [7]
Project Delivery:
Pro-Agile Activists point out that PDMs are very process-centric resulting in vast quantities of documentation which are simply not practical or desirable on small projects. However Anti- Agile activists point out that AM produce products that are short lived since they meet only the needs of the moment and also the poor documentation prevents future modifications or adaptations.
Change Management
Pro – Agile Activists state that allowing on-site customer to make changes by informing the development team makes the process flexible and saves cost of formal overhead. Anti –Agile Activists claim that can lead to costly rework and project scope creep. Pro –Agile activist argue that PDM’s bureaucratic nature ends up preventing critical and necessary changes to project design as any request for change has to be analysed and approved by a change control board. This often leads to the development of a product not suitable for the clients needs.
Risk Management
Pro – Agile Activists claim that AM delivers code in steps and each step is tested before the next stage and so problems are identified at a very early stage and fixed. They however, emphasise that PDMS finishes the whole product and fix problems 4 later this is more risky and might spark overheads. Anti- Agile activists assert that AM make it difficult to identify boundaries and might cause unnecessarily rework
Requirements
Pro-Agile activists argue that requirements should be expressed as automated acceptance tests rather than specification documents. Also requirements should be defined incrementally, rather than trying to get them all in advance. They add that this ensures that clients get exactly what they need. Doing otherwise as in PDMSs will lead to producing a product lacking some needed elements.
Developers, Scalability and collaboration
Anti-Agile Activists oppose the idea that AM software developers are required to work in pairs. They conclude that AM is not scaleable. However Pro- Agile activists claim there is evidence that a team of 100 have successfully implemented a project. In his paper Victor Skowronski, Northrop Grumman [3] states that AM can marginalise problem solvers. He cites that Isaac Newton and Thomas Aquinas who were great problem solvers would have failed as agile programmers. Newton did not share his work and rarely communicated with other workers and most of the time quarrelled. In other words he would have disrupted any agile programming team. He was able to do wonders however, when he had the opportunity to be alone. Thomas Aquinas was noted to be quite and had the nickname “Dumb Ox” at school but, he could be likened to the proverbial programmer who sits silently and walks through his code contrarily to the agile environment that insists that he contributed to the solution in a team. Obviously these two people lacked good people and communication skills and so he concludes that AM is an anti- people oriented programming style.
Design
There is no big design up front. Most of the design activity takes place on the fly and incrementally, starting with "the simplest thing that could possibly work" and adding complexity only when it's required by failing tests. Anti- Agile activist’s fear this would result in more re-design effort than only re-designing when requirements change. 5
Customer and Communication
Pro-Agile activists disagree with AMs procedure of attaching a customer representative to the project. They assert that this role can become a single-point-offailure for the project and some people have found it to be a source of stress. But ProAgile activists affirm that this ensures that the customer is in control of every stage of the development process.
Summary
In an attempt to reconcile the strengths, weaknesses and suitability of the two methods for particular situations we will dwell on the following parameters; developers, customers, requirements, architecture, refactoring, size and primary objectives. Agile Methods expect developers to be agile, knowledgeable, collocated and collaborative but PDMs expect developers to be plan-oriented, with adequate skills and should access external knowledge. Customers for Agile Methods should be dedicated and knowledgeable, collocated, collaborative, representative and empowered but PDMs expect customers to have access to knowledge, collaborative, representative and empowered. Requirements of Agile Methods are largely emergent and favours rapid change. But PDMs requirements are knowable early and largely stable. Architecture for Agile Methods is designed for current requirements but PDMs are designed for current and foreseeable requirements. Refactoring for Agile Methods is inexpensive but expensive for PDMs. Agile Methods favour smaller teams and products whiles PDMs favour larger teams and products. Primary objective Agile Methods favours rapid value whiles PDMs favours high assurance.
Conclusion
Agile Methods becomes suitable for projects that involve new or prototype technology, where the requirements change rapidly, or some development is required to discover unforeseen implementation problems. Or research projects, where the resulting work is not the software product itself, but domain knowledge small and more easily managed through informal methods. [4] 6 On the other hand, traditional methodologies are suitable for projects that involve stable technology and have fixed requirements, where it is known that no changes will occur or involve mission critical or safety critical systems, where formal methods must be employed for safety or insurance reasons. Or are large projects that may overwhelm informal communication mechanisms. [4] My concluding statement is that project managers must weigh project aspects against available methodologies to make an appropriate selection as no two projects are the same.
References
[1] http://agile.vtt.fi/docs/publications/2003/2003_oss.pdf
[2] Strengths and limitations of responsive and agile methods http://davidfrico.com/rico04b.pdf
[3] Do agile methods marginalize problem solvers? http://moosehead.cis.umassd.edu/cis580/readings/AgileProblemSolvers.pdf
[4] http://en.wikipedia.org/wiki/Extreme_Programming
[5] http://fc-md.umd.edu/mikli/Lindvall_agile_universe_eworkshop.pdf
[6] http://www.martinfowler.com/articles/newMethodology.html
[7] http://www.extremeplanner.com/articles/Agile-Project-Planning.html
[8] J. Highsmith, Agile software development ecosystems. Boston, MA.: Pearson Education, 2002.
[9] http://www.knowledgetrain.co.uk/project-management-training-coursearticle002.php 7
[10] P. Abrahamsson, O. Salo, J. Ronkainen, and J. Warsta, "Agile software development methods. Review and analysis," VTT Technical Research Centre of Finland, Oulu VTT Publications 478, 2002.
Tags : MSC Information Technology, University of the West of Scotland, Paisley.
Source:
Excellent
