Table of Contents
What Is Agile Programming?
Agile programming is an approach to project management, typically used in software development. It helps teams react to the instability of building software through incremental, iterative work cycles, known as sprints. But before turning our discussion to the details of agile programming, it’s best to start at the beginning with the project management paradigm that preceded it: waterfall, or traditional sequential development.
What are the Origins of Agile Programming?
The roots of agile programming can be traced back to 1970, when Dr. Winston Royce delivered a presentation called “Managing the Development of Large Software Systems.” This paper introduced his thoughts on waterfall. Basically, Royce asserted that building software was akin to assembling an automobile. Put another way, each piece can be added in isolated, sequential phases.
This process demands that every phase of the project must be completed before the next phase can begin. Thus, developers collect requirements first, work on architecture and design second, and so on. Very little communication occurs during the hand-offs between the specialized groups responsible for each phase of development.
You can probably begin to think of ways in which this approach to software development is flawed. For example, it assumes the customer can identify every single requirement of the project prior to any coding taking place. In other words, waterfall imagines that a customer knows exactly what he or she wants at the outset and that he or she can deliver an airtight and inclusive plan for achieving that vision.
If you’re a developer, then you know that it’s infinitely easier for a customer to describe his or her vision when there is functional software to interact with and respond to. It’s a lesson that many software developers have discovered through failing. Moreover, many times, when a waterfall project wraps, a team that built software based on customer specifications finds out that it’s not actually what the customer wanted or another project has rendered all that heads-down programming irrelevant. In the latter scenario, an organization has spent time and money to create a product that no one wants.
Why Agile Programming?
Agile programming gives teams repeated opportunities to assess the direction of a project throughout the entire development lifecycle. These chances for evaluation are built into the natural workflow of agile programming through regular cadences of work, known as sprints or iterations. At the end of every sprint, the team presents a functioning piece of software to the Product Owner for review. This emphasis on a shippable product ensures that the team doesn’t get bogged down with gathering requirements.
Because sprints repeat and the product continually adds increments of functionality, agile programming is described as “iterative” and “incremental.” In waterfall, development teams have a single shot at getting each part of a project right. Not so in agile programming, in which every aspect of development is revisited throughout the lifecycle. There’s virtually no chance that a project will follow the wrong direction for very long. Because the team reassesses the direction of a project regularly, there’s always time to change course.
Perhaps the effects of this “inspect-and-adapt” strategy are obvious: Namely, they significantly reduce both development costs and time to market. Because teams can gather requirements while coding, exhaustive requirements gathering can’t prevent a team from making progress. And because agile teams develop within the short, repeatable work cycles, stakeholders have ongoing opportunities to ensure that the product being created matches the customers’ vision. In essence, it could be said that agile programming helps companies build products their customers want.
Instead of committing to market a piece of unwritten, sub-optimized software, agile programming empowers teams to build the best software possible. In the end, agile programming protects a product’s market relevance and prevents a team’s work from winding up on a shelf, unreleased, which is an option that makes both stakeholders and developers happy.
