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

The referential implementation finished on time (it took three months). This was a big success because, for the first time, the team actually delivered. The result after these three months was bigger than after the two years of the first try. Of course, this great success was celebrated with a big party.


To reflect on the achievements of the first three months, the starting team went off-site for a closed meeting. During this reflection, this team decided it would need another three months to clean up the architecture. However, the members of the project team who were not part of the starting team were waiting to start. For financial reasons (having 100 people sitting unproductively around costs a lot) the project manager was forced to immediately start expanding the team, and take the rest on board. Although the expansion of the team was mainly financially motivated, this decision was also very important for the motivation of the rest of the team. Everybody wanted to be part of this successful team and, moreover, everybody wanted to forget their experiences on the failed project, which was the only project experience for most of the team members.

# Scaling the process 
Now that this project had started so successfully, the project manager did not want to risk anything and therefore took great care to create and establish a development process that served the needs of the team. From the starting team, we had the experience of a development process, which we knew worked for a small team. So we carefully started scaling this process while growing the team.


# Discovering the (hidden) process
However, the starting team claimed at first that they did not follow any particular process at all. Whenever a successful team says this, we can be assured that it is using a process that is serving them perfectly. The process is serving the team so well that it does not experience the process as an extra task. Instead, it just uses it naturally. Therefore, the team members just do whatever helps them, and omit whatever hinders them. However, they never think that these decisions are process-related; to them, these decisions are just come naturally. It is still a real challenge to pick up such a (hidden) process and transfer it from a 15-person team to a team of more than a hundred people. 

# Learning from previous problems

To scale the process, the first thing was to interview randomly picked members of the project team. The main questions in the interviews, which were always one-on-one, focused mainly on the lessons learned in the first try. This ensured that the lessons learned from the interviews covered both the things that went well and the things that should have been improved. Interestingly, people were really astonished as soon as they realized that although the first try was regarded as a failure, there were still things that went really well. Realizing these good things helped the team members to shake off their lethargy and to feel new energy. They realized that their efforts were not so bad in the first try after all. #key# Norm Kerth: Famous software consultant and author, known as the father of retrospectives and author of the seminal book, "Project Retrospectives: A Handbook for Team Reviews." #key# describes the same experience in "Project Retrospectives," when talking about a postmortem:

> Before the postmortem, no one had realized that significant gains had occurred in the department alongside the failures.

## The cultivation of a fault line between the technical and the domain teams
However, as is often the case, much more information was received about the things that went wrong and the things team members worried would happen again. The risk named the most often was the cultivation of a fault line between the technical and the domain teams. Although a lot of blaming was done with almost all the teams, it turned out that the relationship between technical and business people was especially bad. Each side felt misunderstood by the other. When expanding the team, this problem popped up again. For example, the domain teams blamed the technical teams for not being able to rely on the architecture, saying that they couldn’t rely on it as long as it was still under development. On the other hand, the idea was to allow the architecture to evolve according to the needs of the business domain teams. But, instead of taking their chances, the domain people thought that an evolving architecture would only have a negative impact on them. Moreover, they feared that they would not be able to deliver on time because of the evolving architecture. We did not succeed in selling the new purpose of the technical teams, which was to serve the domain teams. Basically, the domain teams did not trust this new model.

## A method to handle the issue
Therefore, we used a trick: we announced that the architecture was finished (regardless of whatever state it was in at the time) and that the business domain teams could use it as is. We promised that the architecture would not undergo any further changes. As a result, the business domain teams started immediately to develop.

It did not take too long before the first business domain team came up with the first change request for the architecture. We established the following process: all the business domain teams discussed whether they would all profit from this change. Whenever the majority thought they would benefit, they asked the technical teams to incorporate it. So, finally, the business domain teams accepted the service the technical teams provided them with, and, more importantly, they accepted that the architecture was not stable, but evolving. Having installed this process, every team (including the technical teams) was allowed to ask for a change. This way, the technical teams also learned to reason through internal improvements transparently to their customers.


Learn about author's experience in growing the team and project based on initial referential implementation in the case study project.

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

Growing the Team: Learning from Previous Problems