I am considering using Scrum on a very large (40+ developers) multi year project for a major bank.

I am trying to figure out if Agile is feasible for a project this size. There are thousands of requirements, and the team is distributed (between NY, London, and Mumbai. I am in NY.)

I have succesfully managed several medium sized Scrum projects in the past. They were hard due to the number of back-logged requirements. Therefore I am concerned that a project of this magnitude with so many more requirements will be too ponderous to be feasible.

Can anyone weigh in on how to make this realistic, and perhaps to point to any books on the topic?

One other consideration - if you know of some flavor of Agile that is more appropriate for such a project, please let me know.

  • The FBI implemented their Sentinel system a couple of months ago. Team of 55, $110m budget, and 13,000 FBI agents are now tracking 600 crime and terrorism suspects as you read this. A big, hairy project if there ever was one. Once you have my blog article you will not even consider using a waterfall approach. The complete case study is here Oct 11, 2012 at 19:24

4 Answers 4


There is never one definitive answer about whether particular agile techniques like scrum are appropriate in a given environment; the key is to tailor the methods to suit the environment, the client and the project.

For any methodology to work, you need to have the buy-in and support of the executive (i.e. the business interests), the users (those who will be making use of the products of the project) , and the suppliers (e.g. the developers). So the first step to deciding if an agile methodology is feasible is making sure that the important stakeholders understand what agile project management methodologies entail, and that they are willing to participate in it.

Many of the off-the-shelf tools from scrum won't work well with such a large team; for example, you don't want to have a stand-up meeting with 40 people every day (and given they aren't all in the same place, the timing probably wouldn't work anyway). For such a large project, you should aim to divide people up into smaller, more manageable teams (maybe 10 developers at most), and appoint separate scrum masters (or team leaders). For scrum, this would work the best if you can meaningfully divide the project up into a programme of projects, and give each team a different project (whether this is possible will depend on the exact nature of the project, and would be complicated if there are too many different functional roles). The Scrum of Scrums method can then be used - a representative from each scrum meets to share information between what the different scrums are doing.

There are reports of very big projects using tailored versions of Scrum with distributed teams and working out very well - for example see this paper, in which a team of 50 developers over three countries used a modified Scrum methodology to achieve higher productivity; they call their model Integrated Scrums, where you have multiple scrums, but the scrums are cross-functional and incorporate team members from multiple sites. All members in each scrum meet daily with the other members in the same scrum using tele/videoconferencing, and a representative from each scrum based at the central site meets in person with the other representatives to coordinate the entire project.

If you have difficulty getting the organisation to accept this type of methodology (it can't be forced on an unwilling organisation), I would suggest trying to focus on the most important aspects. According to this survey based study, the strongest factor in agile project success is the agile delivery strategy (i.e. delivering products early and getting organisational input, rather than trying a big bang deployment), then agile software development processes (e.g. look to eXtreme Programming), then team capability, and only then project management processes.


Truly Agile Projects Evolve (or, When to Use Scrum)

Agile projects work best when you are working on a project that is iterative, and where the overall project is structured to deliver continuous value as it evolves over time. If you have already done all the work to plan out a waterfall-style work breakdown structure that can't be broken up into iterations, or that won't deliver any stakeholder value until the entire book of work is completed in its entirety, then Scrum is probably not the right choice for the project as a whole.

If your multi-year project doesn't have a giant "integration death march" at the end, and has sub-projects that are a good fit for iterative development and continuous integration, then Scrum may be a good fit for those parts of the project.

Deciding between Scrum (or any agile methodology) and more traditional frameworks based on up-front planning is not an all-or-nothing choice. You can mix and match, if it seems like a sensible thing to do.

Optimum Team Size for Scrum

According to Jeff Sutherland, Scrum teams should not have more than seven people. That doesn't mean you can't use Scrum on your project; it really just means that to use Scrum effectively you would need to break up your overall project up into sub-projects as described above, and then form cross-functional teams for each of those sub-projects.

If you choose to do that, then you will also need to integrate and coordinate your Scrum teams using a "Scrum of Scrums." Even in more traditional methodologies, you need to track dependencies and hand-offs, so this is really no different in that regard.


I would not recommend attempting to introduce Scrum to a 40-man team in one go. More than anything else, Scrum requires time and effort on the scrum master/coach's part to educate the team about how to be Agile, and you won't have the overhead to do it.

However if you have some existing methodology it can be useful to keep everyone following that, but take 7-9 people and form a Scrum unit for some aspect of the project. Once that team is performing optimally you can then look at splitting it in two, adding more members and forming two teams, let them run on scrum for a while, then split again.

That way you get a gradual ramp up of Scrum acceptance

  • 1
    But the master requirements backlog still needs to be maintained. Isn't that prohibitive even with your proposed structure? Oct 7, 2012 at 16:57

Scrum works best with a small team but proportional team of engineers, testers, etc. But this is my experience with scrum teams. In your case I would suggest to do following, if feasible

  • Breakdown the projects into sub-projects or define sets of tasks
  • Identify your team skills across the glob
  • Make smaller groups (6-10), which is considered ideal for development
  • Make scrum dashboard available for each team (e.g. JIRA, tinypm ) to monitor each team daily progress in scrum way

Off-course, it all depends on nature of project etc. In any case, scrum is recommended way of development when you break-down the project into pieces.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.