There’s an ‘I’ in Team

This is another scenario that we see quite a bit: During the sprint review, each developer takes a turn showing what he or she individually worked on during the sprint. The stakeholders are drawn to the more extroverted developers and view them as the heroes of the team. The more introverted developers have trouble explaining their work and speak quickly so they can “get off the stage.”

Hearing the word “I” during a sprint review is a sign that there’s dysfunction in the development team’s self-organizing abilities, and that the team is operating as a collection of individuals rather than as a true team. Such dev teams are likely to start the sprint by individually claiming pieces of work. Then team members go off and work independently on their individual pieces. Seldom do these types of dev teams work on PBIs together, collectively trying to solve a problem.

The “I” mentality creates heroes on teams and gives stakeholders the illusion that one team member is contributing more than others. This gives stakeholders the wrong idea about a self-organizing development team’s collective ownership of an increment: They see siloed developers accountable for individual features. Stakeholders will lay responsibilities for specific tasks on individual dev team members rather than the Scrum team as a whole. Blame over failures and joy over successes go to individuals instead of the whole Scrum team.

As we’ve discussed, the development team as a whole is accountable for the increment, not any individual team member. It takes a “we” mentality to create collective ownership. Teams fail to be self-organizing when they don’t work together on PBIs. If each team member is only thinking about himself, then the team can’t effectively work together to achieve the sprint goal.

Joe asks:

Who should talk during a sprint review?

Everyone on the Scrum team should have the opportunity to speak in order to ensure that there’s sufficient representation of every Scrum role. It’s important that the people doing the work have the opportunity to present it. As a Scrum master, this can be a great opportunity for you to mentor and coach team members who are uncomfortable speaking in front of an audience.

There are many things a development team can do to help foster cooperation and collaboration among team members. Here are a few you may try:

• Limit the WIP (work in progress) of sprint backlog items during a sprint.

• Ensure that team members have a clear and concise sprint goal to self-organize around.

• Try pair programming.

• Experiment with mob programming, a technique where the whole team works on the same thing at the same time.

• Ban the word “I” on the team.

These techniques can really help your Scrum team remember to work as a team, which is what Scrum is all about. If you’ve been hearing a lot of I’s during your sprint review, try some of these methods for getting everyone to refocus on what the whole team can accomplish—together.