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

> An independent architect\
  shouldn’t be guided by sensations   
  but by reflections.\
-- Hans Scharoun

#key# M. E. Conway: Famous computer scientist and hacker who developed coroutines, UNCOL language, and worked on Pascal compiler. Formulated Conway's law in his paper: "How do committees invent?" Datamation, 14, 4, pp. 28-31, April, 1968, p.28  #key# formulated a law in 1968 in an article he wrote for _Datamation_, now widely known as Conway’s law, which says:
> Organizations that design systems are constrained to produce systems which are copies of the communication structures of these organizations. 

This law has even been taken further by several unknown authors, who expressed their experiences by saying:
* The architecture of a system is a copy of the architecture of the organization.
* The structure of a system is determined by the structure of the team.
* To understand the team, look at the software it is producing. If it is slow and bloated, the team is slow and bloated. If it is lean and quick, the team is lean and quick.

All these experiences express the different (nontechnical) influences on architecture. However, there is still one more major influence, best expressed by Nicolai Josuttis in the context of his experience as the chief architect of a large mission-critical project:
> The size of a project, or rather of a team, influences the architecture.

The term “architecture” sounds very solid, which might contradict the intention of an agile process, and talking about an architectural lead in this context might further stress this impression. However, it is not important to be up-to-date. It is important to find the right means (established or otherwise) to create a flexible system that allows change even late in the project. Achieving this flexibility is mainly based on trust in the project members, combined with the important responsibility of the architectural lead.

# Responsibilities of an architectural lead

On a typical agile project with a small team, we will often end up without an architectural lead because the whole team is of equal value and takes the same responsibility for the whole project. Although this could, or should, also be a goal for a large team, it would never work because the development would otherwise be uncoordinated and diverge.

Learn about the role of architecture and the architectural lead in an agile process.

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

Architect and Architecture