Agile Development: Pros and Cons

Recently I’ve been involved in a couple of my library’s web development projects that have used the Agile development framework, so I thought I’d share how Agile can help or hinder technical projects. In my last (non-library) job I worked for a software company that chose to make a full-scale transition from traditional development to an Agile development environment, so this is a topic that I’ve been thinking about for quite a while.

Agile, for those unfamiliar with the basic idea, is an attempt to streamline development work by focusing on producing modular pieces of software that perform simple tasks on their own, but also build on each other to form more complex tools (kind of like the Voltron of software development). So what are the advantages and potential pitfalls of Agile?

Pros

1. Focus on Usability: The basic unit in Agile development is the user story, which documents a specific action that the user (not the software) can perform. This keeps the project focused on what users are supposed to accomplish by using the software, and limits time spent on features that are technologically impressive but don’t solve pressing user needs.
2. Flexibility: Agile development is based on short-burst development efforts called sprints (or iterations). Sprints typically last between 1 and 3 weeks; teams are free to experiment and choose the length that best suit their specific environment. User stories are prioritized and assigned to sprints based on their importance to the user experience, and each story must be completed within a single sprint. The goal of an individual sprint is to produce a piece of software that can be released on its own, and the end of each sprint should coincide with a release. Any stories that are not completed can be held back for the next sprint, rather than pushing back the release to wait for bug fixes. Each sprint completion point becomes an opportunity to test the finished user stories and change project direction according to user feedback.
3. Stakeholder feedback: Because sprints are self-contained and releases happen every few weeks, users are able to closely follow the progress of the project and provide feedback early and often, keeping the project focused on user needs. There should be no “that’s not what we asked for!” surprises near the end of development, and no need for costly re-engineering cycles following disappointing user feedback.
4. Team Motivation: Because work is completed in short bursts and presented to users every couple of weeks, there is no extensive development phase that can lead to loss of focus and motivation.

Cons

1. Lack of holistic focus/scalability: The focus on user stories is great in some ways, but it can hurt the team’s ability to focus on the big picture view of project goals. Agile solves this problem through a role called the Product Owner: someone tasked with interpreting user needs and creating and maintaining user stories. The Product Owner is responsible for keeping the project on course beyond the scope of the current iteration, reviewing and accepting sprint work, and reworking and reprioritizing user stories to address user feedback.
2. Team Dynamics: Because development cycles are so short, communication among team members is crucial to project success. Everyone needs to know what everyone else is up to, and making sure the entire team is working together to meet sprint goals. This is why Agile includes the daily scrum, a brief meeting where each team member describes what she’s working on and identifies any dependencies on teammates. The short cycles can also lead to burnout, which is why proper prioritization and effort sizing are crucial to an Agile project. A development team can survive a few long days at the end of a 3- or 6-month development cycle, but if that is happening every two weeks, the process quickly becomes unsustainable.
3. Documentation: Because Agile prioritizes working software over process, documentation can suffer, especially when it comes to technical specifications. However, there is no rule in Agile that says one can’t create adequate documentation. Development teams should take care to leave enough information behind so that others are able to revisit the project and identify the decisions that were made and the reasoning behind them.

Conclusion

The goal behind the creation of Agile and other related software development methodologies is to increase process flexibility and accountability, as well as minimize wasted effort and inertia. It’s not the ideal methodology for every development environment, but when applied correctly in the right situation, it can greatly increase productivity and team satisfaction.

If you want to learn more about the basics of Agile, you can look here, here, and here.