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

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.⁵ Psychological studies have also shown that pressure, or in fact anxiety of any kind, disrupts decision-making.⁶

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 need to talk to actual users. If they talk to actual users, they obtain an immensely better understanding of the product and how it needs to work. They become as insightful as the Product Owner, and they start to have their own innovative ideas—sometimes really fantastic ideas.

All too often Agile teams are not allowed to talk to actual users. They only talk to the Product Owner. The Agile Manifesto mentions the customer and the user, but not in the context of collaboration, and the reality of Agile development today is that development teams tend to operate apart from actual customers and real users.

This is a great dysfunction. Not only does it squander the creative ability of the technical side of the organization and convert them into an under-appreciated serfdom serving business stakeholders, but it isolates product marketing research and product vision into silos that the people creating the product have no view of—almost ensuring that the product will be suboptimal for its users.