Becoming Agile Rapidly and Painlessly

By: Langdon Morris

To take advantage of today’s and tomorrow’s unique opportunities, and to rise above the intense existential challenges your firm will face in the months and years ahead, it will be supremely helpful and confer enormous advantages if your operations embody the Agile essence: quick, responsive, dynamic, innovative. You’ve got to learn to recognize opportunities and to act on them faster than your competitors do. In this chapter excerpt of Agile Innovation Langdon Morris explores what Agile means in detail, with a focus on the roots of the Agile movement and its many insights and implications for today’s organizations.

The Agile Software movement was initiated in 2001 by a group of 17 programmers, who, it turns out, have significantly changed the world by inventing a new way of organizing work.

They wrote a humble but ultimately wildly influential document called “The Manifesto for Agile Software Development.”

Composed of four simple statements, these axioms express the core values of their system for getting work done:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to value:

• Individuals and interactions over processes and tools.
• Working software over comprehensive documentation.
• Customer collaboration over contract negotiation.
• Responding to change over following a plan.

While there is value in the items on the right, we value the items on the left more.

From this simple vision the Agile Movement was born.

It is, in essence, a social phenomenon, and it has proved to be a brilliantly simple way to organize people to get useful work done.

Because Agile was invented to help manage software programming projects, you might logically infer that its principles and practices are useful only or primarily in technology, but in fact the relevance of Agile is much broader. Its insights and principles are applicable to nearly every kind of complex project that involves creativity and uncertainty, which exactly describes what innovation is all about.

So, what can we learn from Agile about getting innovation work done faster and better? Agile offers insights across the full scope of innovation management themes, ranging from generating ideas to managing people, monitoring progress, assigning work, tracking work, optimizing time, structuring work, defining roles, and even facilitating the process itself.

Furthermore, there are also broad implications across the full range of operational issues that relate to the way we think about and operate entire organizations.

Consequently, in the sections that follow we deconstruct the four major axioms of Agile to explore a set of social conventions that explains how individuals, teams, and entire organizations can produce the very best outcomes across an enormously broad range of work processes and roles in the domains of innovation and beyond.

Individuals and interactions

The first axiom reflects the view that the success of any project depends on the quality of the team, both as individual team members and in their capacity to work effectively through efficient and productive collaboration.

Although processes and tools can provide guidance and support for competent people to work effectively, nothing is more important than solid thinking and meaningful collaboration when it comes to creating something new.

But why did the Agile creators put this axiom first?

Agile was created as a response to business trends of the 1990s, a time when business leaders focused on process improvement as a panacea for all the ills that afflicted large corporations. A new term was invented, business process reengineering, and the associated acronym BPR became an accepted and widely used buzzword.

The BPR approach was hugely popular, and author and consultant Michael Hammer even persuaded Peter Drucker to provide a gracious quote for the cover of his mega-best-selling book about how important reengineering was.

The pendulum went a bit too far in this direction, however, as some business leaders came to have more faith in their processes than in their people, and tried to reengineer, automate, and outsource their way to ultra-stability and ultra-profitability. This was a cheerful way of saying that it didn’t matter if your people were marginally (or significantly) incompetent, as long as your process was correctly structured.

That path might have worked out just fine if business conditions at the time had perpetually stayed the same. However, busts followed booms, new technologies emerged, globalization accelerated, and now, two decades later, we’ve seen wave after wave of disruption in many industries, while the search for process-driven excellence and stability has proved fruitless. How did all those perfectly reengineered companies fare? Some, especially the innovators, did very well; many of the others, particularly the non-innovative ones, collapsed.

The harsh lesson from the reality of the rapidly changing world was, and is, that survival and success are based on brilliant new ideas and the capacity to build and market great products and services much more than on engineered and reengineered processes. Success also requires dedicated and motivated people—engineers, designers, craftspeople, managers, executives, everyone in every functional role—who are filled with genuine passion for greatness, who possess the intrinsic competence and character to pursue it resolutely, and who work in ways that allow their talents to flourish and produce results quickly.

Who has the right stuff?

Logic and experience both tell us that having the right people involved in the right projects is critical to success. But who are the right people?

In our view, they’re the ones with both exceptional technical ability (domain expertise) and who demonstrate effective, self- disciplined behavior.

In his marvelous book, Software Engineering Economics, Barry Boehm proposes the principle of top talent: “Use better and fewer people.” He summarizes: “The top 20% of people produce about 50% of the output.”

The top 20% of people produce about 50% of the output.

Hence, Agile Innovation suggests that you seek out the 20 per- cent and consider leaving the rest entirely behind and that you take very seriously the aphorism that in the long run, and even in the short run, every less-than-competent person on your team will end up costing you a lot of time and even more money.

This is precisely the reason that Steve Jobs had zero tolerance for any but world-class talent. There was no gray scale for Jobs— either you were A-team material, or you were a complete bozo who should be kept as far away from Apple as possible.

Working innovations

The second axiom of the manifesto—“Working software over comprehensive documentation”—moves the effort away from the production of voluminous documentation and specifications of questionable value and instead toward rapidly and continuously delivering actual value and working software.

The conventional approach—the massive design documentation effort ahead of any actual programming—originated from management’s need to exert control over massive software projects that carried commensurately huge risks. To avoid huge mistakes, project teams were tasked to spend months, sometimes years, front-loading a monumental design process. They exhaustively gathered requirements, proposed elaborate system architectures, and designed and then redesigned the associated business processes (and reengineered them). Teams worked by proceeding in a logical and linear fashion and with little to no feedback from the front line, or from customers and users.

Despite these efforts, many projects were still resulting in massive failures, such as the acutely painful ones we noted in Chapter 1.

Even when the products did work, many of the ones intended for commercialization were completed long after the market window had shut, long after customers had become frustrated to the point of fury, and long after the analysts had totally lost faith. By then, the company’s credibility had evaporated.

The Agile Innovation variation on this axiom requires the change of but one single word—from software to innovations and becomes “working innovations over comprehensive documentation.”
In the innovation world, voluminous business cases are much less useful than prototypes of actual working products or services or new business models.

Why is this?

When customers and stakeholders can see your offering, or even a prototype of it, with their own eyes, touch it with their own hands, and experience it with all their senses, then they can give you the meaningful feedback you need, enabling you to learn the most about what’s ultimately going to work and what’s not.

• Does it work the way you intended?
• Will it change the customer’s life?
• What is appealing and not appealing?
• What needs to be improved?
• What’s the next step in design?
• In development?

Learning quickly, the most quickly, is the core and essential goal, particularly in highly competitive markets where speed often wins.

Thus, do we prefer spending six months on research and program planning, followed by six more months of architecture, and then a year or two of coding, product design, or business model construction, all to find out that the product concept doesn’t appeal to customers? Or are we much better off finding out what is critically important within two months?

Preparation of exhaustive administrative documentation must never be a substitute for clear thinking and quick action.

Of course these two-month prototypes will be very rough, and a great deal of further refinement and development will be necessary before they can be considered in any way ready for the market. Because Agile Innovation is about rapid-cycle, iterative development rather than getting it perfect the first time, this trade-off makes perfect sense.

Getting quickly to working products does not preclude the need for some degree of documentation, of course. But preparation of exhaustive administrative documentation must never be a substitute for clear thinking and quick action. Documents do indeed support communication and collaboration, and they are essential tools to enhance knowledge transfer, preserve historical information, assist ongoing product enhancement, and fulfill regulatory and legal requirements.Administrative processes are also necessary, but they have a lower priority than the imperative to get something working, test it, learn from it, and move forward.

By Langdon Morris

Excerpted with permission of the publisher, Wiley, from Agile Innovation: The Revolutionary Approach to Accelerate Success, Inspire Engagement, and Ignite Creativity by Langdon Morris, Moses Ma, and Po Chi Wu. Copyright (c) 2014 by Innovation Labs LLC. All rights reserved. This book is available at all bookstores and online booksellers.

References:

1. Beck, Kent, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin Fowler, James Grenning, et al. “The Manifesto for Agile Software Development.” Agile Alliance. February 2001.
2. Hammer, Michael, and James Champy. Reengineering the Corporation: A Manifesto for Business Revolution. New York: Harper Business, 1993.
3. Boehm, Barry. Software Engineering Economics. Upper Saddle River, NJ: Prentice Hall, 1981.