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 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.
Transformation Is a Journey, Not a Rollout
The traditional approach that organizations use for any large change is to create a big plan. Such a plan has tasks and milestone dates. The theory is that if you perform the tasks and they are done on time, then you will have completed the initiative. You will have “rolled out” the change.
When senior executives meet with their staff about the change initiative, they review a chart showing the status of each task, indicating whether they are on time, and the spend rate. If something slips, it is shown in red. A red task invites questions from the executive. Lots of red tasks indicate that the initiative is not going well—something that is not good for the career of the person leading the initiative. One wants to have all tasks shown in green.
There are several problems with this approach. One is that it discourages honesty. No one wants to report tasks that are in the red, so the tendency is to cover up problems. Scott Ambler has referred to this as green shifting. Such a cover-up is rationalized by the idea that “it will all work out,” and so the progress of each individual task will not matter in the end, as long as the overall initiative succeeds. However, this means that problems are disguised, and so honest discussion—discussion that might help to ensure success—does not occur.
The ability to obtain people's honest beliefs and ideas is essential. You might think that things are fine, but they are not fine at all; and if people are not willing to be frank, they will not tell you what they think that you should be doing instead. As Jack Welch said in his book Winning,
“Lack of candor basically blocks smart ideas, fast action, and good people contributing all the stuff they've got.”7
Another problem is the assumption that the initiative is composed of tasks. If one is performing a largely repeatable process, such as building a new power plant using a design that has been used 50 times before, then one can indeed create a master task plan, and it
