Agile and Other Development Methods

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

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).

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

(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.