Choosing the Right Agile Methodology for Projects Now Easy with these Key Tips

08 June 2023

Add To Wishlist

Choosing the Right Agile Methodology for Projects Now Easy with these Key Tips

Features

Table of Contents

  • Description

  • Where Do You Use an Agile Approach?

  • Scrum

  • Kanban

  • Scrumban

  • eXtreme Programming (XP)

  • Conclusion

Description

Imagine you are a young project manager in the 1970s.

You are given your first software project, the first software project ever to be executed, with a bunch of engineers.

You’d need a methodical approach.

What would you do?

You’d probably look to learn how things are done elsewhere and try to replicate that in your project. And the readily available one is from the all-pervasive Manufacturing field.

The ‘traditional’ approach.

That’s what happened.

It worked then.

Well, sort of. No alternatives were available.

Though, the issue with that approach was glaring:

To develop a physical product, you must design and freeze the features and behavior before manufacturing it. However, if you are developing a software product, you can (and must) be able to change the features and behavior anytime before the product reaches end users.

And so, applying the traditional approach to software development was like trying to fit a square peg into a round hole.

Thus, the Agile approach took birth when 17 software developers met in the Spring of 2000 to discuss how they could create a flexible way to build new software faster, without expensive change cycles.

That Agile thought process created several sub-frameworks and approaches, such as Scrum, Kanban, Crystal, XP and more.

They all have one thing in common: The key principles of Agile.

These agile approaches are:

  • Deceptively simple
  • Easier to manage & control
  • Flexible to incorporate changes
  • Transparent to show progress to stakeholders
  • Engineered to create high quality products efficiently
  • Involves short duration of work with an ‘inspect & adapt’ approach

But not every project is a great fit for Agile.

Where Do You Use an Agile Approach?

At a high level, you will go with Agile if:

  • You want to mitigate risks quickly
  • The requirements are prone to change
  • You need to get to market quickly and economically
  • You cannot visualize how exactly your end product looks like
  • Your stakeholders demand constant involvement and transparency
  • You use complex technology or solution approach that requires research & development

In software development, an Agile approach is the one that involves self-organizing and cross-functional teams that use adaptive planning to develop the product, working closely and transparently with the stakeholders, accommodating changes to specifications to align with business needs.

There are many ‘flavors’ of Agile you can consider.

In general, an Agile method is meant to allow the team to do their best work while maintaining the appropriate level of quality. But, using a wrong Agile approach can create the exact opposite result, restricting the teams from working efficiently.

Hence, as a project manager, you need to be able to choose the Agile approach that is the right fit for your project.

Let us look at some of the most often used Agile approaches, and the factors you should consider as a project manager to validate which is a good fit for your project.

At a high level, you will go with Agile if:

  • You want to mitigate risks quickly
  • The requirements are prone to change
  • You need to get to market quickly and economically
  • You cannot visualize how exactly your end product looks like
  • Your stakeholders demand constant involvement and transparency
  • You use complex technology or solution approach that requires research & development

In software development, an Agile approach is the one that involves self-organizing and cross-functional teams that use adaptive planning to develop the product, working closely and transparently with the stakeholders, accommodating changes to specifications to align with business needs.

There are many ‘flavors’ of Agile you can consider.

In general, an Agile method is meant to allow the team to do their best work while maintaining the appropriate level of quality. But, using a wrong Agile approach can create the exact opposite result, restricting the teams from working efficiently.

Hence, as a project manager, you need to be able to choose the Agile approach that is the right fit for your project.

Let us look at some of the most often used Agile approaches, and the factors you should consider as a project manager to validate which is a good fit for your project.

Scrum

Scrum is the most widely used Agile framework for project management and software development.

It uses the concept of time-boxing, or creating work increments in 2-4 weeks of iterative “sprints”. This allows the team to better meet customer and end-user expectations.

The Scrum framework allows clients to be involved throughout the development process, allowing them to observe the product being built and convey any modifications they require, which may be addressed rapidly.

This ensures client satisfaction and control for on-time delivery.

There are 3 roles in Scrum:

  • Product owner. The bridge between business and development team. Provides clarity on requirements.
  • Scrum Master. Responsible for ensuring that the team and stakeholders work following the Agile principles.
  • Development team. The set of cross-functional people that build the product increment by working collaboratively.

A team of 5-9 people works with the Product Owner and Scrum Master for the duration of the sprint.

At the end of which, they showcase the product increment to any and all interested stakeholders in a ceremony called “product review”.

They also validate their approach in an Agile ceremony called “sprint retrospective”, and make any necessary changes to their process before starting the next sprint.

Factors to Consider as a Project Manager

Scrum framework was developed for two key needs: speed of development and accommodating changing client requirements.

This approach allows you to build a product using an iterative and incremental approach. Use this framework if you want to create a product with changing requirements, but you also need to quickly take the product to the market.

This approach might not be suitable if you don’t have the complete commitment from the team and stakeholders to make it work.

Go for Scrum if the following is true:

  • You have a team that is mature and dedicated
  • Client is not clear about all the requirements upfront
  • Project is complex and needs validation from client throughout
  • The project status needs to be known to all stakeholders on a daily basis
  • Client wants to involve with the development and make changes frequently

Scrum may not be a good choice if the following is true:

  • You do not have a good cross-functional team with expertise in their area
  • Requirements are clear, and the client expects finished product only at the end of the project
  • You are load balancing multiple projects by sharing team members across multiple projects

If you want to learn more about Scrum, Scrum for Agile Scrum Practitioners by GoSkills is a good online course to consider. 

Are you already working as a Scrum Master? Check out this course by GoSkills, specifically tuned for Scrum Masters.

Scrum is the most widely used Agile framework for project management and software development.

It uses the concept of time-boxing, or creating work increments in 2-4 weeks of iterative “sprints”. This allows the team to better meet customer and end-user expectations.

The Scrum framework allows clients to be involved throughout the development process, allowing them to observe the product being built and convey any modifications they require, which may be addressed rapidly.

This ensures client satisfaction and control for on-time delivery.

There are 3 roles in Scrum:

  • Product owner. The bridge between business and development team. Provides clarity on requirements.
  • Scrum Master. Responsible for ensuring that the team and stakeholders work following the Agile principles.
  • Development team. The set of cross-functional people that build the product increment by working collaboratively.

A team of 5-9 people works with the Product Owner and Scrum Master for the duration of the sprint.

At the end of which, they showcase the product increment to any and all interested stakeholders in a ceremony called “product review”.

They also validate their approach in an Agile ceremony called “sprint retrospective”, and make any necessary changes to their process before starting the next sprint.

Factors to Consider as a Project Manager

Scrum framework was developed for two key needs: speed of development and accommodating changing client requirements.

This approach allows you to build a product using an iterative and incremental approach. Use this framework if you want to create a product with changing requirements, but you also need to quickly take the product to the market.

This approach might not be suitable if you don’t have the complete commitment from the team and stakeholders to make it work.

Go for Scrum if the following is true:

  • You have a team that is mature and dedicated
  • Client is not clear about all the requirements upfront
  • Project is complex and needs validation from client throughout
  • The project status needs to be known to all stakeholders on a daily basis
  • Client wants to involve with the development and make changes frequently

Scrum may not be a good choice if the following is true:

  • You do not have a good cross-functional team with expertise in their area
  • Requirements are clear, and the client expects finished product only at the end of the project
  • You are load balancing multiple projects by sharing team members across multiple projects

If you want to learn more about Scrum, Scrum for Agile Scrum Practitioners by GoSkills is a good online course to consider. 

Are you already working as a Scrum Master? Check out this course by GoSkills, specifically tuned for Scrum Masters.

Kanban

According to PMI’s PMBOK guide, Kanban and Agile are two descendants of Lean thinking. Kanban is regularly used for projects either as a complete approach or as part of a Hybrid project management approach.

Kanban originates in the manufacturing field, and uses visual cues about work and flow of the work through the system. This visual representation is called Kanban board.

The original Kanban System, Source: Toyota global website

In the digitized version of this Kanban board, work is pulled from the backlog represented under one of the columns and moved through other columns representing the states it goes through.

Kanban board provides a visual overview of each task’s stage at any given time. This makes it a good system to conduct any type of ‘flow’ based projects, such as creating an advertising campaign, a large legacy product defect management system, or an HR recruitment process.

When you see the big picture, you can also easily identify bottlenecks and mitigate risks.

Kanban approach is built on 6 practices:

  • Visualize the workflow (helps control the quality of outcome)
  • Limit work in progress (avoids spreading team too thin)
  • Manage flow (avoid wastage of time and resources)
  • Make process policies explicit (team works cohesively)
  • Implement feedback loops (continuously get better at producing quality output)
  • Improve collaboratively (develop camaraderie, increase longevity, avoid burnout)

The digital version of the Kanban board looks like this one here.

Image courtesy: Dr Ian Mitchel from wikipedia.org

The great news is that it is flexible enough to adapt to your process flow stages.

Factors to Consider as a Project Manager

Go for Kanban if the following is true:

  • Your project is based on a “flow based” process
  • Your project needs to constantly show progress visually to all stakeholders
  • You need a team to focus on a limited set of tasks at a time, and have a way to control WIP items
  • You prefer to work on a “pull” based approach (where the business needs dictate which task is to be taken up for work and when).

Kanban may not be a good choice if the following is true:

  • As the first step to transitioning a legacy system to Agile
  • Efficiency is not critical (such as Research based work)
  • You are not looking at a continuous delivery based system
  • Your project work passes back and forth across interconnected stages
  • You need multiple teams working interactively across different systems or modules

If you already work on Agile projects and want to learn how to manage projects using Kanban, this course by Pluralsight on Kanban for Agile/Scrum Practitioners is the best one to consider.

If you are just getting started, this Udemy course on Kanban is just what you need to get up and running in no time.

According to PMI’s PMBOK guide, Kanban and Agile are two descendants of Lean thinking. Kanban is regularly used for projects either as a complete approach or as part of a Hybrid project management approach.

Kanban originates in the manufacturing field, and uses visual cues about work and flow of the work through the system. This visual representation is called Kanban board.

The original Kanban System, Source: Toyota global website

In the digitized version of this Kanban board, work is pulled from the backlog represented under one of the columns and moved through other columns representing the states it goes through.

Kanban board provides a visual overview of each task’s stage at any given time. This makes it a good system to conduct any type of ‘flow’ based projects, such as creating an advertising campaign, a large legacy product defect management system, or an HR recruitment process.

When you see the big picture, you can also easily identify bottlenecks and mitigate risks.

Kanban approach is built on 6 practices:

  • Visualize the workflow (helps control the quality of outcome)
  • Limit work in progress (avoids spreading team too thin)
  • Manage flow (avoid wastage of time and resources)
  • Make process policies explicit (team works cohesively)
  • Implement feedback loops (continuously get better at producing quality output)
  • Improve collaboratively (develop camaraderie, increase longevity, avoid burnout)

The digital version of the Kanban board looks like this one here.

Image courtesy: Dr Ian Mitchel from wikipedia.org

The great news is that it is flexible enough to adapt to your process flow stages.

Factors to Consider as a Project Manager

Go for Kanban if the following is true:

  • Your project is based on a “flow based” process
  • Your project needs to constantly show progress visually to all stakeholders
  • You need a team to focus on a limited set of tasks at a time, and have a way to control WIP items
  • You prefer to work on a “pull” based approach (where the business needs dictate which task is to be taken up for work and when).

Kanban may not be a good choice if the following is true:

  • As the first step to transitioning a legacy system to Agile
  • Efficiency is not critical (such as Research based work)
  • You are not looking at a continuous delivery based system
  • Your project work passes back and forth across interconnected stages
  • You need multiple teams working interactively across different systems or modules

If you already work on Agile projects and want to learn how to manage projects using Kanban, this course by Pluralsight on Kanban for Agile/Scrum Practitioners is the best one to consider.

If you are just getting started, this Udemy course on Kanban is just what you need to get up and running in no time.

Scrumban

No, this is not an alternative by people looking to ban the Scrum approach.

As the name suggests, this is the combination of Scrum and Kanban.

The primary benefit of Scrumban is that instead of timeboxing a sprint and deciding the scope of work for that sprint (as in Scrum), the team will “pull” (as in Kanban) work from a prioritized product backlog (as in Scrum), based on team’s capacity, again, reducing the Work-In-Process items (as in Kanban). 

Image courtesy: https://hexaware.com/blogs/agile-devops-part-1-a-guide-to-scrumban/

You will include the planning, prioritizing, reviews and retrospectives as needed or at logical points, such as a consolidated delivery point.

As you can imagine, with Scrumban:

  • Priority of work is more closely associated with business needs
  • There is no imposition of cross-functional team mix or restriction of team size
  • There is no planning at the beginning of a sprint, but periodic planning is required

Factors to Consider as a Project Manager

Go for Scrumban if the following is true:

  • Your project has frequent and unexpected changes to features and their priorities
  • If the work is event-driven (customer support tickets, for example)
  • Your project is transitioning from Scrum to Kanban, or the other way around

Scrumban may not be a good choice if the following is true:

  • Your project is about developing a software product, and a straightforward approach like Scrum works great
  • Your project is purely process-oriented with limited steps, making Kanban a good fit

Does Scrumban look like something you want to learn more about and implement in your organization?

Look no further than this beginner-friendly, but in-depth course for a software developer.

And if you are looking for a Scrumban certification, check out Certified Scrumban Practitioner and Professional Scrum with Kanban Certification by Xebia Academy.

No, this is not an alternative by people looking to ban the Scrum approach.

As the name suggests, this is the combination of Scrum and Kanban.

The primary benefit of Scrumban is that instead of timeboxing a sprint and deciding the scope of work for that sprint (as in Scrum), the team will “pull” (as in Kanban) work from a prioritized product backlog (as in Scrum), based on team’s capacity, again, reducing the Work-In-Process items (as in Kanban). 

Image courtesy: https://hexaware.com/blogs/agile-devops-part-1-a-guide-to-scrumban/

You will include the planning, prioritizing, reviews and retrospectives as needed or at logical points, such as a consolidated delivery point.

As you can imagine, with Scrumban:

  • Priority of work is more closely associated with business needs
  • There is no imposition of cross-functional team mix or restriction of team size
  • There is no planning at the beginning of a sprint, but periodic planning is required

Factors to Consider as a Project Manager

Go for Scrumban if the following is true:

  • Your project has frequent and unexpected changes to features and their priorities
  • If the work is event-driven (customer support tickets, for example)
  • Your project is transitioning from Scrum to Kanban, or the other way around

Scrumban may not be a good choice if the following is true:

  • Your project is about developing a software product, and a straightforward approach like Scrum works great
  • Your project is purely process-oriented with limited steps, making Kanban a good fit

Does Scrumban look like something you want to learn more about and implement in your organization?

Look no further than this beginner-friendly, but in-depth course for a software developer.

And if you are looking for a Scrumban certification, check out Certified Scrumban Practitioner and Professional Scrum with Kanban Certification by Xebia Academy.

eXtreme Programming (XP)

The eXtreme Programming (XP) methodology was developed by Kent Beck and considered suitable for software development projects.

This attempts to simplify the software development process by preferring a straight-forward approach, breaking down the complexity. The eXtreme Programming approach aims to elevate traditional software development practices to a level that ensures very high-quality deliverables.

This is done using practices such as simple design approach, pair-programming, close communication, constant feedback, and intense testing, so there is a lot of stress on teamwork and collaboration across customers, developers, and management.

The five values followed in XP projects:

  • Simplicity
  • Communication
  • Feedback
  • Respect
  • Courage

A mindset of simplicity is like developers asking themselves, “what is the simplest approach that works to implement this feature?”. This mindset avoids unnecessarily complicated designs or development approaches, and advocates the need to be clear rather than clever. 

This mindset works well only when the communication is impeccable, and without ambiguity. Ability to have a face to face discussion with a white board helps efficient communication in a team set up. 

Such a communication approach also encourages constant feedback and areas for improvement-which is the best way to iteratively get better and deliver quality output.

None of this is possible without inherent respect for each other, where the relationships and commitments are honored. 

This in turn builds trust and gives the team members the courage to speak up when something is not right, even at the organizational level. This allows people to share feedback without fear, and gives them the courage to accept and work on it.

Factors to Consider as a Project Manager

Go for XP if the following is true:

  • Your project is heavily testing dependent
  • Your project makes use of bleeding edge technology
  • Your team has a mix of few experts and many juniors
  • You need to ensure simple design and best coding practices

XP may not be a good choice if the following is true:

  • Your team is not co-located. That is, people work remotely from different places or timezones
  • Your product has many parts – software, firmware, hardware, and manufacturing
  • Your project is large and complex with hundreds of team members

XP looks like a good choice for your project, and you want to master this methodology?

Here’s a course from LinkedIn Learning. This eXtreme Programming Practitioner certification course is another option if you are looking for a certification program.

The eXtreme Programming (XP) methodology was developed by Kent Beck and considered suitable for software development projects.

This attempts to simplify the software development process by preferring a straight-forward approach, breaking down the complexity. The eXtreme Programming approach aims to elevate traditional software development practices to a level that ensures very high-quality deliverables.

This is done using practices such as simple design approach, pair-programming, close communication, constant feedback, and intense testing, so there is a lot of stress on teamwork and collaboration across customers, developers, and management.

The five values followed in XP projects:

  • Simplicity
  • Communication
  • Feedback
  • Respect
  • Courage

A mindset of simplicity is like developers asking themselves, “what is the simplest approach that works to implement this feature?”. This mindset avoids unnecessarily complicated designs or development approaches, and advocates the need to be clear rather than clever. 

This mindset works well only when the communication is impeccable, and without ambiguity. Ability to have a face to face discussion with a white board helps efficient communication in a team set up. 

Such a communication approach also encourages constant feedback and areas for improvement-which is the best way to iteratively get better and deliver quality output.

None of this is possible without inherent respect for each other, where the relationships and commitments are honored. 

This in turn builds trust and gives the team members the courage to speak up when something is not right, even at the organizational level. This allows people to share feedback without fear, and gives them the courage to accept and work on it.

Factors to Consider as a Project Manager

Go for XP if the following is true:

  • Your project is heavily testing dependent
  • Your project makes use of bleeding edge technology
  • Your team has a mix of few experts and many juniors
  • You need to ensure simple design and best coding practices

XP may not be a good choice if the following is true:

  • Your team is not co-located. That is, people work remotely from different places or timezones
  • Your product has many parts – software, firmware, hardware, and manufacturing
  • Your project is large and complex with hundreds of team members

XP looks like a good choice for your project, and you want to master this methodology?

Here’s a course from LinkedIn Learning. This eXtreme Programming Practitioner certification course is another option if you are looking for a certification program.

Conclusion

If your project is a candidate for Agile project management, you are spoiled for choice. And if you don’t choose the right approach, you may be doing a disservice to your project and organization.

This article helps you understand the mindset required and points to consider when choosing an agile approach for your project.

Plus, once you make a choice, you can take up one of the suggested courses to authentically learn more about the agile approach and ensure the success of your project.

Features

Table of Contents

  • Description

  • Where Do You Use an Agile Approach?

  • Scrum

  • Kanban

  • Scrumban

  • eXtreme Programming (XP)

  • Conclusion