| --Lao Tzu[155] | ||
In Frank McCourt's memoir, Angela's Ashes, Frank's dad (a shiftless garrulous alcoholic with a soft heart) unilaterally decides that Frank is going to be an altar boy. He then proceeds to torture the little boy with a program of intense preparation. As Frank puts it: "Every evening after tea I kneel for the Latin and he won't let me move till I'm perfect."[156]
Both parents make a huge effort, and spend what little money they have, preparing young Frank for his new assignment, making sure he is prepared and looks just so. Finally the day comes where Frank's dad takes him to see the priest in charge of altar boys. Here's how Frank describes the meeting:
"Stephen Carey looks at him, then me. He says, 'We don't have room for him,' and closes the door."
Frank's quest to become an altar boy abruptly ends.
Why didn't Frank's dad save the family all of that trouble and meet with the priest before Frank was thrown headlong into a grueling preparation? Why didn't he find out whether there was any interest in having a new altar boy?
When Sam Bayer was a consultant some years ago, he used this story to spark organizations to ask themselves why they should spend a long time producing a big thing, only to find that when the thing is done, what they have produced is not what was wanted. Why not focus collective energies on finding out what people want and then figure out step by step whether what you are working on is delivering what they actually want?
Bayer had seen companies spend large amounts of resources building software. But they wouldn't know whether they would succeed or fail until they launched the software, and then their customers would tell them that their product was useless. These companies had spent time building a perfectly useless product.
In 2007, Bayer saw an opportunity to launch his own firm. He noticed that people in the business-to-business world were still placing orders with their manufacturers by phone, fax, and e-mail. This was slow and expensive, and he decided to explore whether he could help by offering a Web-based service.
His idea was to use client-driven iterations to determine whether there was a market, define the service he would provide, and then implement it. He wanted to fail as quickly as possible, recover, and keep honing in on what customers really needed. His aim was to implement this in marketing, sales, and implementation.
He got together an experienced team and, as quickly as possible, built a prototype of the software that he had in mind and the pricing model with software as a service. The team got its presentation ready and then, even before he had incorporated the company, he convened a group of potential customers to see what they thought.[157]
At the time, software as a service was an unfamiliar idea in this market. The technology was straightforward, but the pricing mode was new.
He walked the people through the prototype and the pricing model and asked why it couldn't be introduced the next day. Bayer says, "We weren't asking people for ideas. We were asking people: 'Why won't this work in your organization tomorrow?' We didn't waffle around and talk about all the things it was going to do. We presented it and showed what it actually did. The comments we received went into the next iteration of the service. We were doing engineering, sales, and marketing all at once."
Bayer incorporated his company and is now the CEO of his business-to-business technology firm in Raleigh, North Carolina, called b2b2dot0 (pronounced "bee two bee two dot oh") in 2007. The business continues to grow in this same way. When Bayer launches a new feature or function, he invites customers and prospects to try it out: "You invite people to come and have a look at what you are doing. And if people show up, then for that hour and a half, you take it on the chin. The people say, 'Yeah, we like it, but it won't work because of this, or because of that.' We get thirty to forty reasons per hour as to why it won't work for them. Which I find delightful."
Bayer establishes priorities among the issues that have been raised and fixes the top ones. Then he comes back to the people and asks them, "Now why won't it work?" And they tell him why or say, "I don't see any reason why it won't, so let's go do it."
Bayer describes the work as having "a rhythm to it. There are multiple streams happening. There's an overall quarterly product rhythm. We set out a theme for each quarter. We leave a lot of room for new things to emerge during the quarter. But we have our eyes on one major release for the quarter. On the product side, on a daily basis, we are prototyping, demonstrating, because when software is a service, we can release it."
Implementation is also done in an iterative fashion. For each client, he sets up an implementation project and focuses on thirty days to get some value, then sixty days to get more value, and finally ninety days to get the full value from the project. The length of the iteration depends on the client. There might be weekly demos in some cases. And on a daily basis, they are constantly interacting with the client. In this way, the firm uses client-driven iterations on the front end, on the sales and marketing, and on product implementation. They are concurrent and intertwined.
Is it working? Bayer says, "It's a blast. It really is. It's not a bureaucracy. On a daily basis, we're seeing the impact on the business. Everyone in every role that we play, whether we are implementing product with clients or trying to drum up business, or developing partnerships, it's all direct feedback. Our work—results! Our work—results! We get it on a daily basis. We're preselected to enjoy that."
Credit for the idea of doing work in client-driven iterations is often given to Taiichi Ohno, an engineer at Toyota. Ohno himself says that some of the thinking actually came from America.
Born in Dalian, China, Ohno graduated from Nagoya Technical High School in 1932. He was an employee first of the Toyoda family's Toyoda Spinning, then moved to the motor company in 1943 and became section manager at the Honsha final assembly plant in February 1945.[158]
After the war was over, the challenge facing Toyota was how to be competitive when the U.S. auto industry was eight times more productive than Toyota. "We realized," writes Ohno, "that with our traditional methods the Japanese automotive industry would never survive. We could not even catch up unless we improved our productivity ten-fold."[159]
He wondered how Toyota could possibly improve productivity tenfold. He heard from a colleague in the assembly section of the plant that the president of Toyota, Kiichiro Toyoda, was saying that the most efficient way to assemble cars was when each part arrived "Just in Time."[160] Up until then, the upstream manufacturing processes would deliver the parts they finished one after another. The engines would be delivered, but the cars couldn't be assembled right away because the steering wheels weren't ready. As a result, considerable time was spent waiting around for all the parts to arrive so that work could begin, followed by intense bursts of work and large amounts of overtime. Ohno saw that by organizing the flow of parts so that they arrived in a smooth sequence, or "just in time," major gains in productivity could be accomplished fairly easily.
The idea of "just in time" came from the president of Toyota, but the next step, the idea of having the client drive the iterations, came from America.
Ohno explains that in the early 1950s, one of his classmates had come back from a visit to the United States where he had taken photos. Among them were several photos of what was a new phenomenon for him. The classmate said that in the United States, "there was something called a supermarket, and there was only a young woman at the exit, and the customer pulled along something like a baby stroller, bought just what they wanted and paid at the exits. This reduced expenses quite a lot, so the customers could buy things inexpensively. If one person was enough for the store, this reduced expenses of the store."[161]
Ohno saw that the idea of having customers go to the store to buy what they wanted in the quantity they wanted, and then have the managers replenish the store with exactly the amount and the type of goods that the customers had bought, could be applied to the process of assembling cars. When parts were brought to the assembly section just because they were made, whether they were needed or not, the assembly section was forced to work in a very uneconomical way. So just like a supermarket, the manufacturing section would manufacture only the type and the quantity of parts that the assembly section actually came to pick up.
The system he developed was initially called "the supermarket system": the manufacturing section no longer delivered parts to the assembly section. Instead they waited until the assembly section came to pick up parts, and then manufactured as many parts as the assembly section had actually used. For ten parts actually used, they simply had to make ten parts by the time the assembly people came back the next time. Instead of manufacturing so as to push parts from manufacturing to assembly, manufacturing waited until there was pull from the assembly that they needed parts.
This posed a challenge for the manufacturing section to effectively produce only what the assembly section came to get. In order to do this, they had to keep lot sizes small and do changeovers from one part to another very efficiently.
In due course, the "supermarket system" came to be known as the Toyota Production System. Contrary to what common sense might indicate, once rapid changeovers were accomplished, small demand-driven iterations generally turned out to be more efficient than mass production runs.[162] Toyota's goal was "to go from...'order to cash' as fast as possible at a sustainable pace—to deliver things of value to the customer...in shorter and shorter cycle times of all processes, while still achieving highest quality and morale levels."[163]
Initially Toyota's production system was ignored, even in Japan, because demand was strong and companies were growing quickly. Then the oil crisis of 1973 triggered an economic slowdown, and other Japanese companies saw how Toyota emerged from the slowdown stronger and more resilient. This model of manufacturing came to the United States in the 1980s.[164] In 1990, it was christened "lean manufacturing" in the book, The Machine That Changed the World.[165]
When lean techniques are executed well, with small batch sizes, increased flexibility, and reduced variability, cycle times can drop by factors of ten to one hundred. Inventories can be reduced by more than 90 percent, freeing enormous amounts of cash. Secondary effects include improved quality, accelerated learning, and lower production costs.[166]
Toyota uses an iterative approach not only in manufacturing but also to develop its new models. Lean analysts Mary Poppendieck and Tom Poppendieck write: "The product development process has specific synchronizing events such as vehicle sketches, clay models, design structure plans, prototype and so on. The dates for events are scheduled by the chief engineer. Every engineer and supplier knows that these dates will never—ever—be moved. They know exactly what is expected of their contribution by the date. The engineers are expected to obtain for themselves everything necessary to be ready on time. Thus information is 'pulled' by engineers as they need it instead of broadcast to long distribution lists."[167]
Fujio Cho, board chairman of Toyota says: "You realize how little you know and you face your own failures and redo it again and at the second trial you realize another mistake and so you redo it once again.... So by constant improvement...one can rise to the higher level of practice and knowledge."[168]
In the 1990s, Quadrant Homes, a subsidiary of Weyerhauser, built homes in the Seattle area in the traditional manner.[169] First, the company would buy a tract of land, assuming high demand and hoping for appreciation. Then its architects would design the home from the builder's viewpoint to incorporate the latest housing trends, meet buyer profiles, and match the competition. Next, builders would construct the home in three to four months, adding options that they thought would be appropriate. It was often only toward the end of the construction period that there would actually be a real buyer. When the buyer was in hand, Quadrant would conduct a single final walk-through aimed at fixing defects and problems to be covered under the warranty. Finally, the deal would be completed.
In a seller's market with high demand, this might have worked. But in the Seattle market where Quadrant operated in the 1990s, demand for the kind of houses Quadrant was building was mixed Because the houses didn't sell quickly, it faced the cost of holding high levels of inventory. Buyers encountered sticker shock since the actual price of the house was often above the advertised price as a result of the high-priced options that the builder had installed. To get the home sold, price concessions had to be made, further reducing Quadrant's margins. Overall, the houses that Quadrant was building didn't respond to what home purchasers were really looking for. Customer satisfaction was low.
In 1998, Quadrant took a hard look at what it was doing and came to the realization that it couldn't grow and meet its profitability requirements with the model that it had. It saw that it wasn't in the business of building houses. Instead its goal should be "to help people realize the American dream." When it studied the market, it discovered a large unmet need among first-time home buyers who were buying existing homes that were cheaper than new homes and met their basic needs more closely. Quadrant set out to "provide more house to more homebuyers for less money than they ever thought possible."[170]
To accomplish this, Quadrant began operating in an iterative fashion, starting from what the buyer wanted. Instead of building the home and then trying to sell it, Quadrant sells the home before building it and involves the buyer iteratively in the design and building of the house. The customer can choose from multiple footprints and floor plans. Standardized customization offers the flexibility buyers want while reducing complexity for the builder.
The buyer, not the builder, chooses the options so they get exactly what they want. They can also experience what the design choices feel like in one of two showrooms and on scheduled site visits. The final walk-through inspection with a punch list of issues to be fixed has been replaced by three site walk-throughs with the buyer at key milestones, along with weekly customer calls with updates on progress.
"The word 'choice' is a big deal for us," says Quadrant vice president Ken Krivanec. "It's all iterative for the buyers. They can go from a variety of locations, to a variety of lots to choose from, to a variety of floor plans, and then on to complete customization of the house itself with up to 10,000 different permutations and combinations that they can experience in one of the showrooms."
Quadrant has also made internal efficiencies. Single long-term partners were engaged for each trade. As a result, costs have been lowered and quality raised. Quadrant is also able to compress construction time from a variable 90 to 120 days to a standardized 54 days.
Despite a difficult housing market, an iterative way of working has enabled Quadrant to continue igniting client delight.
Toyota, Quadrant Homes, and b2b2dot0 are just a few of the countless firms that are using client-driven iterations as a means of becoming more productive. Interestingly, client-driven iterations are not just more efficient; they also can help create meaning in work.
Meaning in work, as Chip Conley, the CEO of Joie de Vivre Hospitality, points out in his book, Peak, is different from meaning at work: "Meaning at work relates to how an employee feels about the company, their work environment, and the company's mission. Meaning in work relates to how an employee feels about their specific job task."[171]
Some organizations are content if they have a worthwhile mission and people are paid adequately. Feeling part of an organization that is making a difference in the world can help give people a sense of being part of something more important than themselves. Having a mission that can inspire, like Apple's "Think different," Nike's "Just do it," and Joie de Vivre's "Create joy," can—to a certain extent—give people a feeling that they are working in something larger, and may even encourage them to tolerate bad working conditions.
And yet if people can't see how the specific work they are doing on a daily basis fits into this larger mission, cynicism may set in. This is the issue often faced by people working in the public sector and at nongovernmental organizations: the mission is worthwhile, but the traditional management often practiced by those organizations is dispiriting.
Radical management is about creating both meaning at work and meaning in work: that is, both a worthwhile mission for the organization as a whole and meaningful work on a day-to-day basis. The distinction is nicely depicted in Figure 6.1.
Meaning in work can be facilitated by getting work done within client-driven iterations. This is not only where the rubber hits the road but also where the people doing the work can see the impact of the rubber hitting the road.
Iterative work patterns have been around for a long time. In fact, in painting, literature, music, engineering, and filmmaking, they are the norm. At Pixar for example, the award-winning digital moviemaking firm, although each team has clear leaders, collaboration and criticism are built into the creative process. The work on each film is subjected to daily review and anyone can offer an opinion.[172] And rapid prototyping is one of the practices that underlie the success of the award-winning San Francisco design firm, IDEO.[173]
Figure 6.1. The Distinction Between Meaning at Work and Meaning in Work Source: Based on Conley, C. Peak: How Great Companies Get Their Mojo from Maslow. San Francisco: Jossey-Bass, 2007.
As early as the 1930s, quality management saw the introduction of iterative approaches to work when Walter Shewhart, a quality expert at Bell Labs, proposed a series of short plan-do-study-act (PDSA) cycles for quality improvement.[174] Starting in the 1940s, quality guru W. Edwards Deming began vigorously promoting PDSA, which he later described in his book, Out of the Crisis.[175] Quality management, however, focused for the most part on internally driven iterative work patterns. It was management that defined quality and steered the flow and direction of change. The client wasn't always the center of attention.[176] By contrast, client-driven iterations start from the client. Rather than pushing steadily improved goods and services to the client in the hope of making a sale, client-driven iterations adopt a pull approach, starting from the client.
Through client-driven iterations, firms like Toyota, Quadrant, and b2b2dot0 are able to keep inventory and work in process as small as possible and customize their product not only to meet the customer's original perceived needs but also to adjust it to meet any changes in those needs.
Conceptually, in a pure pull approach, if there is no buyer, the firm does nothing. Instead it sets about improving the firm's practices and techniques or developing new products and services. In practice, the pull approach is never purely pull. So as software developers Larman and Vodde point out, to state that pull is good and push is bad is a false dichotomy.[177] Toyota's manufacturing section has to make some product before it can be replaced by a pull from the customer. Quadrant needed to build the new home showroom and some amount of product to show to potential buyers. Sam Bayer's firm had to build a prototype before he could begin the client-driven dialogue. But the amount of time and effort spent on these push-based activities is minimized until there is a client.
Client-driven iterations have become pervasive in software development with the spread of Scrum and Agile methodologies. The traditional sequential way of managing with a sequence of specifications, planning, implementation, and delivery ran into major problems. The end result of traditional project management wasn't just that the projects didn't finish on time. Around half of all large projects simply didn't finish at all.[178]
The success of client-driven iterative methods in managing software has led to the spread of those methods to related fields. Thus, the Quality Software Engineering group at IBM is responsible for software development processes and practices across the company. As part of the effort to promulgate Scrum in developing software, an iterative process of working was adopted for doing change management.[179]
Similarly, at the Chicago software firm Total Attorneys, iterative work patterns were so successful that they spread to the staff of call centers: small cross-functional teams work in cycles of three weeks. At the Danish software firm Systematic Software, iterative methods have been spreading from software development to other parts of the firm. At the Swedish software firm Trifork, iterative methods have spread from software development to conference management. And Open View Venture Partners, a Boston-based venture capital firm, has expanded client-driven iterations into consulting and finance.
Once a firm sees the power of client-driven iterations in one area, it becomes natural to ask: Why not do all work in this fashion?
Client-driven iterations help force progress on all three sides of the iron triangle of organization, staff, and clients. They improve productivity for the organization by focusing work on the elements that really add value and eliminating work that doesn't add value. They also eliminate unproductive planning time. It's counterintuitive but true that once an organization masters the turnaround, short production runs are usually more efficient than long ones.[180] They also reduce risk to the organization by providing management not with unreliable progress reports, but with evidence of whether actual progress is being made.
They boost job satisfaction by providing people doing the work with a direct line of sight to the clients for whom the work is being done, giving a sense of accomplishment if they succeed and a spur to try harder if they fail. And they promote client delight by giving the clients or their proxies the opportunity to guide the work to generate exactly what they want.
They do these things simultaneously, not in opposition to each other.
Despite the spread of client-driven iterative methods of managing, it is fair to say that the default mental model of management in general remains the push approach of doing work in one go from start to finish in accordance with a plan.
We know that this doesn't work very well in complex dynamic environments. And we know that when the goal of work shifts from the linear task of producing goods and services to the complex challenge of delighting clients, then all work contexts become dynamic and unpredictable.
So why aren't client-driven iterations already the standard pattern for doing work? One reason is historical. Organizations change slowly. The habits of managers who have worked in a sequential push fashion for decades are set and embedded in the culture of most large companies. It is common sense, obvious, and logical to do the requirements, then design, then implement. It gives the impression of an orderly, accountable, and measurable process with simple, document-driven milestones. It is a natural marriage with hierarchical bureaucracy. It ties in with thinking built on the economies of scale, mass production, and mass marketing. There is only one problem: in a complex dynamic environment and where competitive survival depends on being able to delight clients, it doesn't work.
The traditional management approach of big-chunk implementation in accordance with a plan is also based on a philosophical difference. It reflects a deterministic philosophy that imagines we can create a complete definition of what needs to be done and then realize that definition. Radical management accepts that in a dynamic, unpredictable world, it isn't possible to create a complete definition of what needs to be done. The way to cope with a rapidly changing and unpredictable environment is through short iterations that enable adjustment to change.
Big-chunk implementation is also based on an economic error. The conventional view of iterative work processes is that doing iterations and prototypes wastes resources. Why not get it right the first time and do big production runs? Why waste time on multiple cycles? Each iteration incurs a cost in cycle time and transition expenses. Extra iterations incur extra costs and extra costs are bad, so iterations should be reduced to improve efficiency. In reality, once the art of managing quick transitions between cycles is mastered, iterative work patterns are not only more flexible and deliver higher quality; when the overall costs to the organization are taken into account, they are generally cheaper.[182]
The difficulty of communications also plays a role. Iterative work patterns are hard to explain and understand. They are counterintuitive. Software developer Kent Beck writes: "I thought that for a mass-production factory to run smoothly there must be a large inventory of parts between any two steps of the process. That way, if the upstream machine stops working, the downstream machine can keep chugging away on the buffer of parts. [The Toyota Production System] turns this thinking on its head. While individual machines may work more smoothly with lots of 'work in progress' inventory, the factory looked at as a whole doesn't work as well."[183] Analogies can help communicate, as Taiichi Ohno found with the supermarket analogy and Sam Bayer has found with the story from Angela's Ashes.
A less obvious stumbling block is psychological. Managers are used to having comprehensive plans with Gantt charts and fixed delivery dates, often spelled out over several years. Such magisterial plans, however, can lead to magical thinking, with managers confusing plan with reality, viewing the world as an extension of their will, even losing their grasp on the real world as something independent.
Working in client-driven iterations generates self-understanding. We learn that we are not as free or as powerful as we thought. Our shared interdependence is brought into immediate and direct view. We realize that we are tied to our fellow human beings and all the frustrations and delights that this entails. These discoveries are not necessarily comfortable.
A final reason is practical. How do we slice up big, lumpy projects into iterations? We have already seen how client-driven iterations can be applied to building houses, something that doesn't at first glance look as though it can be handled in an iterative fashion. Once we understand the practices involved, virtually any work can be approached in this way.
One of the pioneers of doing work in iterations is Tom Gilb. In his book Evolutionary Project Management, he writes about an apparently unpromising candidate for iterative implementation: a naval radar system on a ship that wasn't due to be launched for another three years. How could it possibly be done in an iterative fashion?[184]
The project was to make a radar device that had two antennas instead of the usual one. The dual signal sources were analyzed by a computer, which presented their data. It was for monitoring the ship and air traffic surrounding the ship. It was like having two eyes.
Gilb began to solve the problem by identifying the stakeholders and the results they would be expecting. The goal was increased accuracy of perception for the Royal Navy, not the production of a black box. Gilb then asked whether the black box worked more or less in the lab. When he found out that it did, this opened the way to asking why it couldn't be tried out on one of the navy's existing ships, initially running in parallel to conventional radar. Then any problems in practice would be ironed out, and desirable new features would be added, possibly giving the test ship itself immediate increased capability. Then when the new ship was launched, the system would be far more mature and safe to use.
Iterative thinking was also used in the U.S. Navy to build submarines.[185] In October 1957, Vice Admiral Levering Smith had recently been appointed technical director of the new Polaris program, which was aimed at developing submarines that could launch missiles when submerged. The first Polaris submarine was scheduled to be operational eight years later, in 1965. That was already an ambitious target, as the Polaris program required the development of nine new technologies. In addition, Smith had a problem. The Soviet Union had just successfully launched Sputnik I, the first artificial satellite to orbit the world. That showed that the Soviet Union had the capability to launch long-range missiles with nuclear weapons toward the United States.
Two weeks after Sputnik I was launched, the deadline for completing the Polaris program was moved up from 1965 to 1959. What was already a very difficult goal had suddenly turned into mission impossible. How could such an acceleration be possible?
Smith's client was the U.S. Congress. To them, time was of the essence. Having any kind of missile-launching submarine in the water was far more important than having the perfect submarine. So Smith decided to approach the task iteratively. Instead of creating the ultimate system in nine years, he set about creating a progression of systems: A1, A2, and A3. The A1 version would contain whatever technology could be deployed in three years. The A2 version would be developed in parallel but proceed more slowly to allow it to use more desirable technologies. The A3 version would incorporate everything learned in the development of the earlier versions.
Smith succeeded. Congress gave him the money, and he delivered. What had seemed to be a mission impossible was accomplished. On June 9, 1959, the first Polaris missile was launched from a submarine. By the end of 1960, two Polaris submarines were patrolling at sea.
Unlike many other defense systems, the missile performed as promised. There was never a hint of a cost overrun.[186]
In essence, radical management and client-driven iterations imply a mental revolution, a different way of thinking about work. Once the mental revolution has occurred, the work can be divided into iterations. The key to success is delivering value to clients at the end of each iteration. It is this question to which we now turn.
Practice #1: Focus on Stakeholders and What Is of Value for Them
The first step in developing client-driven iterations is to shift attention from the thing to the person and identify the primary stakeholders. Rather than focusing on what is being produced, the focus is on whom it is for.
Thus, when radical management is applied to an apparently lumpy thing like building a house, the attention shifts from the house to the person for whom the house is being built. The goal switches from building a structure to fulfilling the client's dream. The house is obviously the principal means by which clients fulfill their dream. But the house is the means, not the end. Radical management asks: Who are the people who need the house? Why do they need it? How can we delight them more or sooner? How do we turn the process of building the house into one that adds to the customer's delight? It's a change in mind-set from things to people.
Practice #2: Identify the Principal Performance Objective for the Primary Stakeholders
It's important not to be distracted by the apparent objective of delivering a thing. One keeps asking why, until one finds what the customer really wants. In the case of the Polaris submarine, the real objective wasn't to develop a missile-based submarine: it was the increased feeling of security generated by having a submarine—any functioning submarine, not the perfect submarine—in the water and operational.
The priority is to focus first on those elements of high value that can be delivered soonest. To the extent possible, the client should participate in setting priorities. If this isn't possible, a proxy representative does the job—someone who spends time with the client, knows the client, understands the client, and has a good sense of what would delight the client.
Radical management is thus a process of organizational learning that allows teams and organizations to discover how to delight a client at the level of the overall business, of a particular product, or an individual team.
Practice #3: Consider How to Deliver More Value Sooner or Cheaper
Once you have the real goal, you can ask: How can we evolve toward that goal sooner? How can we delight the client with partial steps or other means? How can we give the client a taste of what it would be like so that he or she can give us feedback? Is it meeting the client's needs? How it could be improved?
Temporary designs or prototypes can also be used. It may not matter if the design is rough and inelegant. For instance, when the San Francisco–based design firm IDEO was trying to communicate the idea of a new kind of surgical knife to a group of high-powered surgeons, the staff taped together a whiteboard marker, a black plastic film canister, and an orange clothespin-like clip. The makeshift model represented a rough physical prototype of what the surgical knife would look like. Despite its inelegance, the surgeons understood the concept and liked what they saw.[187]
Practice #4: Decide as Late as Responsibly Possible What Work Is to Be Included in the Iteration
By making decisions at the last responsible moment, the team has the best information to make informed decisions. It avoids wasting resources by making unnecessary inventory or early decisions that will have to be undone. This gives the greatest chance to avoid working on something that isn't needed, and to include the best possible ideas at the top of the list of priorities to be worked on.[188]
Practice #5: Have the Client or Client Proxy Participate in Deciding Priorities for the Iteration
Ideally no work is done until there is some indication that the customer wants something, so that the team has a clear line of sight to that customer.
When the product is intended for a mass market, it is obviously not possible to have millions of customers giving their feedback on successive iterations. Here the challenge is to have one voice that speaks for the customers, understands the customers in depth, and anticipates how the customers will react to successive iterations.
The finished product is presented to the client or customer proxy at the end of the process of iterations, and the team doing the work can see and experience the reaction.
Practice #6: Ensure That the Team Doing the Work Knows Who Speaks for the Client
Systematic Software, a Danish software firm, has found that a distinguishing feature of its most productive teams is the clarity of their understanding as to who speaks for the client. They know how priorities are being defined and by whom, and when and how decisions are made. In practice, this function is often being performed by many people, including the project manager, architect, team leader, and lead developers. All of these different people form part of the function that defined priorities for an iteration.
Whether it is the team itself or a separate team that decides priorities or the clients themselves, clarifying who decides on priorities is one of the first steps in setting up a project.
Practice #7: Spell Out the Goals of Each Iteration Before the Iteration Begins
Unless we know where we are going, it is hardly likely that we will get there. Today many knowledge workers find themselves, as did Nathalie, the software developer we met in Chapter One, in the frustrating situation of not knowing exactly what work is meant to be done. There are many possibilities, but decisions are hard to come by.
When we don't know what work is to be done, we will never know when we have finished it. Much time will be wasted in spinning wheels, going down wrong alleys, trying to guess what is needed, and then doing rework when it turns out that the team guessed wrong.
Radical management entails getting crystal clear on what work is to be attempted in each iteration and then getting out of the way to let the team get on with it.
Practice #8: Define the Goals of Each Iteration in the Form of User Stories
In the world of traditional management where the goal is producing goods or services, the target is relatively easy to define in terms of the abstract requirements of the final product or service. Build things. Provide services. How much? How big? How long? How wide? What color? Requirements, sometimes extending over hundreds of pages, often include low-priority things that might be needed.
When work is done in this way, clients are rarely delighted, and workers often see little meaning in their work. That's because when the requirements are spelled out in terms of abstractions, the reasons for them are typically hidden. Why this much? Why this big? Why this long? Why this wide? Our ability to understand the meaning of our work is limited and our ability to innovate eliminated.
It's hard to argue with an abstraction. The job is simply to deliver a product or service in accordance with the specifications, come what may. "Just do it" is the implication. "Don't ask questions." The possibility that there might be a better way of delighting clients is systematically removed.
Once the goal of work shifts to delighting clients, the definition of work moves from an abstraction to a client experience. The questions become: How do we get inside the mind of the clients and understand what their current experience is like? How could that experience be different as a result of what we can accomplish during the iteration? How can we understand what these clients will be experiencing that will cause delight?
Capturing the experience will normally be in the form of a story. Stories catalyze our understanding by providing direct access to other people's thoughts and feelings. They enable us to climb out of our own self-centered world and see things from their perspective. With that understanding, we can begin to imagine what kind of a product or service will be likely to delight them.
In some areas like software development, planning in the form of stories is now pervasive. It is explained in detail in Mike Cohn's book, User Stories Explained.[189] It is now common to hear developers talk in terms of implementing stories: "I implemented three stories in this cycle."
Software developer Mike Cohn recommends a standard form for the user story: As a <type of user>, I want <some goal> so that <some reason>.[190] (See Table 6.1.) Putting the story in the first person is important, because it draws the team into imagining the client's situation. By saying, "As a such-and-such, I want...," one instantly imagines what it is like to be a such-and-such.
It's not that written requirements have to be abandoned. The goal of radical management is to find the right balance between documentation and discussion. Traditional management has focused far too much on producing abstract requirements and not enough on discussion aimed at understanding the client.
Table 6.1. Examples of User Stories
I Want <Goal> | So That <Reason> | |
|---|---|---|
As a parent, | I want a comfortable, affordable home | so that my spouse and I can raise our family. |
As the U.S. Congress, which funds the nation's defense systems, | we want a missile-launching submarine built in a timely fashion | so that we can be assured that the country is safe from nuclear attack. |
As the client of a boutique hotel, | I want a comfortable room with a personal feel to it | so that I have an unexpectedly stimulating night away from home. |
As the holder of a house insurance policy, | I want to know that the major risks to my family home are covered in case there is an unexpected catastrophe | so that I will not be financially destroyed by the catastrophe. |
As the user of a job search Web site, | I want to be able to find and apply for jobs that might interest me | so that I can find a better position than I currently have. |
Practice #9: Treat the User Story as the Beginning, Not the End, of a Conversation
When a user story is dropped into a traditional management setting, the likelihood is either that it will be instantly rejected (because it is a story) or that it will become an artifact, an instruction, a new abstract plan to be imposed on the team. It will be seen as a top-down, one-way communication. One part of the organization defines the requirement, and a different part implements it. Through the written document, the manager is giving an instruction, "Here's what to do," and the team is expected to do it without asking questions.
This type of boss-subordinate relationship with one-way communications is unlikely to create commitment on the part of those doing the work, particularly where the workers are at least as knowledgeable as the boss. Rather than feeling responsible for the success of the product or contributing new ways to delight the client, they will focus on what they have been told to do.[191]
Open-minded conversations have the opposite effect: the opportunity for everyone to participate elicits new insights and inspiration to contribute to the complex goal of delighting the client.
User stories are a way of shifting the focus from writing abstract requirements to discussing what might delight the client. A user story is a short, simple description of a need told from the perspective of someone who wants the product or capability. The written version of the user story is less important than the conversations surrounding the story. It enables the people doing the work to get inside the mind of clients and focus on what might delight them.
Practice #10: Keep the User Stories Simple, and Record Them Informally
Traditional managers visiting Toyota factories are often startled by the simple handwritten documents on which progress is recorded and lessons are learned and shared on single sheets of paper.[192]
Similarly, in the high-tech environment of software development, visitors are often surprised to find that instead of planning being done with sophisticated computer programs, user stories are typically displayed on handwritten cards or sticky notes and prominently displayed in the workplace itself.
Why this preference for handwritten paper notes ahead of computers? Computers are wonderful things, but when information is stored on a computer, it is available only when it is actually accessed and then usually only one person at a time. Moreover, once the information is in the computer, it tends to become a formal, fixed artifact, with all the risk of generating magical thinking that the plan is reality. Having handwritten notes, cards, and charts that are visible to all in the workplace and adjusted as necessary can be a constant reminder of the fluid nature of reality.
Using a lightweight, temporary form of recording like cards or sticky notes also serves as a constant reminder that the written version of the story is a starting point for a conversation, not the final word.
Practice #11: Display the User Stories in the Workplace
A board on which the stories are posted should be visible to anyone in the work space to show what is being worked on, what has been completed, and what remains to be done in the iteration. People can see at a glance where a project stands. The board on which stories are recorded becomes an information radiator.
Practice #12: Be Ready to Discuss the User Stories with the Client or Client Proxy
The story card serves as a catalyst for a two-way conversation between the development team and the client or client proxy. The team promises to talk to the client proxy before beginning work on the story; the client or client proxy has to be available when the team is ready to talk.
The user story is thus useful not as a thing in itself but as a catalyst for conversation. Those doing the work can get inside the mind of the client and figure out what might delight him or her.
The availability of the client or client proxy for conversation is important because it allows the team to accept work in an iteration without having resolved every issue. Similarly, the team's availability to talk to the client or client proxy helps remove concerns by the manager that every last detail must be written down.[193]
Practice #13: Find Out More About the Client's World
Crafting user stories requires knowledge of the context of the client. Becoming de facto ethnographers who visit and live with clients is part of the process of understanding their situation.
Usability expert Jeff Patton talked to me about his experience designing software that would be used by people receiving groceries at the loading dock of a grocery store:
I was building software that would be used in the backs of grocery stores—people who received items on the docks of grocery stores, using handheld devices. I didn't want to try to build the product without an understanding of that world. So I called the grocery stores and arranged to visit, and see what goes on at the backs of grocery stores. Because it wouldn't do any good if I understood and the team didn't, I grabbed members of the team and we went to a grocery store. We spent the day finding out what it was like receiving vegetables at the back of grocery stores. At the end of the day, we were better equipped to design software for people who received groceries at the back of grocery stores because we had lived that experience.
Similarly, when Toyota was designing the Lexus, it sent teams of its designers to California, to live in a beachfront house at Laguna Beach and breathe the world of country clubs, fancy restaurants, and golf courses so that they would understand what is important in that world.[194]
The recent emergence of narrative medicine, in which doctors are trained to listen to and understand the patient's story, is another illustration of the growing recognition of the importance of understanding client's story.[195]
Practice #14: In the User Story, Include a Test to Determine When the Story Has Been Fully Executed
So that you know when you are done, you specify in advance the test of what is meant by "done." The user story includes a test to determine when the story has been executed. In software development, an emphasis on testing is critical to delivering value to clients. The interaction of multiple computer programs is such that automated testing is typically built into the work cycle.
In less structured forms of work, being clear about the definition of completion is also important. Every user story should result in customers or clients who feel as if they have accomplished something.
Practice #15: Provide Coaching to Encourage Good Team Practices
Just as customers don't know what they want until they see it, teams don't know good work or team practices until they have experienced them. They may eventually discover them for themselves. However, the process of learning can be expedited if the team has access to good practices from within the team itself or from coaches outside the team.
A study at Yahoo! showed that the provision of external coaches had a high payoff in terms of team productivity.[196] Traditional management tends to ignore such studies, because the mental model is that the managers are responsible for productivity. The perspective of radical management is that the productivity of the team represents the very future of the organization. Skimping on coaching can be a highly counterproductive form of economizing.