Delve into Agile methodologies, compare them with Waterfall, explore planning techniques, and discover tools like SCRUM and Kanban. Gain insights into solving common problems with Agile.

This course is designed to help learners build an understanding of Agile’s process model and its different approaches and techniques.

To understand the advantages of implementing Agile techniques, the course begins with a comparison of Agile methods and the traditional Waterfall model. Then, you’ll get to know about different planning approaches to help users effectively adjust deadlines. Next, there’s a discussion on backlogs and different visual techniques, such as burn-down charts and burn-up charts, that help increase the efficiency of projects.

You will also learn Agile methodologies including SCRUM, eXtreme Programming, DSDM, Smart and Kanban, as well as the differences and similarities between these approaches. Finally, you’ll look at some common problems and learn ways to solve them using Agile methodologies.

Learn Agile Methodologies from Scratch

## Which agile approach is the best?

Every project is different. There’s no single Agile approach that works for all projects. Discussions on whether one Agile approach is better than the others conducted on several fronts are annoying and superfluous. The most important thing to consider is what we learn from each Agile approach and even traditional methodologies. How can we forge an approach from these experiences that works for our organization and our projects? In short: how can we assemble Agile?

Whichever approach an organization or project chooses is irrelevant. It’s more important that projects learn from the mechanisms and techniques that make Agile efficient and effective. Implement those mechanisms. Short iterations. Collaborating teams. A small unit of work. Prioritize again and again. Continuously plan and measure. Practice continuous testing and delivery. Keep communication as simple as possible.

Choose the approach that’s most obvious and best fits the organization and the type of projects being implemented. The approach gives the team a common vocabulary. Start, for example, with Scrum. Scrum is lightweight, has a big reputation, is fairly easy to implement, and provides a lot of freedom in the use of complementary techniques.


## Factors to consider when choosing an Agile approach

The question then is what additional techniques should companies use in their project? This is different for every project and depends on a variety of factors. The following question will help us understand the factors involved while choosing the approach:

+ Are there few or many stakeholders? 
+ Is the
project carried out locally or is it distributed? 
+ Are end users
directly involved? 
+ How does the project backlog get created?
+ How many parties work together? 
+ Is the software realized by
an external party?
+ Is the price fixed? 
+ How experienced is the
team? 
+ How complex is the architecture? 
+ How complex is the
domain?
+  How complex is the application landscape?
+  How
does the project fit into the existing organization?
+  Which
tools are used? 
+ How is the software handed over to maintenance?

In short, projects also have a sliding scale, from small and
lightweight to heavyweight and complex. As projects become
more complex and heavier, the team needs more grip. Some examples are as follows.
+ **Contracts:** In fixed-price projects, choosing the right contract type is vital.
+ **Preparation:** Many projects, especially long-term ones, choose one or two preparatory iterations using Smart and DSDM to get more of a foundation before starting on the realization.
+ **Set-up:** In short-term projects, it’s of great importance to have the development and other environments established in advance. Establishing the environments in distributed projects is even more complex. Think of continuous integration and unit testing. Establishing them on time is crucial.
+ **Stand-ups:** In any case, organize stand-up meetings. On distributed projects, video conferencing is essential for this.
+ **Dashboards:** In projects that are carried out in one location, a dashboard of post-its on the wall suffices, as does a spreadsheet to monitor progress. On distributed projects, an online dashboard is inevitable.
+ **Unit of work:** For simple applications or mobile web applications, user stories often suffice. In complex service-oriented application landscapes, smart use cases may be a better unit of work.
+ **Estimates:** On projects with distributed teams, estimating can be tricky. Estimation poker isn’t always possible. Are teams in different locations estimating the same way even if they use the same scale?
+ **Tools:** Be careful with the use of all kinds of tools.
+ **Tests:** On more complex projects, the role of testing is more crucial than on lightweight projects. If possible, don’t start complex Agile projects without explicitly having testers on the team.

Above all, don’t be dogmatic. Leave room for the team to optimize the chosen method during the project. Where necessary, add new techniques and best practices from the various Agile and traditional approaches. Give the team this space right from the first day of the project. A team will continue to learn.

This way, no method is imposed on the team. Instead, the team takes responsibility for its own method.


# Which agile approach is the best?

Every project is different. There’s no single Agile approach that works for all projects. Discussions on whether one Agile approach is better than the others conducted on several fronts are annoying and superfluous. The most important thing to consider is what we learn from each Agile approach and even traditional methodologies. How can we forge an approach from these experiences that works for our organization and our projects? In short: how can we assemble Agile?

Whichever approach an organization or project chooses is irrelevant. It’s more important that projects learn from the mechanisms and techniques that make Agile efficient and effective. Implement those mechanisms. Short iterations. Collaborating teams. A small unit of work. Prioritize again and again. Continuously plan and measure. Practice continuous testing and delivery. Keep communication as simple as possible.

Choose the approach that’s most obvious and best fits the organization and the type of projects being implemented. The approach gives the team a common vocabulary. Start, for example, with Scrum. Scrum is lightweight, has a big reputation, is fairly easy to implement, and provides a lot of freedom in the use of complementary techniques.


# Factors to consider when choosing an Agile approach

The question then is what additional techniques should companies use in their project? This is different for every project and depends on a variety of factors. The following question will help us understand the factors involved while choosing the approach:

+ Are there few or many stakeholders? 
+ Is the
project carried out locally or is it distributed? 
+ Are end users
directly involved? 
+ How does the project backlog get created?
+ How many parties work together? 
+ Is the software realized by
an external party?
+ Is the price fixed? 
+ How experienced is the
team? 
+ How complex is the architecture? 
+ How complex is the
domain?
+  How complex is the application landscape?
+  How
does the project fit into the existing organization?
+  Which
tools are used? 
+ How is the software handed over to maintenance?

In short, projects also have a sliding scale, from small and
lightweight to heavyweight and complex. As projects become
more complex and heavier, the team needs more grip. Some examples are as follows.
+ **Contracts:** In fixed-price projects, choosing the right contract type is vital.
+ **Preparation:** Many projects, especially long-term ones, choose one or two preparatory iterations using Smart and DSDM to get more of a foundation before starting on the realization.
+ **Set-up:** In short-term projects, it’s of great importance to have the development and other environments established in advance. Establishing the environments in distributed projects is even more complex. Think of continuous integration and unit testing. Establishing them on time is crucial.
+ **Stand-ups:** In any case, organize stand-up meetings. On distributed projects, video conferencing is essential for this.
+ **Dashboards:** In projects that are carried out in one location, a dashboard of post-its on the wall suffices, as does a spreadsheet to monitor progress. On distributed projects, an online dashboard is inevitable.
+ **Unit of work:** For simple applications or mobile web applications, user stories often suffice. In complex service-oriented application landscapes, smart use cases may be a better unit of work.
+ **Estimates:** On projects with distributed teams, estimating can be tricky. Estimation poker isn’t always possible. Are teams in different locations estimating the same way even if they use the same scale?
+ **Tools:** Be careful with the use of all kinds of tools.
+ **Tests:** On more complex projects, the role of testing is more crucial than on lightweight projects. If possible, don’t start complex Agile projects without explicitly having testers on the team.

Above all, don’t be dogmatic. Leave room for the team to optimize the chosen method during the project. Where necessary, add new techniques and best practices from the various Agile and traditional approaches. Give the team this space right from the first day of the project. A team will continue to learn.

This way, no method is imposed on the team. Instead, the team takes responsibility for its own method.


Learn which approach is better and the factors that need to be considered while choosing the Agile process.


Getting Started

Why does the Waterfall Process model not work?

What is Agile?

Short Iterations in Agile

Collaboration in Teams

Collaborating Roles

Agile Requirements

Estimating

Planning

Implementing Agile

Issues in Using Agile

Choosing the Most Appropriate Process Model

Conclusion

Assembling Agile

Which agile approach is the best?