back

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

Collaborative, feedback-driven, and iterative

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.

Part 1

Rational 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.

Part 2

Crystal 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.

Part 3

Extreme 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.

Part 4

Adaptive 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.

Part 5

Feature-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.

Part 6

Dynamic 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.

 

  8 Main HR Metrics and 5 Tips How to use HR Analytics Effectively