The Intelligence & Efficiency Team was formed two years ago. It is a digital, remote team that is spread out over several cities in two countries. When I joined them, their software was new and just about to go live. We rolled it out at the same time as we added a lot of new features. And, we did it under extreme time pressure.
Despite a lot of struggles, we managed to deliver weekly releases with new functionality. The system went from Beta to live, it was rolled out to customers, and eventually won an award. All this happened in 10 months. How did we do it? It is not because we had an outstanding process, a team of brilliant individuals, or did everything right. It was because we were team players, helped each other, and allowed ourselves to grow and do things we never thought we could!
The struggle
In the beginning, the team suffered from some quite severe problems:
- Lack of business knowledge
- The senior developers and the tester had recently left.
- No established process
- Software quality problems
- Most team members had less than 5 years of experience.
In addition, we had to provide the customers with new features continuously. From the start, there were not so much overall planning. We got one feature in place for test and release, and after that we started to work on next one. With inexperience comes defects, and believe me, we had more than a few!
Eventually we learned and got better, and here is how we did it:
The team culture
We solve problems together, and we give people the space to grow. Each team member takes ownership of, and is accountable for, her individual tasks. This gives everybody the freedom to plan their work, to decide how to solve problems, and who to involve. At the same time, the whole team is responsible for the overall result.
Our goal was to build a culture that allows everybody to perform at their top level, which means most success for the team. This might sound obvious, but in many teams a few people are dominant and work very hard, while others are stuck or have little to do. To achieve success for all team members, senior team members are expected to coach their less experienced peers. Help should always be available.
To agree on some basic values in the team is very important, and we do that based on two principles: Psychological safety and to complement each other rather than compete. This is the foundation of the team.
Everybody wants to be in the front seat!
Intelligence & Efficiency Team member
After a short investigation among the team members in the Intelligence & Efficiency Team, it turned out that these are the main characteristics of the team culture:
- Very good communication between all the team members.
- Openness, honesty, problem solving focus. Everybody is doing their best to help others.
- We are all assessing problems and suggesting solutions together.
- Everybody wants to be involved – we want, and are allowed, to be in the front seat.
- We are challenged and proud of our achievements.
The business objectives
The business objectives are clearly described and communicated to the team. We all know what we are doing, why we are doing it, and how important every team member is for the business.
The objectives are detailed quarterly and they are very clear and easy to understand. They are prototyped, and then broken down to releases and stories that are presented to the team. It is possible to follow the objectives from specification to implementation, and check them off when done.
The distribution of responsibility
It is very important that everybody understands for what they are responsible:
- The team is responsible for the total output according to the prioritised backlog. A feature is not fully done until it is used by customers.
- The team members own their tasks and are expected to solve them, individually, or if needed, with help from others. You are expected to ask for help if needed. The task is finished when set to done, or handed over to another person in the team.
- The team members are responsible to ask if they are missing information, and to coordinate with stakeholders. Nobody can say “I cannot fulfil my tasks because I don’t understand the requirements”, because it is your job to find out.
Deadlines are handled by hard priority of tasks, making sure not not to put an unhealthy pressure on the individuals. The level of quality is described as follows:
If we feel a need to choose between time and quality, we lean a little bit more towards quality. But still consider time as much as we can.
Anonymous architect
The importance of communication
Good communication is crucial for the success of the team. We all know it, but it is hard to keep the communication up. So how did the Intelligence & Efficiency Team do it? We had only a few scheduled team meetings:
- Stand-ups every day, going through what everybody is working with, check the status of each release and reprioritise if needed.
- Requirement walkthroughs before starting to work on a new feature, always with the whole team.
- Retrospective, once per month, if we have time.
In addition to these meetings, it is up to each team member to initiate the communications needed to solve the tasks. And to do so, we highly encourage (remote) communication face to face. We use Slack for minor questions, email is not used at all.
The programming
Since I have the role as tech lead in the team, I want to mention a couple of things around the programming standards and how to keep up the code quality. During my whole career I’ve been working to improve the ways we write code, and I believe most programmers have the same goal, however the outcome is sometimes different. Here are some of the principles applied in the Intelligence & Efficiency Team:
- Write new code according to the existing code style in the service. The style can be improved or changed, but that must be decided together with the team. We don’t change this too often and we are thinking of the code style changes as different generations of code.
- Code improvements and refactorings are mainly done in the core domain.
- The code must be easy to read, but might not be exactly how I would have written it.
- Pull requests are equally much for review, to learn from each other, and to know what’s going on.
- A developer meeting is held every week where we share what’s currently going on in the team from a technical perspective.
If there is a need for more than three comments of a pull request, we call each other and discuss instead.
To avoid competitiveness and uncertainty of our own performance, we learn together. No one knows everything, instead we investigate and discuss different solutions. After all that’s what most of us enjoy with our profession!
The conflicts
The goal is to have the team agree on the best solution to a problem, that keeps all team members motivated. Compromises might be needed, inside and outside the team, as well as balancing of different objectives and opinions. By keeping the team involved in the reasoning, everybody will get a better understanding for the complexity around a decision and they will be more likely to accept a decision that isn’t going exactly their way.
By letting the requirements drive the architectural decisions, the risk of getting into disagreements about theoretical principles is reduced. If stuck in different opinions, which hasn’t happened much in the team, we vote or the techlead decide. Remember to sleep on decisions.
The award
Of course the award was great as a symbol of success and great feedback, but it’s not every time we can earn an award to get good feedback. In the Intelligence & Efficiency Team, positive feedback is provided continuously both on a personal and team level. The effect of confirming and rewarding performance is extremely underrated in leadership and teamwork. It cost you nothing to say a few encouraging words to someone. I’m deeply convinced that the highest motivator for all of us, is responsibility and honest positive feedback.
My sources of inspiration:
https://lattice.com/library/top-4-characteristics-of-high-performing-teams