Why Agile?

What's so great about Agility?

Abstract

"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 they are seeing.

What is Agility?

• 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 foresee. So it is structured to allow us to learn about those things, then adapt to what we learn.
• Collaboration -- The Agile approach places high value on all stakeholders collaborating continuously, including the programmers and their customer.
• 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 be learning 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 get feedback from our customer regularly. 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.

What is Agility Not?

• 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 detail views of those requirements are elaborated 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 statusing 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.

The Value of Agility

• 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 and be skipped or shortcut. 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 best addressed. An Agile project should never surprise stakeholders with problems at the end.
• Adapting to Change -- Change is a fact of business. An Agile project can adapt to changes in the business environment, the organization, or the customer much more effectively than a traditional project.