Which Form of Agile is Best for Your Team? 7 Common Methods of Agile

Agile — it’s a common term in the business world, and it involves many different methodologies that can cater to any kind of team.

But, if you aren’t familiar with the process, it can be intimidating, especially when it comes to choosing a method for your team.

This article will give you a brief overview of each type of Agile and help simplify the decision-making process.

What are the different Agile methodologies?

We are going to discuss the seven major methodologies. Agile methodologies have been adapted over the years and will continue to be adapted, so there are some niche methodologies that aren’t listed in this article.

Different sources will give different names to these various Agile methodologies, and may even give some variation on how they are performed, however, these are the most common ones found throughout most Agile websites, books, and other publications.

Keep in mind that with any Agile methodology, the common goal is to streamline the workflow process, heighten organization, and increase efficiency.

Scrum

Scrum is one of the main Agile methods and is arguably the most used among teams. It involves several roles including a Scrum Master (the team leader and facilitator), a Development Team, and an Initiative Owner. The Scrum process or Scrum Cycle occurs over a set time period, which includes steps like Sprint Planning, The Sprint, Daily Standup Meeting, Sprint Review, and Sprint Retrospective.

The outcome of Scrum (ideally) is to have Artifacts or Deliverables, which are categorized as Product Backlog, Sprint Backlog, and Product Increment.

Read more about Scrum in our “3 Forms of Agile Methodology You Need to Know” blog post

Should my team use Scrum?

Scrum is recommended for smaller teams (less than eight people) that mainly focus on project work (source). Those who use Scrum will benefit from its focus on an iteration format (Sprints) that sets out to execute the entire project process by using repetition.

“Anybody who has a complex project can benefit from using Scrum. Prioritize large to-do lists into manageable tasks with improved teamwork, better communication, and faster results.” (source)

Because of the focus on iteration, Scrum is a great option for teams who like efficiency and organization implemented into their work cycle. A rapid work cycle means quicker feedback, and projects or products generally get completed faster with fewer roadblocks. Within Scrum, if roadblocks do occur, the goal is to fix them as soon as possible to continue with the Sprint process.

Although it is often recommended for project-focused teams, it can also work well for product-focused teams — it’s a great method to use if you are new to Agile because everything is clearly laid out and easy to comprehend if you follow the Scrum process.

If you have a large team or are managing multiple teams and want to apply Scrum, try using either SoS or LeSS. SoS stands for “Scrum of Scrums”, and LeSS stands for “Large Scale Scrum”. Scrum of Scrums will be most accessible to teams who have multiple smaller Scrum teams within an overall organization, whereas Large Scale Scrum is great for scaling Agile in general for any mid-sized team.

If your organization or company is very large and isn’t interested in one specific method, try implementing SAFe, which stands for Scaled Agile Framework (source).

Kanban

Kanban is known within Agile as a product-focused methodology. The method uses what is referred to as a Kanban Board, which can be physical or digital (Stormboard offers various Kanban templates to get you started). The Kanban Board is ideal for teams who need visualization in their work process — to physically see what to do and what will come next. The image below is a sample of a virtual Kanban Board that Stormboard offers.

“With Kanban, you are always working on the most important activities first, as quickly as you can.” (source)

Other than visualization via a board, Kanban is about limiting the work that is being done at any given time, and continually working without having set iterations. This means that whatever is most essential at that time is what is worked on first, without unnecessarily working on things that can be saved for a later time.

Should my team use Kanban?

Scrum can be a bit difficult to adapt or scale in many instances, so Kanban is a good alternative (source). If your team is mostly product-focused, Kanban is highly recommended.

Another reason to consider Kanban is the ability to finish a project or release a product when it’s done, and not have to wait for a Sprint to be over as you would need to in Scrum (source). Flexibility is key with Kanban, so if you aren’t in need of too much structure it is a good way to go.

It’s also a good choice if everyone in your team works better by visually seeing their work on a board and are interested in editing what goes where, as their work progresses. Kanban is ideal if the work you are doing will change multiple times as your process develops — it will allow room for you to adapt.

Does your team prefer continual workflow as opposed to fixed iterations? Then this method will be the best one to choose.

Read more about Kanban in our blog “Your Guide to Using Stormboard for Kanban”

Lean Development

Lean Development, which was derived from Lean Manufacturing, requires teams to cut out as much waste in their work cycle as they can, hence the term “Lean”. Keeping the work to the bare minimum (only what is necessary) is what Lean relies on. Waste can refer to anything from communication that isn’t serving a purpose, to extra tasks that are piling up (source).

Lean is also referred to as Lean Software Development because of its popularity in the software field. Mary and Tom Poppendieck were some of the first people to introduce the principles of Lean, which have evolved and adapted over the years, but generally include: Eliminating Waste, Deliver Work Quickly, Deliver/Decide Late, Build Quality In, Optimize the Whole, Learning and Knowledge, and Encourage/Energize People.

Read more about these principles in our blog post: “3 Forms of Agile Methodology You Need to Know”.

The principles of Lean strive to get teams to ensure that their work is of the highest quality during the entire work process, and to complete the work as quickly as possible so that feedback is brought back to them swiftly.

There are similarities to Kanban in that Lean is also a continuous flow of work rather than iterations. Teams who like to focus on certain projects at once without needing to stop and check-in all the time will benefit from using Lean.

When it comes to team organization, Lean Development teams are often self-organizing. This all depends on the organization and how they choose to scale their work, however.

Should my team use Lean?

Does your team currently have a lot of unnecessary extra work in their process? If so, Lean will help to rid the team of anything considered waste so that you can go back to focusing on what needs to get done ASAP and make sure the product is getting delivered with efficient, helpful feedback.

Lean is also great for teams who don’t want to work with a high-level of role organization and are interested in working in a customer-focused environment. It’s a more flexible method, while still having a strong priority towards what needs to be completed.

Kanban and Lean tend to work well together because both have the priority that only one aspect of a project should be focused on at a time. Many teams find that combining the methods or using both simultaneously is a great advantage to them (source). The main difference between the two is that Kanban relies on its visual board component.

Don’t want too much structure but instead have more freedom to make decisions? Interested in a method that gets projects done ASAP with little to no distractions? Lean might be the right fit for your team.

Extreme Programming (XP)

XP is popular among smaller sized software development teams as it gives a lot of attention to the customer and their relationship with the development team (source). For XP teams, the main goal is to get their product perfect for the customer, and if it isn’t, they will continue to work on it to strive for positive feedback.

Because it is so software and tech-focused, Extreme Programming is one of the only Agile methods that is very niche and specialized, therefore it won’t work for every team.

“Instead of delivering everything you could possibly want on some date far in the future this process delivers the software you need as you need it” – (source)

In XP, software testing happens early and occurs often. There are also similarities to Lean, as XP aims at cutting out extra steps by keeping the entire process as simple as possible. The team and the managers work equally to communicate and deliver quality to their customer base.

Should my team use Extreme Programming?

Is your team in the software/technology development field specifically? Do you hold customer expectations in high regard when it comes to your software product? If you said yes to these questions, your team is a good candidate for Extreme Programming.

Also, if your team enjoys working closely with one another and self-organizing instead of having highly distinct roles, XP will be the appropriate Agile method to use.

Feature Driven Development (FDD)

This method is all about taking a model or a design and transitioning that into the development stage, thus it is ideal for developers, and is recommended for larger teams.

FDD is known to have five processes, which include: Develop an Overall Model, Build a Features List, Plan by Feature, Design by Feature, and Build by Feature (source). These processes are the core of FDD and are in place to allow large teams to divide up the work according to each members’ skills.

Just like Scrum, FDD often uses a relatively short iteration format (a set time period to complete the work). This is better for larger teams because they need more structure. Smaller teams are easier to self-regulate, whereas larger teams can’t usually do this.

Should my team use Feature Driven Development?

FDD is most optimal for big business developers in the banking and financial sectors, where process maturity and quality control are obligatory.” – (source)

Are you working within a large team? Is the team mostly composed of developers? If these sound like your team, then choosing FDD will benefit the work you are doing. Also, if you like the idea of Scrum or XP, but need to scale up, this may be the best alternative.

Crystal Methodology

Crystal Methods (started by Alistair Cockburn) is a term that represents a grouping of sub-methods, all of which have some focus or priority on people.

The different color crystal methods are Crystal Clear, Crystal Yellow, Crystal Orange, and Crystal Red. The darker the Crystal color, the larger the team that it’s recommended for. Crystal Clear, for example, is for the smallest teams, while Crystal Red is for the largest teams (Red can be for huge companies of 50+ people).

The reason for the different colors, according to Cockburn, is that depending on the size of a team, they will need to change their priorities and strategies for scalability.

“The methods are color-coded to signify the risk to human life. For example, projects that may involve risk to human life will use Crystal Sapphire while projects that do not have such risks will use Crystal Clear. Crystal focuses on six primary aspects: people, interaction, community, communication, skills, and talents.” – (source)

While the other Agile methods focus on the process and the tasks at hand, Crystal is more about the actual humans involved and the real-life aspect. People are seen as the top priority within this method. In other words, if the team is not content, safe, or working smoothly, then the process can wait until communication is sorted out.

Crystal doesn’t mean to make the work or the product a non-factor, it just holds different aspects of the overall process in different priority. There are still the common agile goals of having quality work that is delivered as soon as possible and eliminating waste (source).

Should my team use Crystal Methodology?

If your focus is on workplace safety, effective communication, and you want to prioritize the team in the most straightforward way possible, Crystal is a good choice.

The way your team interacts during the work process is what Crystal focuses on. So, If this is of interest to you and your team, it will work well as an Agile method.

Crystal might also be beneficial for teams who need a lot of improvement to their overall communication and interaction efforts. Basically, if you want less complicated work processes and open communication, Crystal is for you.

If you still aren’t sure, Active Collab has compiled an in-depth look at Crystal Methodology that delves into why it’s a useful method.

Dynamic Systems Development Method (DSDM)

Dynamic Systems Development Method, which is more recently referred to as Driving Strategy, Delivering More, is an Agile method that works great with larger organizations and has been known to be popular in the software field. It tackles the entire work process from start to finish — not just one part of it like some of the other methods.

According to AgileKRC, the eight principles of DSDM are: Focus on the business need, Deliver on time, Collaborate, Never compromise quality, Build incrementally from firm foundations, Develop iteratively, Communicate continuously and clearly, and Demonstrate control. These will differ depending on the source but are the general guidelines a DSDM team uses during a project cycle. Because of the various principles being in a specific order, DSDM teams will want to make sure they are following each one to ensure their projects aren’t interrupted.

Based on the eight principles, it’s clear that DSDM focuses on an iterative approach that strives for a solid process and has many similarities to Scrum. The iterations within DSDM are referred to as TimeBoxes or Timeboxing, which are similar to Sprints that are practiced in Scrum.

Unlike other Agile methods, DSDM is known as being more precise, as it usually requires some sort of formal reporting done as the project cycle is occurring (source). The DSDM model usually consists of roles and structure, which is why it can be closely matched to the Scrum mindset. One of the main methods used within DSDM is the MoSCoW method, which stands for Must Haves, Should Haves, Could Haves, and Won’t or Would Haves (source).

Should my team use DSDM?

DSDM will work for teams that need high levels of structure within their project cycles. This form of agile uses many methods and structured processes to make sure teams are getting the highest quality work done in a set amount of time.

Do you have large project cycles that can get out of hand? Want to try Scrum, but need something more scale-able or complex? Then DSDM is a great option for your team.

Conclusion

As we’ve explored in this article, it’s clear to see that Agile is a hugely dynamic methodology that has something for every team in almost every industry. Agile methods are always being expanded, adapted, and even some new ones may appear in the future, which confirms why Agile is such a widely circulated and successful form of project management.

If you found the form of Agile methodology that will best fit your team, what are you waiting for? Use Stormboard to take the next step in implementing your chosen method into your business or organization.

With hundreds of templates and endless customization, Stormboard is the ideal software for organizing your work processes and improving collaboration within your team.

Get Started

Want to see more Agile posts from Stormboard? Try out Stormboard’s Agile Templates  sign up for a free trial today!

Want to save this article to review later? Pin the image below!

 

Keep Reading

Previous
Previous

Announcing Stormboard’s NEW Microsoft Flow Integration!

Next
Next

Stormboard Works With Microsoft to Provide Seamless Integration!