Skip to main content
Enterprise Agile Planning icon with arrows

This post is from the CollabNet VersionOne blog and has not been updated since the original publish date.

Last Updated Nov 05, 2009 — Enterprise Agile Planning expert

Five Myths of Agile Development: Myth #4 / Agile Does Not Scale

Enterprise Agile Planning
After yesterday's Myth #3 / Agile Development is Not Predictablelet's talk about Myth #4 / Agile Does Not Scale. Generally speaking, software development itself has scaling issues. There is plenty of evidence that would suggest this is clearly not a methodology/specific problem. The larger a project's scope, the greater the probability for failure; the greater the number of people involved in a project, the greater the communication risk and complexity. Agile development simply accepts these realities and recommends smaller projects, shorter delivery timeframes, and smaller teams. Smaller teams have been proven time and time again to be much more productive than large teams. This does not mean organizations should avoid solving large problems. Agile simply suggests that there is a different approach to solving the same problems. Agile methods promote taking large projects and breaking them down into a coordinated series of smaller projects staffed by smaller, cross/functional teams. The various teams' work is integrated at least every iteration in order to reduce risk and ensure functional and technical compatibility. There are clearly other processes that need to be instituted in order to facilitate communication, integration, architectural design and standards, and decision/making amongst the teams, but these challenges have been solved before by many organizations. Over the last decade, enough agile projects involving hundreds of people have been performed by multiple teams, in multiple locations, across multiple time zones to have a high degree of confidence in the ability of agile development to scale. In fact, if a company has a very large, complex problem to solve, there are many reasons to prefer the use of an agile process in order to rapidly expose risks, prove business value early, and to quickly institutionalize a highly disciplined approach to software development and testing. For more information on scaling agile, check out Jeff Sutherland's "How To Fail When You Scale" webcast. Tomorrow we'll conclude this series with Myth #5: Agile Development is Just Another Fad.
Read the other posts in this series:Myth #1 / Agile is UndisciplinedMyth #2 / Agile Teams Do Not PlanMyth #3 / Agile is Not PredictableMyth #5 / Agile is Just Another FadIf you'd like to download this entire blog series in document (PDF) format, get the Five Myths of Agile Development white paper.

More from the Blog

View more Government Cloud
Apr 12, 2022 Government Cloud receives FedRAMP Authorization through sponsorship from the United States Department of Veterans Affairs

Enterprise Agile Planning
Flagship Agility solutions can effectively scale agile deve ...
Read More
Nov 22, 2021

What are the qualities of highly effective agile teams?

Enterprise Agile Planning
A team is the core unit of productivity in an agile organization. Wher ...
Read More
Nov 15, 2021

How an open-first attitude revolutionized government tech development

Enterprise Agile Planning
Public perception of government is often that it is slow-moving, reluc ...
Read More
cross functional
Nov 08, 2021

6 best practices for building resilient cross-functional teams

Enterprise Agile Planning
Agile frameworks prize the quality of resilience within every facet of ...
Read More
Contact Us