How to Build Trust and Improve Communication Within Agile Teams

What parallels can we draw between football and software development? You can hire stellar players that cost a fortune, but they will most likely lose as a team if they do not have a shared vision and strategy.

Before hiring new team members for your existing team or building a new team from the ground up, you must define your goals clearly.

Creating a new digital system or application requires certain technologies, which in turn requires certain competencies of specialists. That is, the abilities of hired engineers should correspond to the tasks. There is no point in keeping the team of developers whose potential exceeds the tasks by far: someone may simply be left without work, and this is very irrational and fundamentally contrary to the principles of any modern business.

So start with the thorough analysis and make a work plan that outlines all the functions, competencies and areas of responsibility. Take your time, sleep with your ideas and act. Believe me, all these preparation efforts will pay off in the future.

What’s Behind Ineffective Software Development Teams?

The team refers to a group of people united by motives and intentions to achieve a common goal. It sounds great, but in practice, there are many roadblocks. Ineffective software teams lack the following features:

The Ability to Understand Each Other and Speak the Same Language

We are all different and we perceive things differently. Everyone has their own worldview. Let’s say you ask your colleague to deploy a feature like, for instance, bulk data upload from Excel to the table, and you eventually get the outcome that’s a far cry from what you’d expected originally. No matter how simple the task looks like at first glance, there’s always a chance it’ll be misunderstood or misinterpreted. Therefore, it’s critical to use a task tracking tool within the team to formalize tasks assignment and make sure it’s understood clearly and unambiguously.

The Ability to Talk

Let’s assume your team is working on a very difficult task, and it needs to find the best solution or kludge to solve the issue. You sit together to brainstorm and figure out the solution. While some team members are active in sharing their vision and suggestions, the others have nothing to say. They don’t really want to be bothered and all they’re waiting for is a new task to be explained and assigned. Yet, if you, as a team lead, can encourage them to talk and share their ideas, you may arrive at a better conclusion at the end of the day (the more ideas, the better).

Motivation and Interests

Are you sure your team lead and the team are driven by the same stimuli? As a team lead, your motivation is to make sure the team follows your work plan, and all featured are built and deployed on time and on budget. But your team members may have a different motivation: what if they want to use a new programming language or framework to see how it’ll affect project development speed?

Hear and Listen

Often, engineers do not quite understand why they have been pulled out and made to attend the meeting. As such, they hear you, but they don’t listen to what you say. This is the first sign that you’ll encounter issues as your project is underway because someone didn’t listen to you before.

Involvement in The Process

On many project development teams, especially those that are shuffled from project to project without having any strict attachment to the client and its business goals, programmers may simply complete tasks without having a clear understanding of how their work will affect the client’s business. When your team members blindly write code without delving into the project goals and details (for the sake of closing a ticket in Jira), you’re in big trouble. It means you have unmotivated and indifferent people on your team and such approaches rarely yield any good results.

If a group of people seemingly work on the same project, but everyone has own vision of the end goal, it can’t be called the team! It’s just a group of people, nothing more.

How to Unite People and Build a Strong Self-Organizing Team

The main task of any technical manager, from tech lead to CTO, is to minimize the impact of all negative and distracting factors and to achieve maximum team productivity.

I believe that the key process in a good team is communication. Below I will list the main principles and tips for establishing a seamless and clear communication within your software team.

• Sit down and talk to each employee and ask about their skills and experience. Try to find the strengths and weaknesses of each of your team members. Make sure that people complement each other by drawing on their strengths. This is the only way to achieve maximum efficiency in the end.

• Keep your team informed of the project goals and mission. If you need to implement a particular functionality, everyone should understand the reason behind this. Don’t just throw tasks at them; instead, ask for their opinion and feedback to make them feel included and see how exactly this task will affect or contribute to the project success.

• Explain everything in simple words so that everyone understands and has no doubts. As Einstein said, "If you can't explain it simply, you don't understand it well enough.

• Involve people in discussions. This has been mentioned above. The objective is to make people feel appreciated by asking them to share opinions or feedback. The more often you hold brainstorming and discussion sessions within your team, the more dedicated to the teamwork success they’ll become.

• Forget the word "mistake." Demonstrate to your team that an error or failure is a search for a new solution. All team members should understand that this is a normal workflow and part of the daily routine. Who doesn’t make mistakes? Only those who don’t do anything! While almost everyone can ride a bike, I doubt there’s anyone who never fell when riding.

• Criticize the stuff but not the fluff. If you don’t think a team member’s suggestion or idea is right for your project, never say it’s a bad idea. Learn to explain argumentatively why it won’t work now, but don’t clip their wings!

• Speak the same language. Discuss the tasks and ask for a summary. One useful practice is to ask your software engineers to talk about the solution and how they understand it. You may unveil many interesting things this way. It's better to take the time to discuss than to be surprised at the result down the road when you suddenly realize the solution is completely out of line with what you're trying to accomplish.

• Say thank you. If people do something well, be sure to thank them. This little thing is very important, everyone is happy when they feel appreciated. But don't abuse it, as your gratitude will be quickly devalued.

• Be transparent about each and every team achievement and failure. As mentioned above, each team member should feel valued and when you talk to them openly and give a pat on the back for a good job or encourage to improve efficiency and productivity, they feel valued and become more cooperative. It's good practice for Team Leads, CTOs or CEOs to gather people from time to time (e.g., once a quarter) and report on their achievements and areas of improvement.

As you can see, most of the tips are related to communication and trust in one way or another. If you don't build them properly within the team from the very beginning, there will be issues down the road. It is this communication that largely determines the efficiency of your software engineering endeavors.

Tips and Tricks of Successful Software Team Management

I once read an interesting theory about the optimal size of the team. Once upon a time, George Miller was involved in memory research, and as a result of his experiments, he made a conclusion that our short-term memory usually contains between five and nine incoherent elements. That is, we don’t need to group them according to some principles and characteristics to remember them more easily. Jeff Sutherland, the father of Scrum who repeated the success of Toyota, believed that the team shouldn’t include more than seven people, which resulted in the "seven people per project" rule. In his opinion, only teams of this size can achieve hyper-productivity, and they can be eight times more effective!

I was surprised, but this theory proved to work for me. I once had to manage a team of thirteen people. It was highly ineffective, so I divided it into two teams and the productivity increased noticeably! As the project scaled, we built a third team of six people, and the results improved threefold.  

Below I will give you some tips on team management. There’s nothing new in them, but they helped me a lot when I was involved in distributed software development team management.

• Combine the teams so that they have a place to grow. If you have a distributed team with one part being very strong and productive and the other one less experienced and slow-achieving, shuffle people so that you have a healthy mix of senior, middle and junior specialists who can complement each other’s skills and expertise. After shuffling, productivity will increase.

• Distribute tasks properly. A programmer is an expensive employee for the company. You should always challenge them to drive forward. If you see they solve assigned tasks with ease, make sure to assign more complicated tasks or tasks they may not be familiar with. This will encourage them to research more and fine-tune and polish their problem-solving skills. In short, this will help them grow professionally and personally. An experienced senior developer should not sit over easy tasks, even if they perform them faster than your mid-level developer.

• Hire junior developers with little experience but with a huge zeal to work and learn. Let them work on non-critical tasks. This will help relieve the extra burden of your senior guys, keep them focused on complex and mission-critical tasks, and improve mentorship skills.

• Motivate your employees according to their expectations. You need an individual approach: for some, it's money, for others, it's career growth, for the third it can be an extended vacation. Learn everyone’s motivation and make sure to give each what they want.

• Do not micromanage or try to control each step. People should be aware of their responsibility and accountability. The person who understands this is much more effective and independent. Remember – you don’t hire expensive developers to tell them what to do and how to do it. You hire them to leverage their skills and experience, so they should tell you what to do and why.

• Do not skimp on education. Send your team members to conferences, workshops, and other professional events. It is expensive, but it’ll help your team members enhance skills and gain new knowledge which will pay off well at the end of the day. Moreover, on- and off-job training is one of the most sought-after benefits among software developer candidates, so you simply won’t be able to attract good developers if you don’t offer any self-development opportunities.

At some point, the wagon you're pushing has to go by itself. In a good team, when problems arise or new features are designed, people should sit down and discuss possible solutions and suggest their own options. Ideally, they should do it without a team lead at all. So, your goal is to build a self-organizing team where you’ll encourage, facilitate and mediate rather than control and manage.

Conclusion

A high-performing software development team is a team that learns from mistakes, grows, and is able to fix or predict those mistakes quickly. Everyone listens to each other and hears what they say. A team is a living organism that evolves continuously.

People who understand the purpose are more motivated and can offer solutions to issues that others will not see.

It is necessary to be engaged in building development processes within a team and to pay maximum attention to communication. I believe that a good team lead shouldn’t spend more than 10-20% of the time coding: they should focus mostly on building trust and proper communication to ensure the best outcome ever.

People are your most important assets, so treat them the way you want to be treated. Create conditions for them to develop and grow, and your team will always be ready to go the extra mile to delight you or your client!