A Process Has No Name

Thought of the week: there is power in a name. And there is perhaps even more power in no name.

I was inspired last week by one of John Cutler's tweets, as I often am:

"Modern teams pull from many traditions." How true that is! John mentions a few, but there are countless more, and I'd even include the shifty, hard-to-define practical ideas team members come up with themselves along the way that come from their own experience and ingenuity. There are countless avenues for deciding how to work.

There's this one special thing I've seen in common on high-functioning teams: they co-create their process based on their needs and the systems around them.

And by design, it has no name.

It seems like this kind approach has been growing on small teams. "Post-agile" has been parried around as a term, but maybe it's just "Post-Agile" with a capital A, since it still expresses a lot of agility, but without the name. Agility is just ability to adapt, and changing the process by which you approach work is one of the biggest levers to being more adaptive. It's captured pretty well in the Agile manifesto, even: "Responding to change over following a plan."

I think upper-case-Agile itself, along with Scrum and SAFe and the attendant processes and transformations that have structured themselves like scaffolding around the massive skyscrapers of our enterprise corporations are perfectly fine. I don't tend to care as much about that scale—indeed, I have little experience with it: but they likely need the structure, lest their large buildings and hierarchies fall down from the ground shifting underneath them. It serves a need well.

What I do care about are small teams: startup product teams, smaller self-sufficient groups in larger companies, groups of 5-10 people learning as they go who are just trying to build something they're proud of.

These are the teams that are the incubators of process innovation: not just finding methods that work, but naturally creating the environment where those methods themselves can change and grow as the needs and the systems around them do.

There's something special about this, and I'd like to explore one specific and influential condition of success—avoiding slapping a name on it—and why that might be a generally good practice to have in your toolkit.

Names as curing agents

Naming things has a purpose: we don't talk about "agile" or "scrum" or "sprints" for no reason. Even the simplest words at the foundation of work, like "team" and "project" and "problem" and "company" have meanings that limit our thinking and perception of reality.

That's okay: if we didn't name anything, how would we talk? We'd have no shared definition of the reality we all inhabit together. Names are important. Constraints can be helpful.

Names are also powerful: they're fixers. Like the curing agent in an epoxy, once you add a name to a malleable process, it tends to harden and become more solid. Some part of that is good: a solid, well-defined state is easy to explain, easy to market, easy to teach, easy to talk about, even easier to do over time due to the repeated practice of methods that don't change too frequently. Those are great benefits.

Curing a process into a solid also has other effects, some of which are not necessarily desired or wholly beneficial.

One of the most obvious is that it discourages change. When we name something, we talk about it in a certain way, and especially when we share that definition widely, it binds us ever more strongly to the "right" way of doing. This is where online arguments and opinions prevail: what's the "right" sprint length? What's the "right" story pointing method?

There's an incredible amount of communal knowledge embedded in those names, but also a great number of assumptions about other aspects of the complex systems we all work in. They're not always directly transferrable.

Another interesting point about that knowledge transfer: often teams don't really learn a process by reading or hearing about it, or even being told to do it directly.

People learn why a process is important when they directly experience the problems that process is designed to solve. In fact, it might be the only way they learn: even when implementing a well-worn path, I've seen teams only grasp the reason for doing, say, stand-ups after feeling the pain of the disconnect on the team—overlapping work, rework, backtracked decisions, and frustration. The conclusion is pretty clear at that point: "let's talk more."

I'd even call it just that: why affix a name like "Standup" to something as simple as talking? Especially with people coming from many different adaptations of processes with stand-ups, they might have preconceptions about what it means, or even just emotions attached to it.

What is a standup by any other name? Still just talking about the work frequently, and it works great.

It turns out, in the reality of day-to-day work, whether a practice is named something well-worn or something generic doesn't tend to matter. It's like Advil vs. Ibuprofen: one name is generic, but the effect is exactly the same in the end.

Unnamed methods inspire ownership

Where process improves without names is in how people feel about it: I've seen more adaptation in the last two years at my latest company—where we have half-accidentally half-intentionally avoided naming what we repeatedly do—than in my entire career before that where we used more formal names for things.

For example, we do something I haven't seen anywhere else in quite the same form (not saying it's particularly special—it's not, and I'm sure it's done elsewhere, but we generated it for ourselves and that's something). The last 15 minutes of weekly team planning (basically sprint planning) are a whole-product-team sync. We just finished planning our week, all the info and concerns are still on our minds, and each team reports on what they planned. We came up with this one day when we were all concerned about what other teams were doing, so we did it, and we liked it, so we kept doing it. It's been one of my favorite parts of our planning process, and really helps us communicate well. We don't call it anything in particular.

The way people felt contributed to this: if you have an idea for improving something, just try it! If you feel strongly that there's a problem, talk about it! If you find something that might work, give it a shot! Without a fixed process that implies rigidity, people have more implied permission to improve. And I've seen the magic that can generate.

Finally, when people can improve and change their own process based on what's actually needed on the ground, it produces something that's even more influential: ownership. When people feel ownership over something, they care about it more, they begin to feel accountable for its flaws and results, and they feel more connection to how it works. I truly believe that makes everyone more involved and happy with their work. After all, they can do it better and more effectively.

Avoiding names when possible is a simple switch for that: it just says, we're not limited by what others have done in the past, and you own the process. You can make it better.

Names as shared languages

Of course, names are still needed and useful, and you'll still name stuff. You might end up with names that don't imply rigidity: Team sync instead of standup. Weekly planning instead of sprint planning. Size instead of points. Whatever.

Things in your process that you've tried and tested and feel confident about will become more rigid, and that's a good thing for many of the reasons discussed above. It's also the default state toward which everything will tend, so it's important to keep an eye on the language you use and how it impacts how people think about the meta-level of work.

Making something solid is an incredibly useful tool. Leaving something in malleable form is as well: it allows it to adapt to whatever autonomous teams really need, or how the problems and opportunities change in your market and organization. Naming is a tool, and like any other tool you implement, you should be intentional about how and when you use it.

Like Arya stark, giving up naming your process is almost like giving up your family connection: you might feel a disconnect from a wider community of practitioners with whom you share a common language and background of methods. In return, you become faceless: able to shift quickly with the potential to be remarkably effective (though hopefully not at Arya's line of work—this is the end of the Game of Thrones references, I promise).

With balance, you can choose when to cure a process, and when to leave it flexible and agile.

Just look at the "Spotify model:" intriguing yet almost in a different process language, it was met with both jarring confusion, followed by elaborating presentations like There is no Spotify model and posts urging us, "Don't copy the Spotify model." The reason is just that they're operating in a different language: it's natural to not quite understand it, even though much of it translates. Their advantage, however, is that their language being different allows them to be more adaptive. I think that's a good thing.

I'm seeing this more and more often, even in teams with named processes that they learn from and follow. No team does everything exactly by the book: every culture and process has its own quirks and unique ways of operating. And of course, the Agile manifesto encourages adaptation for this very reason.

Be process bilingual

It's great to see some teams embrace the flexibility of forging their own nameless path, and I think one way we can get the best of both worlds is by remaining intentionally and thoughtfully "process bilingual."

When we're able to talk about Agile, Scrum, and Lean ideas fluently, as well as compare and contrast them to our own working realities and thoughtfully self-designed processes—without getting ourselves stuck in too rigid a structure for our needs on real teams—we have a shot at highly adaptive operation along with rich history and community all in one. I'm highly optimistic about that future.