How to Become Agile Outside of Software?

At a technology company, the CEO called the VP Sales in and say, “I want Sales to be more like the tech team.”

Wait, what? Technology teams as the model of behavior?

Indeed, that’s becoming more and more the case, because Agile development teams — now common in tech — have a different impact on business. They work with the whole product in mind, make more strategic trade-offs, are more transparent and responsive, and so on.

So how does a non-software group/department/unit adopt Agile?

Here are common approaches, which are sometimes combined:

• Formally switch the team to using a well-known method, such as Scrum or Kanban.
• Copy practices from tech colleagues: have sprints, hold daily standups, represent work as user stories.
• Start managing the team’s workload in an Agile management tool or with stickies on a board.
• Get an Agilist from tech to give occasional advice or feedback on the new implementation.

Doing the research for my book Agile for Non-Software Teams I learned how rarely the first three options turn out to be successful. The fourth option succeeds to the extent that the person is available and doesn’t impose the first three options. But why is that? Aren’t these good ideas?

The primary reason these approaches aren’t always successful is that the human system that does the work must undergo a fundamental change. Taking on Agile means starting to value (optimize for) different things: responsiveness vs. predictability, outcomes vs. outputs, people vs. standardization, and treating customers as partners rather than as a source of requirements. Adopting tactics alone rarely brings about a change in the value system.

Another reason is that context is everything. The landscape — business, work, personalities, needs, objectives — all call for custom tactics. No practice can be universally best; for every so-called “best practice” there are teams that tried it faithfully and it didn’t work well in their context.

A third reason is the adoption strategy. We know from 20 years of Agile in software that imposing it on unwilling people is usually a non-starter. We also know that implementing it from a standpoint of certainty and inflexibility — knowing exactly how it should look and expecting the transition to be “one and done” — often ends in mediocrity or a bounce-back.

If your team doesn’t make software but you want to be more Agile, what can you do?

Start by understanding your motivation for a different way of working. Which business outcomes do you want to accomplish? Which problems will you solve by working differently?

Next, compare and contrast the Agile approach with your team’s current way of working. Not on the tactical level (practices, roles, artifacts, meetings), but on the more fundamental level of choice-making and values. With this clarity, is Agile an appropriate and compelling choice for the outcomes you want?

Involve your team in this thinking about ways of working. What problems are they seeing? What’s worrying them? What kinds of change are they yearning for (or anxious about)? Are they willing to give it a try? What will make the experience safe for them? Consider your managers and stakeholders as well. How will you interact with them differently? Will they support your efforts, merely tolerate them, or hold you to non-Agile values?

If you’re intent on embarking on an Agile journey, envision it as a series of increasingly larger experiments. Apply it first to a portion of the work where it seems appropriate, is safe to try, and will provide good learning. Decide what you’ll optimize for in that area (for example, adaptation and customer collaboration), choose a few operating principles (for example, team ownership and minimizing work in progress), and design a simple process to implement your choices. Do all this with your team, so they own their methods. You might use your tech colleagues’ methods as a source of inspiration, but there’s no need to copy what they do. Do what’s right for you, reflect on it frequently, and adjust based on the results.

Is this approach slower and more work than basing it on prepackaged or colleagues’ solutions? Somewhat. Does it have greater unknowns for you? Probably. Yet, growing Agile organically to fit your context has a higher chance of “sticking,” making your team happier, and delivering good results. You might find it a lot more exciting too!