What is agile software development?
Agile software development refers to a collection of methodologies and frameworks that promote adaptive planning, evolutionary development, and continuous delivery. Instead of focusing on a final output — the finished product — agile teams prioritize working in short increments with frequent release cycles to deliver value faster.
Software development is an adventure. And like most adventures, it is unpredictable. That is why agile philosophy centers around rapid iteration — solutions evolve organically through cross-functional collaboration between self-organizing teams. Customer satisfaction is on the horizon, with their feedback incorporated throughout the development process.
Explore agile development
Every organization will practice agile in its own way. Company culture, industry, and functional discipline all play a factor. And some groups simply gravitate towards one methodology more than others. Software developers, for example, often prefer scrum. Whereas IT groups who manage long lists of customer tickets or issues may prefer kanban.
But other functional groups within an organization find value in agile practices too. Openness to change, trusting collaboration, customer-centric thinking — these concepts easily apply to other types of work. You may have seen agile principles infused into content marketing, project management, and product management.
This guide is meant to give you an overview of agile software development — its history, evolution, and some of the challenges organizations find when implementing agile. But it is not a tactical primer for companies that are looking to overhaul workflows and “go agile.” Those types of transformations are sweeping in scope and require deep thinking about what needs to change and why.
Early agile practitioners did not prescribe a specific framework or doctrine. The goal was to empower teams with a mechanism for responding to change quickly and continuously improving. There is no “right” way to weave agile thinking into your team’s processes. But in the spirit of unencumbered innovation, we suggest taking what you need and leaving what you can.
Let's explore the following:
What is the history of agile development?
Agile development is older than you think. Kanban was conceived in the 1940s. Iterative and incremental development (IID) dates back as early as the 1950s, with evidence of use by teams at NASA and IBM Federal Systems Divisions. Other adaptive methods such as Evolutionary Delivery (EVO) and Rapid Application Development (RAD) were in use through the 1970s. However, it was not until the late 1990s that agile gained widespread traction. So what pushed what we now know as agile to the forefront? Two things: Backlash against bureaucracy and colossal business change.
For decades IID, EVO, RAD, and other adaptive methods were seen as fringe and not taken seriously. Most organizations relied on the single-pass software development lifecycle known as waterfall. Waterfall defines requirements upfront and delivers projects in sequential phases. It can be effective for projects with a fixed scope, but vulnerable to failure if requirements change during development. And as anyone who has worked in technology knows — it is nearly impossible to anticipate all requirements at the outset.
The rigidity of single-pass software development created breakpoints between management and engineering teams. Do you remember the beleaguered engineer from the comic strip “Dilbert”? First published in 1989, the comic’s satirical plot points encapsulate many frustrations shared by developers who felt stifled by office politics and top-down micromanagement. The main complaint was that busy work and process were prioritized over productivity.
Around that same time, new technologies emerged that enabled faster product development. Widespread access to the internet disrupted entire markets. As new software-based products and services gained traction, expectations began to change. Accelerating time-to-market became a business priority as companies struggled to survive in highly competitive marketplaces. Customers wanted products to be continuously improved with new functionality. And they wanted to be involved in suggesting what that new functionality should be.
With all of this percolating, a group of 17 software practitioners gathered in Utah in 2001. That meeting is the one most widely reported in historical accounts of the agile movement. But the group had met in Oregon in 2000 to discuss what they called “light” or “lightweight” development methodologies. No one was particularly comfortable with the potentially negative implications of “light” and so the word “agile” was agreed upon when they gathered the following year to formalize what became the Agile Manifesto.
It is worth noting that many of the original authors of the Agile Manifesto had developed their own methodologies such as Extreme Programming (XP), Crystal, and scrum by the time the group gathered in 2001. These methods, coupled with other novel approaches to programming drawn from the past, were an ideal foundation for developer communities ready to adopt a new mode of working.
What are the values and principles of the Agile Manifesto?
The authors of the Agile Manifesto defined four core values and 12 principles. Those values and principles are meant to guide how agile software development teams should approach their work. Together, the 16 tenets serve as the foundation for many of the agile methods teams use today — with special attention paid to flexible planning, efficient communication, very short feedback loops, and adaptive cycles:
“We are uncovering better ways of developing software by doing it and helping others do it.
Through this work we have come to value:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within the development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity — the art of maximizing the amount of work not done — is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.”
What is an agile philosophy?
There is Agile and then there is agile — with a little “a.” Some believe that unless you are following a certain framework or set of rules, that you are not really agile.
Method tailoring, process pragmatism, and a comfort with the messy reality of how people plan and deliver should all be welcomed by agile thinkers. What matters is embracing a flexible mindset and continuously seeking ways to improve how work is done so you can maximize the value you give to your customers.
Merriam Webster defines agile as “the ready ability to move with quick easy grace.” Any team would be happy to be described that way. And ultimately, each team must choose their own path towards quick and easy grace — regardless of methodology.
Related: The Reasons To Go Agile With a Little "a"
Benefits of adopting an agile approach
There is a reason agile is so popular — it has the potential to benefit teams in myriad ways. Here are a handful of benefits your team might experience by adopting an agile approach:
Increased transparency: Agile teams document their work. Backlogs, work in progress, status updates — it is all visualized and accessible to teams across the organization. This translates into increased knowledge sharing, alignment, and accountability.
Greater adaptability: Agile teams do not fear change — they embrace it. An agile approach encourages you to think iteratively, break work into small chunks, and tackle it in kind. Heightened flexibility means you can quickly adapt to a changing market and incorporate customer feedback early and often. It is a boon for businesses and customers alike.
Reduced risk: Agile processes reduce waste — in terms of time, effort, and money. When you set plans months in advance and then commit capital to those plans (with a waterfall approach, for example), you risk delivering increments that are no longer timely or reflective of actual customer needs. Agile, on the other hand, encourages you to deliver what is most needed — now. Less waste, increased viability and success.
Motivated teams: Agile teams have increased autonomy — to collaborate, prioritize work, and assess progress. And when teams feel like they have a say in how they get work done, individual team members are more motivated and energized.
Most popular agile methodologies
Agile is an umbrella term for a philosophy that you can apply to a variety of different software development methodologies. So when we refer to an agile framework, what do we mean? Does each one adhere to the Agile Manifesto? Not quite.
All agile frameworks are rooted in the values and principles behind the Agile Manifesto. But some were defined prior to the 2001 manifesto and others came after. While each approach provides a unique set of workflows and practices, together these frameworks embody elements of the philosophy behind what we know generally as agile software development. And as teams continue to discover new and better ways to work together, new frameworks will emerge.
Kanban
Kanban is not a full-fledged methodology — it is a tactical method for managing the flow of work items with an emphasis on continuous delivery. Teams visualize work on a kanban board and follow a pull-based approach — grabbing a new task as they have bandwidth. The three core principles of kanban are to visualize what you do today, limit the amount of work in process, and optimize flow.
Kanban boards include columns that represent workflow statuses (e.g. "Not started," "In progress," and "Done"). User stories, features, or tasks are represented by cards on the board. Teams monitor progress across the board until work is completed according to the team's definition of done.
An example of a kanban board created in Aha! Develop.
Lean software development
Lean software development (LSD) applies lean manufacturing principles and practices to software development. The key principles of LSD are to eliminate waste, ensure quality, create knowledge, defer commitment, deliver fast, respect people, and optimize the whole. Lean teams collaborate to deliver a Minimum Viable Product (MVP). Once that product is released, the team gathers customer feedback and then applies those insights to new product iterations.
Related: What is a Minimum Lovable Product?
Scrum
Scrum is an iterative and incremental agile software development framework. Unlike some agile methods, scrum is a defined framework that comes with its own rules and processes. Scrum teams operate on core pillars of transparency, inspection, and adaptation. Teams work in time-boxed sprints of two to four weeks and follow scrum ceremonies — such as sprint planning, daily scrum, sprint review, and sprint retrospectives. These ceremonies facilitate the continuous improvement and tight alignment that allow scrum teams to deliver value at a sustainable pace.
Related guides:
Other common agile frameworks
By far, the most popular frameworks among agile teams are kanban, lean, and scrum. But the table below provides an overview of a few more you may or may not have heard of.
Agile framework | Description |
Agnostic agile | Agnostic agile practitioners might balk at being included in a list of agile frameworks, since one of the key principles is not to adhere to the specifics of any one framework. This approach is about leading with agile principles and then choosing any framework that best serves the needs of a specific organization. |
Adaptive software development (ASD) | Adaptive software development is based on RAD. It focuses on the rapid creation and evolution of software systems. This approach repeats a series of speculate, collaborate, and learn cycles. Key characteristics of an ASD approach are that it is mission-focused, feature-based, iterative, timeboxed, risk-driven, and change-tolerant. |
Crystal | Crystal is a collection of agile software development approaches. Crystal practices iterative and incremental development, active user involvement, and delivering on commitments. This approach emphasizes the importance of people and process and the interaction between them. |
Dynamic system development method (DSDM) | Dynamic system development provides a four-phase approach for implementing software projects. These phases are feasibility and business study, functional model or prototype, design and build iteration, and implementation. This approach uses RAD techniques to accelerate the software development process. |
Extreme programming (XP) | Extreme programming sets specific practices for software development. XP characteristics include sitting together, pair programming, test-first programming, continuous integration, collective ownership, and incremental design. This approach is intended for small, co-located teams working with dynamically changing software requirements. |
FAST agile | FAST is an acronym for fluid scaling technology. This agile framework puts the emphasis on self-organizing teams (or “tribes”) who form, change, dismantle, and reform dynamically over value cycles as short as two days. |
Feature-driven development (FDD) | Feature-driven development is a model-driven methodology intended for larger teams working on a project using object-oriented technology. FDD defines five processes: develop the overall model, build the feature list, plan by feature, design by feature, and build by feature. |
Scaled agile framework (SAFe®) | The Scaled Agile Framework® is typically used by larger organizations who want to apply agile and lean principles at scale. It offers guidance for action across three main levels of an organization: team, program, and portfolio. An optional fourth level addresses organizations working with value streams. |
Agile team roles
The specific roles and titles on an agile team will depend on your team's chosen methodology and factors such as the size of your organization. But some job functions are common to most agile teams, regardless of methodology. Here are four roles (and their accompanying titles) that you can expect to find on most agile teams:
Team lead, scrum master (scrum), team coach, project lead: This role guides the team, connects them to necessary resources, and helps remove roadblocks. This role is not necessarily the same as a team's manager. Scrum masters, for example, are considered leaders but not people managers.
Team members, engineers, development team: These folks deliver the work. Team members can include developers, quality assurance (QA), user experience (UX) designers, and anyone else responsible for product planning, design, development, testing, and delivery.
Product owner (scrum), product manager: This person represents the voice of the customer and champions the product vision. They manage and prioritize the product backlog, write user stories, and ensure that development work aligns with the product roadmap.
Stakeholders: These folks provide feedback and share insights throughout the development process. Stakeholders are not part of the core agile team but maintain a continued interest and investment in the product's success. Examples of stakeholders include end users, people funding the product, and other teams within your organization such as sales and business analysis.
Related: What are scrum roles?
Common agile metrics
Agile encourages flexibility, not foolhardiness. You still need to establish clear metrics for success and track and analyze output. You want to repeat your successes and spot opportunities to make adjustments.
Common agile metrics and agile reports include:
Control chart: Time spent working on different issues during a sprint (measured by lead time and cycle time) to predict future performance.
Cycle time: Time spent actively working on an issue from start to finish, including time spent on reopened issues.
Deployment frequency: How often new code is deployed.
Escaped defects: Number of bugs discovered after a release enters production, which indicates weaknesses in your quality assurance (QA) processes.
Failed deployments: Number of failed deployments in a given time frame, an indicator of code stability.
Lead time: Total time an issue exists — from the moment it is initially logged until work is completed.
Sprint and release burndown charts: The team's progress toward completing all items in a particular sprint or release.
Velocity: Average amount of work completed in a given sprint.
An example of a sprint burndown chart created in Aha! Develop.
What are some common issues when implementing agile?
Let’s start with some of the common tactical issues that development teams face when implementing agile:
Fixed time, resources, scope, and quality
Lack of sponsor support
Lack of overall product design
Product owner role is not properly filled
Scrum master is also a contributor
Problem-solving in daily standups
Attempting to take on too much in an iteration
Adding stories to an iteration in progress
Adding unrelated tasks to sprints
Allowing technical debt to build up
Developer burnout
If you have experienced this hit list of pain before, then you likely know that agile itself is rarely the issue. That is because (as we have reiterated a few times so far) agile is a philosophical approach to work.
Some organizations choose to slowly wade into the agile world by choosing a hybrid approach. This refers to an agile framework combined with a traditional waterfall (so-called “wagile”) or project-based development structure. Hybrid agile can be a helpful transitional path and some companies may find that it is a lasting solution for their teams.
Some even go so far as creating their own agile frameworks. UnitedHealth Group established the Optum Scalable Agile Method (OSAM), which is a modified application of SAFe®. According to a slide presentation that shares some of their challenges with implementing agile at scale, one of Optum’s largest agile portfolios has more than six release trains, 35 scrum teams, and hundreds of teammates. OSAM offered flexibility to evolve a massive organization over time.
Others face challenges when trying to adhere strictly to one framework. So you may find that your team does better with a blended approach. Blended agile refers to two or more established agile frameworks used together. For example, “scrumban” blends the structure of scrum with the flexibility and visualization of kanban.
In order to implement agile, you have to fundamentally change the way people think, operate as individual contributors, and collaborate as teammates. The larger and more established an organization is, the more difficult it can be to change “old guard” mentalities and processes. The collective aim should be to critically assess your approach before you venture into the details.
The benefits of adopting an agile approach are often worth the effort of clearing these hurdles. Agile brings quicker release cycles and higher quality code — leading to increased customer satisfaction and happier teams. Your team can end up saving valuable time and resources while creating products that customers love.
Productive and happy development teams use Aha! Develop to customize the way they work. Sign up for a free 30-day trial to discover all you can do with this fully extendable agile development tool.
