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

# Taylor’s centralized knowledge teams
A development team is not usually organized like a team in the strictest sense of the word (assembled by peers with equal rights), but is more like a hierarchy. The typical hierarchy in a development team, which can be found mainly in traditionally led projects, follows #key# Taylor's theory: Taylorism is characterized by the division of labor, repetitive operations, extreme labor discipline, and the supervision of work. #key# about centralizing a team's knowledge. The individual team members take up specific roles and corresponding tasks. Analysts, designers, developers, and testers often work independently of one another in a linear process.

Due to this separation of tasks and roles, a hierarchy is created. Although this hierarchy might not officially exist, it is formed by the different roles in the team, some of which have greater prestige or importance (acceptance level) than others. Often, the acceptance level is defined by linear development. This means that analysts have the highest acceptance level, whereas coders, testers, and, even worse, maintainers, are at the end of the acceptance level chain, doing all the "dirty" work. This sequence of acceptance levels is just one example, but is an oft-encountered one.

However, the major problem is that nobody wants to be at the lower end of this acceptance-level chain. Therefore, everybody tries to climb up the ladder from maintainer to designer or, even better, to analyst. Or, if we look at it from another perspective, we'll find the largest percentage of novices in maintenance or implementation. Consequently, there are often too few experienced coders on a team.


Learn how agile teams differ from Taylor's centralized team in terms of respect to each team member and acceptance of every point of view.

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

People: Respect and Acceptance

Taylor’s centralized knowledge teams