Evolution of the Development Team
Ten years ago, I had the privilege of being a developer in a Scrum team. Today, I still find joy watching other teams adopt Scrum. However, I see many teams get stuck halfway.
Join the DZone community and get the full member experience.Join For Free
What are the characteristics of a good development team and how does a development team evolve when it is using Scrum? In my previous two articles, I described the pattern of an evolving Scrum Master and a Product Owner. This article describes how a development team typically evolves.
Ten years ago, I had the privilege of being a developer in a Scrum team. This was a real revelation for me; the atmosphere and the excitement were great and we were actually delivering valuable software! Now, ten years later, I am still infected by the Scrum virus. I see many teams going through that same excitement and it is still a joy to watch.
However, I see more teams that get stuck somewhere halfway, not reaching their full potential. For those teams, I would like to present the gift of this article, which describes a pattern that most teams go through in their adoption of Scrum.
People who were once part of a successful team will probably recognize that the path to success is difficult. Many factors influence your team and its dynamics. It takes a lot of courage and resilience to walk this path.
Despite the effort and energy, once you’ve been there, you’ll never want to go back.
Some of the characteristics are software-specific, but a large number of them could hold for any team that you work in (even if you don’t use Scrum).
Evolution Stages of the Development Team
The pattern is incremental, and with each step in the evolution, the expected benefits of the team grow. Each of the stages in the team's development is an upgrade of its predecessor and it contains all characteristics of the previous stages.
All new teams start as a group. In this early stage, people are looking for stability, rest, and a sense of belonging to the group.
Team members are still discovering each other and their place in the team. As a result, they have a wait-and-see attitude and do not show their true selves.
Team members are mostly focussed on themselves and committed to their personal goals. Each independent individual in the group has his own standards. These individual, personal standards determine if people respect each other.
Members of the Group typically join the Scrum events, but they often let the Scrum Master guide them towards a result.
Each individual brings his or her own practices to the team and applies them. Forcing these practices to other team members feels overwhelming. Conflicts are felt internally but not expressed until they feel safe.
If there is a Definition of Done, it is mostly a collection of personal practices from the most experienced team members.
Within the Sprint each individual typically works on his own items. Once done, he or she picks up stuff that is in his area of expertise.
Once people feel safe in the group, they will start looking for a common understanding. In the presence of safety, members gradually open up towards each other. Although opening up, people only trust themselves. They start to learn on how to become accountable to each other.
As a result of being more open, people start to learn their differences. Disagreements and conflicts will appear. Resolving conflicts means letting go of old dogmas:
When dogmas disappear, respect is earned. Multiple opinions can lead to new insights about each other.
When dogmas stay, people will try to convince others to start using "their" practices. Their quest for influence could lead to personality clashes, more conflict, losing respect and people closing again.
The feeling of security and safety will either increase or decrease after people had their first conflicts.
Now that people know each others' standards, they start to form an opinion about the best standards. A first mutual Definition of Done appears on paper. This DOD is often not actively used because people still struggle to adopt the newly gained insights.
Since there is no common understanding or goal yet, people find it hard to commit to a Sprint goal.
A real team will emerge when individual members can overcome their personal differences. Conflict, egos, and dogmas make a place for new insights and finding common ground. This common ground leads to shared goals and more clarity and focus in a team.
Goals and standards are becoming clear and they get captured.
Success is actually measured and commitment gradually grows with it. Some of the development team members start showing real accountability.
Mutual respect and trust are being earned on a daily basis. The increased safety leads to a need for more intimate relationships and friendships. Team members start sharing personal stuff and take part in regular social events. A team starts admitting mistakes and learns from these mistakes.
The team has had a number of conflicts. Conflicts are therefore considered unwanted and members try to avoid them. Teams want the stabilization to complete, so members are sometimes afraid to share the more controversial ideas.
Practices like pair programming, TDD, and CI move from a personal to a team practice.
Retrospectives become a place where people don’t only complain but actually discuss improvements and new standards. The Definition of Done is now actually used on a regular basis by each team member. In the daily Scrum, people ask for and offer help to their peers.
In a family, there is respect for each member of our Development Team. We have learned to overcome our differences and trust is the basis of everything we do.
In a family, we see a rise of constructive conflict; members are carefully mentioning conflicts in order to become better in everything they do.
Every member of the family is committed and accountable. People are starting to develop accountability at the team level as well. Sprint goals are set during the Sprint planning and team members dare to speak up when the Sprint goal is under pressure.
KPIs are really driven by team behavior (“we make sure we finish what we agreed”). Team members measure their performance and improve KPIs in order to be more in control. The first, real tangible results appear in the form of frequent value delivery.
The events are running smoothly now. Every team member knows the purpose of each Scrum event and the Scrum Master does not need to point this out anymore.
Successes lead to an increase of people’s self-esteem and drive for accomplishment. People become more motivated, knowledgeable, and competent. Team members regularly visit events and go outside to learn new practices and share knowledge.
A few development team members are showing autonomous behavior; they make decisions without a need for supervision. More and more intuitive decision making, based on experience is allowed. People also allow more dissent, because they see that a variety of opinions lead to more options and better solutions.
Multiple disciplines in the team start taking over each others' work because they value reaching Sprint goals above working on their own discipline. Techniques like swarming (team members collectively finish ongoing tasks before moving to new tasks) and team-wide pair-programming appear.
Continuous Delivery and Continuous Integration are becoming default team standards. The team starts experimenting with team-wide sharing of practices and new, improved standards. The Definition of Done is continuously used, challenged and updated if necessary. It is OK to make mistakes, as long as people learn from it.
Living in a family already feels great, but once you are in a wolfpack, you will experience what an awesome development team is all about. Team members in a wolfpack are courageous. They stand out from the crowd. They dare to be different and swim against the tide.
Instead of living by the rules, people in the wolfpack make the rules; they continuously determine new practices or refine existing ones. Team members teach each other as well as people outside the team about good practices and what works well. The Definition of Done might be on paper, but the Wolfpack doesn’t need paper; good practices are in each individuals mind all the time.
New work is being delivered to the archive a few times a day and with one press of a button the team is able to deliver high quality, valuable functionality to the customer.
There is no more fear of conflict. People demand debate. There are accountability and a willingness to continuously confront each other with difficult issues. Team members trust each other blindly and respect is in the DNA of each team member.
Mistakes are mandatory and when they are made, they are celebrated. There is no greater good than continuous learning, creativity and achieving one’s full potential.
People in a wolfpack are highly knowledgeable and autonomous. Dissent is expected because that is what you need to become better.
Each event has a clear outcome and the rules of engagement are in the minds of everyone. Almost every Sprint the team reaches their goals and sometimes they exceed expectations. Beside a clear goal, the Wolfpack has a vision for the future. They help their customers become more successful.
Now you’ve seen the evolutionary pattern of a development team, see where your team is. Figure out what steps to make and be aware that it is no shame to be in a group or a storm; every family and wolfpack has gone through these phases. A good Scrum Master will understand that teams need to go through these phases. However, avoid getting stuck in the early phases because this is a reason why many teams fail or even dissolve over time.
Published at DZone with permission of Ron Eringa, DZone MVB. See the original article here.
Opinions expressed by DZone contributors are their own.