Introduction
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 (
http://www.agilemanifesto.org):
- 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 (
http://agilemanifesto.org/principles.html):
- 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.
Background
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
| |
Waterfall |
Spiral |
Iterative |
Agile |
| Defined Processes |
Required |
Required |
Required |
Planning & Closure only |
| Final product |
Determined during planning |
Determined during planning |
Set during project |
Set during project |
| Project Cost |
Determined during planning |
Partially variable |
Set during project |
Set during project |
| Project Completion Date |
Determined during planning |
Partially variable |
Set during project |
Set during project |
| Responsiveness to environment |
Planning only |
Planning primarily |
At end of each iteration |
Throughout |
| Team flexibility, creativity |
Limited, cookbook approach |
Limited, cookbook approach |
Limited, cookbook approach |
Unlimited during iterations |
| Knowledge transfer |
Training prior to project |
Training prior to project |
Training prior to project |
Teamwork during project |
| Probability of success |
Low |
Medium Low |
Medium |
High |
(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:
http://martinfowler.com/articles/agileOffshore.html. 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
Conclusion
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.
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Rant 
Admin 
if this is the case which criteria one can use to choose the best project methodology to use in the project. or there is possibilities to combine different methodology in one project.
ReplyDeleteThe methodology are determined by the needs of the organisation, resources, the budget and time available. It is also determined by the quality of the product.
ReplyDelete