Why adopt an Agile software development methodology?

Why adopt an Agile software development methodology?


For many decades, organizations have been trained to believe that the most effective way to develop software is to fully define requirements up front, thoroughly describing them in analysis documents and then carefully completing the design before building the system. Once the application is completely built, it is integrated and tested. Engineers have been taught that if they do not follow this phase-based approach and carefully design the system upfront to prevent mistakes it will increase enormously the costs of maintenance and bug fixing of the projects. Customers have also been led to believe that this phase-based approach is the only acceptable choice for building software. They embrace the concept of specifying everything they want in advance, then waiting for the architects and engineers to return many months later with the finished product. When a project does fail, the common explanation is (still…) that the team neglected to spend enough time up front in requirements definition or technical design.

This mindset has become even more reinforced by auditors who expect to see certain documents signed off at key points along the project lifecycle.

After years of failed projects being blamed on the same side, disruptive methodologies have appeared, to establish new approaches for creating applications. The Agile Methodologies are among these new approaches and their growing adoption has caught the attention of analysts and IT gurus worldwide.

But, what makes Agile Methodologies different from traditional engineering methods?

  • There are two major differences between both methodologies:
    • Instead of finding a new way to improve requirements definition, Agile methods assume that these initial definitions will be changed, focusing the teams effort in adapting to new requirements rather than in predicting them. Even if analysts could settle the fuzziness of requests and get an accurate and stable set of requirements, the projects wouldn’t be kept from failing. In today’s economy the fundamental business forces change the value of software features too rapidly and most of these changes are unpredictable. That’s with IT teams need methodologies that give them control over unpredictability. This is what adaptive processes is all about.
    • Agile methods are people-oriented rather than process-oriented. The goal of traditional engineering methods is to define a process that will work well whoever happens to be using it. Agile methods assert that no process will ever make up the skill of the development team, so the role of a process is to support the development team in their work.

Why should organizations adopt agile development?

  • Agile methods minimize the projects’ risk of failure by introducing specific development techniques. The most important mechanism to avoid this is to iteratively and accurately get information about the project situation. The key to iterative development is to frequently produce working versions of the final system that have a subset of the required features. These working systems are short on functionality, but should otherwise be faithful to the demands of the final system. They should be fully integrated and as carefully tested as a final delivery.
  • The point of this method is that there is nothing like a tested, integrated system for bringing a forceful dose of reality into any project. Documents can hide all sorts of flaws. Untested code can hide plenty of flaws. But when people actually sit in front of a system and work with it, then flaws become truly apparent: both in terms of bugs and in terms of misunderstood requirements.

But, how frequently should iteration occur?

  • The tendency of agile methodologies is to make each iteration cycle as short as possible, but usually they take no longer than one month. This provides more frequent feedback, keeping a more accurate track of the projects.
  • This kind of adaptive process requires a different kind of relationship with a customer than the ones that are often considered. The customer has much finer-grained control over the software development process and at every iteration, gets to check progress and to alter the direction of the software development. This leads to much closer relationship with the software developers, a true business partnership.
  • All this yields a number of advantages for customers. For a start they get much more responsive software development. A usable, although minimal, system can go into production earlier on. The customer can then change its capabilities according to business evolution and also from learning how the system is used in reality.

For further information on this topic, please also consult the Showcasing Agile Development whitepaper, from Digital Focus, and follow this link to learn more agile methodologies.

As you may know, the project development starts off with choosing an appropriate software development methodology.

Software development methodology, or system development methodology  --  splitting software and building work into different stages with certain activities for the purpose of more effective planning and management.

There are numerous software development methodologies such as Waterfall, Cleanroom, Rapid Application Development (RAD), Team Software Process (TSP), Personal Software Process, Scrum, Kanban, Extreme Programming (XP), and dozens of other iterative and agile software development approaches.

                                                   Waterfall methodology for software development

To get more about software development methodology, I recommend this short article - A Fresh Take on 5 Software Development Methodologies