back

6 Agile Methods You Should Definitely Know About [Agile Methodology]

Last Updated on August 16, 2026 by Status.net Editorial Team

When several people representing various software development methods convened at The Lodge at Snowbird ski resort, they all agreed to deliver excellent products (check our article about Agile Management to learn more). This would be done by operating in an environment which places people as the most important aspect of the business, and through the use of lightweight methods of developments.

These ‘lightweight’ methods are now considered as Agile methodologies. The methods are iterative and develop products incrementally by obtaining feedback from the users after a useful version of the product is put on trial.

Table of Contents

Part 1What Is Agile Methodology and How Do These Six Methods Fit Into It?

Agile methodology is an umbrella term for approaches to software development that prioritize iterative delivery, close collaboration with customers, and the flexibility to adjust plans as new information comes in. It grew out of the Agile Manifesto, published in 2001 by the same group of practitioners who met at Snowbird, and it values working software, customer collaboration, and responsiveness to change over rigid, front-loaded planning.

Agile is best understood as a philosophy built on a shared set of values and principles. The methods and frameworks below are the practical systems teams use to put that philosophy into action on a real project. Scrum and Kanban tend to get the most attention because they are widely adopted and relatively easy to learn, but they represent only part of a much larger agile family. Rational Unified Process, Crystal, Extreme Programming, Adaptive Software Development, Feature-Driven Development, and Dynamic Systems Development Method each solve a different piece of the same puzzle, giving teams options when their size, industry, or risk profile does not fit the standard Scrum template.

The Agile Values Behind RUP, Crystal, XP, ASD, FDD, and DSDM

Even though each of these six methods prescribes its own vocabulary and cadence, all six trace back to the same core commitments: deliver working software frequently, welcome changing requirements, and let the people doing the work self-organize around the problem in front of them. Where they differ is in how much structure they add on top of those commitments.

  • RUP leans toward more documentation and formal governance. It keeps the iterative, feedback-based spirit of agile while adding more of the ceremony that heavier, enterprise-scale processes rely on.
  • Crystal and XP sit closer to the lightweight end, trusting small, co-located teams to communicate constantly and relying less on heavy documentation.
  • ASD, FDD, and DSDM occupy the middle ground, offering enough structure for larger or distributed teams while still cycling through short, feedback-driven iterations.

How These Six Methods Differ From Scrum and Kanban

Scrum organizes work into fixed-length sprints with defined roles such as Scrum Master and Product Owner. Kanban visualizes work on a board and limits how much is in progress at any time. The six methods covered in this article predate or run alongside Scrum and Kanban, and many teams borrow ideas from more than one at once. For example, a team might run daily standups and sprint reviews borrowed from Scrum while still using FDD’s feature list to structure its backlog, or use DSDM’s MoSCoW prioritization inside a Kanban board. Agile methods are meant to be assembled and adapted. Many teams borrow practices from several methods and combine them into one workflow that fits their own project needs.

Part 2Rational Unified Process

Originally designed as a software process product, the Rational Unified Process (RUP) is an iterative development process framework from the Rational Software Corporation of IBM. It highlights a systematic way of assigning tasks and responsibilities within a development group which will eventually create a high-quality product within a set schedule and budget.

RUP provides team members with access to project guidelines, templates, and tools that will enable the team to speak one language no matter which part of the development process they are working in.

This approach can be customized to the particular needs or requirements of a project by selecting the elements of the method applicable to its development.

Though they are called ‘best practices,’ there are six all-embracing principles that development teams employing this method should observe so they can maximize the full potential of the RUP;

  1. Develop subjects iteratively

    It is important that the developers know, throughout the project, what they are supposed to produce so they will not drift too far from their objectives, especially given that Agile methods are flexible.

  2. Manage requirements

    Although the iterative process is flexible and allows changes from time to time, it is important to have an overall vision for fulfilling the requirements of the project, so that the client receives a product that he can use

  3. Use Component-based Architectures

    Another great feature of an Agile approach is that project development is divided into different iterations. Developers need only to focus on what they are supposed to create or develop for a particular period. It allows developers to test individual components of the project before proceeding to the bigger system.

  4. Visually model software

    Everyone’s life is easier if they can visualize the client’s requirements, the users of the product and their interactions so they can understand what is being done for that particular project.

  5. Verify quality

    Quality assurance should not be treated as a separate phase or activity. It should be integrated into all aspects of the project.

  6. Control changes to software

    Since some of the areas of the project may have been developed by different teams located in different places, or even different time zones, a conscious effort should be made to make every team and every team member aware of changes. At the same time, integration and implementation of these changes should be consistent and synchronized.

A project being developed using the RUP has four phases:

  • Inception. In this phase, the team establishes the scope of the project and defines its coverage for the purpose of managing resources. The team also forms the business case which includes, the context of the project, measures of success, and the financial forecast, complemented by the project requirements, constraints and key features.
    If the project does not pass this initial phase, it may be canceled or thoroughly reexamined.
  • Elaboration. The project takes shape at this stage. It is also the time when the team analyzes the problem domain, and the project plan is formed. This step is also made of several iterations and should produce a valuable product at the end of it.
    The project may also be canceled or reworked if it does not pass this phase. It is important to note that there should be a careful analysis of whether the project is strong enough to leave this stage since the next step entails a lot of risks. Beyond this phase, developers may find it hard to accept or adapt to changes.
  • Construction. It is now time to build the product. This phase can be divided into several iterations to make it more manageable and for the team to be able to produce a prototype worthy of being presented to the clients and the stakeholders.
    There’s no turning back at this phase because this is where the first product launch will take place.
  • Transition. At this point, the project moves from development into production. The finished product is evaluated against the objectives set during the inception phase. If it passes evaluation, it is turned over to the end-users. Aside from evaluating the product and turning it over to the client, there may also be other activities such as training users how to use the product and conducting a ‘beta test’ to validate if the end product meets the expectations of the client and the users.

The RUP’s flexibility can effectively deal with changes and allows for integration throughout the product’s development. However, it requires that team members should be experts in their respective fields since every activity is expected to produce results.

RUP Roles and Where It Fits Best

RUP assigns clear roles across the project, including analysts, architects, developers, testers, and project managers, each with defined responsibilities inside the four phases. That role clarity is part of why RUP tends to show up most often in larger organizations, regulated industries, and projects where audit trails and formal sign-offs matter, such as government contracts, financial systems, or healthcare software. Smaller startups with a handful of developers often find RUP heavier than they need and gravitate toward Crystal Clear or XP instead.

Part 3Crystal Methods

The Crystal Methods form a family of Agile methodologies and focus on human interaction within a project. Crystal Methods put a premium on frequent delivery, close communication, and reflective improvement. They prioritize the team that will develop the software over the process undertaken for the project. Alistair Cockburn, the developer of the Crystal Methods, believes that each project is different since it has a varied set of policies, practices, and processes.

Among its various variants, Crystal Clear is the most Agile, and it is also the most lightweight.

Crystal Clear is best handled by a team of 6 to 8 members who are in the same area.

The Crystal Clear method gives importance to achieving the properties rather than following set procedures. This shift to features from procedures was born from the underlying motive that procedures may not produce the resources.

  1. Frequent delivery

    Ideally, any project should deliver useful products to its client frequently. This is beneficial for both the user and the developers because it lets them follow the project’s progress. They can periodically monitor the development and see for themselves that this product is what they are really expecting to produce in the end.

  2. Reflective improvement

    The Crystal Clear method has a lot of vague details, and it is up to the developers to adapt based on their circumstances. To achieve this, teams must gather together periodically and discuss how things are working at their ends and take notes of what is working for other teams and what is not.

  3. Osmotic Communication

    This is the process by which background information is picked up by members of the team. Information flows through the project and they hear about it informally. When this type of communication takes place, team members will find it easy to exchange questions and answers related to the project.

  4. Personal Safety

    In the context of Crystal Method, personal safety means that a team member can freely talk about any concerns they may have without fear of repercussions. When team members feel free to speak without hesitation, it demonstrates mutual trust and confidence. This confidence will translate into other areas and increase the productivity of the team. This in turn, is beneficial for the project as a whole.

  5. Focus

    Team members should be given clear assignments and instruction on what they will work on. They should be allowed to work on it, and be given enough time to complete it. They should also be provided with a conducive environment. They should be trusted to deliver results on time by letting them work on their own without anyone hovering above them, checking what is on his or her screens at any given time.

  6. Easy access to expert users

    Since feedback has a significant weight using Agile methods, teams must be given easy access to expert users who can provide information to the developers in relation to the product they are working on.

  7. A technical environment with automated tests, configuration management, and many integrations

    This property is related to the previous one; only this particular feature requires that the developer team should have a technical environment equipped with the facilities and infrastructure essential to the product they are developing, testing, or evaluating. It is important that they have access to this environment for them to maximize their use of time and effort. If they have easy access to these requirements, they can focus more on the tasks assigned to them, giving more quality to the service they provide.

The Crystal Method has four recurring cycles of processes of various lengths. Each cycle has its own sequencing.

  • The Project Cycle. Composed of three parts which include chartering, a series of two or more delivery cycles and the project wrap up, this is the sequence where the core team is formed, the methodology to be used is shaped and fine-tuned, and the initial project plan is built.
  • The Delivery Cycle. This cycle has four parts namely: recalibration of the release scheme, a series of one or more iterations, presentation to real users, and a completion ritual that reflects on both the product created and the methods employed. This is where a valuable product is presented to the users and feedback about the product is obtained from them.
  • The Iteration Cycle. With three parts completing the cycle—iteration planning, daily and integration cycle activities, and a reflection workshop—the length and format of this period is not consistent. It is also the time where the team may make changes to the requirements, functionality or capabilities of its environment.
  • The Integration Cycle. There is no prescribed length for the integration cycle. For some teams, the integration cycle may only take half an hour while for others, it may be for multiple days. Some may do it more than once a week while others may carry out continuous integration or after every design episode.

The Crystal Method is expandable. It can be used by a large or small teams to work on either simple or complex projects. It places importance on the development teams’ skills, interactions, and on communication. This in turn, encourages collaboration and the exchange of ideas. It is also beneficial for the client since it delivers the most important component or features of the product first.

On the other hand, The Crystal Method does not plan based on the requirements of the project.

Crystal Family Variants: Matching Team Size to the Right Crystal Method

Crystal development methodology is a family of related methods, and Crystal Clear is only the entry point. Cockburn built the family around two variables: the size of the team and how critical a failure would be to the business. That gives teams a way to pick a variant that matches their real-world stakes instead of forcing every project through the same lightweight process.

  • Crystal Clear. Suited to teams of roughly 6 to 8 people working in one location, typically on projects where a defect causes inconvenience rather than serious financial or safety consequences.
  • Crystal Yellow. Designed for teams of around 10 to 20 people. It adds a bit more coordination and planning discipline than Crystal Clear without becoming heavy.
  • Crystal Orange. Fits teams of about 20 to 50 people working on projects with a longer time horizon, often a year or more, where more formal milestone tracking becomes useful.
  • Crystal Red, Maroon, and beyond. Reserved for larger programs of 50 to several hundred people, or for systems where failure could threaten essential money or human life. These variants borrow more structure from methods like RUP to manage the added coordination risk.

Choosing the right color in the Crystal family often matters more than debating Crystal against other agile methods. A team that picks Crystal Clear for a 60-person program, or Crystal Orange for a 5-person startup team, tends to run into friction that has more to do with fit than with the method itself.

Part 4Extreme Programming

Extreme Programming was created by Kent Beck while he was working on the Chrysler Comprehensive Compensation System payroll project. Commonly known as XP, this method gives emphasis to customer satisfaction by providing the products exactly when they need them, as opposed to coming up with an ideal product based on their requirements, after the developers finished the product.

XP also gives importance to teamwork and provides a simple environment with sufficient resources to make teams highly productive. Team members are treated equally, no matter what their roles are.

As an Agile method, XP understands that changes are a natural and desirable part of development projects.

The principles that set the tone for this methodology are based on the values of communication, simplicity, feedback, courage, and respect that XP lives by.

  1. Feedback

    Valuable feedback is obtained frequently and immediately—a short gap between the release and presentation of the product to the user and receiving feedback is a risk that should be addressed and dealt with. Through feedback, minor mistakes and shortcomings are tackled right away, before they can cause further damage and at the stage where changing some aspects of the product is still feasible and welcome.

  2. Assuming Simplicity

    XP believes in taking one step at a time. Frequent and small-scale releases are beneficial for the project so that both clients and developers are attuned with the development of the project, and they can easily spot any errors or shortcomings of the product.

  3. Embracing Change

    Changes are inevitable that is why XP developers do not close their doors to them, but instead they embrace and try to work around them. This saves undue stress that will only waste time and lessen productivity.

Projects employing XP undergoes these phases;

  • Planning. During this period, clients and the developers meet to discuss product requirements which will turn into ‘user’s stories.’ These user’s accounts are converted into iterations where developers will work on specific functionality or features of the product. The team also prepare the plan, assignments, schedules, and costing for each iteration.
  • Coding. In software development, XP believes that coding is the most important process of the project. In business perspectives, this is the stage where the developers are looking for the best possible solution to a problem or requirement set by the clients.
  • Testing. Testing is done within the development phase and not at the end of it. Products are presented and demonstrated to the customers, and they test them based on their requirements and the product’s usability.
  • Listening. After testing, and if the customers reported that the product needs to be improved, the developer will work based on the feedback obtained. If the client is already satisfied with the current prototype, a new iteration will start.

XP is all about efficiency and customer satisfaction. Aside from it being potent, flexible, and cost-efficient, it prioritizes team collaboration and dynamic product delivery. However, since this method relies on constant communication with the client, schedules and timelines might be compromised if the customer does not have the time, or the interest to join and participate in meetings with the developer team.

Core Practices of Extreme Programming (XP)

XP is an agile development method that turns its five values into a specific, day-to-day set of engineering practices. This is what separates it from broader frameworks like Scrum, which describe roles and meeting cadences but leave engineering technique up to the team. The practices most associated with XP include:

  • Pair programming. Two developers work at one workstation, one writing code while the other reviews it in real time. This catches defects early and spreads knowledge across the team.
  • Test-driven development (TDD). Developers write an automated test before writing the code that makes it pass, which keeps the codebase verifiable at every step.
  • Continuous integration. Code is merged and tested against the full system multiple times a day rather than in large, infrequent batches, which reduces integration conflicts.
  • Refactoring. Code is regularly restructured to keep it simple and maintainable without changing what it does, so the design does not decay as features pile up.
  • Collective code ownership. Any developer can change any part of the codebase, which prevents knowledge silos and bottlenecks around a single person.
  • On-site customer. A customer representative is available to the team to answer questions and clarify requirements as they arise, rather than through occasional check-ins.
  • Small, frequent releases. Working software ships in small increments so feedback loops stay short and course corrections stay cheap.
  • Sustainable pace. XP discourages sustained overtime, on the reasoning that tired teams produce more defects and burn out faster, which slows delivery over time.

Teams considering XP in an agile methodology mix often start with just a few of these practices, commonly TDD and continuous integration, before adding pair programming and an on-site customer once the team is comfortable with the rhythm.

Part 5Adaptive Software Development

The Adaptive Software Development (ASD) method is all about the rapid creation and evolution of the product. Development has no end and project has no final product—only updated versions of the product. The gaps between the previous product release and the enhanced one are short. The product produced using this development method undergoes continuous enhancements from developers after receiving feedback from the users.

In terms of project management, ASD provides a framework for a continuous improvement in decisions, policies, and practices through lessons learned from the previous decisions made.

ASD provides developers with wide room for exploration and a fast development cycle since they need only the feedback for the previously released product to come up with an enhanced version of it.

  • Characteristics

  1. Mission Focused. Though lacking in pre-planning activities, a mission statement for the project is created and established to guide the overall course of the project. The mission statement acts as an anchor on which all developments and enhancements on the products are based. It also encourages the developers to explore the limits of product development while, at the same time, providing boundaries but not a set route.
  2. Feature-based. Activities within ASD cycles revolve around building features and functionalities of a product and not merely on tasks assigned. These features undergo extensive development based on feedback received from the intended users of the product being developed.
  3. Iterative. Being an Agile method, many iterations result in a usable product that can be presented to the client or the user for them to test. The feedback obtained from this trial will guide the next batch of iterations to come up with an improved output.
  4. Time-boxed. An Iteration within an ASD cycle does not follow a deadline. It is time-boxed in the sense that developers are required to focus on a particular task for the timely delivery of results.
  5. Risk-driven. From the beginning of a project, risks are identified, and these are tackled and managed during iterations.
  6. Change tolerant. An important feature of an Agile method is that it is receptive to change. It can be adjusted to accommodate modification that is intended to raise the functionality and quality of the product to a higher level.

  • Phases

    Cyclical, as well as dynamic, Adaptive Software Development has three stages that are more than just a repeating sequence. These stages also serve as a management style. The cycle concentrates more on the results and not on the tasks that will produce these results.

  1. Speculate. In ASD, speculating takes the place of planning, which indicates a certain amount of uncertainty when conceived. What an ASD team speculates, they acknowledge that they are more than likely to be wrong about certain elements or outcomes of the project. They accept that they can only explore the possibilities and options presented to them.
  2. Collaborate. There is an enormous amount of information that needs to be gathered, analyzed, and processed. Different teams possess this information; in order to make use of this distributed data, the teams need to work together to piece this information together into something sensible which can be applied to the product’s development.
  3. Learn. This is the phase where developers change their perspectives based on the knowledge they gained from collaboration, and feedback from the users. It is also in this phase that they will apply what they learned to enhance and improve the product before releasing it again to the client or the user.

ASD encourages collaboration and promotes communication among stakeholders. This remains important until the desired outcome has been achieved. However, this method requires a longer development time because it is a series of several short iterations and all stakeholders must agree to adopt changes before they can be integrated into the project.

When Adaptive Software Development Makes Sense

ASD tends to fit projects where requirements are genuinely uncertain at the outset, such as research-heavy products, new markets, or emerging technology where nobody on the team can confidently predict the end state. Because the speculate-collaborate-learn cycle assumes the team will be wrong about some early assumptions, ASD works best when leadership is comfortable funding exploration instead of demanding a fixed scope up front. Teams working under a fixed-price contract or a hard regulatory deadline often find ASD’s openness harder to reconcile with those constraints, and may lean toward DSDM or RUP instead.

Part 6Feature-Driven Development

By description, Feature Driven Development is an Agile method that brings together some of the best practices in the industry into one homogenous aggregate that can be used by large teams. Fundamental to this approach is the creation of a features list to identify the project requirements and to manage tasks related to the development of the product.

Features, also called ‘use cases’ in Rational Unified Process, and as ‘user’s stories’ in Scrum, provides the basis for the requirements of the project and planning exercises and is expressed as action-result-object.

  • Best Practices
  1. Domain object modeling. An overall domain model is built providing a framework for features development.
  2. Developing by feature. Features sets are broken down until they reach the smallest point that is manageable enough to deliver results.
  3. Component/Class Ownership. Responsibilities over a particular feature or functionality to be developed are assigned, and accountabilities for the consistency, performance, and integrity of the project are reiterated to the process owners.
  4. Feature Teams. These are small development groups which are dynamically formed, disbanded, and reformed again, depending on the features to be built.
  5. Inspections. Defects and errors are identified and addressed during inspections to ensure that the released product is of high-quality.
  6. Configuration Management. Changes in the product are documented and maintained for future reference.
  7. Regular Builds. To ensure that the product will be relevant and useful, regular builds are initiated until the project is done.
  8. Visibility of progress and results. Progress is monitored and reported to allow the project managers to see if the project is making progress and still on the right track towards the project’s intended destination or results.
  • Stages

  1. Develop an overall model

    The overall scope of the project is determined to provide an extensive set of features to be developed. An overall pattern is formed by a team composed of development groups and industry people. This model revolves around team discussions.

    It is important that all persons involved with the project share a common understanding of the ideas and concepts behind the project.

  2. Build a features list

    The overall model then guides the identification of the features or functionality to be developed. These functions are broken down into sets, and then into individual features.

  3. Plan by feature

    At this point, primary responsibilities have already been distributed, as well the original schedule. Feature sets are also assigned to team leaders.

  4. Design by feature

    Iterations are formed based on the features identified for development. Team leaders also recruit their own teams at this point. The teams collaborate, design, and analyze the features determined for an iteration. They may also conduct a walkthrough of the requirements with an industry expert and study any available documents related to the project.

  5. Build by feature

    Developers now design an activity plan for each feature. After inspection and unit testing, the feature is ready to be built or developed.

What is key about the FDD approach is that requirements are clear, and the system by which the project operates is understood by everyone involved in the project. Roles and responsibilities of the development team are clearly defined, and the risks are reduced by working in iterations, On the other hand, FDD falls short on a smaller project and with small groups and relies heavily on the Chief Programmer or anyone who acts as the overall project manager.

Where FDD Fits Compared to Scrum and RUP

FDD was designed with large teams in mind, often 50 or more people split into multiple feature teams working in parallel. Its five-step process gives every subgroup a shared domain model to build from, which keeps a big team pointed in the same direction without requiring the heavier documentation of RUP. Organizations that need FDD’s scale but also want lighter governance sometimes pair it with Scrum ceremonies, using the feature list as the backlog while running sprints and standups on top of it.

Part 7Dynamic Systems Development Method

The Dynamic System Development Method (DSDM) Works effectively for a small team. DSDM has provided a mature approach to Agile methodology in a corporate setting. Based on a straightforward framework, DSDM converges with software development and process engineering to create a schema of solving complicated issues. It has 9 principles that those who employ this method should stick to. Apart from that, the project management team can carry out any Agile development process. But if any one of the 9 principles is not applicable, then DSDM is not the best methodology for that project.

  • Principles
  1. Active user involvement is imperative. Collaboration between the developers and the client is indispensable for the development of a product since it will reduce the chance of errors. It will also save time, money, and effort.
  2. Teams must be empowered to make decisions. Teams should be vested with authority to decide on actions that need to be taken immediately and on those matters critically related to the project.
  3. Focus on frequent delivery. DSDM favors releasing products which are incrementally developed over a perfect final product which has never undergone users’ testing and evaluation.
  4. Criterion for accepted development. Products released after every iteration should be a working version that has the capacity to address customers’ needs even if the development is not yet complete.
  5. Iterative and incremental development-mandatory. Development of the features and functionality of the product is done gradually, and enhancements are made based on the product users’ feedback.
  6. All changes during development must be reversible. There should be an option for the developers to revert to the previous version of the product before changes have been integrated.
  7. Requirements are baselined at high-level. Boundaries should be established to properly align changes which will be made during the product development. These limits or baselines should be agreed upon by both developer and client during the business study phase of the project.
  8. Testing is integrated throughout the lifecycle. Putting the product on test should form part of the development phase in order to immediately identify loopholes and errors. Developers and the client should not wait for the product to be finally completed before they put it into the test.
  9. Collaborative and cooperative approach. Cooperation and trust are essential for a DSDM project to succeed because, without it, teams will find it hard to collaborate and depend on each other. Information exchange and feedback gathering will not be possible if teams do not have a good working relationship. Post Project
    Periodic monitoring of how the product is performing will be conducted to check if it was able to serve its purpose, and if there are other ways that it can be enhanced or further improved.
  • Phases
  1. Pre-project phase. At this stage, developers and client conceptualize the project and decide if the project is worth realizing.
  2. Feasibility study. A feasibility study is conducted to see if the project will work and how it will be done. It is also determined at this stage if the project can be implemented using DSDM.
  3. Business study. The team then undertakes a business study to determine if the end-result of the project will make business sense and identifies the best work plan to build, test, deploy, and support it.
  4. Functional model iteration. The requirements defined in the previous stages will now be realized into prototypes and models of the end-product. This prototype will be presented to the users, and they will evaluate and test it. After this the users then provide feedback to the developers.
  5. Design and build iteration. When iterations are done, and all features, and the functionality has been developed, enhanced, and updated, it is now time to integrate all these components into one system that can be used by the intended users.
  6. Implementation. Once the users are satisfied with the end-result of the project, it is now time to implement the system and train the users how to use it. During this stage, developers will also review the system or the product if it meets the requirements set at the beginning of the project.
  • Core Techniques

  • Time-boxing

    An interval of no longer than six weeks, time-box prescribes a set of tasks to be accomplished in order to deliver a product at the end of it.

  • MoSCoW Rules

    Features and functionality are grouped according to its importance to the users since DSDM projects put more emphasis on being able to deliver on time and work within a budget.

     

    The MoSCoW rules are as follows:

    1. Must have
    All features under this category should be strictly implemented. These are the most important set of features since failure to develop these can make the system or product fail.

    2. Should have
    This set of features could make a significant contribution to the project but can be omitted if there are time and budget constraints.

    3. Could have
    These set of features bring functionality and enhancements to the product or system but can be reassigned to a future time-box.

    4. Want to have
    These set of features are of little value and will only be used by a few groups of users.

  • Prototyping

    This technique allows for frequent delivery and Agile development of a product or system. Prototypes are developed to enable users to test a product and provide feedback.

  • Facilitated Workshops

    Making way for user-developer collaboration, workshops identify selected people to participate. This helps avoid any lock-down that could result from having too many participants in a seminar.

DSDM ensures that the end-product is delivered on time and within budget, the most basic functionality is provided early on and that more functions and features are added gradually. It entails the deep involvement of the users with the development of the product or system.
However, even DSDM proponents agree that the method will not work with all kinds of projects since it requires that each of its nine principles are observed in the development process.

 

Part 8How to Choose the Right Agile Method for Your Team and Project

With six methods on the table, the practical question most teams face is which one to start with. A few factors tend to drive that decision more than any other:

  • Team size and location. Crystal Clear and XP were built for small, co-located teams of roughly 6 to 12 people. FDD, RUP, and DSDM scale to larger or distributed teams with dedicated leads coordinating the work.
  • How stable the requirements are. ASD suits projects where the end state is genuinely unclear. DSDM and RUP work well when a client needs baselined requirements early, even if the details evolve later.
  • Customer availability. XP depends on an on-site or highly available customer. If that access does not exist, Crystal or FDD, which rely less on constant customer presence, may fit better.
  • Documentation and governance needs. Regulated industries, audits, and contractual obligations tend to favor RUP or DSDM, both of which build in more formal checkpoints and baselines.
  • Team experience with agile practices. XP’s engineering practices, such as TDD and pair programming, ask more of a team technically. Newer teams sometimes start with a lighter Crystal variant before layering in XP practices.

Is RUP Truly Agile, or a Hybrid Approach?

This is one of the more common debates among practitioners comparing RUP methodology to agile in general. RUP predates parts of the Agile Manifesto and was originally built for large enterprise software projects with formal governance in mind. Because it can be scaled up or down and includes iterative phases with early and frequent delivery, many practitioners classify it as an agile-friendly framework. Others argue it carries too much upfront documentation and process weight to count as a lightweight agile method in the same sense as XP or Crystal. In practice, most teams that adopt RUP tailor it heavily, keeping the four-phase iterative flow while trimming the artifacts and formal reviews so it behaves more like the other agile methods on this list.

Part 9Common Mistakes Teams Make When Adopting These Agile Methods

Years of watching teams adopt these methods surface a familiar set of missteps, most of which have more to do with fit and follow-through than with any flaw in the method itself.

  • Picking a method for its popularity. Choosing RUP, XP, or another method because it is well known, without checking whether it matches the team’s size and the project’s risk profile, usually causes friction within the first few iterations.
  • Running RUP’s phases like a waterfall. Treating Inception, Elaboration, Construction, and Transition as one long sequential pass, and skipping the internal iterations within each phase, erases the agile benefit RUP is supposed to provide.
  • Starting XP without customer availability. XP’s feedback loop depends on a customer who can answer questions quickly. Without that access, teams end up guessing at requirements and lose the method’s biggest advantage.
  • Skipping ASD’s “Learn” phase. Some teams speculate and collaborate but never formally capture what they learned, which means the same mistakes resurface in the next cycle.
  • Underinvesting in FDD’s Chief Programmer role. FDD depends heavily on strong technical leads who own each feature area. Rotating that role too often, or leaving it vacant, tends to stall the whole model.
  • Dropping one of DSDM’s nine principles. DSDM is explicit that skipping even one principle, such as reversible changes or integrated testing, undermines the rest of the framework.
  • Mixing methods without adjusting ceremonies. Combining, say, XP practices with FDD’s feature teams can work well, but only when the team agrees on which meetings, artifacts, and roles apply. Layering methods without that alignment creates conflicting expectations.
  • Skipping training before the switch. Agile methods carry specific vocabulary and practices. Teams that jump in without a shared understanding of terms like time-boxing, MoSCoW, or osmotic communication tend to apply the method inconsistently from one person to the next.

Part 10Related Agile Concepts Worth Understanding Alongside These Six Methods

These six methods rarely operate in isolation. A well-rounded understanding of agile methodology also benefits from a working knowledge of the frameworks and practices that often surround them:

  • Scrum and Kanban. The most widely adopted agile frameworks, often combined with elements of the methods above, such as running Scrum ceremonies over an FDD feature list.
  • Scaling frameworks. Approaches like SAFe (Scaled Agile Framework) and LeSS (Large-Scale Scrum) exist for organizations that need to coordinate many agile teams at once, a challenge that FDD and RUP were also designed to address in their own ways.
  • Retrospectives. Regardless of which method a team uses, a regular habit of reflecting on what worked and what did not, similar to Crystal’s reflection workshops, tends to separate teams that improve over time from teams that repeat the same mistakes.
  • Metrics that matter. Velocity, cycle time, and lead time help teams see whether their chosen method is actually delivering value faster, rather than relying on gut feeling alone.
  • Agile transformation and training. Moving an organization from a traditional process to any of these methods usually takes deliberate coaching, pilot projects, and patience, since teams often need a few full cycles before the new rhythm feels natural.

Frequently Asked Questions

Is Agile a methodology, or is it a collection of methods?

Agile itself is a set of values and principles rather than a single, fixed procedure. Rational Unified Process, Crystal, Extreme Programming, Adaptive Software Development, Feature-Driven Development, and Dynamic Systems Development Method are each a distinct method that puts agile values into practice in its own way, alongside more widely known frameworks like Scrum and Kanban.

What are the general steps in an agile development process?

Most agile methods follow a similar rhythm even when the terminology differs: gather and prioritize requirements, plan a short iteration, build and test a working piece of the product, present it to users or the client for feedback, and use that feedback to plan the next iteration. RUP labels this progression Inception, Elaboration, Construction, and Transition. XP calls it Planning, Coding, Testing, and Listening. The underlying pattern of building, checking, and adjusting stays consistent across methods.

Is RUP methodology considered agile, or is it a hybrid framework?

RUP is often described as a hybrid. It keeps the iterative, feedback-driven core of agile development while adding more formal documentation and governance than lighter methods like XP or Crystal. Many teams that adopt RUP scale back its artifacts to make it feel closer to a standard agile approach.

Is Extreme Programming (XP) an agile development method?

Yes. XP was developed by Kent Beck as one of the original agile methods, built around short feedback loops, frequent small releases, and a specific set of engineering practices like test-driven development and pair programming that support those loops.

What is Crystal development methodology best suited for?

Crystal is best suited to teams that value direct, frequent communication over heavy documentation. Crystal Clear works well for small, co-located teams of about 6 to 8 people, while the other Crystal variants, such as Yellow, Orange, and Red, scale the same principles up for larger teams and higher-stakes projects.

How do I know which agile method my team should use?

Start by looking at team size, how available the customer or client will be for ongoing feedback, and how much formal documentation your industry or contract requires. Small, tightly knit teams with an available customer often do well with XP or Crystal Clear. Larger or regulated projects tend to fit better with RUP, DSDM, or FDD.

Can multiple agile methods be combined on a single project?

Many teams do exactly this. It is common to run Scrum-style sprints and standups while using FDD’s feature list as the backlog, or to apply DSDM’s MoSCoW prioritization inside a Kanban board. Combining methods works best when the team agrees in advance on which practices, meetings, and roles apply so expectations stay consistent.

What is the difference between an agile methodology and an agile method?

Agile methodology refers to the broader philosophy and set of values described in the Agile Manifesto. An agile method, such as RUP, Crystal, XP, ASD, FDD, or DSDM, is a specific, structured way of implementing that philosophy, complete with its own phases, roles, and practices.

  Advantages of SWOT Analysis (6 Benefits and 4 Limitations)
Posted in: Methods