What’s so Great about Agility?
The Agile approach to managing software projects has been getting a lot of play recently. Why are people talking about it so much? Is this just the latest "new thing"? Or is there some real value to it?
"Agile," as a set of software development methods, was defined seven years ago, so the "flash in the pan" would have burned itself out long ago. The fact is that more and more organizations (from small shops to large corporations) are finding real value in Agility.
After defining what Agility is and is not, we will look at the value it can bring.
The Agile approach has a number or key attributes that can be referred to as the "Essence of Agility." They are:
· Learning and adaptation – Traditional approaches expect that we can foresee how the project will unfold with reasonable precision. The Agile approach accepts that there are many things we cannot anticipate, so it is structured to allow us to first learn about those unknowns and then adapt to what we learn.
· Collaboration – The Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customers.
· Customer focus – The customer is the central focus of an Agile project and is actively involved throughout.
· Small self-directed teams – Agility capitalizes on self-directed teams and recognizes that small teams can self-direct most effectively.
· Lean principles – The principles that have been proven by Lean Manufacturing are embodied in Agility, especially concepts like "Just Enough" and "Just in Time."
· Progressive requirements elaboration – We expect to learn about the system requirements as the project progresses, so trying to nail them down in a full-blown specification at the beginning of the project doesn’t make sense. Agile projects establish a roadmap and elaborate the details as they are needed.
· Incremental delivery – The best way to ensure we are building the right system is to regularly get feedback from our customer. Agility always includes incremental delivery of the product to the customer – at least for acceptance testing.
· Iterative planning and adaptation – Agile projects place a high value on planning. They engage in planning at various levels of detail and engage in it regularly. Again, this is driven by the fact that we cannot foresee everything that is important, so we must adapt our plans as we learn.
Many people have abused the term "Agility" by using it as an excuse for undisciplined practices. Some people wrongly believe that Agility means these things:
· No documentation – The documentation that an Agile project produces is significantly different from what traditional projects produce, and an Agile team will always ask why various documents are needed. But they always document (in unique ways) their plans, requirements, designs, and whichever other artifacts provide value.
· No planning – Agile projects actually engage in more planning than most traditional projects. They produce a high-level plan during project initiation, and they re-visit and adapt that high-level plan regularly throughout the project. They produce a plan of what they will do during each iteration of development, and they meet daily to check their progress and plan the day’s work.
· No requirements – The Agile team’s Product Owner (customer) defines a Product Vision, and they work together to document the product’s high-level requirements (called the product backlog). Then, more detailed views of those requirements are elaborated upon and documented as they are needed throughout the project.
· No schedule or budget control – Agile projects always operate within a "Time-Box." That is, they have definitive start- and end-dates and are not expected to violate those dates. And because people’s time is the largest part of a software project’s budget, the time-box limits the project budget as well. The Agile mantra is, "We will deliver the greatest possible customer value within the project constraints!"
· Programmers doing whatever they like – The Customer has primary control over an Agile project. The customer is involved in all aspects of planning, prioritization, and status keeping throughout an Agile project. If the project team is not producing what the customer finds to be valuable, it is up to that person to re-direct the work. The team’s only role is to estimate what can be done in limited timeframes. The team’s customer determines how that effort will be directed.
There are many reasons why companies find the Agile approach (when it is implemented as intended) to provide value. The value that is cited usually includes:
· The right product – The customer is continuously involved in the project, ensuring that valuable software is being built and prioritizing the work. In addition, the customer accepts or provides critical feedback on each increment of the product that is produced. With this level of involvement by the customer, there is no way that the wrong product can be built.
· Quality – Agility always includes a strong focus on the quality of what is built. This includes not only the customer’s acceptance testing, but also many technical quality practices. Properly functioning Agile teams produce high-quality software.
· Schedule and budget – Time-boxing of an Agile project means that its schedule and budget are rarely "over-run" If things don’t work out as planned, the low-priority features can be skipped or cut short. If an Agile project does need to extend its time-box it would be with their customer’s and management’s full concurrence.
· Early warning – Because an Agile project is essentially a series of short mini-projects, problems become apparent very early, when they can be corrected.
· Adapting to change – Change is a fact of business. An Agile project can adapt to changes in the business environment, within the organization, or with the customer much more effectively than a traditional project.
Every business values agility (lower-case "a"). What many are finding is that Agility (upper-case "A") provides what it promises.