Agile 101: Larger Teams

Tom Mochal, PgMP, PMP, TSPM is the president of TenStep, Inc., a methodology development, consulting and training company. Tom won the Distinguished Contribution Award from the Project Management Institute for his work spreading knowledge of project management around the world. He is a speaker, lecturer, instructor and consultant to companies and organizations around the world.

  Agile   Communications Management   ProjectsAtWork  

Agile says less is almost always better — less documentation, less process, less intrusion from management. So how can a “less is more” approach be applied to complex projects with larger teams? By creating sub-teams that still work independently, but do much more of one thing: collaboration.

When the Agile movement gained steam in the early 2000s, the conventional wisdom was that Agile worked on smaller projects but did not scale well for larger ones. This seemed to make sense because as projects grow larger and team size increases, it is logical to think that the team needs more — more coordination, more structure, more documentation. This logic made it appear that running large projects using the pure Agile approach would not work well.

It is true that running a 50-person Agile project will not work if you use the same processes that you use for a 10-person project. But you know what? This observation is true for all projects. As projects get larger, it is important to change your approach to be able to deal with the complexities. This applies to traditional or Agile projects.

For an Agile project, the first and primary technique is to break the large project into a number of smaller Agile teams. For example, a 50-person Agile project team may be too complex to manage. (Any 50-person team would be complex to manage.) But what if the 50-person Agile team can…

Please log in or sign up below to read the rest of the article.