Gain insights into applying Agile methods in large projects and teams. Explore challenges, best practices, and strategies to secure organizational buy-in for successful implementation.

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

# Introducing change
Not every change benefits from a smooth introduction. Sometimes it is better to change something so radically that the change we originally wanted to make comes naturally with the exaggerated change.


## Continuous feedback
Especially for a large project, continuous feedback is essential. For example, cycles for iterations and releases have to be much shorter than with smaller teams. 



The most important thing is to obtain quick feedback on all kinds of things: the organization, the environment, running software, staff satisfaction, and the like. Quick feedback should be the first thing we introduce. There is no way we can smoothly introduce shorter feedback cycles. As soon as this is established, all other changes will follow more naturally.

## Change gradually and listen to  the team
When introducing a massive change like a switch to agile development, do not force all the changes at once. Some might not be acceptable to the whole team. If we force such a change, team members may try to undermine every future change we try to make. Remember, it might just be the wrong time for the introduction of this change. Therefore, it is sometimes better to just wait until a situation arises that makes this change a necessity for the whole team and not just the change agent. In which case, it will be much better accepted.

>**Note:** Although we have the best arguments for the change and we believe Confucius was right when he said, 2500 years ago, that "thinking is the noblest way of learning," our team may want to follow the notion that the "hardest way of learning is experience."

We still have to respect that people hate change in general because they will always feel more comfortable in their existing situation than in an unfamiliar one (and typically believe that things can only get worse). People will only embrace change if their acceptable limit of suffering overtakes the pain threshold. They have to admit to themselves that the only way out is to give up their old habits and
go for the change.

Whenever there is resistance to a (necessary) change, suggest trying it at least for one development cycle. Sometimes, once they actually undertake the change, people are pleasantly surprised to find out that it is not as bad as they had assumed and that it actually worked out very well. Therefore, the pain they feared they would experience is often far greater than the actual pain.


Learn and understand the principles and practices for introducing change in a project's process.

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

Culture of Change: Introducing Change

Introducing change