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

#
## Refactoring
Typically, if a system grows over time, its design tends to get messier and messier at the same time. This can be worse on a large team because the more people that are involved with building a system, the harder it is to keep it clean. However, if everybody on the team refactors continuously, there is a chance that the design will stay clean and easy to understand. 


### Why isn't refactoring common?
Refactoring does not seem to be a common habit in (large) teams because:
*  A lot of people still believe it will slow them down. 
* Sometimes there is no refactoring tool support for the particular project available, which makes it much more difficult than it should be.
 * The developers often fear being blamed for not developing any new functionality because they are busy refactoring.
* Most people are not trained to do refactoring properly. They do not know how, why, when, or where they should refactor, and they are scared of taking up the responsibility to do so.

### Best practices: Making refactoring a habit

To make refactoring a habit, implement these practices:
* Consider necessary refactorings while planning an iteration. Essential refactoring provides a business value and should be explained to the customer.
* Coach in continuous refactoring. If the team is used to continuously improving the code, refactorings should not be too overwhelming.
* Occasionally devote a development cycle or an iteration to refactoring. In such a refactoring iteration, there will be no focus on feature development—all effort will revolve around cleaning up the design.
* Ask the review team to point out necessary refactorings. To emphasize the training opportunity, the review team should not only point out the refactorings, but should also show how the refactorings can be accomplished and explain the underlying purpose of each one.

We should always work toward making refactoring a habit. If we're successful, most refactorings will not require any special planning effort. Instead, the team members will start to refactor the design whenever they feel it is necessary, and will only indicate whether it requires a longer timeframe than usual and has to be scheduled (especially in an iteration).



Learn about good practices in refactoring and supporting tools.

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

Techniques and Good Practices: Refactoring

Refactoring

Why isn’t refactoring common?