Wishful thinking. I see it whenever an engineer hears one thing about a feature and the requirements are actually quite different. The feature goes into QA and several issues come back. You'll hear something like this coming out of their mouth:
"She said this. He said that. We agreed it should be built this way".
It's not entirely that engineer's fault for misunderstanding the requirements, particularly when the ticket they are working on doesn't have clearly written acceptance criteria. For so many teams well-formed stories are not a thing. All the engineer can rely on at this point is verbal communication. Memory fades, wishful thinking sets in. Engineers can start taking matters into their own hands, implementing a feature the way they think it needs to be done. It's never a good idea to go off on your own. Instead, communicate with other members of the team and get a consensus on how to proceed before starting a task.
Communication Is A Two Way Street
Breakdowns in communication are not always the fault of "the other". Listening is the key to understanding how a feature should be implemented. Asking pertinent questions helps resolve issues before they happen. Well-formed stories, mockups, documentation, feature requirements, acceptance criteria, comments all help to ensure a feature is implemented as prescribed. When communication begins to breakdown, details can fall through the cracks.
When coding a feature goes off the rails, all it can take is a conversation to ensure code is implemented properly. That doesn't mean engineers are just vessels to be filled with information, engineers can provide helpful feedback too. Engineers end up sabotaging the work with wishful thinking when little to no communication has happened.
Engineers Are Introverts
A stereotype that engineers have to contend with is that they are introverted, not the best communicators. While that is an unfair label to put on an entire group, sometimes there is a grain of truth to the stereotype some product or project managers place on engineers. Maybe engineers were never really given a solid chance to learn how to effectively communicate. If communication theory were a basic requirement of any computer science degree perhaps engineers would have a better understanding of how to be better communicators. Communication theory is not only pertinent to how the internet works, understanding different communication models can have a profound impact on how well someone can communicate. Once someone realizes they are part of a system, things can change dramatically and the ego can be diminished.
Play Project Manager
Project managers typically organize the information needed for the team to do their job, however not every organization is setup to provide someone in this capacity or the job title can change. Not all is lost. Someone on the team should volunteer to record acceptance criteria, requirements, document links to any materials required to complete a development task. Sometimes everyone on the team takes on this responsibility, even when it isn't in their job description. When you see a particular ticket doesn't have valid information, take a few minutes out of your day to remedy the situation. Be proactive and talk to stakeholders, find the resources, record your findings in the ticket. It will save so much time and energy for everyone involved later.
Be A Team Player
Nobody wants to work with difficult people. There are times agile teams lack the personnel to gather all the information for engineers. Even though tasks may not be in your job description, be a team player and gather all the information needed to complete a task fairly early in development. By going above and beyond you will be rewarded in some way or another. You could get a promotion, a recommendation, maybe even an award. At the very least the workplace can be a less hostile environment when everyone is pitching in to get the job done.
Not stepping up will have only a negative impact on the team. Who wants that? Even when your code works, it may still perform poorly, have other negative impacts on the end user, or cause side effects down the road. There is always something you can do to improve the overall quality of the work before making that pull request.
Summary
Wishful thinking has no place on agile development teams. Before you even start work on a ticket, take a look at it and make sure it has everything you need. When features are poorly implemented, engineers can blame others when there are poorly written tickets that lack requirements, acceptance criteria, links to other materials. Be the hero and collect all the information you need prior to working on a ticket, write up the requirements yourself. Step up to the plate and maybe you can hit a homerun.
For more career advice, follow me!
Top comments (2)
Communication and team work is the new skill in "2020 Skills to Know!" Articles. I'm loving this article and the message it presents:
Be thorough.
Communicate everything.
I like the Scrum metaphor (granted, I've only worked on small team, but large companies also break down into small teams..so it's possibly still effective)
How are you supposed to keep your eye on the ball if you don't know where the ball is in the first place?
Thanks for writing this. Sadly, this is a common experience in Agile teams.
In my own experience I have noticed this to be particularly true when Team Members silo themselves in their role and the Team lacks a wholesome approach to their work. This can be seen, like you described, as handover of artefacts that go back and forth, and and arguments on the lines of "thats not my job".
What we have done in my current company is start from scratch with a Lean mentality, and a focus on delivering value. Our current process (still evolving with Team's feedback) goes something like this: