There is a reason why the Agile training methods are becoming mainstream. They can work! Although every Agile practice is not necessarily appropriate for every organization, each practice has delivered real value to many organizations, and some Agile practices can be used by anyone!
Advantage #1: Customers' Needs Met
Agile projects involve the customer regularly, not just at the beginning (for requirements) and the end (for acceptance). This customer involvement mitigates one of the most consistent problems on software projects: What they will accept at the end of the project differs from what they told us at the beginning.
While good Business Analysis (or Requirements Analysis) practices can help with this risk, they can only take us so far. There is no substitute for demonstrating to the customer what we are building and getting their feedback regularly throughout the project. This is precisely what Agile projects do.
In addition to uncovering misunderstandings early in the project, this interaction helps the customer to form a better vision of the emerging product. Along with the ability to visualize the functionality that is coming, based on what has been built so far, the customers develop a better understanding of their own needs and the vocabulary to express it to the developers. It also allows them to identify when their needs change, which we will discuss next in Advantage #2.
All of these dynamics come together to enable the customer to steer the project toward producing as much of what they need as can be done within the constraints of the project. We will address this topic of constraints in Advantage #3.
Advantage #2: Greater Agility
The world does not remain static between the day we begin a project and when it is done. Whether the project takes a few days, several months, or more than a year, the organization changes, the customer changes, the environment changes, and, yes, even the developers change.
The main reason why the Agile methods are called "Agile" is because the iterative lifecycle is designed to accommodate change. Work is done in short "iterations" (or Sprints) of only a few weeks, and the transition from one iteration to the next includes taking stock of what may have changed since the iteration began and how to adapt to those changes.
As we mentioned in Advantage #1, our customer's needs may change. It really doesn't matter whether that change constitutes the customer gaining a new and better understanding of their needs, or it is a result a very real changes in their environment. The bottom line is that delivering a product that meets the original (obsolete) needs is wasteful and counter-productive. But the customer is not the only source of change. The development organization's situation could change as well.
The changing business environment might impact the value proposition for the project, causing management to allocate more or fewer resources, rearrange priorities, extend or contract the timeline, or even suspend or cancel the project.
The iterative and incremental nature of the Agile planning process makes any of these sorts of changes much less disruptive than on traditional projects. Reworking the over-all project roadmap is relatively easy because it is based on rough order of magnitude estimates with very little accompanying detail. And because detailed planning is done just-in-time (for only a few weeks at a time), changes will cause little or no rework there as well.
Regardless of the source of the change, the customer is as involved in adapting to it as they are in any other part of the project. This guarantees that agility does not come at the expense of satisfying the customer (a point we will expand on next in Advantage #3).
Advantage #3: Realistic Customer Expectations
Most customers have little or no understanding of what it takes to develop software. This can result in many problems and arguments on projects as the customer makes demands that they imagine would be easy for the development team, and question where the time and effort is going and why the project is taking so long.
Agile projects include the customer in all of the most important activities. That is why the customer is counted as a member of the Agile team!
The developers and the customer collaborate to define the high-level requirements (User Stories) and to maintain them throughout the project.
The customer is present as the developers generate their rough estimates (e.g., Story Points) to answer questions about each requirement if necessary.
Find out more about Agile training.