What is Agile Development?
The term “Agile Development” is often misunderstood and confused. The mission statement for Agile software development is “Develop quickly, deliver often.” This single thought is the driving force behind the idea of Agile development.
The idea of Agile is being able to adapt and change direction when necessary. In regards to the concept of Agile development, the developer needs to be able to match and meet what the client requests, while sticking to the single concept of being able to adjust quickly. It is also important to be able to switch gears when new changes are requested at any point in the project.
The choice in becoming more Agile is not on that should be taken lightly. For many companies, it requires changes in the normal day-to-day procedures that every developer normally follows. Agile methods quickly expose the weak points in projects that normally lead to project failure. Once a weak point has been found, the team uses that information to improve the next iteration (or sprint) so as to avoid similar mistakes, and help ensure the success of the project. Although Agile cannot guarantee zero mistakes, it does help to improve quality and productivity.
Productivity with quality is important because most believe it is important to focus on both at the same time. Many believe that if you need to finish a project before a deadline, you cannot focus on quality as you could if you had more time. On the other side of the coin, more time is required if a project is to be more error free. There is often conflict between the two, and often certain details are bypassed to meet deadlines. “Good, fast, cheap - pick two” is an often-heard cliché in software development. With Agile, it does not ring true.
With Agile, you focus on the delivery of quality product while continuously improving productivity, all while staying with a set budget. By using sprints, or time-boxed development cycles, Agile focuses on meeting customer requirements on an incremental basis. This means that the smaller sections, or increments, can be delivered at regular intervals and shown to the product owner, which can be manager or a client, along with other stakeholders. When each increment is presented, alternative or additional requests can be made.
It is easier to recognize how shorter sections of an overall project can be accomplished in less time. On a psychological level, individuals dread long, drawn out projects. When a project is smaller in nature, it encourages the developers to accomplish the project in a smaller amount of time without wasting any time reflecting on the immensity of the project. In addition, it is far easier to meet requested changes when projects are divided up into sprints, as opposed to being interrupted in the middle of the process.
When a project is divided, it also allows for more individual attention to be placed on each feature, thus encouraging a higher level of commitment. When more attention is focused on individual parts, it will yield a higher quality of work than a monolithic project might receive. In a race, runners improve their stamina by pacing themselves, allowing them to run for a greater period of time. This same principal holds true with Agile.
In traditional project management methods, client changes were highly disruptive. With Agile, change is not only expected, it’s welcomed. Every sprint cycle, the client can change the direction of the project. At each sprint review the client sees the current progress, and updates their priorities and plans accordingly. This gives the client great flexibility. It also allows the development team to keep the project requirements in mind as they are reviewing them.
Many traditional developers feel that the old ways are best where they focus on a large project, and prefer to have a single deadline rather than many smaller ones. However, human nature has shown that in most cases it is best to set smaller goals that are more easily achieved. This gives the development team much more focus, and the client more flexibility. Following Agile also allows a client to notice any possible changes that are needed, correct them as the project continues, and still meet deadlines. If a project was presented as one large final product, this would mean that if anything were to change, developers would have to return to a point they did some time ago and try to remember what they did, thus delaying the entire project.
About The Author :: Robert Dempsey
Robert Dempsey is a Certified ScrumMaster and CEO of Atlantic Dominion Solutions, a
Ruby on Rails development shop
in Winter Park, Florida. Robert has lectured, trained, and provided coaching and consulting to many software developers and small business owners since 2000.
Please Note:
This article is copyright to the author and may not be reproduced without permission.
|