What Is Agile?

(Excerpted from Transitioning to Agile by Rick Freedman)

Agile is an evolutionary and revolutionary way of thinking for enterprises. Agile practices encourage team collaboration, incremental delivery, and continuous planning and learning within organizations. What started as an approach to managing individual software projects has blossomed into a powerful group of principles and practices that any organization can implement to stay successful in an ever-evolving business environment.

Agile does more than just replace heavy, bureaucratic software development life cycles. Agile requires significant changes to culture, roles, methods, and metrics. Like the Lean production methods that inspired it, Agile requires executives, managers, and team members to bring new skills and new attitudes to the development of software and, indeed, of all new products.

At its creation, the Agile Manifesto initially focused on software developers iterating through an incremental process. Agile rookies learn Agile as a series of practices, like standups, demonstrations, and retrospectives. Many firms begin their Agile journey by piloting these practices in small enclaves within IT. As Agile matures in an enterprise, these new software engineering practices end up touching the entire organization, as faster delivery cycles affect marketing and logistics, and enhanced quality and maintainability free developers from drudge work and enable even higher productivity.

However, if we take a look at the Agile Manifesto, it’s clear that these ideas can translate to any function in the enterprise (with some adjustments):

• Individuals and interactions over processes and tools

• Working software over comprehensive documentation

• Customer collaboration over contract negotiation

• Responding to change over following a plan

Even though the Agile Manifesto is brief, it contains a distillation of the ideas that had been circulating in the IT community, as developers searched for alternatives to the Waterfall methodology and its many pitfalls. A Waterfall method emphasizes that a logical progression of steps be taken throughout the development of a new product or feature, much like the cascading steps down an incremental waterfall. This means you must wait until the very end of a project to see whether certain elements work and implement feedback—that’s not iterative, responsive, or how successful companies work.

The Agile Alliance, the organization formed to promote these ideas, realized that there needed to be an evolution of these initial ideas and published a set of 12 Agile Principles to flesh out the manifesto. The principles stress the Lean concepts of simplicity, customer participation, just-in-time planning, and working products. Many “Agilists” believe the principles to be a clearer, more definitive guideline for the adoption of Agile practices than the manifesto itself.

These Agile principles, derived from Lean manufacturing theories, present a viable alternative to time-honored traditional models. The new team structures, roles, and interactions that Agile brings, however, imply deep and disruptive change, down to the organizational bone. When traditional meets Agile, friction is inevitable.

But Agile works. A recent InfoQ study clearly illustrates that Agile is more successful than Waterfall methods. Agile projects succeed 42% of the time; in comparison, Waterfall projects succeed only 14% of the time. Failed Waterfall projects made up 39% of the total surveyed, but Agile failures were only 9%.

Agility has measurable financial value, as well. According to The Economist Intelligence Survey, Agile businesses have 29% higher earnings per share, 20% better net margins, and 8% higher revenue growth than their non-Agile competitors. And 88% of executives cited agility as a critical success factor, so much so that 50% called it a key competitive advantage.

What do Agile enterprises do that enable them to reap these benefits? Unlike traditional Waterfall methodologies, Agile projects have the following attributes:

• Large projects are broken down into smaller increments and releases.

• Development teams are composed of members with cross-functional skills, so the team can take responsibility for the project from conception to delivery.

• Products are delivered incrementally, in short, regular iterations, with each iteration delivering a small number of features.

• The entire life cycle is performed within each iteration, from planning to design, development to testing, to get that module of functionality to done.

• Teams collaborate and self-manage, working together to make their own plans and figure out for themselves the best way to tackle their work.

• The entire ecosystem of participants, from the executive sponsor to the developers and testers, are actively involved in prioritizing, planning, and reviewing the project as it is built to ensure continuing alignment with strategic goals.

• Rather than measuring progress on a Gantt chart, Agile organizations have three simple measures of progress: better business outcomes, more productive and engaged teams, and happy customers.

• Changes, improvements, and additional features are incorporated throughout the project life cycle. Change, rather than being perceived as a failure of the process, is seen as an opportunity to improve the product and make it more of a fit for its use and business purpose.

Many firms considering the move to Agile worry about the familiar artifacts and practices to which they’ve grown accustomed in Waterfall. Where’s my project plan? How do I track and measure progress? One of the myths about Agile is that it’s an undisciplined, “make it up as you go along” practice, whereas the truth is that Agile incorporates more planning and rigor than most Waterfall programs. For example, these working principles are quite focused:

• Build plans just-in-time, in the form of prioritized backlogs of work items, that have the potential to be reorganized, changed, and reprioritized as business needs evolve.

• Make all work visible, through the use of taskboards, either physical (cards on a wall) or virtual (in an Agile project-management tool).

• Simplify metrics by relating all measurements to actual, valuable features delivered and accepted by customers.

Agile teams assume that clients can’t know what they want in detail until they see a prototype. Agilists assume that as you iterate toward a complete solution, small releases at a time, stakeholders will guide you to a product that fits their needs and expectations. Each iteration delivers a working product or prototype, and the response to that product serves as crucial feedback into the succeeding iterations.

The strategic goal of Agile is not agility itself—it’s competitive advantage and enhanced business results. Respondents to The Economist survey cite a number of compelling drivers of the migration to agility, including better ability to handle changing priorities, increased team productivity, and increased project visibility. Other reported advantages include improved morale and motivation, better predictability, faster time to market, and enhanced quality. Reduced risk, improved strategic alignment, enhanced maintainability; the benefits reported are so compelling that they seem almost magical.