April 7, 2020
As much as we all love our developers, sometimes it’s hard to understand what they really mean when they talk about work.
Deciphering all of the abbreviations they use and the jargon they throw around during daily stand-ups can be difficult, especially when you’re doing everything in your power to make sure that the project runs smoothly. After all, what does “A feature needs refactoring” really mean to the average person? Is it something bad? Will it have considerable impact on the scope or will it require just a minor change?
This post is powered by our Head of Technology—Tomasz Kania-Orzeł.
Sometimes, we tend to shrug off issues or terms that aren’t exactly clear to us or get brought up at every stand-up by default. Left unchecked, however, problems like that tend to blow up in the most unexpected moments.
The consequences can be numerous, and none of them pretty. You might end up with a severely overengineered product or miss your delivery deadline. The product may end up failing to reflect business requirements. Multiple bugs may “suddenly show up” in the production code. Finally, the client might not want to pay for a delayed or buggy product or developers may want to drop out of the malfunctioning project.
And so, we compiled this brief guide to help you avoid consequences like these and to improve the communication between your PMs and developers. It will help you understand what developers really talk about and decide whether you should be taking action to mitigate the risks ahead.
With our guide in hand, you will be able to tell when they’re overengineering a task or when they lack the necessary knowledge. To make use easier, we’ve split the contents into three categories of risk in terms of severity, which will let you know how fast you should be moving in order to neutralize the potential threat.
Let’s start things off easy. A yellow light means you may run into a small delay in the project's timeframe or problems in feature delivery. However, you still have enough time to take action and deliver the sprint without major hiccups.
You will know a yellow light has flashed when you hear or see the following:
Usually means that things are getting serious. If you encounter any of the situations described below, you probably won’t be able to deliver the features without any hindrances. The developers will be able to do some work, but blockers will prevent them from delivering the full planned scope.
You will know a orange light has flashed when you hear or see the following:
This is when you know your ship is really starting to take in water. There are some major holes in the project and, while you can still fix them, considerable delays in the delivery schedule are probably going to be unavoidable. Problems like these can occur in projects both big and small, and there’s no particular set of circumstances that would always precede their emergence.
Fortunately, the situations listed below are rare, because in most cases the Project Manager would have to be completely delinquent in their duties to precipitate their appearance. However, if you see them in someone else’s project, you’ll know they need help.
You will know a red light has flashed when you hear or see the following:
Understanding developers can be hard at times, but we have to learn to communicate effectively, otherwise it’s the work we do together that suffers. When we’re not exactly sure what we’re hearing, it’s easy to dismiss that misunderstood piece of information as unimportant.
I hope this post will help you develop a common language with your fellow teammates. While you don’t have to start speaking in acronyms yourself, it’s good to know the meaning behind most of them.
And here's a handy glossary of technical terms for dessert. Enjoy! (Simply download it by clicking the image below)