Important Things You Need To Know About Agile Development

Information may not be reliable

In 2001, a group of 17 software developers met and discussed a new philosophy in software development. It was their opinion that the development practices of the 20th century were no longer appropriate in the 21st. Clients were frustrated by the lack of communication. Developers were frustrated by the regular need for revisions on finished projects. The product of their time together was a list of 12 principles published as part of their “Manifesto for Agile Software Development”.

The focus of this style of development is not what is being produced but how it is produced. Agile practices can be applied to any type of project. They focus on giving programming teams flexibility and efficient productivity.

Agile Values

Agile software development is based on several values that are meant to increase communication among developers and between developers and clients. They are also intended to allow clients to have a better sense of project progress so that revisions can be addressed earlier in the process.

Clear Communication: Programming team members need to be in regular communication so that questions can be answered quickly and instructions delivered directly. This makes communication more efficient, keeping everyone on the same page. It also streamlines the development process.

Short-term Goals over Long-term Plans: Agile software development encourages breaking projects down into smaller pieces. Partners and teams are assigned small chunks of programming with short deadlines. Short-term goals allow for greater flexibility. As changes arise, goals can be more easily modified.

Active Collaboration between Client and Developers: One of the frustrations for clients was not being able to see the progress on a project. At the same time, developers would be frustrated when a finished project was sent back for multiple revisions. By bringing the client in as a partner, revisions can be brought in as part of the goal-setting process during the building phase.

Shorter Feedback Loops: In the agile world, testing becomes a regular part of the process. Small pieces of the project are tested and presented on a regular basis. This gives everyone a better sense of the project’s timeline. In addition, this frequent testing allows developers to catch bugs before they become deeply entrenched in the code.

Agile Practices

Agile development does not mandate particular practices, but a number of standard practices have come into place as a result of the values of the agile model. One common example is paired programming. Here, two developers work together as they code a piece of the project. One programmer does the coding, and the other reviews the code as it is written.

Another common agile practice is the daily standup meeting. Here, each team will give a status report to the project manager. Then, new goals are set for the current day.

A final practice is working in sprints. Rather than set a long goal, many agile models encourage doing work in short bursts. Many offices use a two-week sprint model, where developers try to handle as many issues or address several user stories in a short period.

Issues with Agile Development

As with any development model, agile developing may not be the best fit for every workplace or every project. There are some common criticisms of the agile model.

Loss of Unified Design: It is said that a camel is a horse designed by a committee. When many developer teams are working on individual parts of a project, you can lose the overall unity of the original vision.

Loss of Focus: When developers are only looking at pieces, they can lose sight of the whole. This can lead to minor parts of a project taking up too much time.

Best for Object-Oriented Programming: Because OOP naturally breaks projects into chunks, OOP languages will be the natural choices for agile developers. Projects in non-OOP languages may not be as good of a fit.

Difficulty in Larger Settings: There is some concern that developing in the agile style does not work as well in large settings, where programming teams can get lost in the shuffle, or on very large projects, where many small programming chunks can be harder to track.