It’s show time. Brian, the product owner of the Irresistible Snacks team, can’t quite contain his excitement—though he notices, to his annoyance, that the excitement is tempered by periodic waves of anxiety. Engineers don’t get anxious, he reminds himself. “The data is what it is. You just have to deal with it. This is just another project.”
Sure it is. Brian’s team is six weeks into its new-product development program. Today is its third sprint review, and team members will be asking twenty real-life customers to unwrap and sample the seven leading prototypes for the proposed new line of “healthy, indulgent” snack bars. Irresistible’s executive committee will be out in full force to observe the session. Brian winces, remembering that several executive committee members openly opposed this new agile process from the beginning. Today is make or break. Maybe it shouldn’t be, but it is.
Brian is a foodie by avocation and a food-development engineer by trade. But until recently he had always worked for small companies. Only two years ago, he was heading up new-product development for AlwaysAuthentic Nutrition, a rapidly growing young company that was beginning to reshape the snack shelves in supermarkets and convenience stores. An ideal job, he felt. On good days he could even bike to work from the Cleveland suburb where he lived.
But then came the news. Irresistible Snacks—a large processed-foods company that was part of an even bigger consumer-goods corporation—was acquiring AlwaysAuthentic. It was a generous offer. The smaller firm’s owners made out like bandits, and a little of that large sum trickled out to the employees. But the acquisition brought layoffs, plant closures, and sad departures. What would come next? Brian had no false modesty about his reputation—he was known and respected throughout the industry—and he knew he could get a job pretty much anywhere. But where? And doing what? That was when one of Irresistible’s top food engineers approached him. “You guys are fast on your feet,” the engineer said to Brian. “You can teach us. We want to learn to innovate like a disruptive start-up. Join us. We need you.”
It was a seductive idea, even for a small-company guy like Brian. Move up to the majors. Try out your skills on the big stage. The offer itself turned his head. The salary and benefits came to more than he had ever earned. There was the prospect of a bonus that would finally let him sock away some serious money.
So he had taken the plunge. And of course the job wasn’t anything like what he expected. Budgets at Irresistible were tight. The company’s procedures made it impossible to do anything without half a dozen signoffs, signoffs that required weeks to get. For a year and a half he felt as if he was perpetually running his head smack into the proverbial brick wall. Irresistible wanted to learn from the acquisition? Ha. More like they wanted to catch and kill a competitor, eliminating a threat to their old-school bureaucratic approach. After eighteen months of frustration, Brian was on the verge of quitting.
But then Irresistible’s CEO, Lori, called Brian into her spacious corner office. Lori was blunt and to the point. “We’ve been losing market share for three years,” she said. “This can’t continue.”
Brian was taken aback. For one thing, Lori was younger than he expected. He had seen her before, but only from a distance, and up close you could see that she was scarcely over forty. Quite a difference from the old guys who occupied the other executive suites. She was even younger than Brian, who at forty-nine was beginning to feel like a graybeard.
Nor did Lori mince words. “Our market research group has identified an opportunity in what we might call healthy but indulgent nutrition bars. Our product development group is telling me it will take at least twenty-four months to work up such a radical departure from our current products. Frankly, I don’t think they really want it to succeed. They fear it will cannibalize our profitable lines of candy bars.”
Lori leaned forward and looked straight at Brian. “I hear that you have a different attitude and a different way of doing things. I would like you to lead the development team for this new product line. What do you think?”
Wow. The scuttlebutt about Lori had been right: she was direct to the point of bluntness. He remembered hearing that her appointment had come as a surprise. She was a dynamite marketer, everybody agreed, but apparently some of the folks in Irresistible’s C-suite had bridled at the board’s decision to make her CEO.
Brian hesitated. Are you kidding? he thought. Aloud, he said, “I’m not sure I’m the right guy. Your organization has pretty much chewed me up and spit me out. But thanks for thinking of me.” If she was going to be direct, he would be, too.
Lori laughed. “I expected that. I’ve heard you’re getting a little fed up with this company. That’s the problem right there.” She came around the desk and sat down in the chair beside him. “Please, don’t tell me no. Tell me what you need to succeed. If I can’t give it to you, we’ll shake hands and part ways on friendly terms.”
Brian took a long evening to mull it over. He talked with his wife. He called a guy who had mentored him in the early years. The consensus was clear: What did he have to lose? Might as well give it a shot.
Three days later he was back in Lori’s office, bustling with the kind of energy that had built his reputation in the business. “We’ll need a multidisciplinary team. I’m proposing the following people: Danielle from product development, Jordan from packaging, Ellie from sales, Alyssa from marketing, Brianne from consumer insights, David from manufacturing, Gavin from supply chain, and Leah, who has experience coaching agile teams. I want 100 percent of all of them—no part timers. We’ll need a space with lots of white boards where we can all work together face to face.”
Brian looked at Lori to get her reaction. She nodded for him to go ahead.
“We’ll need direct access to some innovative retail chains and also to potential consumers. The annual budgeting cycle just closed and we have no budget, so we’ll need your help with funding. We can’t waste time waiting in the back of the long line for help with safety, regulatory, legal, or IT assistance. If we can run this program like we used to run AlwaysAuthentic, we can release the best product on the market to select retail customers in six months rather than eighteen, with a full-scale rollout within twelve months instead of twenty-four. The clock will start as soon as the team is in place and we are ready to begin.”
Lori looked a little surprised by the length and specificity of Brian’s requests. “You sure there’s nothing else?” she asked, allowing a small smile to cross her face.
Brian chuckled. “Just two more things. We need the executive committee to be involved. We’ll welcome their ideas but not their traditional micromanagement methods. We get to decide what to do with their suggestions. And I don’t want to sound disrespectful, but this will be especially important for the control freaks like Stacy, Kelly, and Eric to understand. If they start giving orders to their subordinates on our team, it won’t work.
“And, finally”—might as well go for it all—“my real goal is to get every product development team, maybe every innovation team, to see the value of this approach and adopt it for themselves.” He took a breath. “One or two product successes won’t be enough to create the change we need. We don’t just need a couple of agile teams, we need an agile enterprise.”
For the first time, Lori balked. “Whoa,” she said. “I agree we need some new products. I’m not sure we need a whole new system. Let’s see how this project goes and then we can talk about where to go from there.”
Brian realized he’d gotten a little carried away. “Fair enough,” he said. “That’s actually consistent with agile principles. But I’m going to take notes and share my observations with you along the way. The problem with this first pilot is that I know we can make it succeed. We can use your clout to bulldoze our way through almost anything, and we can create workarounds to systemic obstacles. I’ve seen this kind of coddling increase the odds of a team’s success before. The problem is that it doesn’t produce the learning environment or organizational changes necessary to scale dozens or hundreds of teams. Testing agile teams, just like testing any prototype, should reflect diverse, realistic conditions. We have to expose and fix the experiences that are causing the greatest frustrations with our current system. Will you at least promise to listen with an open mind?”
Lori found it easy to agree—what Brian was asking for was somewhere in the future, and anyway it all would depend on the results of the first team. What she was doing here was risky enough, but at least it was limited in time and scope. She would have to see what the future held.
“It’s a deal,” she said, and they shook hands.
Once outside Lori’s office, Brian pulled out his notebook and turned to a blank page. He gave it a title and added a single bullet:
SCALING AGILE
The first three months were painful. Lori had to use all of her CEO authority to free up the right people. In the past, starting a new project was relatively easy. If you needed nine full-time equivalents, you’d put together a team with maybe four readily available people half time, ten with 25 percent allocations, and forty or fifty with 10 percent assignments. Functional leaders rarely objected—they didn’t have to give up anyone, and having a representative on the project team would give them visibility into the effort. But this was crazy! Pulling nine good people full time out of their current operating roles? That was outrageous, and it wasn’t going to happen without a fight. “How about taking Darrell instead? He has lots of time.” “David doesn’t want to do this agile stuff. He’s afraid it will hurt his career.” “Couldn’t you do with 25 percent of Danielle? That’s the way we’ve always done it. She’s deep into that other key project and we don’t have anyone to backfill for her. It will absolutely kill us to pull her off.”
But Lori was firm, and pretty soon Brian had everyone he had asked for.
Brian wasn’t demanding organizational superstars. He realized that if the team couldn’t work with typical people, agile would never scale to dozens or hundreds of teams. But he refused to start until the team was properly established and fully committed. Along the way, he opened his notebook and started a new page with two bullets:
STRUCTURE AND PEOPLE
Once the team was in place, Brian wasted no time jumping into the work. Team members spent three days together. They learned agile mindsets and methods. They created a vision for their program. They reviewed the consumer insights work. They developed, prioritized, and sequenced a backlog of customer (retailer) and consumer (shopper) needs to address. They also decided that they would run in two-week sprints. This meant that every two weeks, they would deliver a working version of some element of their program—a nutrition bar, a new wrapper, a manufacturing process, a marketing program, sales materials, shelf displays, or any other element of the end-to-end buying and using experience. For the first sprint, they would build two versions of a new nutrition bar.
Danielle from product development took the lead. She reached out to a chef who showed interest in the project, though he was working on four other projects and had limited time. Brian opened his notebook to the “Structure and People” heading and added a sub-bullet under “Talent gaps.”
STRUCTURE AND PEOPLE
Alyssa from marketing wanted to create an online community of two hundred consumers to get rapid feedback on prototypes. The IT department told her they couldn’t get to it for at least nine months. Brian created a new page called “Processes and Technology” where he added two bullets:
PROCESSES AND TECHNOLOGY
He didn’t like going outside for help, but he immediately contracted with a third-party provider to create the online community platform.
Next, Irresistible’s food safety department said that nobody would be allowed to taste any prototypes until the full range of standard tests had been completed, which would take at least ten weeks. Brian couldn’t understand that. The tests they were requiring went way beyond what federal regulators demanded for this type of product. Erin, the food safety manager, described some of the problems they had encountered in the past and explained why they had gone to one standardized system for all new products. Brian described how AlwaysAuthentic had developed four different testing and approval processes, customized to the amount of change required to existing products. In this case, he pointed out, they were not introducing any new ingredients, and there were no risky ingredients such as eggs that could carry salmonella. Erin said she would run that idea up the chain of command, but she wasn’t optimistic that the higher-ups would change their minds. In the meantime, Brian proposed a couple of workarounds. “Could you please try to fast-track the approval process, and could we test samples with our team members and internal employees who sign consent forms?” Food safety checked with legal and agreed it would be OK.
Brian pulled out his notebook, turned to his “Processes and Technology” page, and entered another bullet:
PROCESSES AND TECHNOLOGY
The team worked far too hard. But after two weeks, the members had their prototypes and were thrilled to present them. Sadly, CEO Lori and Kelly, the head of research and development, were the only people from the ten-member executive committee to show up for the review. Over the years, excomm members had learned that the first few reviews of any task force would only present future work plans, so they were a complete waste of time. They were wrong about this one. The team had prototypes to sample, based on inputs from the online consumer community. Lori tasted them, looked at the nutrition label mockup, and smiled broadly. “We never see new product prototypes in less than three months, and they often take six. You have done it in two weeks. They’re certainly not perfect. The shapes are a little weird, and they are overbaked, but I can see where you’re going.” She paused. “And I like it.”
The team was fired up, but Brian knew this was just the beginning. Members got together to review the first sprint and to consider changes in the backlog sequencing. They felt they needed more prototyping capacity. The consumer community had suggested five flavors that might be better than the two the team first chose. Producing that level of variety with enough volume for consumer sampling would require more than a test kitchen. They would soon need a pilot manufacturing line. David from manufacturing said there were no such testing lines—Irresistible had never needed them. He did find a small, seldom-used line that could be quickly converted, but it would cost about $250,000, maybe more. Brian quickly filed a capital request.
That led to an awkward conversation, worse than Brian had imagined. Colin, the CFO, was not known for his willingness to experiment, and he rejected the request out of hand. “Look, Brian, we’re facing a tough year, and this is not in the budget. You’ll have to find another way until we can work it into our next operating plan.”
Brian was flabbergasted. “Of course it’s not in the budget. Neither are the revenues that will come from it, nor the profits that will probably be fifty times higher than these costs. We can’t wait that long.”
Colin was not amused. “The costs are certain, but the revenues and profits are not. If everybody did what you’re trying to do, this company would be in complete chaos. I have responsibilities to our shareholders, and to others in the company who are sticking to their budgets.”
Brian pulled out his trump card. “I don’t like doing this, but you know I’ll need to talk to Lori about this, right?”
Colin shot back, “You do that!” and turned to some papers on his desk. Brian walked out and headed straight for Lori’s office. Lori didn’t like overruling her CFO, but she had promised to fund the project, so she did—quickly. Brian knew there would be additional budget requests, and he pulled out his notebook. He found a blank page and wrote:
PLANNING AND FUNDING
The team continued pushing through barrier after barrier. Consumers wanted see-through packaging so they could see the actual product. The packaging department worried that clear packaging would shorten the products’ shelf lives. Team members knew that start-up competitors had been using clear packaging for many months, so they found and quickly qualified a supplier that had solved the shelf life problem with new materials. Consumers also said they wanted some products with pistachios, cranberries, and higher cocoa content. Sourcing these materials required finding and qualifying new suppliers, and the new ingredients would also require more extensive safety testing. Brian and the team agreed that the extra time required for safety checks was well worth the delay. They restructured their activities to avoid running into those bottlenecks.
Gradually, word of the agile team’s accomplishments spread. So did the number of people who wanted to get involved. Every member of the executive committee attended the second sprint to review five new prototypes. But it was just as Brian had feared: some of the more control-oriented executives began causing problems. They demanded make-up sessions for the reviews they had missed. They began issuing orders to their subordinates on the team. They insisted on updates prior to major reviews. The team members worried that failing to follow their bosses’ orders could be disastrous for their careers. After all, when this program was over, they might be returning to their old jobs. Brian had no choice but to request time on the excomm’s agenda to describe the agile process and clarify their roles in removing barriers rather than issuing orders.
Again, Lori reinforced Brian’s message, and her personal prodding enabled temporary workarounds for most problems. Still, Brian continued to fill his notebook. Turning to a blank page, he created a category for “Leadership and Culture,” adding several bullets:
LEADERSHIP AND CULTURE
The bullets under other categories grew as well. Under “Structure and People,” he added three new bullets:
STRUCTURE AND PEOPLE
Under “Processes and Technology,” he continued adding bullets:
PROCESSES AND TECHNOLOGY
The third sprint had the potential either to build momentum and commitment to agile processes or to give skeptical bureaucrats ammunition for killing it. Brian was taking another risk with the product review. Irresistible had always relied on third-party agencies to conduct product reviews. The rationale was sensible: they were skilled facilitators, plus they could be perfectly objective and nondefensive. But Brian wanted his team members to develop deep customer intimacy, and he didn’t like waiting two or three weeks for the agency to deliver a polished report on the reviews. Few team members had ever done this sort of thing, and nearly all of them were nervous about how they would be judged by executive committee members.
Today, groups of five consumers each are filing into the four conference rooms surrounding the central observation room. The ten excomm members also congregate. Some focus their attention on only one group. Others rotate to hear the feedback from several groups. They talk among themselves about how to interpret the consumers’ comments.
From the team members’ perspectives, the reviews are successful. Four of the seven products tested have very high appeal to different consumer segments, and they receive good suggestions for ways to make the products even better. There are insights into packaging, labeling, marketing messages, and pricing. Three of the products have too many problems and fall to the bottom of the backlog. But what does the executive committee think? It’s time to find out.
As the team members file into the central observation room, a few of the excomm members actually clap. “That was amazing,” says Kelly, the R&D chief. “I have never seen so much progress after six weeks.” Lori is more restrained, but she is clearly pleased—it looks as if the risk she took is paying off. All eyes turn to Colin, the CFO, his suit dark gray and his face dour. A small smile crosses his lips. “I think I can support this,” he says.
From Colin, that is the equivalent of a four-star review, and it seems to open the floodgates. The executives shake hands with all the team members. They start asking what they can do to help. They even begin talking about other innovation projects that should adopt agile ways of working. Tomorrow will be the team’s retrospective on what they can do better in the next sprint. But for tonight, it is time to celebrate—and for Brian to get some sleep.
Irresistible Snacks, Brian, and the agile team he leads are of course fictitious. The story is a composite, based on hundreds of companies and teams that we have observed. But the fiction reflects two sets of facts about agile.
First: the agile team lies at the very heart of an agile enterprise. If you don’t understand agile teams, you can’t understand agile as an operating philosophy. That’s why we described Irresistible’s team in so much detail. In the rest of this chapter, we will examine where teams like Brian’s came from. We’ll describe in broader terms the principles and practices that govern what they do, how they work, and why they operate as they do. And we will of course define agile catchwords like sprint and backlog. But we first wanted to offer a sense of what these teams look and feel like, because both their origin and their operation reflect people’s attempts to escape the confines of bureaucracy.
Second: it’s easy enough to run a few agile teams in any organization. But if your ultimate goal is to scale agile, you need to begin changing the way people throughout the organization think and act. That’s the significance of Brian’s notebook. As you’ll see, the challenges and obstacles he took note of are the challenges and obstacles that are likely to arise in any company that scales agile. These are the issues that we will take up in later chapters. We’ll focus on what we think are the most important ones: leadership behaviors; planning, budgeting, and reviewing; organizational structures and people management; and processes and technology.
Some historians trace agile methodologies all the way back to Francis Bacon’s articulation of the scientific method in 1620. In our view, a more reasonable starting point might be the 1930s, when the physicist and statistician Walter Shewhart of Bell Labs began applying continuous improvement cycles (specification-production-inspection) to products and processes. In 1938, W. Edwards Deming grew interested in Shewhart’s work and popularized it with today’s well-known plan-do-study-act (PDSA) cycle.
In 1986, Ikujiro Nonaka and coauthor Hirotaka Takeuchi published an article in Harvard Business Review called “The New New Product Development Game.”1 Studying manufacturers that were releasing successful innovations far faster than competitors, the authors identified a team-oriented method that had changed the design and development process for products such as Fuji-Xerox’s copiers, Honda’s automobile engines, and Canon’s cameras. Rather than following conventional relay race methods of product development—one group of functional specialists handing off its completed phase to the next functional stage—these companies were using what Takeuchi and Nonaka called a “rugby” approach, “where a team tries to go the whole distance as a unit, passing the ball back and forth.”2
In 1993, Jeff Sutherland faced what seemed like an impossible task. Easel Corporation, a software company, needed to develop a new product to replace its legacy offerings in less than six months. Sutherland already had a strong background in methodologies such as rapid application development, object-oriented design, PDSA cycles, and skunkworks. He hoped to create a skunkworks-like culture in the middle of Easel’s corporate headquarters, blending the benefits of both separation and integration. So he began by learning everything he could about maximizing organizational productivity. Reading hundreds of papers and interviewing leading product-management experts, he found himself intrigued by several provocative ideas.
One came from a Bell Labs article on the Borland Quattro Pro team, suggesting that short daily team meetings increased group productivity dramatically.3 Similar tips turned up in other materials. But the capstone concept for Sutherland was the discovery of Takeuchi and Nonaka’s rugby approach, even though it focused on manufacturing rather than software. Borrowing many of their article’s key ideas and filling in specific operational practices, Sutherland created a new way of developing software; honoring the rugby imagery, he dubbed his approach Scrum. Scrum methods enabled him to finish his seemingly impossible project on time, under budget, and with fewer bugs than any previous release. He then collaborated with longtime colleague Ken Schwaber to codify the approach, and in 1995 the pair presented Scrum to the public for the first time.
Of course, Sutherland and Schwaber weren’t alone in their search for innovative methods. The information age was exploding. Disruptive technologies were terrorizing slow-footed competitors. Start-ups and incumbents alike were seeking better ways to adapt to the unfamiliar and turbulent environment. Software was becoming an integral part of nearly every business function, and many creative software developers were working hard on better methods of programming to increase adaptability.
In 2001, seventeen developers who called themselves organizational anarchists met in Snowbird, Utah, to share their ideas. Sutherland and other proponents of Scrum were among them. The group also included advocates of several competitive approaches, including Extreme Programming (XP), Crystal, Adaptive Software Development (ASD), Feature-Driven Development (FDD), and the Dynamic Systems Development Method (DSDM). All these approaches were collectively known as lightweight frameworks because they used fewer, simpler rules to allow faster adaptation to rapidly changing environments. (Not many of the attendees found the lightweight terminology flattering.)
Although they disagreed on much, members of the group eventually settled on a new name for the movement: agile. The word was suggested by an attendee who had been reading the book Agile Competitors and Virtual Organizations: Strategies for Enriching the Customer, by Steven L. Goldman, Roger N. Nagel, and Kenneth Preiss.4 The book offered one hundred examples of companies—including ABB, Federal Express, Boeing, Bose, and Harley-Davidson—that were developing new ways of adapting to turbulent markets. Name in hand, attendees then forged consensus on a call to arms, which they dubbed the Manifesto for Agile Software Development. The manifesto spelled out four key values that everyone agreed on—such things as “working software over comprehensive documentation” and “responding to change over following a plan.” Later in the meeting, and continuing over the next few months, they developed twelve operating principles, such as “Our highest priority is to satisfy the customer through early and continuous delivery of valuable software” and “Simplicity—the art of maximizing the amount of work not done—is essential.”5 From 2001 on, all development frameworks that aligned with these values and principles would be known as agile techniques.
Once the Snowbird meeting had canonized a creed for agile innovation, the agile movement spread rapidly. The signatories posted their document online and invited others to add their names as supporters. Most members of the original group, joined by a number of new adherents, reconvened later in the year to discuss ways to disseminate agile principles. All agreed to write and speak on the topic.
Over time, the use of agile grew. In 2016, one of this book’s authors (Darrell Rigby) joined Sutherland and Takeuchi to write a Harvard Business Review article called “Embracing Agile.”6 By then, the article reported, National Public Radio was employing agile methods to create new programming, John Deere to develop some of its new machines, and Saab to produce the Gripen jet. Mission Bell Winery, in California, was using the methods “for everything from wine production to warehousing to running its senior leadership group.”7 OpenView Venture Partners, based in Massachusetts, was encouraging its portfolio companies to adopt them. Agile has spread further since then, as the examples in this book will show. While its complex family tree sometimes provokes passionate debate among agile practitioners, two things are clear from this brief history. First, agile’s roots and applications extend far beyond its uses in information technology; they are relevant to many different elements of an organization. Second, agile is likely to continue to spread. It was developed to help people escape the clutches of bureaucracy—and what the Irresistible Snacks of the world need now, more than anything else, is the ability to restore the balance between bureaucracy and innovation.
Agile teams work differently from chain-of-command bureaucracies. They are best suited to innovation—that is, the profitable application of creativity to improve customer solutions, business processes, and technology.
To tackle an opportunity, the organization forms and empowers a small team, usually three to nine people, most of whom are assigned full time. The team is multidisciplinary and includes all the skills necessary to complete its tasks. It manages itself and is strictly accountable for every aspect of the work. Senior leaders tell team members where to innovate but not how. Confronted with a large, complex problem, the team breaks it into modules, develops solutions to each component through rapid prototyping and tight feedback loops, and integrates the solutions into a coherent whole. Members place more value on adapting to change than on sticking to a plan. They hold themselves accountable for outcomes (such as growth, profitability, and customer loyalty), not just outputs (such as lines of code or number of new products). The teams work closely with customers, both external and internal. Ideally, this puts responsibility for innovation in the hands of the people who are closest to those customers. It reduces layers of control and approval, thereby speeding up work and increasing the teams’ motivation.
Agile approaches are a combination of both mindsets and methods. Although religious wars break out among zealots battling over which is more important, the debate is absurd. Is your head or your heart more important to survival? You die unless you have both. As a philosophy, agile focuses intently on customers. Practitioners believe that every work activity has a customer, and that work should be structured around meeting customers’ needs as effectively and profitably as possible. The finance group, for instance, serves the operating units it funds, and they should provide feedback on their satisfaction with finance. Agile teams thus have backlogs—essentially, prioritized and sequenced to-do lists—based on customer needs, not tasks to complete.
The agile mindset abhors work in process (WIP). WIP ties up work while adding no value. The longer it sits, the more it costs. Meanwhile, customer needs are changing, competitors are innovating, and WIP is growing obsolete. So agile favors small batches, produced in time-limited (less than a month) work cycles called sprints. Contrary to some skeptics’ opinions, agile practitioners do not run short sprints to make team members work harder. They run short sprints to encourage fast feedback from real customers. A short sprint encourages agile teams to think about how they can quickly create something worth testing. Short sprints also make it easier for team members to synchronize long, slow processes with fast ones.
The team’s initiative owner, also known as a product owner, is ultimately responsible for delivering value to customers (including internal customers and future users) and to the business. The person in this role usually comes from a business function and divides his or her time between working with the team and coordinating with key stakeholders: customers, senior executives, and business managers. The initiative owner may use a technique such as design thinking or crowdsourcing to build a comprehensive portfolio backlog of promising opportunities. Then he or she continually and ruthlessly rank-orders that list according to the latest estimates of value to internal or external customers and to the company. The initiative owner doesn’t tell the team who should do what or how long tasks will take. Rather, team members themselves create a simple road map and plan in detail only those activities that won’t change before execution. They break the highest-ranked tasks into small modules, decide how much work they will take on and how to accomplish it, develop a clear definition of done, and then start building working versions of the product in sprints. A process facilitator (often a trained scrum master) guides the process. This person protects the team from distractions and helps it put its collective intelligence to work.
The process is wholly transparent. Team members hold brief daily coordination meetings to review progress and identify roadblocks. They resolve disagreements through experimentation and feedback rather than through endless debates or appeals to authority. They test small working prototypes of part or all of the offering with a few customers for short periods of time. If customers get excited, a prototype may be released immediately, even if some senior executive isn’t a fan or others think it needs more bells and whistles. The team then brainstorms ways to improve future cycles and prepares to attack the next top priority.
Compared with traditional management approaches, agile offers a number of major benefits, all of which have been studied and documented. It increases team productivity and employee satisfaction. It minimizes the waste inherent in redundant meetings, repetitive planning, excessive documentation, quality defects, and low-value product features. By improving visibility and continually adapting to customers’ changing priorities, agile improves customer engagement and satisfaction, brings the most valuable products and features to market faster and more predictably, and reduces risk. By engaging team members from multiple disciplines as collaborative peers, it broadens organizational experience and builds mutual trust and respect. Finally, by dramatically reducing the time squandered on micromanaging functional projects, it allows senior managers to devote themselves more fully to higher-value work that only they can do: creating and adjusting the corporate vision; prioritizing strategic initiatives; simplifying and focusing work; assigning the right people to tasks; increasing cross-functional collaboration; and removing impediments to progress.
Agile practitioners are extraordinarily skeptical of managers’ abilities to predict, command, and control innovative solutions, especially when what to deliver and how to deliver it are vague. As a thought experiment, imagine that you are charged with designing an autonomous vehicle to drive from Minnesota to Florida. You would have two options:
The first is to develop a deterministic model for the vehicle. You could study every detail of the roads between Minnesota and Florida, predicting every possible twist and turn, traffic light change, pedestrian or deer crossing the road, traffic accident, and weather condition. When the car crashes during a trial run (as it inevitably must), you will be told to work harder and to improve your predictive skills. But the chances are slim that more work will solve the problem. If the vehicle were traveling inside a tube, maybe the predict-and-plan model would work. In the real world, things get very complicated very quickly.
A different approach is to program the vehicle to adapt to changing conditions. Start by determining why someone might want to go from Minnesota to Florida in the first place. If hurricane conditions make Florida too dangerous, consider rerouting to California. Then anticipate the situations that could arise, develop ways to measure those situations, create sensors to track them, and incorporate appropriate responses to deal with them. Collect data from weather centers, traffic monitors, and other drivers. Provide the data to those same sensors from your vehicle. “I am approaching this intersection, be sure to stop for the light.” If the feedback loops are short enough and sensitive enough, the transitions will be smooth and comfortable rather than abrupt and jarring. That’s what agile is all about—learning as you go.
FIVE KEY TAKEAWAYS