Scaling is always a difficult challenge; whether it is in manufacturing, in growing a small business, or in software development. For organizations that are trying to adopt the Agile software development methodology, successfully scaling presents some unique challenges. Often scaling too quickly leads to problems that people blame on Agile. In reality, the problems could have been avoided, or at least mitigated, if more upfront planning had been done. This chapter looks at what can happen when an organization scales its Agile teams without learning from the success stories of other Agile teams.

Real-Life Stories

Story 1: Learn from the Success of Others

I was once part of an Agile project team that had only been using Scrum for about eight months or so when we were asked to start on a project with a very aggressive timeline. We tried several different approaches in the first month of the project, eventually deciding to use Kanban. We chose Kanban because the project was moving so fast and we needed to work in a “just-in-time” fashion. The project was to rewrite an existing application that took about a year and a half to build. We were able to rewrite the application in six months and deliver it to Production with no major defects.

Our team became very popular in the organization. People wanted to know how we worked: they asked questions like “how are you doing automated testing?” and “how do you manage Work In Progress Limits?” It was a great feeling to be part of a successful Agile team. We were selected to work on a new project that would be one of the biggest ever for the organization. This is where it got interesting.

Management split our team into several new teams. Instead of keeping the processes and things that made the team so productive, these new managers chose to start from scratch. I think this was mostly a case of managers who were new to Agile and wanted to try their own ideas of how to manage Agile teams. But the main issue was that for this project, they spun up about 20 teams. The members of these teams were more or less new to Agile. In this case, there were no Agile Coaches (either from internal employees who had Agile experience or from outside the company) and the teams tended to have a lot of problems. There was very little consistency across teams and everyone had to relearn the same pain points. This led to all kinds of issues for the project, including poor-quality software and a lot of people becoming burned out due to a lack of understanding of velocities and mandated Sprint commitments (yes, mandated, but I will discuss that later, in Chapter 7).

Thoughts

The project described above was extraordinary in many ways, including the number of Scrum teams that were formed in a short amount of time. But even with that being the case, there were still things that could have been done to set the teams up for success and not failure.

For instance, this organization had used Scrum for about two years on several prior projects. Most of this experience was concentrated in just a few teams, some of which, by all accounts, had been pretty successful. We could have seeded some of the new teams with members from the seasoned teams. We could have hired Agile Coaches to assist these new teams for the first few months. Management could have inquired about what had made the experienced teams successful on their past projects—which is important because these teams knew how to use Agile within their organization—and passed the information on. That is key because what works in one organization does not necessarily work in another.

Story 2: Share Knowledge Across Teams

I was fortunate to be a technical lead of a highly productive Scrum team on another large project with more than a dozen teams. We made great use of the Retrospective meeting at the end of the two-week Sprint. We used it to try new things to address pain points and were constantly improving. The team was not afraid to try a lot of new things (everything from how we wrote acceptance criteria in User Stories to the way developers collaborated with the Business Analyst and Quality Assurance engineer).

But an interesting thing happened when managers tried to get other teams to adopt some of our processes. These other Scrum teams were very resistant to change and there was a lot of pushback. Ultimately, the managers did not push the issue. The unfortunate part is that these other Scrum teams might have learned better ways to do things, but that sharing never happened.

Thoughts

I’m not saying that what works for one team will necessarily work for another team. But when something is proven to work really well for one team, why not try to spread it to other teams? Maybe other teams will try something new and in the Retrospective they decide that the change didn’t work. They can always revert back to the way they were working before. This seems like a very natural way for an Agile team to operate. I see Agile teams as incubators, and when one team finds a better way to do something that leads to better-quality software, better collaboration, and improved velocity, then why not try to spread that knowledge to other teams.