Manage Learn to apply best practices and optimize your operations.

Accelerating businesses with agile development

Want to become a better leader in agile development projects? This chapter from Stand Back And Deliver, will teach you excellent approaches to everyday programming issues.


In this chapter, we explain what we mean by "stand back and deliver" by presenting some situations that may seem...

alarmingly familiar to you. We then cover some of our core concepts and beliefs that underlie the tools we recommend you implement to get your organization going in the right direction.

What Could Go Wrong?

Have you ever done things by the book, but the book was out of print? Such was the case for a large, successful product company. This company had developed what it considered to be a revolutionary new product. With its heavy engineering background, the company did product development by the book-the way it had worked many times before.

Through its research and development activities, the company had dis-covered that it could use a waste material as the basic raw material for a new product. Imagine the possibilities: Currently the company pays to dis-pose of this material, but now it could use this "waste material" to make an industrial product. The company did what it had always done. It selected one of its best engineers to sort through the product design and manufac-turing options. It set up the engineer with all of the development and test-ing equipment he would need. It gave the engineer the time and flexibil-ty he needed to design what he thought the market needed.

Information on this title:
This chapter  introduced the issues involved in involving the right players in your  organization to gain a competitive advantage. It also introduced the framework  of concepts and tools for doing so. For more information on this title click here Stand Back And Deliver 

Within a year, the engineer had perfected a formulation that worked. The resulting product had impressive characteristics. It had high worka-bility and could be formed into various shapes and sizes. The engineer pro-duced small batches of the product that the company used to generate early customer interest. Using these small batches, the company formed several industry joint ventures and alliances. The future looked bright.

The engineer next worked on the manufacturing processes needed to produce the product. In parallel with this effort, the company issued press releases and featured the new product in its annual report: "Coming soon, a revolutionary, green product." One year later, the engineer announced that his work was done. He documented the product formulation. He described in great detail how to scale the manufacturing process from the small batches he had created to full-scale production. The company built the first of what it planned would be multiple manufacturing plants and hired a plant manager to follow the engineer's scale-up process. In the meantime, the market waited for the formal product release. The company hired a dedicated sales force to start generating interest in the product. The development engineer was promoted and assigned to a different project.

Five months later, the first manufacturing plant came on line. As the first full-size batches of the product came out of processing and into pack-aging, problems arose. When subjected to full-sized manufacturing, the product had tiny cracks. In the small batches prepared by the development engineer, there had never been any cracks. In expanding the product batch size by a factor of 10, however, there they were—tiny cracks. At first, no one gave the cracks much thought, because they did not affect the product characteristics or performance. But then the company shipped its first order. As the delivery truck rolled down the road, the cracks propagated throughout the product. By the time the truck arrived at the customer's facility, some of the product had broken into pieces. After two years of engineering and five months of manufacturing scale-up, the company had a great product, so long as it did not have to ship the product to anyone!

In retrospect, it is easy to identify some of the mistakes this company made. We have spent hours with groups dissecting this true story to learn from-and to not repeat-the mistakes of the past. The development engineer developed the product in isolation and did not think through scale-up issues. The company did not produce any full-sized product samples until after it had built the manufacturing plant and then discovered the propagation of the cracks. It is easy to mock management for the wasted investment.

Before being too critical, however, we should consider this point: If the final product had not developed the tiny cracks that spread during shipping, the product and the process would have been a success. In fact, many times previously, the company had used a similar process and gotten good results. Using what had worked before, those involved in this project were clueless about the risks that lurked in the shadows of their process. What is now obvious to us became obvious to them only after this product failure.

The most important lesson we can draw from this story is that we, too, are brilliant but sometimes clueless. We live in an environment of increas­ing global competition, an increasing pace of market changes, and a need to develop solutions that are increasingly complex. In this environment, we do not have the luxury of missteps and hidden risks. There is increasing pressure to deliver complex solutions in less time and to get it "right the first time." If we don't, we can completely miss our business value goals. The good news is that we can make sure that our brilliance results in things that work. To see how, we continue our story.

What Went Right

With the development engineer assigned to and buried by a new project, it fell to the plant manager to sort out the issues with the propagating cracks. Fortunately, the plant manager recognized that what had worked before had not worked for the new product. Before he plunged into root cause analysis on the cracking problem, he took a huge step back, all the way back to the beginning.

Under pressure to immediately solve the problem, he asked to meet with company management. At the meeting, he asked some fairly basic questions: "How important is this product to the company? Is this a product that will provide us with a competitive advantage in the marketplace?"

His rationale for asking these questions was to get a sense of the purpose of the product. If the product would generate competitive advantage, he and the company would treat the product differently than if it did not.

The plant manager got very clear answers from the management team. This was a product that fit squarely in the company's strategy. The company's claim to fame was using recycled, recovered raw materials to produce industrial products. This product was a perfect example of the company's expertise and creativity.

In that case, the plant manager asked, could he treat this product as what it was-something that would help differentiate the company in the marketplace? Recognizing, in retrospect, the problems with the initial development, the management team gave the plant manager free rein.

The plant manager started by convening the right people. The right people included design engineers, production workers, manufacturing engineers, a sales team, and, in a surprise to everyone, one of the early-adopter customers. To make sure that the team understood all that had happened and all that needed to happen, the plant manager gave a painfully honest review of the development of the product and the issues the company had encountered in moving to full-scale production.

After getting the team up to speed, the plant manager asked a gut-wrenching question: "Can we fix the problems or would the company benefit more if we halted production?" This sparked a lively discussion that ranged from necessary changes to the product development process to the humiliation of now shutting down the product line.

The plant manager let this "airing" continue for some time but then refocused the discussion on his question: "Let me ask my question another way: What made this product so critical to us when we launched the initiative?" The answers again ranged from the product's revenue potential to the commitments that had been made. The plant manager then asked a more generic question: "How do we differentiate ourselves in the marketplace?" The company had developed proprietary ways to use recycled products to make new materials. This capability had propelled the company to market-leader status. An engineer asked, "Why does that matter?" The plant manager responded, "It seems to me that if we can solve the issues, this product aligns perfectly with what makes our company unique. With this product, we have once again taken a waste material and produced something of value. For that reason, it seems we should do our best to fix the problems and get this product to market. This product exemplifies what we do. If you agree, let's move onto how we can approach the product. Ignore how we have developed the product to date. As a strategic initiative, what should we do?"

About the author
Pollyanna Pixton is an international collaborative leadership expert who has developed models for collaboration and collaborative leadership throughout her 38 years of working inside and consulting with corporations and organizations.
Niel Nickolaisen started his career in engineering, but then got involved with process improvement methods such as Lean and Six Sigma.
Todd Little is a chemical engineer turned petroleum engineer who has been developing software products for more than thirty years.
Kent McDonald has nearly fifteen years of experience as a project and program manager in a variety of industries, ranging from automotive to financial services.

The team then sorted through the specifc product features that made the product different. Only one was apparent—the use of waste material to make a usable product. With that as the principal requirement of the product, the team identifed design options that could either eliminate or mitigate the full-scale production issues. Would a different form factor reduce the cracking? Or was changing the manufacturing process the only option? As the team discussed these alternatives, they associated complexity and uncertainty with each alternative. In terms of uncertainty, was there a specific market need that their product could meet? With what certainty did they understand these needs? Which form factor would the market accept, and did they know which forms were acceptable? How much did they know about the reactions taking place in the manufacturing process? How well could they link cause and effect? In terms of complexity, which options did they have to simplify the process? How could they simplify the product?

After the team mapped out the options and associated information, the plant manager asked the team which decisions they needed to make now, which decisions they could delay, and what they needed to know prior to making the decisions. All of this information was combined to provide a logical, rational approach for making the product go/kill decision and, if possible, fixing the product problems.

For example, the team could delay the go/kill decision until after the members had determined whether there was a form factor the market was dying to have. Likewise, the team could delay research into the cause of the large-batch cracking if the market would accept form factors that could be made with small batch sizes. To explore these issues further, the team members signed up for the assignments that best matched their interests and capabilities.

Over the next few weeks, the team worked through the assignments and options. Based on the work of the sales team and the early-adopter customer, the team revised the form factor. The new form factor actually met a previously unknown-at least to the company market-need. Revising the form factor enabled the company to manufacture the product in the small batch sizes it could produce without cracks. Taking this approach let the company retain most of its current investment in the manufacturing plant; it just needed to redesign its consumable molds. The team members took a more measured approach by eliminating uncertainty and complexity at each step of the process. They solved the problems they could when they could and postponed work on the most uncertain and complex issues.

Because the product was not "right the first time," the expected revenue was delayed. Also, because of the initial problems, the revenue stream grew more slowly than projected. Nevertheless, the company learned the value of the foundation tools of agile leadership.

Why Do We Do This to Ourselves?

We were all sitting around one afternoon talking about this story. Each of us found ourselves identifying a different aspect of the story that we thought was the cause of all the travails of the organization.

We identified the initial failure of the organization to properly align its approach to the project with its true strategic nature. We also determined that, initially, the organization did not properly lead collaboration; in fact, it did not initially have any collaboration on this particular project.

We found that the organization chose the wrong approach for the project, tackling a very complex project filled with uncertainty with a process more suited for a low-complexity and low-uncertainty project. It also assigned a leader who did not recognize the uncertainties and the complexities.
We realized that the organization did not gather all of the information it needed to make proper decisions about how to market the product and in which markets to sell the product. We also identified several cases where the company made commitments earlier than it needed to, especially with potential customers and industry partners.

As we talked about this case more, we realized that there was no one cause for the project's initial problems, but rather several contributing fac­tors. When we discussed the various tools we would have used to help the company, we realized that while each tool was powerful in its own right, when put together the entire toolset could really help an organization succeed.

A Framework of Effective Tools

What are the tools we would use to address the situation described earlier in this chapter? Through our experiences and sharing stories, we found that a collection of tools apply to how organizations approach their work, especially work that involves change and innovation; when used in moder­ation and in conjunction with each other, these tools can have a dramatic impact on the success of the organization. We drew the "napkin drawing" shown in Figure 1.1 to capture our thoughts, and we chose to organize this book around four main applications of those tools.


The Purpose Alignment Model, described in Chapter 2, generates imme­diately usable decision filters that leaders and teams can use to improve design. This tool evaluates business activities and options in terms of their capability to differentiate an organization's products and services in the marketplace and their mission criticality. This tool helps teams identify areas to focus their creativity and those activities and features for which "good enough" is good enough. This approach lowers direct and opportu­nity costs and accelerates market leadership. This simple, yet powerful, concept recognizes that not all activities should be treated in the same way. Some activities will help the organization win in the marketplace; others will help keep it in the game. We risk under- and over-investing in activi­ties if we treat all of them as if they were identical.

FIGURE 1.1 Leadership tools for use in today's complex marketplace

Here are the big ideas of Chapter 2:

  • Aligning on process purpose is a smart, simple way to improve deci­sion making.
  • Designing our work around process purpose helps us quickly iden­tify how to achieve optimal business value.
  • Strategic decision filters can be cascaded throughout the organiza­tion to dramatically improve organizational alignment.


As the proverb states, "No one of us is as smart as all of us." The proper use of the tools described in this book is dependent on a culture of collaboration. In the story presented earlier in this chapter, when a single person developed a product, it took more than two years to produce something that did not work. When a leader considered purpose, business value, uncertainty, and complexity in a culture of collaboration, the team made better decisions and started to generate results. Developing collaboration skills and capabilities is essential in today's dynamic marketplace. Sustainable innovation comes through collaboration. Sustainable innovation is a prerequisite to change from market follower to market leader. Today, it hinges on collaboration.

Here are the big ideas of Chapter 3:

  • To develop a sustainable competitive advantage, unleash the talent in your organization to deliver innovative ideas to the marketplace and to improve the throughput and productivity in your organizations.
  • The answers are in your organization.


    Delivery is the ultimate measure of success. Any experienced leader knows that all projects are not created equal and no single approach is applicable to every project. The tool described in Chapter 4 provides a practical model for evaluating uncertainty and complexity as well as guidance for tai­loring an appropriate leadership approach. The characterization of uncer­tainty and complexity also correlates to project risk, and we provide a roadmap for potentially reducing risk. For example, it is possible to break projects that are both highly complex and uncertain into components with lower uncertainty and risk. This process reduces the overall project risk. An understanding of complexity and risk also allows leadership to match the skills of project leaders to the needs of the project.

    Here are the big ideas of Chapter 4:

    • By understanding the uncertainty and complexity characteristics of your projects, you can identify better ways to lead those projects.
    • High complexity or uncertainty correlates to higher risk. Reduce these factors, and you reduce your level of risk. Project decomposi­tion can reduce complexity, while incremental delivery helps lead a project through uncertainty.
    • Some leaders are natural managers of complexity, while others are experts at uncertainty. Match leadership styles to project character­istics, and develop leaders' skills to broaden their capabilities.


    The tools we describe in this book will help you to make the key decisions you face on a regular basis, but we felt it important to discuss the actual approach to decision making. Knowing when to make your decisions and which information you need to make those decisions is very important. Chapter 5 introduces the value model tool, which provides a structure for organizing information—such as purpose, considerations, costs, and bene-fits—that you can use to aid your decision making.

    Here are the big ideas of Chapter 5:  

    • Business decisions focus on delivering value to the organization and to the marketplace. Life is much better if everyone in the organiza­tion understands what generates value and makes decisions that improve value.
    • You can develop a value model that helps you make better decisions, but this model is not just a calculation that generates a numerical value. Instead, it is a conversation that you should revisit often, especially when conditions change.

    The Leadership Tipping Point

    While we describe each tool on its own and provide plenty of examples of when those tools are useful, we knew this treatment would not be com­plete without describing how you can put our tools to work as a leader, addressing the issues of how and when to step back and how and when to step up without rescuing your teams. This is the big idea of Chapter 6, which we call the leadership "tipping point."

    Leaders can stifle progress when they interfere with team processes. At the same time, as a leader, you don't want to go over the cliff and deliv­er the wrong results. Sometimes leaders should stand back and let the team work—and sometimes leaders should step up and lead. In Chapter 6, we discuss how you can decide which situation you face.

  • This was last published in July 2009

    Dig Deeper on Agile Software Development (Agile, Scrum, Extreme)



    Find more PRO+ content and other member only offers, here.

    Start the conversation

    Send me notifications when other members comment.

    By submitting you agree to receive email from TechTarget and its partners. If you reside outside of the United States, you consent to having your personal data transferred to and processed in the United States. Privacy

    Please create a username to comment.