This is my second post about development teams and the problems I’ve spotted by working with various of them.
This time I wanted to be more pragmatic than in the previous and try to identify some team smells.
The term “team smell” is a deliberate homage to “Code Smell” of agile memory.
With this word, I wanted to expose some of what I think are symptoms of problems that could lead a development team to generate frustration and inefficiency.
Team smells
“Overcrowded meeting” or “Sorry, I wasn’t listening”
This usually happens when the team is composed of more than 5 people that need to communicate together constantly, communication is slow, and information is lost.
A small team is an efficient team, and growing it will most likely render it slower and less productive.
This could be a symptom of a business desire to increase productivity. Any tech knows that it’s instead the classic “9 women can deliver a baby in 1 month” thinking problem.
In a remote-working environment, I like to call it the “Too many squares in this call” smell.
“The smell of New-Old Project in the morning”
When most of the team members are new-joiners on a project that is stable and active, it could be a symptom of high churn rate and team unhappiness. Maybe also of the whole organization.
It could happen if a project has been developed by external consultants and now is fully taken care internally. In that case, this smell should be considered as a red flag that requires a team to take its time to “make itself comfortable” on a project.
“Deploy and run” or “I’ll write a bug ticket for it”
A team that “deploys and runs” is not responsible for its bugs and its project deployment. It could indicate a cluttered pipeline, a misunderstood definition of done, and tolerance for an unstable, unreliable system.
It could hide “delivery rush”, “feature creep” and everything that pushes an “always forward” mentality.
“All good for me”
This smell is perceivable when, during project-related meetings, most people don’t have anything to say or any question.
It could hide a blaming mentality or a condition for which people don’t feel comfortable in sharing and asking questions, impeding the discovery process and even hiding information.
“Rushy dailies”
Since I remember, the most effective dailies were the ones with the fewest rules.
Dailies have to be informal and be effective, short meetings for syncing everyone who needs to be synced. The ritual itself could be a waste of time if the team uses other means to communicate its state.
The dailies are another tool in the team’s toolbelt. If they are useless, then the team should be free to drop them.
What would happen if your team decides that the daily is useless?
“I want this technology” or “Put me this a/b test tag here”
This happens when a team is requested to implement specific technologies without being consulted first and without knowing why.
The reason could be related to an “always yes” attitude of the team to accept any ticket is given, but also to an established wrong way of collaboration between client and the team itself.
Also, this could happen if the team lacks a pragmatic approach to problems, focusing on the way to solve the problem more than the outcome.
“Could you write a ticket for us?” or “F***ing Jira”
Tickets are a way to represent a desire and to define a minimal unit of delivery.
Some tickets could also come from the team itself as a way to give visibility to its process and plan it.
Delegating the tickets writing to a third party outside the team could hide the incapability to contribute to its activities or express its needs. The “Alienation of labor”.
It could also hide an excessively complex planning process that the team doesn’t fully understand. That’s a tool like any other, and the team should be able to change it however is effective to it
“It’s red, it’s fine” or “We usually don’t care for that test”
If a team works with a CI that includes a suite of tests that are too often failing, it could mean that the team doesn’t control it.
Sometimes is about skills that can be acquired, but it could hide a top-down influence on the tool choice.
A team should be able to decide for itself what’s the best tool for the job, often could be a well-known tool, but if it’s broken, then it’s useless.
“I just picked it from the top of the backlog” or “I don’t know what to do next”
If a team doesn’t know its backlog, it’s not in control of its process.
Knowledge is fundamental for the effectiveness of a team and also being able to decide what makes sense and what doesn’t.
A team should not only build artifacts, should fully contribute to their development with its knowledge.
Conclusions
I think every organization involving software development might have its own particular team smells. These are some that I’ve been able to recognize.
Please feel free to let me know what do you think about these and if you have any idea for different team smells. The more we are aware of them, the more we’ll be able to fix the problems behind.