Click here to Skip to main content
13,355,311 members (62,113 online)
Click here to Skip to main content
Add your own
alternative version


21 bookmarked
Posted 15 Apr 2008

Agile and Other Development Methods

, 6 Jul 2010
Rate this:
Please Sign up or sign in to vote.
Agile methods are evolved to adopt changes quickly during the development.


Agile methods have evolved so that changes during development can be quickly adopted. This approach is the opposite of plan driven traditional approaches. The main focus of agile methods is the early release of working software by responding promptly to changes in specifications using collaborative techniques, code refactoring, test driven development and customer involvement.

As stated in the Agile Manifesto (

  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

Agile methods follow these principles (

  • Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
  • Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
  • Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
  • Business people and developers must work together daily throughout the project.
  • Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
  • The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
  • Working software is the primary measure of progress.
  • Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
  • Continuous attention to technical excellence and good design enhances agility.
  • Simplicity - the art of maximizing the amount of work not done - is essential.
  • The best architectures, requirements, and designs emerge from self-organizing teams.
  • At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

Every agile method tries to follow these basic principles in order to overcome the common problems that occur during and after any software and project development. Every agile method defines its own set of practices based upon the above principles. The intention behind the evolution of these methods is to serve the customer better and to make the development process simpler. In this article we will discuss agile methods and compare them with other more traditional development methods.


In general we follow two types of software development methods:

  • Traditional, Plan Driven methods (waterfall, spiral, iterative etc), and
  • Undefined methods (we treat them as without any formal process).
Some of the most common problems faced during and after software project development are discussed in the following sections.

Frequent changes from the client

In the traditional development model, first we collect and freeze the requirements based upon discussions with the client, then do the development and testing and finally send the release to the client. However, in most of cases we find that the client's expectations have changed by the time of software delivery, so we put our efforts in mapping the expectations to the approved requirements and then try to talk the client out of all the out of scope functionalities. Sometimes we able to convince them to include the additional functionality in next development phase and sometimes we include the changes to make the client happy.

In some cases we receive frequent small changes from the client and it is almost impossible to apply classical processes, so we implementing changes after delivery on an ad-hoc basis. Gradually, this creates a chaotic situation and the project ends up in a nearly unmanageable state.

Dependency on resources

Since different teams are responsible for different phases of development, there are more dependencies on their respective resources.

Documentation takes lot of time

Often we find documentation consumes lot of time. It's very hard to create and update the documentation for short duration projects or projects with short deadlines.

Impact analysis very complex

We always emphasize the creation of documents that must cover all the important information, when everything relevant is included, the document becomes very large. Hence although we create all required documents, when we do impact analysis, it becomes a cumbersome job.

All of these problems lead us to consider other possible alternatives.

Comparison with other existing methods

Defined ProcessesRequiredRequiredRequiredPlanning & Closure only
Final productDetermined during planningDetermined during planningSet during projectSet during project
Project CostDetermined during planningPartially variableSet during projectSet during project
Project Completion DateDetermined during planningPartially variableSet during projectSet during project
Responsiveness to environmentPlanning onlyPlanning primarilyAt end of each iterationThroughout
Team flexibility, creativityLimited, cookbook approachLimited, cookbook approachLimited, cookbook approachUnlimited during iterations
Knowledge transferTraining prior to projectTraining prior to projectTraining prior to projectTeamwork during project
Probability of successLowMedium LowMediumHigh

(Source: SCRUM Development process by Ken Schwaber)

Limitations of Agile Method

Limited Support for distributed environments

Face to face communication is an essential characteristic of agile processes. The emphasis on co-location advocated by agile processes does not fit well with the trend in some industries toward globally distributed software development environments. Development environments in which team members and customers are physically separated may not be able to accommodate the face-to-face communications advocated by agile processes. In such cases, one can approximate face-to-face communications using technologies such as video-conferencing, but these technologies are sometimes expensive and not as effective as one would hope.

My Comment:Martin Fowler, a famous author and international speaker on software architecture, specializing in object-oriented analysis and design, UML, patterns, and agile software development methodologies, including extreme programming, has considerd this problem and has shared his experience in this article: All we need to do is customize and use some creativity in existing agile practices to compensate.

Limited support for building reusable resources

A case against agile processes is that they target specific problems in the software and are deficient in producing generalized solutions.

My Comment: Building reusable resources is a very controversial topic. It's very hard to develop something that is truly reusable. Declaring something to be reusable is not enough. Many times I have come across so called "reusable resources" in my projects and needed to make drastic modifications, so that it would have been easier to create new resource as per my own requirements.

Limited support for developing safety-critical software

It is said that agile quality control mechanisms like pair programming, informal reviews, refactoring, etc. are not sufficient to assure users of the safety of the final product.

My Comment: I have used TDD, pair programming, informal reviews, and refactoring and achieved great success in the final product. I want to emphasize once again that we are free to customize or modify the existing process as needed.

Limited support for development involving large teams

This is a well known limitation to agile processes. It is believed that agile process more more suitable for small collocated teams.

My Comment: This is nothing more than an assumption. I have seen many people and organizations that have successfully used agile methods in large projects and large, distributed teams.

What we currently do? Do we need it?

As discussed initially, currently most organizations follow a plan driven method or follow nothing. Normally, in the case of large projects the processes are followed, but all of us understand the limitations of this effort. Some times we get small projects or have projects with frequent small changes and we therefore inadvertently put the processes aside to achieve a timely result and try to make client happy.

One obvious question arises: Will the use of agile methods solve these problems?

My answer is: I can’t say. I am not sure.

So, what is the point of this discussion?

First of all, the intention of this discussion is not to provide you a solution that will always work for all projects. But to make you aware of existing alternatives. We don't need to use the same methodology for all projects. Instead we must choose a methodology from the existing lists while considering the nature of each project.

In additionas, by studying and comparing different development methods based upon experience, we can also follow some mixed practices. Below are some best practices of agile process:

  • Unit-Testing and Test-Driven Development ensures that bugs and errors are found quickly and early so they are cheaper to fix.
  • On-site customer and functional testing ensures that the analysis and specification of the system is up-to-date and corresponds to business requirements.
  • Pair programming allows two developers working together on one computer, which increases the chances of finding bugs and leads to a simpler design
  • Refactoring "once and only once" increases design consistency and makes the structure simpler and more flexible. This ensures that the system is well-designed and easy to change.
  • Regular releases give the customer feedback and forces the team to make the "release to production" and maintenance phases as cheap as possible.
  • Daily small status meetings ensure the progress is on track
  • Use of UML diagrams help to address difficult documentation and cumbersome impact analysis of any design changes.

We should always be free to customize the development methods depending upon the nature of each project. One can mix SCRUM and XP practices as well as other agile methods, however, it's not always simple to quickly adopt customized, agile methods. Indeed, it requires good creativity, deep analysis and open-mindedness.

Challenges in Adopting Agile Methods

Although agile methods are much hyped these days, it's not so easy to adopt in many organizations. People with traditional or closed mind sets, who do not easily adapt and learn new methods, are a big challenge anywhere. In some cases people specialized in one skill set can create problems. Agile methods require the participation of everyone, so team members with specialization in more than one field may be able to adopt agile methods easier. Some organizations follow a specific set of methods and do not want to change. Other organizations may simply ahave a fear of change.

Sometimes I feel a person with outdated skills also creates problems, as well as someone who loves to create detailed documents for every piece of project. Since design documentation can be addressed with UML design methods and agile methods focus on code development over creating UML designs, most documentation can be reduced and people or organizations who love long documentation don't like it.

The most important problem may well be the attempt to adopt agile practices all at once, abruptly. And finally, we should also keep in mind that office politics can also play a large role in the adoption and use of agile methods. In summary, below are the challenges in adopting agile methods:

  • Fear of change
  • Specialized skills
  • Outdated skills
  • Documentation heavy mind set
  • Do-it-all-at-once attitude
  • Serial Thinking
  • Closed Mindedness
  • Office Politics
  • Black and White mindset


If you are not having trouble with or are satisfied with the development method your organization is currently using, then there is no need to change to agile methods. The ultiamte goal is to meet the client's expectation and satisfaction. The goal of using agile methods should be to respond quickly to changes, even late in the development effort, and have complete satisfaction upon the delivery of any software or project.


This article, along with any associated source code and files, is licensed under The Code Project Open License (CPOL)


About the Author

Vinay Krishna
Software Developer Cegedim Software India Pvt Ltd
India India
I am a Software Professional worked as developer, tech lead, consultant and architect. I have Developed many portals and Client Server based applications using .Net, Plumtree, Business Object, COM/DCOM, RDBMS and OOP concepts that is easy to use and greatly enhance user’s ability in their work.

I am flourished in a fast-paced environment requiring excellent problem solving skills, multiple project completion under short deadlines and the ability to communicate with clients and end users.

As an architect I highly relied on my involvement and integration with the project teams. I played good role to understand the actual requirements and needs of the User. I decided the best technology to use based on the gathered requirements and designed more flexible, user friendly and robust system. I was the bridge between developers, project manager and business experts and ensured the technical directions and choices to build durable architectures.

I had worked with Nagarro, Algorism, Mascon etc earlier and played all different roles successfully.
Currently I am working with Cegedim, world’s leading CRM business for the life science industry, as a Senior Specialist. I have been here since April 2007.

You may also be interested in...


Comments and Discussions

GeneralMy vote of 1 Pin
Member 1101941518-Aug-14 3:01
memberMember 1101941518-Aug-14 3:01 
GeneralAgile vs non-Agile Pin
Ronaldo Madrid - INTERPAC13-Jul-08 2:08
memberRonaldo Madrid - INTERPAC13-Jul-08 2:08 
I like the impartiality of the way you discussed this topic, as most articles I've read about this were all super-macho agilists who believe that they're the only ones capable of delivering quality software.

Comparing Agile to non-Agile procedures is really like comparing Alternative and non-Alternative music. The truth about music is that they are all alternative. In any software developement project you have to adapt flexibly to changes, ragardless of how you call your internal process, be it SDLC, waterfall, Agile, or whatever. It has always been a part of the game so everything is really agile in that sense, and Agilists are hyprocites to think that they're the only ones capabale of doing that.
GeneralRe: Agile vs non-Agile Pin
Vinay Krishna13-Jul-08 19:14
memberVinay Krishna13-Jul-08 19:14 
Generalblablabla [modified] Pin
Gevorg16-Apr-08 3:14
memberGevorg16-Apr-08 3:14 
GeneralRe: blablabla Pin
Nirosh16-Apr-08 16:57
memberNirosh16-Apr-08 16:57 
GeneralRe: blablabla Pin
VirtualVoid.NET7-Jul-10 6:49
memberVirtualVoid.NET7-Jul-10 6:49 

General General    News News    Suggestion Suggestion    Question Question    Bug Bug    Answer Answer    Joke Joke    Praise Praise    Rant Rant    Admin Admin   

Use Ctrl+Left/Right to switch messages, Ctrl+Up/Down to switch threads, Ctrl+Shift+Left/Right to switch pages.

Permalink | Advertise | Privacy | Terms of Use | Mobile
Web04 | 2.8.180111.1 | Last Updated 6 Jul 2010
Article Copyright 2008 by Vinay Krishna
Everything else Copyright © CodeProject, 1999-2018
Layout: fixed | fluid