is probably something else.
I’ve been reading some interesting emails concerning names in an Scrum environment. Backlog in particular seems to generate energy.
Several valid points for change have been made. Backlog felt negative to one team, and they wanted to use a positive term. Another participant mentioned that “backlog” was difficult to translate into his language. Yet another argued that Agile is more about what you DO, than what you name what you’re doing. I think these points have validity.
So what’s the problem?
Take a step back and ask, “What is the purpose of language?” What did you come up with?
For me, the purpose of language is to get the thoughts out of your head into my head, and vice versa. This has several benefits:
1. We can learn from each other’s experiences.
2. We can share (and help create) knowledge.
3. We can co-create a co-reality.
What it Looks Like
We interact with the real world, and through the processes of abstracting (extracting sensory data) and abstraction (converting the sensory data in to words, thoughts, and feelings). Words (hopefully) represent some object in the real world. When we interact with another person, it looks like:
Communicaton Model
The explanation is contained in Getting to Language.
The Problem Arises
As Kelly Waters points out when you choose to use different words, translation trouble occurs. George Dinwiddie and I recently had a discussion about a Scrum Project. Since we share a common Scrum vocabulary, we discussed the project owner, product backlog and sprints with no explanations. We didn’t have to say “OK, by product owner, I mean the person who ….”.
What NOT to Do!
- I doubt I’d whip out the diagram. If pushed for why common words are important, I’d use the Satir Interaction Model
- I wouldn’t say they’re wrong. If we argue, the team will become more entrenched. And I don’t believe the team is wrong
- I would avoid discussions about “The One True Way”. Agile (and Scrum) are about providing working software and business value. I’d prefer to use the same words other teams use (especially if they mean the same), but that’s not the major goal
So What to Do?
To resolve the “backlog” seems negative to the team issue and keep the same word for “backlog” (which is of course “backlog”), I’d try the following:
- Acknowledge the feeling that “backlog” seems negative. It’s how the team (or some portion of the team) feels
- Explore with the team WHY they think “backlog” is something negative. Are all backlogs negative? Is it possible for some backlogs to be positive? Could it be that backlog is both positive and negative?
- Based on the exploration, I’d try to get an experiment approved where we used “backlog” for a set number of sprints, and then revisit the issue. This is the “Trial Run” Pattern from Fearless Change
I suspect that after three sprints, the concern about “backlog” being negative will disappear being replaced by other concerns about delivering business value via working software.