What Are Agile Methodologies? Agile Methods Explained

In the last two decades, software development has undergone an Agile transformation because of the many benefits like improved quality and predictability across projects. Agile methods have become the standard in many contexts, using small, self-directed teams to create a product in short order. In this article, we’re going to cover the basics of the Agile methodologies and discuss when it might be appropriate to adopt one for your own project.

Key Takeaways: Agile Methodology

• Agile methodology focuses on key ideas, like producing working software and an iterative development process.
• Agile teams are usually smaller, working on smaller projects.
• While many methods are older, Agile was defined in the Agile Manifesto in 2001.
• The Agile Manifesto included four values and 12 principles.
• There are many Agile methods, with different advantages.
• Some Agile approaches can be scaled to larger teams and projects.
• Before Agile, project management used traditional or waterfall methods.

Historical Overview of Agile Methodology

The modern approach to project management is considered to have developed during the Cold War, as project managers brought together existing ideas and added their own. Many concepts that are now thought of as Agile actually have their roots much further back, in that early era of project management. 

An Alternative Approach to Project Management

Early project management focused on large projects that required tight organization. The methods developed, now thought of as waterfall or traditional approaches, reflect those strict needs. However, even in that era, people were finding faults with waterfall methodologies.

Read: Waterfall vs Agile Methodology: What’s Better for Your Project?

Core Agile concepts, such as iterative and incremental development, have been in use at least since the 1970s. The concept of customer collaboration, as well as a focus on products rather than documentation, can also be found in use in the 70s.

Lightweight Software Development

As computers got smaller and more powerful, small groups began developing software in a volatile business environment. Things came to a head during the computer boom of the 1990s when many Agile methods were developed. Examples include:

• Extreme programming.
• Scrum.
• Rapid Application Development.
• Crystal methods.
• Dynamic Systems Development.

While each of these project management methodologies software are now considered examples of Agile development, at the time they were instead called “lightweight”. All were created in the context of software development and were considered suited only for small teams and projects.

The Age of Agile

In 2001, 17 project managers and software developers met. Each was a leader in a different type of Agile software development, including extreme programming, scrum, adaptive software development, and others already mentioned. 

Together, they wrote the Agile Manifesto, a brief document that outlines the values and principles behind Agile methodology. Doing so rebranded their areas of expertise as Agile, a name that implied an ability to manage to change circumstances.

What Is the Agile Manifesto?

The Agile Manifesto is the defining document of Agile project management. The values and principles found in the manifesto are less a formal methodology than guiding principles. It doesn’t define project management phases, for example, but instead questions whether they’re worth worrying about.

As mentioned, the concepts in the Agile Manifesto are expressed in four values and 12 principles. The four values include:

1. Individuals and interactions over processes and tools.
2. Working software over comprehensive documentation.
3. Customer collaboration over contract negotiation.
4. Responding to change over following a plan.

The 12 principles of Agile project management are:

1. The highest priority is meeting customer needs, achieved through early and continuous delivery of valuable software.
2. Accept changing requirements throughout development. Agile methodology uses change to the customer’s competitive advantage.
3. Deliver working software frequently throughout the project lifecycle, the sooner the better.
4. Agile teams should include developers, business people, and other stakeholders.
5. Give motivated individuals the resources and support they need. Then, trust them to produce high-quality software.
6. The most effective way to communicate, within the team or otherwise, is a face-to-face meeting.
7. Working software is the primary method of judging progress.
8. Agile aims to be sustainable, so that the pace of work could be continued indefinitely.
9. A focus on continuous improvement and technical excellence improves agility.
10. Keeps things simple by maximizing the amount of ‘work not done.’
11. The best results arise from self-organizing teams.
12. Iterative development means the team meets and reflects on how to become more effective, then adjusts its behavior accordingly.

Both these values and principles are also used in large projects with multiple teams, using tools like the Scaled Agile Framework to contain what could be a hectic methodology.

7 Different Types of Agile Methodologies

As important as the values and principles are, it’s not straightforward to apply them to the project management process. Additionally, the manifesto doesn’t offer a single, formal Agile definition that can be generalized. Instead, there is a collection of methods that are considered Agile software development.

The seven on our list are some of the most common, though there are other Agile methodologies out there, including many specialized methods. Additionally, variations like Disciplined Scrum and Scaled Agile Frameworks can be used with larger projects.

Scrum: Sprint Through Software Development Projects

Perhaps the most popular Agile framework, Scrum methodology outlines how to manage an iterative process in constantly changing circumstances. The development process is broken up into sprints, before which tasks are broken down and assigned during Sprint Planning.

Planning includes the entire scrum team. In a traditional process, the bulk of the manager’s time is spent assigning tasks and following up. The team takes care of that in Scrum, so the manager instead becomes the Scrum Master. Their role is more of a facilitator, rather than a manager.

The Product Owner acts as a representative for the customer. They are the only person able to add additional features or requirements throughout the project. They do so using a list called a product backlog, which includes the tasks to be completed in each sprint. After each sprint, the development team meets once more to assess how work went. 

Key Principles:

• Small working teams maximize communication and informal information sharing, while minimizing overhead.
• Adapting to the technical requirements or marketplace ensures the best possible product.
• Work focuses on executables that can be tested, documented, and built upon as the project progresses. 
• Partition the work assignments into discrete packets without overlap.
• Testing and documentation are performed constantly throughout the build.
• The product could be declared finished at any time.

Strengths:

• Detailed process.
• Breaks tasks into manageable parts.
• Progress can be made even if requirements change.
• Fosters good communication.

Weaknesses:

• Focuses purely on development without addressing any other aspect of business.

Extreme Programming: User Stories and Pair Programming

As the name implies, Extreme Programming (XP) is used for software development projects.

Extreme programming starts when the customer produces user stories, which are short descriptions of functions. Ideally, these can be built and tested in as little as a week. The features are then presented to the customer, who evaluates and picks another week’s worth of stories to focus on.

One characteristic that’s often associated with XP is pair programming. With this practice, programmers work together, with one writing new code while the other observes and checks work. 

Key Principles:

• The planning game: Planning begins with user stories and a discussion with the customer about priorities.
• Small releases: Start with the smallest and simplest features. Release new features frequently.
• System metaphor: Each project has an organizing metaphor that provides a shared story regarding how the system works.
• Simple design: Always use the simplest design that will do the job.
• Continuous testing: Before a feature is added, write a test for it. Test frequently.
• Refactoring: Remove duplicate code.
• Pair programming: All code is written by two programmers at one machine.
• Collective code ownership: Any developer should be able to work on any part of the system.
• Continuous integration: Changes are integrated daily, if not more often. Tests run before and after integration.
• Forty-hour work week: No overtime.
• On-site customer: Development team has access to someone who will use the system.

Coding standards: Everyone codes to the same standards.

Strengths:

• Good communication.
• Focus on simplicity and feedback.
• Social activity.
• Emphasis on design.

Weaknesses:

• Doesn’t produce documentation.
• Can be expensive.
• Weak in some areas of business management.

Feature Driven Development: Know What It Does

Another one where the hint is in the name. Feature-driven development (FDD) focuses on creating features derived from a model of the end product. It is considered to only cover two parts of the software development process: design and build. 

Software development teams are divided into chief programmers and class owners. Chief programmers are generally more experienced. They lead a team of class owners, acting as a guide and organizer. Class owners are less experienced programmers who may do the bulk of the coding.

FDD is broken down into five steps, including:

1. Develop a model: A domain expert presents a model of the desired end product. Team members work to create a ‘walkthrough’ of the model.
2. Using the model and walkthrough, a list of desired features is created.
3. Plan by feature: The features list is broken down into design packages, which are assigned to chief programmers.
4. Design by feature and build by feature: These two steps are often handled together, as they are the iterative, or repeating, part of the method. The chief programmer chooses features to work on for the next period, usually a week or two.
5. At the end of that period, further features are chosen for another period of work. 

Key Principles:

• To scale to larger projects, there must be an organized method of producing systems.
• A simple and well-defined process is best.
• Steps in the process should be logical and obviously worthwhile.
• Process pride can prevent substantive work.
• A good work process fades into the background while the focus is on the product.
• Short, iterative cycles focusing on features work best.

Strengths:

• A practical method with strong modeling of features
• Detailed guidelines for design and build

Weaknesses:

• Focuses on design and build and therefore requires supporting methods.
• Requires subject experts to produce reliable models.

Crystal Method: Agile Communication

Crystal Methodologies is an Agile framework that is less a software process than a people process. It was developed to address the problem of poor communication between team members in projects.

The solution proposed by Crystal is to emphasize face-to-face communications among development teams. Informal knowledge is shared more easily, so the overall project is more likely to be successful.

This approach is also designed to scale to the size and number of Agile teams. Different ‘shades’, or sub-methods, can therefore be used by project management teams according to their needs. Variations, from most to least Agile, include:

• Crystal Clear.
• Crystal Yellow.
• Crystal Orange.
• Crystal Red.

Three key factors:

• The amount of communication between development team members, taking into account details like physical location, office layout, and personalities.
• The potential consequences of undiscovered software defects, including lost money, work, or even life.
• The presence of corporate goals that affect project decisions.

Strengths:

• Strong focus on communication addresses a common problem in projects.
• Well-defined guidelines for different team sizes.
• Well-defined risk control and technical practices.

Weaknesses:

• Not widely used or tested.
• Lack of guidance for wider business concerns.

Dynamic Systems Development: Build What You Can Afford

Dynamic systems development method (DSDM) expands and refines one of the earlier Agile development methods, Rapid Application Development (RAD), adding an iterative component.

According to some, DSDM is actually a framework, a more rigid approach to problem-solving. However, proponents say it has Agile development principles at its heart. The underlying principle is to fix time and resources available to the project, then adjust the product’s functionality to those constraints.

Unlike some of the other methods on this list, DSDM actually provides some guidance on wider business issues, rather than focusing purely on development. It uses a five-step approach to project management:

1. Feasibility Study: This step assesses the product and organization. Informed decisions can then be made, including whether DSDM is the correct method.
2. Business Study: Usually, this step takes the form of a workshop in which stakeholders and experts meet. The result is the Business Area Definition, which identifies potential markets and users.
3. Functional Model Iteration: This step includes analysis of requirements and production of a prototype. This step is then repeated until a ‘final’ prototype is produced, along with the results of the analysis.
4. Design and Build Iteration: Prototypes are reviewed by users. Their comments are included in further development, with a releasable product as the end goal.
5. Implementation: The product or system is transferred to the users, including training and documentation. Maintenance is sometimes viewed as continued, iterative development.

Key Principles:

• Active user involvement is imperative.
• Teams must be empowered to make decisions.
• Focus on frequent delivery.
• Fitness for business is a criterion for accepted deliverables.
• Iterative and incremental development is mandatory.
• All changes during development must be reversible.
• Requirements are baselined at a high level.
• Testing is integrated throughout the lifecycle.
• A collaborative and cooperative approach is important.

Strengths:

• Based on RAD principles, so well tested and reliable.
• Offers guidelines for wider business decisions.
• Scales to larger teams.

Weaknesses:

• DSDM is a proprietary methodology that isn’t available to everyone.

Lean Software Development: Trimming the Fat

Strictly speaking, Lean development is more of a management philosophy than a method of Agile development. Its concepts draw both from Agile practices and from the Lean manufacturing approach that gained popularity in the 1980s. 

As a result, Lean development doesn’t offer a specific set of project management tools. Instead, it’s an attempt to apply Agile principles at the very top of a company starting with the CEO, and propagating them down from there. The 12 principles of Lean software development draw both from Agile and from the Lean principles that preceded them.

Key Principles:

• The top priority is to satisfy the customer.
• Offer the best value for the money possible.
• The customer must participate for the project to succeed.
• Lean development is always a team effort.
• Anything can be changed.
• Domain, not point, solutions.
• Complete, do not construct.
• An 80% solution today is better than a 100% solution tomorrow.
• Minimalism is essential.
• Needs determine technology.
• Product growth is feature growth, not size growth.
• Never push Lean development beyond its limits.

Strengths:

• Focus on the top.
• Guidelines for business systems.
• Risk control is well defined.

Weaknesses:

• Lacks some key Agile features, like easy adaptation to changing requirements.
• Limited application to software development.
• Technical practices aren’t defined.
• No guidance for small teams.

Adaptive Software Development: Harnessing Complex Systems

Adaptive software development is based on some complex math concepts focusing on complex adaptive systems. A frequently cited real-world example of such a system is the flocking of sparrows. While each moves independently, because of behavioral rules, the whole flock seems to move as if choreographed. 

That sort of self-organization can be crucial in a volatile development process, when the business environment may change rapidly. ASD combines some of those ideas of emergent organization with Agile software development methodologies. As a result, it’s most useful in extreme projects.

The ASD approach is divided into three steps. They are:

1. Speculate: Define the project mission.
2. Collaborate: High change systems require a balance between teamwork and managing.
3. Learn: Recognize mistakes and make changes.

Key Principles:

• Mission focused: Mission artifacts guide development.
• Component focused: Each cycle develops a specific list of components.
• Iterative cycles: Do and redo to improve.
• Time-boxing: Evaluate goals in light of time estimates and resources.
• Critical risk: Recognize risks so they can be avoided.
• Change tolerant: Changes are inevitable and advantageous.

Strengths:

• Best suited for high pressure or rapidly changing projects.
• Addresses non-technical aspects of development.
• Well-defined risk control.

Weaknesses:

• Provides a management culture, not development guidelines.
• No guidelines for small teams or individuals.
• Lacks technical and testing guidelines.

Pros and Cons of Agile Methodologies

Agile methodology is innovative in many ways and can be applied in a wide range of circumstances. However, it can’t productively be used in every project. Understanding the benefits and disadvantages of an Agile framework can help clarify where it will be most useful.

Pros:

• Produces working software quickly.
• Values individuals.
• Focuses on customer input and collaboration.
• Responsive to changing requirements and circumstances.
• Cross-functional teams create a multi-disciplinary approach.
• Prioritizes face-to-face communication.
• Allows for a healthy work/life balance.
• Continual problem-solving.

Cons:

• Scaling to larger teams and projects is difficult or impossible.
• Face-to-face communication is limiting in some ways.
• Project scope can be constantly redefined.
• May not be suitable for life-critical systems.
• Relies on individual skills, including social skills.
• Produces no or poor documentation.
• Can produce a subpar user interface.

Bottom Line on Agile Methodology

There’s no question that Agile methodologies are here to stay for the right projects. While there are some projects that will always require a traditional approach, businesses continue to change more rapidly every day, as does the world at large. In the Agile approach, it’s possible to find a framework for harnessing that rapid flow of progress to your advantage.