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

> We believe we make experiences,\
 but the experiences make us.\
– Eugène Ionesco


To more clearly illustrate the things that we've discussed in this course, this chapter covers an example of a large project that decided to adapt an agile process. This is actually an experience report, which brings together the practices described earlier.

#
## The project's history
This project had roughly 200 members and had been under development for about two years when the customer realized there was no working software available and it was impossible to even guess when it would be available. Therefore, the customer decided to cancel the project.

The large company that was developing the project tried to convince the customer to give the project a second chance. The developing company promised to do everything differently this time. Somehow, this was so convincing that the customer agreed (mainly because the customer was also the co-owner of the company), but with strict regulations. Although almost everybody was happy about this decision, the developers still weren’t really motivated because they had just seen two years of work get tossed in the bin. But now, with this second attempt, the project became mission-critical for the development company.

Because several million dollars had been spent already, the customers were very suspicious of how this second attempt would fare. So they decided to not promise monetary support for the duration of the project, but instead they would discuss financial support every three months, depending on the project’s progress. When the project restarted, everybody assumed that after the first (successful) three months, the customer would commit to financing the rest of the project. Instead, the customer decided to stick to the probationary three-month period because of the previous development attempt. Making a decision about whether or not to continue financing the project was going to be based on the outcome of each release cycle. Luckily, the team kept on delivering a new functionality every three months. Seeing the system grow reestablished the customer’s confidence in the team.


Learn about contextual details and the history of the case study.

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

Context and Stakeholders

The project’s history