Chapter 9 Team, Really?
. . . in which the borders of the team are blurred, and the team members all help each other figure out who should attend the retrospective
The team lacks sufficient software architecture knowledge, so a software architect is assigned to help in this area. Bo is not happy about it, since he believes himself to be a software architect and that the team therefore needs no outside help. Bo does not say so out loud, though, since that would be admitting that the team has not acknowledged it to be true. The architect is assigned not only to this team but also to three others, and thus is not with any team on a full-time basis.
On first consideration, it sounds like the architect will work 25% of the time with each of the four teams, but whenever we share our focus between two or more things, we lose a percentage of our time due to context switching.1 How much time we lose depends on a number of circumstances, but a good estimate is between 10% and 40%, according to research. To reduce the amount of time lost to context switching, the architect decides to spend two consecutive days with each team instead of moving between teams every time one has a question for her to answer or a meeting they want her to attend.
It turned out the teams had a lot of questions for the architect and started following her around. Whenever she went for a break, people would line up by the coffee machine or even outside the restroom and inundate her with questions. Finally, the architect started bringing her own coffee and using a different restroom.
The effect is that whenever a team has a question for the architect, they have to wait up to 6 days for an answer because the architect is working with other teams. When weekends, sick days, and travel are factored in, it can take even longer. It is not a surprise, then, that the teams often must find answers for themselves, and Bo is happy again. The system suffers, though. Bo’s decisions sometimes have ripple effects on parts of the system other than the one he and his team worked on. They are not problems that showed up in the regression tests but subtle changes caused by disregarding the architect’s guidelines. Each problem generated a lot of shaming and blaming between the architect, the other teams, and the team in question, most of it directed at Bo.
When deciding whom to invite to a retrospective, many things should be taken into consideration. Should the manager be in the room (see Chapter 15, Curious Manager)? Should the student intern be present? Should the experts who assist us from time to time be present? And should they be there for all of the retrospectives or just select ones? Often, the people who are working with different teams want to optimize their time spent with the teams, so they skip social time, most standup meetings, and retrospectives.
The solution we often use is to save time for the experts by not inviting them to the retrospectives.
A retrospective where an important part of the puzzle is missing is suboptimal. One of the main outcomes of a retrospective is that the team shares how this last sprint/week/project/year was for them: what worked, what made them happy, what gave them energy, but also what actually happened. I often hear one or more team members say, “I did not know this!” while gathering data. Sometimes people expect everyone else to know what they themselves know, but even when people work together in an open office, there are things, important things, that some people miss.
The picture that is drawn by gathering data from the whole team is invaluable in understanding, or in other words, inspecting, how the work is done in the team. The experiments that are decided on—the changes made to the way the team works together or with the technology—are also important outcomes of a retrospective because these experiments are the way the team adapts to the situation at hand. When a member of the team or someone who works closely with the team is absent from the retrospective, the actions decided on may not be acceptable for all. Perhaps the decisions even cause problems, such as with the architecture, the UI, or the tests, that the missing team member could have foreseen. This inspecting and adapting is the heart of agile development.
Last but not least, I have often heard people say that a retrospective feels like group therapy for the team and that it is where they start sharing and feeling like part of a team. People who do not attend the retrospectives consequently might feel less like part of the team.
Topics introduced at the standup meeting are important for the work of someone who is not there. A person crucial for implementing a user story has not been involved in creating it. Decisions are made on a daily basis without consulting someone whose opinion should be taken into account.
Everyone has to attend the team retrospectives. When I say everyone, I do not actually mean “everyone”—I mean the core team and the people needed to create a reflection on the previous way of working and to make decisions about how to work together in the future. The next question is, How do we know who is needed?
The manager might be needed if the team has some issues that are outside their circle of influence (see Chapter 3, In the Soup) or if they want to address something they need the manager to hear about. The same is true when it comes to people such as architects, UX experts, and testers who have specialist skills that are needed in many teams. If you are working on parts of the system that will change the architecture, or if the architecture is changing and has a consequence for your work, you should invite the architect. The same logic applies for testers and other experts. You could argue that everybody should be able to test, for example, but the reality is often that even if the developers know how to test, they need a test expert to make a plan and set some boundaries for the test strategy. These aspects of the work are so important that it is my belief that the experts need to be at all retrospectives in order to be there when information is exchanged about how it is to actually work within the boundaries they have described.
The architects need to be present when decisions are made about how to work with the architecture (or around it). I would also argue that for someone who is on the periphery of the team, it is even more important to be there when decisions are made about how to work with each other in the team.
Some solutions to the absence of experts at retrospectives, of course, are not even related to retrospectives. Perhaps the company needs to hire or train more people with the needed skills. Perhaps the way of working could be made more convenient to accommodate the circumstances, such as having a kickoff meeting at the beginning of each project to make decisions on how to communicate with the people they need.
Since this antipattern is about whom to invite to a retrospective, an online retrospective has the same issues as an offline retrospective. One small difference is that the people invited to the retrospective from outside the core team find it more convenient to attend because they can be there remotely and because the online retrospectives are often shorter than the offline ones. I have also facilitated retrospectives where the team invited the manager in for just part of the retrospective, which is also easier online.
This anecdote is from my work as an agile coach at a large Danish company. Four different teams worked on different parts of a product, and the teams were cross-functional with all the expertise and skills needed in every group. Unfortunately, some of the expertise was to be found in only a very few people at the company, so these experts (e.g., testers, UX experts, and architects) had to be part of several different teams at the same time. They divided their time between three or four different teams, and in effect, they had to rely on each team to follow their guidelines even when they could not be there themselves to ensure their decisions were adhered to.
Because of the enormous load on each of them, being shared between many teams, they wanted to spend time on only the most necessary meetings. Retrospectives have a tendency to be valued less than other meetings, and as a consequence, the experts chose to avoid them. At one retrospective, there was a discussion about the UX side of the product, and everyone had an opinion. A decision was made to go back to the earlier UX design, since this would speed things up development-wise for this particular part of the system. The team took the action point from the retrospective room on a Post-it Note, and the development continued with the earlier UX design.
After about a week, the UX person had time for that team again and attended a standup meeting in the morning. At this standup, people shared what they had done and what the obstacles were, and the UX person understood that the team had been aligning their work with an earlier version of the UX design. A discussion followed, quite heated, and it turned out that there was a very good reason for abandoning the earlier UX design. Of course.