SEMINAR REPORT ON AGILE SOFTWARE

IIMT ENGINEERING COLLEGE MEERUT

(AFFILIATED TO G.B.T.U UNIVERSITY)

SUBMITTED TO: Mr. Harshwardhan Barik ( CS DEPARTMENT)

SUBMITTED BY: Name : Aman Deep Singh Roll No: 0912710012 B.Tech 6th Semester

ACKNOWLEDGMENT

I would like to thank everyone who helped to see this seminar to completion. In particular, I would like to thank my faculty members for his moral support and guidance to complete my seminar on time.

I would like to take this opportunity to thank Prof HARSHWARDHAN, Head of the Department, Computer science & Engineering for her support and encouragement.

I express my gratitude to all my friends and classmates for their support and help in this seminar.

Last, but not the least I wish to express my gratitude to God almighty for his abundant blessings without which this seminar would not have been successful.

With Regards Aman Deep Singh Roll no.0912710012 C.S.E 3rd year Dept of computer science and engineering IIMT engineering college Meerut

Page 2

TABLE OF CONTENT
S.no. CONTENT
1 2 3 4 ABSTRACT INTRODUCTION HISTORY PRINCIPLES BEHIND AGILE METHODS THE AGILE MANIFESTO

Pg.No.
4 5 6 7

5 6 7 8 9 10 11 12 13 14

CHARACTERISATION DEFINATION EXISTING AGILE METHODS COMPARISON WITH OTHER METHODS SUITABILITY OF AGILE METHODS AGILE DATA

8 9 12 21 23 26

AGILE METHODS AND METHOD TAILORING 27 CRITICISM CONCLUSION BIBLIOGRAPY 29 31 33

Page 3

ABSTRACT

Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life-cycle of the project. The basic value of agile approaches is to put back some emphasis on the importance of people collaboration, both developers and customers, in software development projects.Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office. The office may include programmers and their customers, testers, interaction designers, technical writers, and managers. Agile methods also emphasize working software as the primary measure of progress. Combined with the preference for face-to-face communication, agile methods produce very little written documentation relative to other methods. The principles behind the Agile Manifesto are customer satisfaction by rapid continuous delivery of useful software, simplicity and continuous attention to technical excellence and good design.

Page 4

INTRODUCTION
Agile software development is a conceptual framework for software engineering that promotes development iterations throughout the life cycle of the project. There are many agile development methods; most minimize risk by developing software in short amounts of time. Software developed during one unit of time is referred to as an iteration, which may last from one to four weeks. Each iteration is an entire software project: including planning, requirement analysis, design, coding, testing and documentation. An iteration may not add enough functionality to warrant releasing the product to market but the goal is to have an available release (without bugs) at the end of each iteration. At the end of each iteration, the team re-evaluates project priorities. Agile methods emphasize face-to-face communication over written documents. Most agile teams are located in a single open office sometimes referred to as a bullpen. At a minimum, this includes programmers and their "customers" (customers define the product; they may be product managers, business analysts, or the clients). The office may include testers, interaction designers, technical writers, and managers.

Page 5

HISTORY
The modern definition of agile software development evolved in the mid 1990s as part of a reaction against "heavyweight" methods, as typified by a heavily regulated, regimented, micromanaged use of the waterfall model of development. The processes originating from this use of the waterfall model were seen as bureaucratic, slow, demeaning, and inconsistent with the ways that software engineers actually perform effective work. A case can be made that agile and iterative development methods are a return to development practice seen early in the history of software development. Initially, agile methods were called "lightweight methods." In 2001, prominent members of the community met at Snowbird, Utah, and adopted the name "agile methods." Later, some of these people formed The Agile Alliance, a non-profit organization that promotes agile development.

Page 6

PRINCIPLES BEHIND AGILE METHODS-THE AGILE MANIFESTO

Agile methods are a family of development processes, not a single approach to software development. In 2001, 17 prominent figures in the field of agile development (then called "lightweight methodologies") came together at the Snowbird ski resort in Utah to discuss ways of creating software in a lighter, faster, more people-centric way. They created the Agile Manifesto, widely regarded as the canonical definition of agile development, and accompanying agile principles. Some of the principles behind the Agile Manifesto are:

Customer satisfaction by rapid, continuous delivery of useful software Working software is delivered frequently (weeks rather than months) Working software is the principal measure of progress Even late changes in requirements are welcomed Close, daily cooperation between business people and developers Face-to-face conversation is the best form of communication Projects are built around motivated individuals, who should be trusted Continuous attention to technical excellence and good design Simplicity Self-organizing teams Regular adaptation to changing circumstances

The publishing of the manifesto spawned a movement in the software industry known as agile software development.

Page 7

CHARACTERISATION

Miller gives the following characteristics to agile software processes from the fast delivery point of view, which allow shortening the life cycle of projects:

1. 2. 3. 4. 5. 6. in small steps. 7. 8. 9.

Modularity on development process level. Iterative with short cycles enabling fast verifications and corrections. Time bound with iteration cycles from 1 to 6 weeks. Parsimony in development process removes all unnecessary activities. Adaptive with possible emergent new risks. Incremental process approach that allows functioning application building

Convergent approach minimizes the risk. People-oriented. Collaborative and communicative working style.

Agile methods are designed to:

feedback.

Produce the first delivery in weeks, to achieve an early win and rapid

Invent simple solutions, so there is less to change and making those

changes is easier. Improve design quality continually, making the next iteration less costly to

implement, and Test constantly, for earlier, less expensive, defect detection.

Page 8

The basic principles of agile methods comprise an unforgiving honesty of working code, effectiveness of people working together with goodwill and focus on teamwork.

DEFINITIONS

The agile movement in software industry saw the light of day with the Agile Software Development Manifesto published by a group of practitioners and consultants in 2001.The focal values honored by agilists are:

Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan

These central values that the agile community adheres to are: First, the agile movement emphasizes the relationship and communality of software developers and the human role reflected in the contracts, as opposed to institutionalized processes and development tools. In the existing agile practices, this manifests itself in close team relationships, close working environment arrangements, and other procedures boosting teamwork.

Second, the vital objective of the software team is to continuously turn out working software. New releases are produced at frequent intervals, in some approaches even hourly or daily. But more usually bi-monthly or monthly. The developers are urged to keep the code simple, straightforward and technically as advanced as possible, thus lessening the documentation burden to an appropriate level.

Page 9

Third, the relationship and cooperation between the developers and the clients is given preference over strict contracts, although the importance of well drafted contracts does grow at the same pace as the size of the software project. The negotiation process itself should be seen as a means of achieving, and maintaining a viable relationship. From a business point of view, agile development is focused on delivering business value immediately as the project starts, thus reducing the risk of non-fulfillment regarding the contract.

Fourth, the development group, comprising both software developers and customer representatives should be well informed, competent and authorized to consider possible adjustment needs emerging during the development process life cycle. This means that the participants are prepared to make changes and also the existing contracts are formed with tools that support and allow this enhancement to be made.

Cockburn defines the core of agile software development methods as the use of light but sufficient rules of project behavior and the use of human and communication oriented rules. The agile process is both light and sufficient. Lightness is a means of remaining maneuverable. Sufficiency is a matter of staying in the game. He proposes the following sweet spots the presence of which in software development work enhances the prospects for a successful project outcome:

- Two to eight people in one room. o Communication and community

- Onsite usage experts o Short and continuous feedback cycles

- Short increments Page 10

o One to three months, allow quick testing and repairing

- Fully automated regression tests o Unit and functional improvement tests stabilize code and allow continuous

- Experienced developers o Experience speed up development time from 2 to 10 times compared to slower team members

Page 11

EXISTING AGILE METHODS

Currently existing agile methods are

1. 2.

Extreme Programming Scrum

1.EXTREME PROGRAMMING

Extreme Programming (XP) has evolved from the problems caused by the long development cycles of traditional development models. It first started as simply an opportunity to get the job done with practices that had been found effective software development processes during the preceding decades. The term extreme comes from taking the common sense principles and practices to extreme levels.

PROCESS

The life cycle of XP consists of five phases: Exploration, Planning, Iterations to Release, Productionizing, Maintenance and Death.

Page 12

In the Exploration phase, the customers write out the story cards that they wish to be included in the first release. Each story card describes a feature to be added into the program. At he same time the project team familiarize themselves with the tools, technology and practices they will be using in the project. The exploration phase takes between a few weeks to a few months, depending largely on how familiar the technology is to the programmers.

The Planning phase sets the priority order for the stories and an agreement of the contents of the first small release is made. The programmers first estimate how much effort each story requires and the schedule is then agreed upon. The time span of the schedule of the first release does not normally exceed two months. The Planning phase itself takes a couple of days.

The Iterations to Release phase includes several iterations of the system before the first release. The schedule set in the planning phase is broken to a number of iterations that will each take one to four weeks to implement. The first iteration creates a system with the architecture of the whole system. This is achieved by selecting the stories that will enforce building the structure for the whole system. The customer decides the stories to be selected for each iteration. The Page 13

functional tests created by the customer are run at the end of every iteration. At the end of the last iteration the system is ready for production.

The Productionizing phase requires extra testing and checking of the performance of the system before the system can be released to the customer. At this phase new changes may still be found and decision has to be made if they are included in the current release. During this phase, the iterations may need to be quickened from three weeks to one week.

After the first release is productionized for customer use, the XP project must both keep the system in the production running while also producing new iterations. In order to do this, the Maintenance phase requires an effort also for customer support tasks. Thus, the development velocity may decelerate after the system is in the production. The maintenance phase may require incorporating new people into the team and changing the team structure.

The Death phase is near when the customer does no longer have any stories to be implemented. This requires that the system satisfy customer need also in other respects (eg. concerning performance and reliability). This is the time in the XP process when the necessary documentation of the system is finally written as no more changes to the architecture, design or code are made. Death may also occur if the system is not delivering the desired outcomes, or if it becomes too expensive for further development.

Page 14

ROLES AND RESPONSIBILITIES OF XP

There are different roles in XP for different tasks and purposes during the process and its practices. Some of the roles are:

a. Programmer

Programmers write tests and keep the program code as simple and definite as possible. The first issue making XP successful is to communicate and coordinate with other programmers and team members.

b. Customer The customer writes the stories and functional tests, and decides when each requirement is satisfied. He sets the implementation priority for the requirements. c. Tester

Testers help the customer write functional tests. They run functional tests regularly, broadcast test results and maintain testing tools.

d. Tracker

Tracker gives feedback in XP.He traces the estimates made by the team and gives feedback on how accurate they are in order to improve future estimations. Page 15

e. Coach

Coach is the person responsible for the person as a whole. A sound understanding of XP is important in this role enabling the coach to guide the other team members in following the process.

f. Consultant

Consultant is an external member possessing the specific technical knowledge needed. The consultant guides the team in solving their specific problems.

g. Manager (Big Boss)

Manager makes the decisions. For this he communicates with the project team to determine the current situations, and to distinguish any difficulties or deficiencies in the process.

SCOPE OF USE

The XP methodology is by no means suitable everywhere, nor have all its limits yet been identified. XP is aimed for small and medium sized teams. Team size is limited between three and a maximum of twenty project members. The physical environment is also important in XP.

Page 16

Communication and coordination between project members should be enabled at all times. For example, scattering of programmers on two floors or even on one floor is intolerable for XP. The business culture affecting the development is another focal issue in XP. Any resistance against XP practices and principles on behalf of project members, management or customer may be enough to fail the process. Also technology might provide insuperable obstacles for the success of an XP project. For example, a technology that demands a long feedback time is not suitable for XP processes.

2.SCRUM

The Scrum approach has been developed for managing the systems development process. Scrum concentrates on how the team members should function in order to produce the system flexibly in a constantly changing environment. The main idea of Scrum is that systems development involves many environmental and technical variables (e.g. requirements, time, frame, resources and technology) that are likely to change during the process. This makes the development process unpredictable and complex, requiring flexibility of the systems development process for it to be able to respond to the changes. As a result of the development process a system is produced, which is useful when delivered.

Scrum helps to improve the existing engineering practices (testing) in an organization, for it involves frequent management activities aiming at consistently identifying any deficiencies or impediments in the development process as well as the practices that are used.

PROCESS
Scrum process includes three phases: pre-game, development and post-game. Page 17

The pre-game phase includes two sub phases: Planning and Architecture/High level design. Page 18

Planning includes the definition of the system being developed. A product backlog list is created containing all the requirements that are currently known. The requirements can originate from the customer, sales and marketing division, customer support or software developers. The requirements are prioritized and the effort needed for their implementation is estimated. The product backlog list is constantly updated with new and more detailed items, as well as with more accurate estimations and new priority orders. At every iteration, the updated product backlog is reviewed by the scrum team so as to gain their commitment for the next iteration In the architecture phase, the high level design of the system including the architecture is planned based on the current systems in the Product Backlog. In case of an enhancement to an existing system, the changes needed for implementing the Backlog items are identified along with the problems they may cause a design review meeting is held to go over the proposals for the implementation and decisions are made on the basis if this review. Also preliminary plans for the contents of releases are prepared. The development phase is the agile part of the scrum approach. This phase is treated as a black box where the unpredictable is expected. The different environmental and technical variables (such as time frame, requirements, resources, implementation technologies and tools) identified in Scrum, which may change during the process are observed and controlled through various scrum practices during the development phase. The post-game contains the closure of the release. This phase is entered when an agreement has been made that the environmental variables such as the requirements are completed. In this case no more items and issues can be found nor can any new ones be invented. The system is now ready for the release and the preparation for this is done in the post- game phase including the tasks such as integration, system testing and documentation. ROLES AND RESPONSIBILITIES There are five identifiable roles in Scrum that have different tasks and purposes during the process and its practices. Scrum Master, Product Owner, Scrum Team, Customer and Management. a. Scrum Master Scrum Master is a new management role introduced by Scrum. Scrum Master is responsible for ensuring that the project is carried through according to the practices, values and

Page 19

rules of Scrum and that it progresses as planned. Scrum Master interacts with the project team as well as with the customer and management during the project. b. Product Owner Product Owner is officially responsible for the project, managing controlling and making visible the product backlog list. He us selected by the Scrum Master, the customer and management. He makes the final decisions of the tasks related to product backlog, participates in estimating the development effort for backlog items and turns the issues in the backlog into features to be developed. c. Scrum Team Scrum Team is the project team that has the authority to decide on the necessary actions and to organize itself according to the goals of each Sprint. The scrum team is involved, for example, in effort estimation, creating the Sprint Backlog reviewing the product backlog list and suggesting impediments that need to be removed from the project. d. Customer Customer participates in the tasks related to product backlog items for the system being developed or enhanced. e. Management Management is in charge of final decision making, along with the standards and conventions to be followed in the project. Management also participates in setting of goals and requirements. SCOPE OF USE Scrum is a method suitable for small teams of less than 10 engineers. The developers suggest for the team to comprise five to nine project members .If more people are available multiple teams should be formed.

Page 20

COMPARISON WITH OTHER METHODS

Agile methods are sometimes characterized as being at the opposite end of the spectrum from "plan-driven" or "disciplined" methodologies. This distinction is misleading, as it implies that agile methods are "unplanned" or "undisciplined". A more accurate distinction is to say that methods exist on a continuum from "adaptive" to "predictive". Agile methods exist on the "adaptive" side of this continuum. Adaptive methods focus on adapting quickly to changing realities. When the needs of a project change, an adaptive team changes as well. An adaptive team will have difficulty describing exactly what will happen in the future. The further away a date is, the more vague an adaptive method will be about what will happen on that date. An adaptive team can report exactly what tasks are being done next week, but only which features are planned for next month. When asked about a release six months from now, an adaptive team may only be able to report the mission statement for the release, or a statement of expected value vs. cost. Predictive methods, in contrast, focus on planning the future in detail. A predictive team can report exactly what features and tasks are planned for the entire length of the development process. Predictive teams have difficulty changing direction. The plan is typically optimized for the original destination and changing direction can cause completed work to be thrown away and done over differently. Predictive teams will often institute a change control board to ensure that only the most valuable changes are considered. Agile methods have much in common with the "Rapid Application Development" techniques from the 1980's as espoused by James Martin and others.

CONTRAST WITH ITERATIVE DEVELOPMENT METHOD Most agile methods share other iterative and incremental development methods' emphasis on building releasable software in short time periods. Agile development differs from other methods in that its time periods are measured in weeks rather than months and work is performed in a highly collaborative manner. Most agile methods also differ by treating their time period as a strict time box. Page 21

CONTRAST WITH WATERFALL METHOD Agile development does not have much in common with the waterfall model. As of 2004, the waterfall model is still in common use. The waterfall model is the most predictive of the methodologies, stepping through requirements capture, analysis, design, coding, and testing in a strict, pre-planned sequence. Progress is generally measured in terms of deliverable artifacts requirement specifications, design documents, test plans, code reviews and the like. The main problem of the waterfall model is the inflexible nature of the division of a project into separate stages, so that commitments are made early on, and it is difficult to react to changes in requirements. Iterations are expensive. This means that the waterfall model is likely to be unsuitable if requirements are not well understood or are likely to change radically in the course of the project. Agile methods, in contrast, produce completely developed and tested features (but a very small subset of the whole) every few weeks or months. The emphasis is on obtaining the smallest workable piece of functionality to deliver business value early, and continually improving it/adding further functionality throughout the life of the project. Some agile teams use the waterfall model on a small scale, repeating the entire waterfall cycle in every iteration. Other teams, most notably Extreme Programming teams, work on activities simultaneously.

CONTRAST WITH COWBOY CODING Cowboy coding is the absence of a defined method: team members do whatever they feel is right. Agile development's frequent re-evaluation of plans, emphasis on face-to-face communication, and relatively sparse use of documents sometimes causes people to confuse it with cowboy coding. Agile teams, however, do follow defined (and often very disciplined and rigorous) processes. As with all methodologies, the skill and experience of the users define the degree of success and/or abuse of such activity. The more rigid controls systematically embedded within a process offer stronger levels of accountability of the users. The degradation of well-intended procedures can lead to activities often categorized as cowboy coding.

Page 22

SUITABILITY OF AGILE METHODS

Although agile methods differ in their practices, they share a number of common characteristics, including iterative development, and a focus on interaction, communication, and the reduction of resource-intensive intermediate artifacts. The suitability of agile methods in general can be examined from multiple perspectives. From a product perspective, agile methods are more suitable when requirements are emergent and rapidly changing; they are less suitable for systems that have high criticality, reliability and safety requirements, though there is no complete consensus on this point. From an organizational perspective, the suitability can be assessed by examining three key dimensions of an organization: culture, people, and communication. In relation to these areas a number of key success factors have been identified. They are

The culture of the organization must be supportive of negotiation People must be trusted Fewer but more competent people Organizations must live with the decisions developers make Organizations need to have an environment that facilitates rapid

communication between team members The most important factor is probably project size. As size grows, face-to-face communication becomes more difficult. Therefore, most agile methods are more suitable for projects with small teams, with fewer than 20 to 40 people. Large scale agile software development remains an active research area. Another serious problem is that initial assumptions or overly rapid requirements gathering up front may result in a large drift from an optimal solution, especially if the client defining the target product has poorly formed ideas of their needs. Similarly, given the nature of human behavior, it's easy for a single "dominant" developer to influence or even pull the design of the target in a direction not necessarily appropriate for the project. Historically, the developers can, and often do, impose solutions on a client then convince the client of the appropriateness of the solution, only to find at the end that the solution is actually unworkable. In theory, the rapidly iterative nature should limit this, but it assumes that there's a negative feedback, or even appropriate feedback. If not, the error could be magnified rapidly. Page 23

This can be alleviated by separating the requirements gathering into a separate phase (a common element of Agile systems), thus insulating it from the developer's influence, or by keeping the client in the loop during development by having them continuously trying each release. The problem there is that in the real world, most clients are unwilling to invest this much time. It also makes QAing a product difficult since there are no clear test goals that don't change from release to release. In order to determine the suitability of agile methods individually, a more sophisticated analysis is required. The DSDM approach, for example, provides a so-called suitability-filter for this purpose. Also, the Crystal family of methods provides criteria on how to select the method for a given project. The selection is based on project size, criticality and priority. The DSDM and Feature Driven Development (FDD) methods are claimed to be suitable for any agile software development project, regardless of situational characteristics. A comparison of agile methods will reveal that they support different phases of a software development life-cycle to varying degrees. This individual characteristic of agile methods can be used as a selection criterion for selecting candidate agile methods. In general a sense of project speed, complexity, and challenges will guide you to the best agile methods to implement and how completely to adopt them. Agile development has been widely documented as working well for small (<10 developers) co-located teams. Agile development is expected to be particularly suitable for teams facing unpredictable or rapidly changing requirements. Agile development's applicability to the following scenarios is open to question:

Large scale development efforts (>20 developers), though scaling

strategies and evidence to the contrary have been described.

Distributed development efforts (non-co-located teams). Mission- and life-critical efforts Command-and-control company cultures

It is worth noting that several large scale project successes have been documented by organizations such as BT which have had several hundred developers situated in the UK, Ireland and India, working collaboratively on projects and using agile methodologies. While questions

Page 24

undoubtedly still arise about the suitability of some agile methods to certain project types, it would appear that scale or geography, by themselves, are not necessarily barriers to success. Barry Boehm and Richard Turner suggest that risk analysis be used to choose between adaptive ("agile") and predictive ("plan-driven") methods. The authors suggest that each side of the continuum has its own home ground: Agile home ground:

Low criticality Senior developers Requirements change very often Small number of developers Culture that thrives on chaos

Plan-driven home ground:

High criticality Junior developers Requirements don't change too often Large number of developers

Page 25

AGILE DATA
One of the most challenging parts of an agile project is being agile with data. Typically this is where projects hit legacy systems and legacy requirements. Many times working with data systems requires lengthy requests to teams of specialists who are not used to the speed of an agile project and insist on exact and complete specifications. Typically the database world will be at odds with agile development. The agile framework seeks as much as possible to remove these bottlenecks with techniques such as generative data models making change fast. Models for data serve another person; often a change of one table column can be a critical issue requiring months to rebuild all the dependent applications. An agile approach would try to encapsulate data dependencies to go fast and allow change. But ultimately relational data issues will be important for agile projects and are a common blockage point. As such agile projects are best suited where projects don't contain big legacy databases. It still isn't the end of the world because if you can build your data dependencies to be agile regardless of legacy systems you will start to prove the merit of the approach as all other systems go through tedious changes to catch up with data changes while in the protected agile data system the change would be trivial.

Page 26

AGILE METHODS AND METHOD TAILORING

In the literature, different terms refer to the notion of method adaptation, including method tailoring, method fragment adaptation and situational method engineering. Method tailoring is defined as: A process or capability in which human agents through responsive changes in, and dynamic interplays between contexts, intentions, and method fragments determine a system development approach for a specific project situation. Potentially, almost all agile methods are suitable for method tailoring. Even the DSDM method is being used for this purpose and has been successfully tailored in a CMM context. Situation-appropriateness can be considered as a distinguishing characteristic between agile methods and traditional software development methods, with the latter being relatively much more rigid and prescriptive. The practical implication is that agile methods allow project teams to adapt working practices according to the needs of individual projects. Practices are concrete activities and products which are part of a method framework. In the case of XP the need for method adaptation is made explicit. One of the fundamental ideas of XP is that there is no process that fits every project as such, but rather practices should be tailored to the needs of individual projects. There are also no experience reports in which all the XP practices have been adopted. A distinction can be made between static method adaptation and dynamic method adaptation. The key assumption behind static method adaptation is that the project context is given at the start of a project and remains fixed during project execution. The result is a static definition of the project context. Given such a definition, route maps can be used in order to determine which structured method fragments should be used for that particular project, based on predefined sets of criteria. Dynamic method adaptation, in contrast, assumes that projects are situated in an emergent context. An emergent context implies that a project has to deal with emergent factors that affect relevant conditions but are not predictable. This also means that a project context is not fixed, but changing during project execution. In such a case prescriptive route maps are not appropriate. The practical implication of dynamic method adaptation is that project managers often have to modify structured fragments or even innovate new fragments, during the execution of a project.

Page 27

AGILE METHODS Some of the well-known agile software development methods: Agile Modeling

Agile Unified Process (AUP) Agile Data Daily kickoff and review of goals short release cycles Test Driven Development Responsive Development Generalism - Use of generic skill sets which are common across the team

not reliance on specific skill sets which are scarce

Feature Driven Development (FDD) Essential Unified Process(EssUP)

Other approaches:

Software Development Rhythms Agile Documentation ICONIX Process Microsoft Solutions Framework (MSF) Agile Data Method Database refectory

MEASURING AGILITY While agility is seen by many as a means to an end, a number of approaches have been proposed to quantify agility. Agility Index Measurements (AIM) score projects against a number of agility factors to achieve a total. The similarly named Agility Measurement Index, scores developments against five dimensions of software project (duration, risk, novelty, effort, and interaction). Other techniques are based on measurable goals. Another study using fuzzy mathematics has suggested that project velocity can be used as a metric of agility.

Page 28

CRITICISM
Agile development is sometimes criticized as cowboy coding. Extreme Programmings initial buzz and controversial tenets, such as pair programming and continuous design, have attracted particular criticism. However, much of the criticism is believed by Agile practitioners as misunderstandings about agile development. Criticisms include:

lack of structure and necessary documentation only works with senior-level developers incorporates insufficient software design requires too much cultural change to adopt can lead to more difficult contractual negotiations

The criticisms regarding insufficient software design and lack of documentation are addressed by the Agile Modeling method which can easily be tailored into agile processes such as XP. Agile software development has been criticized because it will not bring about the claimed benefits when programmers of average ability use this methodology, and most development teams are indeed likely to be made up of people with average (or below) skills. POST AGILISM In software engineering, post-Agilism is an informal movement of former "Agilists" (Agile Software Development evangelists) who have chosen to draw from a much wider range of methods and schools of thought on software development, preferring to avoid being constrained by what they consider to be "Agile Dogma". The term Fragilism is sometimes used to mean the same thing. Much of the debate around Post-Agilism centers around the meaning of the word Agile with a capital 'a' - vs. "agile" (the dictionary definition of the word). In late 2005, Jason Gorman argued that the meaning of Agile was ambiguous and was being inappropriately applied to a very wide range of approaches like Six Sigma and CMMi. He also argued that "Agile", "evolutionary", and "lean" (as in Lean software development) did not mean the same thing in practice, even though they are all lumped under the banner of "Agile" - possibly for marketing Page 29

purposes. Gorman argued that process-oriented methods, especially methods that incrementally reduce waste and process variation like Six Sigma, have a tendency to limit an organizations adaptive capacity (their "slack"), making them less able to respond to discontinuous change - i.e., less agile. He also argues in later posts that "agile", "lean" and "evolutionary" are strategies that need to be properly understood and appropriately applied to any specific context. That is, there is a time to be "agile", a time to be "lean" and a time to be "evolutionary". The debate continued on various discussion groups, and transferred into the blogosphere in December 2005. In June 2006 the debate widened and the term Post-Agilism was coined by Jonathan Kohl to describe the growing - but still very loose - association of people extolling "post-Agile" sentiments in their work. Much of the post-Agile thinking centers on Nonlinear Management, a superset of management techniques that include many agile practices.

Page 30

CONCLUSION
Studies have shown that traditional plan-driven software development methodologies are not used in practice. The traditional methodologies are too mechanistic to be used in detail. As a result, industrial software developers have become skeptical about new solutions that are difficult to grasp and thus remain unused. Agile software development methods, officially started with the publication of the agile manifesto, make an attempt to bring about a paradigm shift in the field of the software engineering. Agile methods claim to place more emphasis on people, interaction, working software, customer collaboration, tools, contracts and plans. A number of promising new methodologies claiming conformance to these agile principles have been introduced. Yet, no systematic review of the agile methods has been attempted. What makes a development method an agile one? The conclusion was that this is the case when software development is Incremental (small software releases, with rapid cycles), Cooperative (customer and developers working constantly together with close communication) Straight forward (the method itself is easy to learn and to modify, well documented), and Adaptive (able to make last moment changes)

Anecdotal evidence suggests that agile methods are effective and suitable for many situations and environments. Moreover, the frequent release of new agile methods is more likely to bring about confusion rather than clarity. Each method uses its own vocabulary and terminology and little work is being done in integrating the many viewpoints expressed. In conclusion, agile thinking is a people-centric view to software development. People-centered strategies have been argued for as an important source of competitive advantage, because, unlike technology, cost, or new product Page 31

development, these human strategies are difficult to imitate. This, however, is not a realization. A1990 issue of the American Programmer (Ed Yourdons Software Journal) was devoted exclusively to Peopleware. The editor comments the special issue by pointing out that Everyone knows the best way to improve software productivity and quality is to focus on people. Thus, the ideas that agile methods bring about are not new, nor do the agilists claim so. We, however, believe that agile software development methods provide a novel way of approaching software engineering problems, while also maintaining that the methods are by no means exhaustive or capable of solving all the problems.

Page 32

BIBILIOGRAPHY

1. CSI COMMUNICATIONS Agile Software July 2007 Volume No: 31

WEBSITES www.wikipedia.com www.agilemodelling.com www.agilesoftware.com

Page 33

Page 34