Words are hard. They shouldn’t be, but they are. We each internalize a definition of a word, and more oft than not, our internal definition conflicts with someone else’s. Even ancient Greek philosophers like Epictetus faced this problem offering this advice:
First learn the meaning of what you say, and then speak.
Today, let’s talk about two words I see organizations and individuals struggle with: process and efficiency.
In my experience, these are terrible words. Of course, they didn’t start as terrible. They began as respectable words. After all, wouldn’t we want efficient teams? And shouldn’t we manage our chaotic environments by adhering to some process? Perhaps. Unfortunately, their definitions vary so widely from one person to the next that I do my best to avoid them all together.
Why Efficiency Is Terrible
We misuse efficiency in a number of ways:
- Team member cite it as a means to dismiss cross training. After all, why should I pick up some back end skills? I’m not good at it, and I’m just going to distract the dev as he teaches me. Why not just stick with what we’re good at? That seems more efficient.
- Product Owners cite it as a means to discard quality. We’re an agile shop now. Our stake holders are expecting us to churn out new features weekly so we need to work more efficiently to do so, team. Let’s worry about testing later.
- Executives cite it as a means to exclude team members from decision making. I spend much of my day talking to customers so I’m familiar with their needs. It’s more efficient for me to make decisions for the team so they can focus on writing code.
- Managers cite it to means to emphasize velocity. Look at how efficient team x is over team y. They’re getting twice as many points done and have doubled their velocity over the last several sprints!
Does a higher velocity really mean we’re getting more done? Does it guarantee we’re delighting the customer to a greater degree? Likely not. Also, why did so many latch on to this notion that agile is efficient? It’s not. It’s effective, and I think this 4-minute video explains the difference well. Check it out.
When I hear the word, I tend to stop the conversation and invest some time understanding what the word means to the person I’m speaking with. During the conversation, I try to shift us away from efficiency and make it about effectiveness. For example, if I’m speaking with a team member, I might ask questions like:
- You’re the only person on the team with this skill. What happens when you take a week off? Should we just stop working for a week?
- Do you really want to be answering questions while you’re out for a week? How are you going to recharge if you can’t get away from work?
- What happens when we have a ton of work for you? Shouldn’t we have someone else who can lend a hand in those situations? Wouldn’t that be more effective?
Why Process Is Terrible
Process is another dangerous word, and by looking at the manifesto, it seems I’m in good company:
Individuals and interactions over process and tools
I can’t tell you how many times I’ve heard the phrase, “Scrum says…” and I cringe every time. Scrum doesn’t say anything; Scrum is simply a framework. People say things, and too often we don’t take the time to explain the why of our conversations. I also believe we should share stories as to how we got where we are. Doing so provides context and sometimes inspires ideas to help us improve.
The situation is often exacerbated when words like process are coupled with “best practices”–another terrible term. If this is the “best” way of doing something, why would we ever attempt to improve it? And doesn’t best practice assume all humans are cog in a machine? That we’re all interchangeable? Because of the complex world in which we live, I believe that the perfect solution in one context could fail in others. Check out Cynefin for a model that accounts for best, good, emergent, and novel practices appropriately.
Finally, many use the word process as a means to gain compliance from others, and that dehumanizes our great assets: people. In fact, I’ve heard the role of Scrum Master described as the keeper of the process, and I couldn’t disagree more. I prefer something different.
My role as Scrum Master is to help people find better and more effective ways of working together. Isn’t that a better way of framing it?