Often when we work with product and engineering teams to improve their processes we also end up talking with executives that aren’t directly involved in building the product. Of course, products are not built in a black box — you cannot adopt the good thinking that has gone into Agile practices without having organizational buy-in. But many product teams struggle to get executives to see Agile thinking as more than just an engineering practice.

We put together a short presentation hitting some of the key tenets of Agile specifically for a non-engineering, non-product audience. The presentation has been well received, so we’re sharing it here in case it’s helpful for your organization.

The vocabulary of Agile does more harm than good. In helping companies adopt Agile methods we find we need to correct mistaken impressions people have gotten from Agile literature. Our first task is often to help them unlearn unhelpful language so that they can set the right goals and get buy-in from teams. As George Orwell wrote in his famous essay, “Politics and the English Language,” “language can also corrupt thought. A bad usage can spread by tradition and imitation even among people who should and do know better.” Perhaps Agile is dead, but in any case it’s definitely time for a new product development vernacular.

Teams that are new to Agile are particularly susceptible to flaws in the lexicon, often getting the wrong impressions about why these practices might help them. We’ve seen teams go from openly hostile to embracing Agile practices when we get them past the literal meaning of the words, so let’s stop needing to explain so hard and start getting a better set of words to use.

The worst words we use…

“Sprint”

A sprint implies a furious run as fast as you can over a short distance, after which you are out of breath, sweaty, and generally spent. Agile is supposed to be the opposite of that. We want a regular rhythm – not death marches to hit arbitrary deadlines, not idle time waiting for monolithic product requirements documents to get finished. Many teams want “going agile” to make them faster – a goal that is counterproductive and ultimately damaging to success. The theme of speed is woven throughout the Agile lexicon, and it has not served product people well. The language should imply doing work on a regular cadence in intervals short enough to allow for confidence in estimating what we can get done but long enough to allow for meaningful progress in each cycle. I prefer words like “cycle” or “interval” or “period” or “stretch” (I don’t care for “iteration” because it often implies for too many people that we will only ever make small changes).

“Velocity”

In an ideal world teams are relatively stable from cycle to cycle and have a consistent level of productivity. The point of velocity is to give us a reflection of the amount of work we can expect to produce as a team over a known period, so it’s seductive. But teams are rarely ideally configured, and how many points we get done can vary widely. Even when we are producing at a consistent pace the implication is still that we’re measuring speed, and it’s hard to resist the temptation to want to go “faster,” especially since we’re measuring our velocity with a number (assuming we’re using story points).

Velocity, as a quantifiable measure of productivity, is destructive to the goals most teams set out with in changing their processes. Managers tend to want to increase velocity by doing things like giving bonuses for getting more story points done. That attitude is profoundly misguided, not least because of the obvious corruption of incentives when teams are given reasons to inflate points or otherwise come up with a larger aggregate number for its own sake. What we actually want is frank assessments of relative difficulty in order to accurately and confidently gauge what we can get done in a given cycle. When velocity is corrupted to be something other than a means to achieve decent estimates (and thus commitments) it has a net-negative impact on producing good software.

I much prefer words like “capacity” or “load” that get us away from thinking about speed and the sensation of hurtling to the finish line and towards thinking about how we can do our own reality check on the work we commit to do.

“Backlog”

Backlog isn’t nearly as bad as sprint or velocity, but it isn’t great. The biggest problem is that in other parts of life we don’t want backlogs – the word implies things that are piling up, undone. It implies chores you have been putting off, things that stress you out because they are backed up. Constipated. We don’t have a “backlog” in any other domain that we are looking forward to tackling, so why use that word in our work? How about “pipeline”? We like to have a healthy pipeline of things. Or perhaps “slate” or even the very broad “board” as a more general list of things we’re currently focused on.

“Story”

The formal structure of common templates for user stories can be very useful. We’ve seen lots of people embrace the “As a… I want to… So that…” model with good results. That said, we’ve also seen a lot of product managers get very hung up on trying to write a “story” because that word implies a lot of structure and skill, not to mention just sheer word count. We would prefer the artifact use as few words as needed, and we find that over time teams start to find the formal structure to be cumbersome. If we have developed short-hands through conversations, that’s exactly what we want, and feeling pressure to make each line item a “story” with a narrative structure can be counter-productive. Call me old-fashioned, but I think “ticket” works well because it’s fairly general, cognitively allowing for a wide range of granularity. Some might prefer “feature” as distinct from bugs or tasks.

“Scrum Master”

The role of Scrum Master is the most problematic for organizations making a transition to Agile processes. Much of the difficulty has nothing to do with the name, but the name does carry unnecessary baggage into the discussion of what a Scrum Master does and why they are good to have. As a role that isn’t directly responsible for making something concrete, many managers who would otherwise be enthusiastic about Agile are loathe to pay for someone to “just” run sprint rituals. That resistance is exacerbated by confusion about the power (or lack thereof) that person will hold by virtue of the title “master.” Sometimes the best people to play this role are actually up-and-coming engineers who are eager to better understand Agile methods and take on a leadership role. “Coach” or “captain” can help frame the role better in the minds of managers and team members.

“Agile”

Finally we come to the name of the entire discipline. Once again we are faced with speed-based thinking, and once again we endanger the success of our process by focusing on the wrong thing. We’re right back to setting the wrong expectations that we’ll be magically faster and cheaper. It’s nice to have a named set of tenets, but the reality is that teams have specific and distinct challenges and constraints. Rarely should we implement a pure version of any of the flavors of Agile practices. It has become increasingly common to see long-time advocates for Agile practices become disillusioned with what “Agile” has come to mean.

In our consulting work we focus on tailoring the recommended changes to the specific team and the goals they have. Usually we end up focusing on being more adaptive and responsive or on shortening the distance between ideas and manifestation of those ideas (both in terms of communication and elapsed time). A process well-matched to a team should be derived by that team based on first principles that come from introspective self-awareness by that team.

In summary, here’s a mapping of some suggested changes to the vernacular, in rough order of my preference.

Agile → Responsive; Humanized

Sprint → Cycle; Interval; Period

Velocity → Capacity; Throughput

Backlog → Pipeline; Slate

Story → Ticket; Feature; Token

Scrum Master → Coach; Captain