Last summer I was looking for a healthy lunch alternative that can vary and doesn't take too much time. My protein porridge was born. Ever since my girlfriend and I have that for lunch.
It's mostly the habit that I am preparing it. With this everyday routine, I discovered a flaw in our communication: In some cases we don't speak the same language. I always shouted through the whole house, "Food is ready," which made her come downstairs.
But she had to wait a few minutes, as her understanding of "READY" is different from mine. Mine was: Food is ready in pot; hers was: Food is ready on the table nicely decorated and the kitchen is clean.
With a team of two people, solving this issue is easy. We decided on a "Definition of Done". Within teams or even whole organizations this can lead to bigger issues.
About Abbreviations, Own Terms and Insider Jokes
Think about it, how many home-made abbreviations are you using in your daily work? Some of them may be widely accepted, some not.
Everybody knows what CR means in the tech industry: Code Review. But as soon as you talk to someone from the SAP industry they could potentially think about Crystal Reports.
Your colleagues from accounting may also not know what you are talking about when you tell them their feature request is currently in CR.
It gets even more complicated with company-specific abbreviations. Every time I switched to a new company I got into at least into one situation, where someone has thrown strange abbreviations at me and expected me to know and understand them.
Are we done yet
The good old story.
The Product Owner/Product Manager/Project Manager/Janitor asks the developer about the status of her work.
"I am done," says the developer. "Ok, great, I will coordinate a demo with the client," answers the product guy. "No, I still need to integrate it and test it," screams the developer and rolls her eyes. The product guy is looking confused and asks her, "Haven't you said you're done?"
I guess everybody who has ever worked in a project knows a similar story. This can lead to huge delays and waste of a lot of time and resources. Plus, it adds frustration to the pot.
Not speaking the same language leads to more work, waste of resources and energy. This does not only apply to a "DONE" state, also for the "READY" state.
Whenever a developer receives a ticket, it should be ready to start working on it. Otherwise, this can lead to tons of frustration, going back and forth about unclear details every single time.
But there is light
Write a Handbook
Especially for the first few examples, about abbreviations and home-made terms, there is a straightforward fix.
Write a handbook. And every time a new abbreviation is coined, update that handbook. It will be a living and always work-in-progress document as an organization grows.
It's worth it. You will save yourself and new employees a lot of time.
When someone new joins your organization hand them over a copy, physically or digitally, and tell them to look into it when they are bombarded with abbreviations and such.
Another positive side effect of a handbook is, you finally have some space to document your ever-changing processes.
It's simple, but it takes some effort to keep it updated and spread.
Definitions of Done and Ready
If you are having an Agile background, have read the Scrum guide or some other framework, this may not be new to you.
Still, it cannot be emphasized often enough: Create Definitions of Done and Ready.
When a work item is created and handed over to the developer, make sure it fulfills certain criteria, so that the work can be started without any further discussion or information.
Define what makes a ticket self-contained; make sure it can be worked on, if you are hit by a bus. Without that, a team will have a hard time working self-organized.
In the other direction, the same applies. When you get the ticket back from a developer, you need to know what ready means.
Both definitions should be widely known and accepted. And of course, they should reflect reality. It doesn't make any sense to put unrealistic wishes into either definition.
If your team doesn't have a proper automated testing workflow, it doesn't help anybody writing it into the "Definition of Done" and hope for some magical solution of your problem. Sorry to disappoint you.
Work or personal relationship, it helps to speak one language. Lots of frustration, anger, and headache can be avoided by clarifying terms upfront.
The two practices above are easy to implement and will pay immediate return when you hire someone new, there you would have done it anyway.
If you have any further questions or need help with your team, feel free to book a free session with me.