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

#
## Finalizing the architecture
After the referential implementation is complete, the starting team often has a lot of ideas about what should be improved and how to develop not only a really good solution but also the world’s best architecture. We have to balance the following arguments and decide how good will be good enough for our architecture.

### Arguments worth considering
* Everybody would be proud to call their own architecture the best that has ever been developed, but the domain teams won’t profit from unnecessary flexibility.
* If the rest of the team has already been assembled, all the other project members are probably waiting to start their work. They probably won’t be able to contribute a lot to the discussion because they do not know much about the architecture built so far; therefore, they don't know if they need a better one. They will, though, probably be afraid to start developing if the architecture is not stable (or finalized).
* The customer is more interested in functionality than in how great the architecture is, mainly because they will neither see the architecture nor directly benefit from it.

Although all these arguments should be respected, the customer’s lines of reasoning carry the most weight. This does not mean that we should never build anything in our system that is not directly visible to the customer, but rather that we should only build it when it is needed in the development of some functionality.

### Fear of change
Allowing the architecture to improve can also provide a psychological problem. Developers tend to refuse to use something that is not yet finalized. They fear that all their effort will be thrown out if the architecture changes. On the other hand, the team cannot yet judge how much it might benefit from shaping the architecture itself. 


Learn how to improve upon referential architecture and about the importance of strategies for slow and steady team building.

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

Agile Process: Finalize the Architecture and Grow Slowly

Finalizing the architecture

Arguments worth considering