Everyone Claims They Are Following 'Agile Methods' But Few Actually Do

When we talk with managers who are undertaking ambitious digital projects, we ask them if they are using agile methods. Many of them will say “yes, we’ve adopted agile already.” You’d think that would be an encouraging sign: when practiced well, agile methods can create exceptionally valuable and productive teams. But we’ve learned it most often reveals something quite different: that they aren’t using agile at all.

Agile development is not new. Highly evolved product development teams have been using it for upwards of two decades. Its project management framework owes much to lean manufacturing philosophies: it emphasizes customer pull versus management push and empowers self-organizing teams to improve how they work together.

It’s an elegantly simple method—and one that has begun spreading rapidly from engineering departments and into marketing, sales, finance, and even HR teams. But much can and does go wrong at every level of the organization, from the individual team member all the way up to the CEO. Which is why most companies, despite their intentions to adopt agile methods, often end up working in a way that doesn’t look much like true agile at all.

Let’s start in the middle. In large organizations, middle management can throw up some of the biggest roadblocks. Managers often refuse to dedicate people to a single project: “50% dedicated” is a common refrain, with no oxymoron intended. But most teams that use agile methods work in two-week “sprints.” They are required to create “potentially shippable” working products during each of these periods, a challenging feat. Without control of their time, team members cannot commit themselves to an agile-style sprint, creating unforeseeable dependencies and eroding team trust.

Middle managers can also miss the importance of co-locating teams by bringing together designers, engineers, product managers and content specialists in the same physical space. The most highly functioning agile teams aren’t just at the same location or on the same floor: they share the same table.

Agile methods also involve building the thinnest possible slice of the product and putting it in the hands of real users as soon as possible, to test and validate assumptions. Middle management can miss the value of this approach. Blocking team deployments with corporate anxiety about what is “right” (or what they think the boss wants) prevents teams from learning with customers, who these days want to be part of a brand’s evolution and not just passive consumers.

Failure to fully embrace agile methods isn’t always the fault of management. Individuals can struggle with the culture of agile teams. Agile favors so-called T-shaped skills: people with deep expertise in one area and broad interest and a willingness to learn across many skill sets. Holding on too tightly to one’s sole area of expertise, no matter how deep, compromises collaboration, breeds resentment, and reinforces a delegation of responsibilities that must actually be shared by the team. It also forecloses on a culture of learning which agile can otherwise inspire. We have seen copywriters who take on coding tasks, designers who start to write and developers who unblock the team with hidden diplomatic talents.

Perfectionism can also be a problem if it conflicts with the team’s quality standards. “Perfect is the enemy of better” is a core adage of agile methods. For some experts, especially designers, this can be a deal breaker. It’s not that craftsmanship is jettisoned; the bar for “good enough” can be set as high as the team determines, but it must be a shared determination and not an overly private one.

Agile is a true democracy. It requires consensus building, and teams must nurture a culture of honest feedback. When things go wrong, they need to be discussed. If people are unhappy with certain dynamics, they need to be surfaced. If there are unspoken hurdles that are hindering the team, they must be put on the table. Sprint retrospectives facilitate this kind of dialogue. Teams who do not take them seriously often suffer from hidden resentments and poor morale—a kind of team-level depression that prevents creativity and throttles effectiveness.

Even with supportive middle management, passionate and inspired individuals, and highly functioning teams in place, there is one level of an organization that can seed the most pervasive hurdles: upper management, including the CEO. Too often executives give lip service to agile but are only invested in a superficial sense of it being a way to work faster—an industrial-era measure of success whose value is dwarfed by the potential for teams to work smarter.

If a company wants to build products based on what features a customer wants (and in what order they want them), its executives need to stop pushing their own ideas from the top down. All too often, however, the drive for sales and profit growth gets translated into directives that are then driven through management chains, reinforcing what one organization we have worked with labels “executive-driven innovation” (another oxymoron). This top-down behavior undermines team autonomy, degrades morale (“shit rolls downhill”) and blinds the organization to the signals from customers they might otherwise become more responsive to. Even agile transformations tend to happen as executive mandates—a contradictory state of affairs for a philosophy of work that relies fundamentally on self-managing teams.

So what is it that we want to hear in our conversations with managers about agile? How about this: “we are trying. It’s hard. We’re getting better at it … I think.” That kind of humility is a real sign that a company is embracing the agile spirit of continuous learning and improvement. We are all of us only as good as our last sprint.