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

#
##
If we want to make progress, we are probably suspicious of every bottleneck that might slow down the team. Sometimes, we might install a bottleneck intentionally—for example, having a single integration point is an intended bottleneck for avoiding conflicts. However, most of the time, we want to avoid bottlenecks no matter what the cause. 
### Bottlenecks in a large team
Here are the most frequent bottlenecks found in large teams.
#### Coupling
The architecture has to ensure that the subsystems are as loosely coupled as possible. Otherwise, a single change can require the compilation of the whole application because it is very likely that our application will be huge after a while; this can be very time consuming.

This problem can be solved by eliminating strong typing (either by an interpretative or just-in-time programming language like Smalltalk or by generic interfaces supported in Java). The disadvantage is that the type won’t be checked during compile time.

#### Enterprise-wide object model
Do not insist on an enterprise-wide object model. The value of an enterprise-wide object model is rarely worth the effort of creating it. The higher the effort of creating the enterprise-wide object model, the more we should question its value. It's probably so difficult because everybody (or every team) has a different view of the objects needed. Instead of forcing everybody to have the same view, it might be more helpful to support different views. The problem with an enterprise-wide or system-wide object model is that it creates a lot of general dependencies not only among the objects but also among all teams. Often, we will find that the model is highly coupled, probably with several cyclic dependencies in place. This usually leads to a general recompilation as soon as something in the model changes.

An enterprise-wide or system-wide data model is most often sufficient and often already available, as it is rare to work on the very first system for a company. A much more typical situation is one where a client company already has a system (or systems) in place and just needs another system (or a new version), which will operate on the already existing data model.

Learn about different technical and organizational bottlenecks in large teams

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

Avoid Bottlenecks