12Agile 2 at Scale
When people say that Agile must work “at scale,” what they mean is that it must work when applying it for many teams at once, to build or achieve “big things.”
There is an argument that scale should not be needed: that one should always decompose any large endeavor into small independent endeavors—so-called independent autonomous teams—so that single-team methods can be used. However, as we have seen, it is difficult or impossible to achieve full team autonomy for complex products, even though autonomy and independent teams are powerful constructs and a worthwhile goal.
What about the product? Can it be separated into enough separate and completely independent subproducts so that each team can operate autonomously?
If you do that, then you do not have a product anymore. You have many small products. Imagine going to your bank's website and logging in to perform a function; but then when you want to perform a different function on the same website, you have to log in again to that function. No one would like that.
Or imagine the situation that Spotify had, where it had one set of teams for its mobile app and another set for its web app, and the two apps looked and behaved totally differently. That inconsistency was a contributor to why Spotify created its famous “Spotify model”1—to harmonize the work spanning the many different teams. From its website,
“In the early days of Spotify, there was no design system—we were building everything for the first time. ...
Get Agile 2 now with the O’Reilly learning platform.
O’Reilly members experience books, live events, courses curated by job role, and more from O’Reilly and nearly 200 top publishers.
