Simplify

If you want to be fast and agile, keep things simple. Speed isn't the result of simplicity, but simplicity enables speed. [7] If you want to be slow and rigid, pile on the bureaucracy. A friend who once worked for NASA relayed the story of his team's unique software design criterionleast impact on documentation. The documentation revision process was so onerous and time consuming that minimizing the documentation changes became the major design objective. This is a clear example of how compliance work not only impedes delivery by draining away engineering time, but also undermines technical design decisions.

[7] Colleague Luke Hohmann has a speed-oriented catch phrase that he shared with me: "When you want your boat to go fast, it is easier to cut anchors than add horsepower."

When you simplify processes by taking out the detailed tasks and compliance, you force people to think and to interact. Neither they nor their managers can use structure as a crutch. While some structure aids agility, the overabundance of structure in many organizations gives people an excuse not to think, or bludgeons them into not thinking. Either way, people feel their contributions are devalued, and they lose any sense of personal responsibility or accountability for results.

Generative Rules

The epitome of simple rules lies within Nordstrom's employee handbooka 5x8-inch card that outlines Nordstrom's goal of providing outstanding customer service and lists the company's rules:

Rule #1: Use your good judgment in all situations. There will be no additional rules (Collins and Porras 1994).

Simple principles (or rules) are one facet of "swarm intelligence" from complexity theory. This is the idea that the right set of simple rules, applied within a group of highly interactive individuals, generates complex behaviors such as innovation and creativity. Jim Donehey, former CIO of Capital One, used four rules to help ensure everyone in his organization was working toward the same shared goals:

1. Always align IT activities with the business.
2. Use good economic judgment.
3. Be flexible.
4. Have empathy for others in the organization (Bonabeau and Meyer 2001).

Do these four rules constitute everything that Donehey's department needed to do? Of course not, but would a 400-page activity description get the job done? What Donehey wanted was bounded innovationa department that thought for itself in a very volatile business environment, but also one that understood boundaries.

Principles do not define activities that a development group should accomplish. However, the right set constitutes the minimum set of rules that bound innovative and productive work. They create an innovative environment by specifying a simple set of rules that generate complex behavior. APM, for example, doesn't include a configuration control practice. It assumes that when a team needs configuration control, it will figure out a minimum configuration control practice and use it. Agile methods don't attempt to describe everything that any development effort might need in thousands of pages of documentation. Instead, they describe a minimum set of activities that is needed to create swarm intelligence.

Developing a useful set of rules is not a trivial exercise, since the right combination can often be counterintuitive. Apparently minor changes can have unforeseen results. Changing one practice, without understanding the interactions and the concepts of swarm intelligence, can cause an agile system to react in unforeseen ways. The guiding principles of APM, and its practices, constitute a set of rules that have been shown to work together well.

Barely Sufficient Methodology

When deciding on process, methodology, practices, documentation, or other aspects of product development, the admonition to simplify steers us toward a bare sufficiency, toward streamlining, toward implementing "a little bit less than just enough." Simplicity needs to balance the need for speed and flexibility with retaining enough stability to ward off careless mistakes. Barely sufficient does not mean in sufficient. It does not mean "no documentation" or "no process." Furthermore, barely sufficient for a 100-person project will be very different from barely sufficient for a project of only 10 people.

John Wooden's admonition to his basketball teams seems appropriate here: "Be quick , but don't hurry." As author Andrew Hill (2001) recounts his playing days with Wooden, he enriches the meaning of the phrase "Life, like basketball, must be played fastbut never out of control." In product development, lack of quickness results in competitive disadvantage , while hurrying causes mistakes. Balancing, one of the keys to agility, was part of Wooden's coaching technique. As Hill writes , "Wooden's genius was in helping his players find and maintain that razor's edge between quickness and hurrying." Finding that razor 's edge isn't easy. If it was, everyone would be doing it.

An engineer who hurries to design a feature but fails to adequately review or test it creates defects that ultimately slow the project. Delivery activities done quickly and effectively speed projects, while overemphasis on compliance activities act as a speed break. Selecting the activities that absolutely , positively have to be done, and doing them well, contributes to quickness. Sloppy execution of those key activities can be the consequence of hurrying.

One of the competitive advantages of finding this balance, of being quick without hurrying, is that it often forces the competition into hurrying. This is actually one of the potential dangers of implementing agile project management and development approaches. Less disciplined organizations and teams may confuse quickness with hurrying and misunderstand the foundational work, experience, and dedication it takes to balance on the edge. Wooden used the fast break to increase the tempo of the game enough that the opponent was pressured into hurrying. Because of his team members ' discipline and work ethic , they could play faster than opponents but still be in control. Project teams can use the same strategy.

New product development teams inhabit a world of growing complexity, developing ever more complex products while being bombarded with a bewildering array of information. Leaders who can coax simplifications out of the complexity, who can institute just enough process, who can find that razor's edge between quickness and hurrying have a much better chance of success.