I have had the pleasure of observing, working with, or being part of many Scrum teams over the years. I recently observed a Sprint Review of a reasonably seasoned Scrum Team. As they were sharing the Increment with Stakeholders, I noticed the use of “I” by almost every individual on the team. “I” coded this. “I” figured this problem out. “I” created the user interface. “I” came up with this idea.
I’ve played a lot of sports over the years: rugby, football, lacrosse, soccer, really anything I’ve had the opportunity to try. The old saying “there is no I in team” has always resonated with me. I began thinking about the Scrum team I was observing. What affect might using the term “I” be having on their health and ability to self-organize.
The Fragility of Self-Organization
For a team to lead itself and, as a unit, organize around a problem is not a simple undertaking. Tuckman’s stages of group development explains that it is not uncommon to jump back and forth between stages of group development (forming, storming, norming, and performing). This notion signifies to me that even teams that have been together for long periods of time can revert backwards and have trouble self-organizing around a problem. I’ve witnessed and been a part of this phenomenon.
One might describe the ability to self-organize as fragile. There are many variables that could be at play if a team finds itself struggling. Perhaps they are adopting a new technology stack, are suddenly changing direction, or are just beginning the adventure of becoming a team.
Let’s consider language and behavior as variables that can significantly have a negative or positive impact on a team. Is the use of “I” a sign of underlying team problems?
When presenting or discussing work to influencers outside of the team, saying “I” portrays to outside observers old thought patterns that we are working diligently to overcome. Focusing on the output of an individual rather than the output of a team is comfortable and the norm in the old style of working. That’s not how Scrum works best. The roles in Scrum each have some differences in accountability but does Scrum work proper if we operate as individuals in those roles? From the Development Team perspective, does it work if each developer works in a silo?
I believe it is better for a Scrum Team to portray themselves as “We”. There is so much cross-disciplinary work that often passes over the desk of several individuals before the team can consider a Sprint Backlog item as done. You might ask yourself:
- Who implemented the great idea I had?
- Who tested my code?
- Who dug deep into the customers mind for requirements?
- Who did my code review?
There are a lot of factors involved in developing a great product because software development is a complex profession. “We” can cohesively win and lose as a team while learning from our success and failures together.
“I” and “We”
There is still a place for “I”. Within the Scrum Team “We” want to follow Scrum Values which should be viewed from both the “I” and “We” perspectives. “We” want to be transparent about our individual work and struggles. It’s how “We” identify as individual contributors to a team. It’s how “We” know who needs help. It’s how “We” might improve. That is why “I” commit to being a good teammate and to portray our team as “We”.