Have You Used Word’s "Smell-Check" Features?

We all know that Microsoft Word has some powerful features, but imagine my surprise when I realized how its spelling and grammar checkers are helping me identify agile smells, those signs that something might be wrong! There is an element of synesthesia here, as I’m blending visual and aural examples, but stick with me and you’ll see—er, hear—what I mean.

Repeated Words
Back when I tended bar, one particular customer I’ll call George liked his martinis dry and would specify “dry dry.” I didn’t even glance at the vermouth bottle, and George tipped well! Time passed, my career took a turn (whether shaken or stirred is irrelevant), and I found myself in software.I soon realized that repeated words can indicate not only emphasis, but also lack of clarity. You’ve probably heard (or maybe even said) “done done” or “fixed fixed.” What does that mean? Let Word force the conversation. How?

One of the options you can set in MS Word is the ability to flag repeated words (via File/Options/Proofing). It won’t tell you that the term for this is contrastive focus reduplication, but when you repeat a word in a document, Word will flag the repeated word. No, you don’t have to capture every thought in a Word doc, but you can set your own mental repeated word flag.

Agile teams know how important having a common definition of done is, so we don’t hear “done done” as much as we used to, but we might still hear that something is “ready ready” or has been “tested tested” or “fixed fixed.” So while your team likely has a definition of done, when you hear a word that seems to be repeated for emphasis, there is probably some ambiguity that needs to be rooted out or definition to be normed. When you hear this occurring, flag it and invite your team to discuss it to gain clarity.

Slashes
Slashes (/) and backslashes (\) serve us well in HTML, JavaScript, URLs, and even in separating behavior-driven development steps (given/when/then), but not so well in the everyday English that most user stories are written in.

One team I worked on was comprised of people not familiar with the client’s domain and systems. Our product champion, Melissa, was new to behavior-driven development but enthusiastic about working closely with the team. A typical acceptance test Melissa wrote would contain a given step such as “Given a credit application that has been submitted/approved ...” In discussing the story and acceptance tests with Melissa, to understand if she intended the when step to apply to applications in either state, she explained that her intent was to help remind us of the overall process flow.

Slashes can also be an indicator of ambiguity or lack of precision. For example, is it both or either? Or is it a decision yet to be made? If we have a persona, Bob, whose story says he can enter data via keyboard/voice, is it up to the developer to decide which? Or does it mean that we need to provide both input methods for Bob to use simultaneously, or that he would have the choice? If you saw this user story for Bob, how many acceptance tests would you write?

If your team has recently formed and people are joining from a variety of experiences and methodologies, it is especially important to establish norms and gain clarity. One team I worked with was composed mostly of contractors who had not worked together before. One member, Tom, used the terms sprint and iteration interchangeably. Some team members assumed we were using Scrum, and at an early retrospective, a concern that we weren’t using all Scrum practices was identified. Tom had good intentions; he knew that not all members had knowledge of Scrum, and he thought using alternative terms was helpful to them. When we discussed this, we realized we needed to invest a little more time in defining our practices and terms and continue to inspect and adapt.

Other words sometimes used together as though they are interchangeable but that I “hear” a slash between are req/spec, and plan/schedule. When some team members distinguish between two terms and others use them as synonyms, this could lead to miscommunications. So if you listen for slashes as if you’re searching a Word document for them, you might “hear a smell” that warrants team discussion.

Passive Voice
Another MS Word feature you can use is the passive voice checker. Whether you are discussing a basic course of events that is part of a steel thread or modeling processes, it is important to understand who does what, when, to accomplish the task.

I once took on a new assignment and was feeling completely out of my element. The person showing me the ropes, Christa, earnestly attempted to explain things to me, such as “the first batch job is run, then it goes upstairs past where the old library used to be.” I peppered her with questions: “Is that a batch job? Do I run it or does someone else? How do I do that? When do I do that? What goes upstairs? Where?” About two hours into my first day, she looked at me and said, “I hate to train people because I can’t explain anything; besides, it’s time for a break, so I’ll show you where the cafeteria is.” I had no problem with that!

When we discuss user stories, we have a good idea of whose story it is, but we need to be alert for passive voice in other contexts. When you are recapping an incident, saying “The problem was resolved” might be enough; but if you are writing instructions or probing handoffs, you must describe what the actor has to do, not merely what mysteriously happens. You should preanswer questions about who, when, what, and how, and your ability to do that depends on listening for passive voice.

Air Quotes
You know them, whether you use them yourself or have seen others use them: the little vertical hooking gesture made with the first and second fingers of both hands when using a word or phrase. I remember when I joined one team and asked about coding standards, a team member told me, “Oh, sure, we have ‘standards,’ but they’re really just guidelines; we don’t have to follow them,” using air quotes when he said the word standards.

Recently I ran into a colleague and he mentioned his company’s “cleanroom,” enclosed in air quotes. I asked him what the air quotes were about and he said, “Oh, we wear Tyvek and all that, but we don’t actually meet any clean air standards, so we call it a cleanroom but it’s not, really.” Sometimes air quotes are used derisively, such as when the speaker mentions the “help desk” or “quality assurance.”

I see air quotes as a sort of visual disclaimer, a wink-wink, a way for the speaker to say, “Someone else calls it that, but I haven’t bought in,” or the expression of a personal opinion that might not be shared by others. This is another “visual smell” that could indicate lack of agreement or norming amongst the team.

While we may want to minimize documentation and the use of Word, we can mentally use some of Word’s features to sniff out some whiffs of smells.—just the way George could sniff out a drop of vermouth in those “dry dry” martinis.