One thing I learned doing a lot of both customer projects as well product development: One main reason for failing development projects is communication problems. There are definitely a lot of other reasons (see References), but this a a recurring scheme that I saw.
Or to put it the other way around: Don't ever try to lower development project costs by reducing communication a team needs.
You may have been in situation like this:
[Team] : We should set up this meeting where we discuss technical issues.
[Manager]: Who we should send?
[Team] : Uh...the whole team?
[Manager]: *calculates the costs of whole team by 1h*
No, pick one.
or this:
[Team] : Can we have a proper kick-off together with the second team in one location?
[Manager]: *calculates the travel costs of sending a whole team to the other location*
No, we could send the architect and maybe the Scrum Master.
Usually, one would probably argue a bit until giving up thinking "OK, maybe it will still work out without the whole team."
Usually, it won't.
Team
Development most often starts with a team.
There is a good reason why Scrum actually defines certain meetings like Planning and Refinement that must be held with the whole team.
There is the Daily that allows the whole team to see the current development status and, more importantly, if there are any impediments. This is an important part to let product owners or project leaders to know about risks quickly.
The Refinement will allow to talk about the requirements and if they make sense and are well-specified. Bad requirements usually lead to bad software or - even worse - to large delays.
But this isn't about Scrum or Agile. If you restrict communication to just one member or some fraction of the team, it will slap back later.
One important part of regular team communication is knowledge sharing. E.g. we spend regular team-time on Pair Programming, Coding Dojos and some way of exchanging small helpful tips with the team.
More importantly, trust the team. No developer likes to spend their whole day in meetings instead of coding. If developers ask to be on a meeting because they thinks it's necessary, let them.
If they complain about to many meeting, try to reduce the number.
Remote Teams
Adding a second team to a development project, adds non-linear complexity to everything, especially communication. This is increased by having teams at different locations. If there are no precautions, this can lead to disaster.
This also applies to one team with developers working from remote locations permanently to some degree.
Kick-Off
Let us come back to the conversation from the beginning. It's utterly important to put remote teams together physically once in a while if you can't risk the project to fail. Even if it has high travel costs.
Developers are - surprise, surprise - no machines. When there are conflicts between individuals (and there will be some), it is really hard to guess what some spoken words actually mean or more precise, what the person thinks at that moment.
Here are some things that could happen, when working remote (and yes, they could also happen when not working remotely):
- Some people are shy, they won't simply say something even if they oppose
- Some people make use of irony / sarcasm which is sometimes hard to guess in mails or voice communication
- Some people write harsh emails but don't mean it
- People behave differently in remote meeting than at the coffee machine
- Teams start to divide in "them" vs. "us" instead of just "us"
An there is certainly more. This is why it is important to put people together. At least once at the beginning. People need to learn to kind of read other peoples minds by seeing them, taking to them, making fun, pushing the boundaries and to norm. It's like learning to handle a new tool or technology.
Just as for a team, the "forming - storming - norming - performing" phases apply well to multiple teams if they need to work on one product.
Some of the "not seeing each other" problems could be reduced by video calls but they just don't work that good when having more than two people in a call due to low resolution an missed facial expressions.
The foundation of a good relation is very often made at the coffee machine or by spending lunch together. This is only possible when being in one location physically.
Talking to Customers
One other scheme I've seen is to let developer develop and others like project mangers do the talking. Talking to customers and especially users. When there is a direct customer, there might be a chance that there will be a product owner that represents the customer and the users, but still it's very helpful to have direct user contact (see User Centered Design).
But it is very important for the team to know the customers and users to be able to help steering in the right direction in Refinements or even during implementation. There are often some "A or B" decisions. Knowing the user helps developers make the right decisions.
Costs
Costs are often the killer argument for not allowing communication of all sorts. However, this is very short-sighted.
Communication issues will lead to project delays due to misunderstandings and uncompensatable sick leaves, lower quality products, products that do the wrong thing, unhappy customers and demotivated team members.
All of the above are severe but hidden costs that could and should be avoided.
Communication Trainings
Not all communication issues can be solved by just letting people talk to each other. Sometimes it's the way how people talk or how the interpret the spoken words. Often developers that are really good at technology aren't that good at talking. I know it's a prejudice but to be honest, I've seen a lot of developers including myself that could improve their social skills.
Think about joining a training that improves those skills. This might be about communicating the right things in the right way or about resilience on how to deal with conflicts without taking every argument personally and much more.
Conclusion
Communication is one important part and skill of developers and thus key to successful software development projects. Suppressed communication will lead to hidden costs and project risks and thus should be avoided by planning communication and its costs upfront. Trust teams to find the right balance between too little and to much regular meetings and allow team members to see each other in person once in a while.
Top comments (0)