Agile 2. Adrian Lander
Читать онлайн книгу.
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
Again, the how matters—strategically.
Does this mean that one person needs to know how everything works and everyone's job function?
No, no one can know all that. But the person in charge of an area needs to know what they need to know—which things are important and which are not. To make that determination, they must have a vision for how everything works at a high level, and what can go wrong, so that they can zero in on those areas and make sure that the important issues are being decided the right way—and if they are not, to intervene and drive good decisions, either through spearheading discussions or setting guardrails.
Most of all, a leader cannot afford to say, “That is technical—I don't need to know about how the technical stuff is done.” That won't work for a company whose business takes place on a technology platform.
What about everyone else? The CEO is not the only decision-maker in an organization. Yes, everyone else matters too. It is no longer the case that someone needs to know “only their job” the way that an assembly line worker at a Ford plant only needed to know how to attach a certain part. Today's organizations work in a more collaborative manner, so you need to understand what others do as well, to be able to participate in discussions with them and understand their needs and how your needs and their needs can be harmonized. Understanding the full range of activities (everyone else's jobs) also enables you to see opportunities for holistic improvement—approaches that make things better overall, instead of locally optimal.
It does not mean that everyone needs to be an expert in everything. That is not even possible. Instead, it means that everyone needs to take an interest in the entire value stream—the end-to-end sequence of activities that deliver value to customers or users. Learn as much as you can, instead of ignoring other job functions as “not your job.”
By now you probably see a connection to Agile: we are advocating collaboration across job functions. One of the Agile Manifesto principles reads, “Business people and developers must work together daily throughout the project.” The Agile Manifesto delineates between the business and the development teams.
There is actually nothing wrong with that statement. There are “businesspeople” and there are “developers” in most organizations, and they are separate job functions. However, the Agile community—as it has done with all of the manifesto—interprets it in the most extreme way. The business has been seen as something that feeds requirements—in the form of user stories—to development teams, usually via a backlog of work.
Thus, the business has been cast by Agile as apart from the developers—a dichotomy that is antithetical to the approach used by Elon Musk and Steve Jobs and Jeff Bezos and all the successful tech executives of our day, who know that there is no real separation between technology and business—that a successful product vision needs to be highly informed about the product, not just its features, but also how the product is built and delivered.
Tech Cannot Be an “Order Taker”
Agile treats a development team as a taker of orders: build this, and build that. That is the reality. In most Agile environments, the business and the developers are not partners. If products were like pizzas, where each is the same as the others before it, this order-taking approach would work, but when one designs and builds a new product, it is unique, and so a lot of creativity is needed. It is not mere execution. It requires inspiration and creativity. Taking orders does not inspire.
There is also an implicit assumption that innovation comes from the business, in the form of a product vision. That is how it is usually described. The developers are supposed to implement the work elements—the stories—to achieve the business's vision.
There is no mention of a vision coming from the technical side—the developers. In fact, the process of Scrum often—usually we would say—is a relentless mill of implementing one story after another. Many in the Agile community feel that Agile is often contorted into a kind of treadmill whereby teams are driven with the pressure of their sprint commitments, and the pressure never lets up, because they run from one sprint to the next, forever. Not only do many programmers feel that way, but one of us was told by an architect that she has observed that “Agile burns people out.” Agile promotes a “sustainable pace” of work, but in many organizations it is a relentless pace, without peaks and lows.
One of us met an Agile coach who has worked in Silicon Valley since the 1990s. She said that the original sprints were followed by a period of rest. The choice of the word sprint was deliberate to describe a race to a finish line. Originally, there was never any intention of running race after race.
Developers have the weekend off—usually—but at work, the backlog is endless. It is a modern-day assembly line. There is no time for innovation or creativity among the programmers.
The pressure takes a toll as well. In 1908 psychologists Robert Yerkes and John Dodson documented the Yerkes-Dodson law, which showed that slight psychological pressure helps to drive performance but that increasing the pressure further decreases performance. In other words, relentless pressure on people does not make them deliver more or better work; it decreases their performance.5 Psychological studies have also shown that pressure, or in fact anxiety of any kind, disrupts decision-making.6
Agile coaches will say that teams that are in that situation are not run properly, that the business—the Product Owner if they are using Scrum—needs to allow for periods in which programmers can experiment. That is a hard sell, though. Product Owners usually have little understanding of the technical work, so asking them to let the technical team experiment when they could be working on features that the Product Owner wants is like saying “Let them play around—your business features can wait.”
The core problem is that Agile—in practice—is set up so that the business and the developers are not partners. The developers take orders from the business. That makes it unlikely that the developers will ever be able to offer an innovative approach.
But could developers have innovative ideas? If the ideas are technical, surely. Some of the most successful technology products—perhaps most truly game-changing technology products—were the inspiration of technical individuals. Examples include Linux, Skype, Napster, the first Apple computer, Microsoft's first operating system, Google, Amazon—these are but a few of a long list, and they changed or created new industries. A pure businessperson could not have thought of these things.
But what about in an established company, with a mature product? Will the developers think of innovative ideas pertaining to the product? Yes, if they are familiar with how the product is being used. That means that either they need to use the product themselves (programmers call that “eating their own dog food”) or they