Evolution of the Development Team
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 blogs I described the pattern of an evolving Scrum Master and a Product Owner.
This blog describes how a Development Team typically evolves.
10 Years ago I had the privilege to be 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, 10 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 half the way, not reaching their full potential. For those teams I would like to present the gift of this blog that describes a pattern that most teams go through in their adoption of Scrum.
People who were once part of a successful team will probably recognise that the path to succes is difficult. Many factors influence your team and its dynamics. It takes a lot of courage and resilience to walk this path. But despite of 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, where at each step in the evolution the expected benefits of the team grows. Each of the stages in the teams 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 own practices to the team and applies them himself. 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/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, disagree 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 go down 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\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 & dogmas make place for new insights and finding common ground. This common ground leads to shared goals, 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 is being earned on a daily basis. The increased safety leads to a need for more intimate relationships & 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 stabilisation to complete, so members are sometimes afraid to share the more controversial ideas.
Practices like Pair Programming, TDD & 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 help 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.
KPI's are not only 'management porn', but they are really driven by team behaviour ("we make sure we finish what we agreed"). Team members measure their performance and improve KPI's 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, knowledgable 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 behaviour, 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 felt 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, but also 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 for conflict and people demand debate. There is 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 knowledgable 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 & 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 do not succeed or even dissolve over time.
Creating a Wolfpack is a tough job and a rewarding one and maintaining a Wolfpack is even harder, since teams are continuously challenged with outside influences!
Read my other blogs in this series: