Succeeding with Agile – Stages of team development

Agile Teams exhibit different stages of team development. In 1960s, Bruce Tuckman identified four stages that teams normally experience – Forming, Storming, Norming, and Performing. Teams that are transforming from Waterfall to Agile methodology, using Scrum and existing Agile teams would find the following as a reference in their path to reaching a high performing self-organized team. Since there is no fixed duration for each stage the characteristics and behaviors expressed by your team would identify the corresponding stage and its estimated duration. It is possible that your team could skip a stage, operate in a particular stage without any progression or revert to an earlier stage due to a change in team composition.


This is the first stage when an agile team is formed. The primary focus during this stage is orienting with team members, establishing relationships, and jump starting the mechanism of applying Scrum as an Agile methodology.

Characteristics of this stage:

  • The members of the team are announced, followed by a product team kickoff.
  • Members approach each other with varying levels of expectations, and establish their “first impression”.
  • The product owner outlines the product vision, roadmap, and scope of activities.
  • The product owner may also present a list of requests, stories or Epics.
  • The product team could take a week or two for grooming stories and refining acceptance criteria.
  • Scrum Master describes or revisits the Scrum framework and guidelines with the entire team.
  • The team kicks off the core scrum meetings – Daily Standup, Sprint Planning, Sprint Review and Retrospective meetings

Possible outcome from this stage:

  • Team members may feel overwhelmed about the sprint meetings and daily standups. This is very likely, especially if the teams have transitioned from Waterfall methodology where typical status meeting are held once a week or longer.
  • The lack of formal requirements document may initially challenge some team members.
  • They could experience frequent questions, conversations, interruptions during daily standups.
  • The retrospective feedback from each sprint could expose several places for improvements. It is very likely that one or more team members may not be vocal in expressing their feedback.
  • There is a natural grouping or socializing between team members.

Typical duration:

This stage is typically a short one from launch of product team until 1-2 releases. Teams could exhibit varying lengths or dive quickly into the storming stage.


This is the second stage where there is conflict among team members who bring different ideas or solutions. Individuals may resist changes or may be reluctant in adopting the new methodology. As a result the team dynamics gets challenged. The focus during this stage is mostly “I” centric – representing the tone of “my idea sounds better (than yours)”, “I want to do it this way”, etc.

Characteristics of this stage:

  • Execution of tasks and selection of stories could resemble a min-waterfall approach within sprints.
  • The team may spend the longer hours identifying and refining acceptance criteria.
  • Individuals in your team may propose various options for tackling different situations.
  • One or more individuals and possibly your entire team could feel frustrated about the Agile framework.
  • Some team members may dominate or defend in retrospective sessions, while other may choose to speak less.
  • It is likely that some team members may feel that the agile approach isn’t working right for them or the team.
  • One or more team members would begin to seek assistance or escalate issues with the senior management for resolving any disputes. Senior management may provide recommendations or set expectations that might challenge the natural tendency for your teams to Self-Organize.

Possible outcome from this stage:

  • Planning sessions may take longer and even exceed the duration of the Sprint planning meeting.
  • The velocity of the product team could vary significantly across sprints, even though the team may be releasing some or all items in the sprint backlog.
  • Some teams may need a week or two for Sprint Zero related activities.
  • The retrospective meeting would indicate several places for improvements and perhaps outnumbering “Things that went well” in a given sprint.

Typical duration:

This stage could last from a few weeks to several months.


This is the third stage, where the team demonstrates a need to overcome resistance and begins to work together as a team. One of the indications of this transition would include a transition from frustration to being optimistic and hopeful. During this stage, the team begins embracing the new methodology, and fosters collaboration among people. Most team members begin expressing a positive feeling. There is a natural transition from “I want to do this” to “let’s try this”, focusing on helping each other than competing.

Characteristics of this stage:

  • Sprint planning sessions may demonstrate a collaborative session among developers or testers.
  • Improvement in sizing of stories – This would be fostered by strong and open communication between team members.
  • The retrospective feedback would start showing a consistent pattern on generic “Things that went well”. Ex: Team collaboration, communication, etc.
  • There is an improvement in user stories including acceptance criteria resulting in good Sprint Planning sessions.

Possible outcome from this stage:

  • The team’s velocity becomes a predictable measure for future releases.
  • The team would participate in refining acceptance criteria rather than expecting completed stories to be handed over to them.
  • The team may still indicate “Places for improvements”, but would shift toward proactively seeking action items for improving things. The places for improvements would indicate maturity in the issues being presented.



In this stage, the team is successful and very efficient in producing results. Each member of the team is self-motivated and works in the best interest of the team. The entire team works collaboratively, supporting each other.  It is likely that some team members may demonstrate good characteristics of performing stage even before reaching this state.

Characteristics of this stage:

  • All team members actively participate in Sprint planning. Team members discuss ways to find efficiencies in completing tasks.
  • There are clear channels of communication between developers, testers, architects, product owners, stakeholders and scrum master.
  • Recognition is measured on a team level basis. Team members who tend to do less would get exposed, providing them an option to step-up.

Possible outcome from this stage:

  • Highly efficient product team producing great results.
  • A positive and energized atmosphere within the team.
  • Team follows a rhythm in deploying releases periodically, with good quality.

Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: