Читать книгу Agile 2 - Adrian Lander - Страница 20

From the beginning, Agile ideas were expressed in terms of “the team,” implying that there is one team working on one product. A one-team product occurs frequently, but multiteam products are just as common, if not more so.

Could it be that Agile methods only work for a single team? Maybe Agile methods worked well, not because the methods were good but because they were commonly applied for the easy case: one team. We do not believe that, but it is a valid challenge.

There is also the case of multiple teams but a single monolithic product. In the early days of Agile, most software products were monolithic; that is, they consisted of a small number of very large bodies of code. A typical architecture was a web application, which consisted of a user interface web page, a web server, and an application server.

That kind of architecture could become pretty complex, and there were frameworks for breaking up the application into pieces on the server. The most well-known examples were the Enterprise JavaBean architecture and the web service architecture, and these patterns were often used together. Still, the number of runtime components was generally a handful at most.

Contrast that with today. A typical architecture at, say, a large bank, is that the company's digital platform will consist of tens or hundreds of products, each supported by hundreds of distinct microservices, and all these microservices interact in various ways in real time by sending messages or calling each other. There are often hundreds of development teams working on these many moving parts, which together constitute an integrated product ecosystem.

In his Forbes article “The End of Agile,” Kurt Cagle wrote this:

Scale problems only show up once you've built the system out almost completely and attempt to make it work under more extreme conditions…This becomes even more of an issue when developers have to integrate their efforts with other developers, especially for those components developed at the same time.2

The complexities of scale are what make the scale issue perhaps the most important technical issue today. It is also an issue that strongly overlaps with the issue of how leadership should scale: through a traditional hierarchy, through a network, through informal means, or in other ways.

Single-team startups generally had little trouble using Agile methods. Frankly, a startup is the easy case; it is “table stakes” for Agile. The hard case is making Agile work for a multiteam product, and an even harder problem is making it work in a multiproduct ecosystem.

Agile had no answers for these situations in the early days. Over time, various people tried to address the issue, by defining Agile scaling frameworks, but unlike the original Agile Manifesto, these attempts generally came from individuals and were used as brands to drive proprietary consultancies, so no consensus emerged on what to do.

Meanwhile, large consultancies embraced one or more of the branded scaling frameworks, having their staff obtain certifications in those and then marketing their staff as commodity experts (which seems to us like an oxymoron). This further entrenched the commercial nature of Agile and the approaches for “scaling” Agile. To say that the situation became unhealthy is an understatement.