Agile methods allow us to handle rapidly changing requirements, typical in most software projects. These methods are conventionally used for small teams and software projects. However, in this course, you will learn how to effectively apply Agile methods to large software projects and large teams.

You’ll start with a recap of the Agile Manifesto, followed by a description of the common challenges associated with Agile methods in the context of large software projects. You’ll learn how Agile approaches have been applied to build responsibility. Next, you’ll learn about approaches to apply Agile methods in the processes. You will then learn best practices for applying Agile methods such as software testing, and software architecture. 

This course provides insights into successful and unsuccessful approaches to introducing agility to teams, processes, and technology aspects of large projects. It also teaches strategies to secure organizational buy-in for agility in the context of large projects and teams.

Applying Agile Methods to Large Teams and Projects

## Labeling agile challenge
Agile processes are trendy. Everybody wants to label all their products and services as "agile." Furthermore, the manifesto is written in a way that is very hard to disagree with. Even hardcore linear process fans will agree that people are the most important subject in project development. Therefore, glancing at the manifesto will not help to characterize an agile process. On top of that, there are no formal, explicit, or hard criteria that define an agile process. This makes it easy to sell every process as an agile one. Although some of the agile processes are described in every detail because they serve as a starting line and can be adapted according to the team's needs, they can change over time. Consequently, they may change during the course of the development cycle, so that they no longer reflect their original definition. 


# Labeling agile challenge
Agile processes are trendy. Everybody wants to label all their products and services as "agile." Furthermore, the manifesto is written in a way that is very hard to disagree with. Even hardcore linear process fans will agree that people are the most important subject in project development. Therefore, glancing at the manifesto will not help to characterize an agile process. On top of that, there are no formal, explicit, or hard criteria that define an agile process. This makes it easy to sell every process as an agile one. Although some of the agile processes are described in every detail because they serve as a starting line and can be adapted according to the team's needs, they can change over time. Consequently, they may change during the course of the development cycle, so that they no longer reflect their original definition. 


Learn about the challenges and common pitfalls in characterizing a process as agile and some guidelines to address this problem.

Introduction to the Course

Agility and Largeness

Dealing with Large Teams

Dealing with the Process

Dealing with the Technology

Dealing with the Company

Putting It All Together: A Project Report (Case Study)

Final Thoughts

Cloak Agile Process

Labeling agile challenge