Adrian Lander - Agile 2

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.

The Industrial Revolution brought about large companies that built really big things—things that required machines. Carnegie Steel, Rockefeller's Standard Oil, Thomas Edison, Henry Ford—big companies were synonymous with the individuals who founded them.

Then during the 1960s, as the business landscape came to be dominated by publicly traded companies without individual owners or prominent founders, modern management thinking came to see a company as a collection of distinct interacting functions. Senior management was seen as existing to increase the value of the company, in a financial sense—something logically distinct from the company's actual business. Managers became financial overseers, and involvement with actual products and markets became the province of corporate vice presidents, who often saw themselves as financial overseers of a market rather than visionaries of products.

The Internet age was like the Industrial Revolution in that it represented a pioneer period in a new landscape: the global network of the Internet. Just like the Industrial Revolution, huge companies grew, identified with their founders: Apple and Steve Jobs and Steve Wozniac; Google and Sergey Brin and Larry Page; Amazon and Jeff Bezos; Netflix and Reed Hastings.

But was this return to owner-dominated giant companies only due to the Internet? What about SpaceX, which was founded by Elon Musk? SpaceX has become a huge company, outdoing the likes of Boeing in the production of spacecraft, yet it was a tiny startup 10 years ago, and it had nothing to do with the Internet, although that is changing since they have undertaken to launch a network of Internet satellites. But the company's growth was based on its approach to building rockets—it was not due to the opportunities presented by the new Internet landscape.

What is noteworthy about these new companies is that their founders are deeply technical. In each case, the founder understood, or learned, the technology used to deliver the product or service. Steve Jobs and Steve Wozniac were both home computer builders. Sergey Brin and Larry Page were both research scientists from Stanford. Jeff Bezos had degrees in electrical engineering and computer science from Princeton.

Elon Musk is an interesting case. He did not know much about rockets when he founded SpaceX, so he hired Tom Mueller, a rocket engineer. But Musk did not do what a modern management executive would do, which would be to concentrate on the business and delegate the product development to a VP. Instead, Musk said, “Teach me about rockets.” Musk continued to drive the development of SpaceX's rockets, deferring to experts but always staying involved in the decisions—just as Steve Jobs personally approved of any product that Apple launched, and Jeff Bezos personally directed the development and technical parameters of Amazon Web Services. 3

This personal involvement in the organization's products and services seems to be a common characteristic of managers of the most highly successful technology companies today. The view of these executives seems to be that the product delivery technology is not just a supporting function, subordinate to the company's strategy. Instead, it is part of the company's strategy.

How the company delivers is as important as what it delivers.

The value proposition of SpaceX is that it can launch satellites for less cost, and with higher frequency, than its competitors—substantially so. That is true only because of the way that it builds its rockets.

The value proposition of Amazon is that it can deliver products cheaper and faster than alternatives. That is true because of the way that its technology platform works. And Amazon can also update its platform rapidly and test market-facing features—and that is true only because of the way that it builds and delivers software to its online systems.

The way —the how —is not secondary. It is strategic. It is as important a differentiator as the product itself.

This means that today's executive cannot say, “That's a tech thing—my CTO deals with that.” Today's executives need to understand how things are built, how they are delivered, how they work, and how they can go wrong. Elon Musk knows how rockets can fail because a failure can ruin the company's reputation. One of his main preoccupations is ensuring reliability. He achieves that by influencing how SpaceX builds the rockets. It uses what he calls a hardware-rich approach, whereby they don't try to perfect a design but instead perform early testing and iterate, constantly measuring and refining, until a design has proven itself to be robust and reliable. 4