Evolution of the Developers

2016-12-14 Ron Eringa

What are the characteristics of a good team of Developers and how do they evolve their Scrum implementation?
This blog describes how a Developers typically evolves.

From 2000 until 2006 I was a developer in a Scrum team. This was a real revelation for me: the atmosphere and the excitement were great and, at moments, we were actually delivering valuable software! Know, I lead Agile teams to accomplish similar results and 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 this blog describes a pattern that most teams go through in their adoption of Scrum.

The pattern

Developers who were once part of a successful team will probably recognise that the path towards 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 development team

Evolution stages of the Developers

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.

The Group


New teams start as a Group. In this early stage people desire stability, rest and a sense of belonging.
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.

Individual focus

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 Developers respect each other. Each individual brings his own practices to the team and applies them himself. Forcing these practices to other team members feels overwhelming. The team feels internal conflicts but doesn’t express them until they feel safe.


Members of the Group typically join the Scrum-events, but they often let the Scrum Master guide them towards a result. 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.

This description of the ‘The Group” corresponds with level 1 in our maturity model

The Storm


Once Developers 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.

Overcoming conflict

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 team standards. A first mutual ‘Definition of Done’ appears on paper. Since people still struggle to adopt the newly gained insights this DOD is often not actively used.
Since there is no common understanding\goal yet people find it hard to commit to a sprint goal.

This description of the ‘The Storm” corresponds with level 2 in our maturity model

The Team


A 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.

Measuring success

The Team explicitly captures goals and standards. Success is actually measured and commitment gradually grows with it. Some of the Developers start showing real accountability.

Opening up

Team members start trusting each other and mutual respect is building. 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.

This description of the ‘The Team” corresponds with level 3 in our maturity model

The Family


In a Family there is respect for each Developer in the 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.


All members of the Family are committed and feel 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 just ‘management porn’, but the team uses them to make daily decisions (explicit goals and communication). 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.

Developers are showing more 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.


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.

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 team continuously uses, challenges and updates the Definition of Done. It is ok to make mistakes, as long as people learn from it.

This description of the ‘The Family” corresponds with level 4 in our maturity model

The Wolfpack


Living in a Family already felt great, but once you are in a Wolfpack you will experience how awesome a team can be. 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.

Continuous Value

The team delivers new functionality a few times a day. With one press of a button the team delivers high quality, valuable functionality to the customer. 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.

Continuous Learning

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.

Developers 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.

This description of the ‘The Wolfpack” corresponds with level 5 in our maturity model


Now you’ve seen the evolutionary pattern of the Developers, 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. You should avoid getting stuck in the early phases, because this is a reason why many teams do not succeed or even dissolve over time.
It is a tough, but rewarding job to create a Wolfpack. Keeping a Wolfpack mature is even harder, since teams are continuously challenged with outside influences!

More info

Read my other blogs in this series:

We have captured the patterns described in these blogs in an Agile Maturity model and game. You can download them here.

, ,

Ron Eringa

Ron’s mission is to create organizations where people love to work and create value to the world. As trainer for Scrum.org, writer and frequent speaker he is enthusiastic about leadership development. Ron has helped many organizations to develop learning journeys for their Agile Professionals. Founder of Agile Leadership School.

Comments (6)

  1. Development team has to be more innovative in their approach during development. The more they will be concrete in their approach the better they can deliver the results to clients.

  2. A very informative article! Great points made on development of a Team when using the Scrum Methodology. The examples on the types of teams is quite interesting. Thanks for sharing this great article.

  3. Sue Delgado

    I love this Ron! May I have permission to print a copy of your chart to share with my teams?

    • Ron Eringa

      Thanks Sue!
      Sure, go ahead and share…I hope it will help the team move forward

  4. Astrid Aaby

    I still miss that team when we where a wolfpack. It was awesome to be a part of 🙂

    • Ron Eringa

      Yeah, I know the feeling….very once in a while you need the change to create that all over 😉

Leave a Reply

Your email address will not be published. Required fields are marked *