I was looking at Tuckman model (Forming, Storming, Norming, Performing=Maturity) which shows the evolution of maturity of a new team with time (the life of project) and I concluded that in both branches of methods (traditional & Agile) the same evolution happens but in Agile through sprint retrospective we can create the artificial conflicts in games so speeding up the team maturity. But I don’t see any other challenge or advantage in the way the traditional and Agile methods works in respect to Tuckman model.

Do practices common in agile frameworks (such as PokerPlanning and Standup meetings) have an impact on team maturity?

  • 4
    "Agile" is not a framework. It's a philosophy and a set of best practices for embracing changing business requirements. I think this is a false comparison. What's this ultimately in aid of?
    – Todd A. Jacobs
    Apr 29, 2021 at 18:58
  • 2
    The title and body don't seem to match.... which one is your actual question?
    – Sarov
    Apr 29, 2021 at 19:06
  • In managing a project, different things are defined for the project ( specifications, cost estimation, planning, team, etc). i'm interested in team management and i'm trying to compare the challenges that a project manager should handle when work method changes from from a traditional method to Agile. In this regard, i read about Tuckman model which is not related to any method but it states the evolution of a team and I would like to compare this model in both methods and see the chalenges.
    – Michelle
    Apr 29, 2021 at 19:48
  • @ToddA.Jacobs I added some info in a comment to clear up my intention
    – Michelle
    Apr 29, 2021 at 19:50
  • 1
    Took a stab to make the question more aligned to the description and also less of a opinion-poll.
    – Tiago Cardoso
    May 1, 2021 at 9:45

5 Answers 5


I'm going to make an assumption that you mean Scrum. One of the common differences that you'll encounter as it relates to teams is that Scrum and some other frameworks and methodologies that fall under the Agile umbrella require or encourage long-lasting consistent, self-organizing teams.

On the other hand, though it is not inherent in waterfall approaches, many projects cycle team members as needed. Further, if you look at the Katzenbach and Smith model as well, you may see that many projects actually have working groups rather than teams, so that would preclude any movement on the Tuckman model.

  • yes, please take scrum as assumption. What is the difference between a working group and a team? when you use long-lasting consistent group for Agile umbrella methods, you mean that the team doesn't change throughout One project, but it can change for another project. isn't it?
    – Michelle
    Apr 29, 2021 at 20:23
  • I'm obviously giving Katzenbach and Smith a light treatment here, but they consider a working group a group of people who all have tasks that move in the same direction, but do not specifically collaborate and therefore gain no extra benefit of being in a team and their best output is the same as the aggregate of the output of the individuals. Both models are useful, but I think that taken together they give a much richer picture of team growth.
    – Daniel
    Apr 29, 2021 at 21:38
  • As for long-lasting teams, in traditional projects, team composition could change weekly or daily. Tuckman calls out that changes in team composition push teams backward in that model. There is a lot of disagreement in the Scrum community and other circles about exactly how long team should stay together (because while long-lasting teams can mature, they can also stagnate), but generally, most agree that they should be given the time to get through the Tuckman stages at least. I don't recall exactly, but I think Tuckman said the median time for the teams he studied were 6+ months
    – Daniel
    Apr 29, 2021 at 21:42

On Tuckman model, do teams using Agile frameworks mature faster in comparison to teams using Waterfall?

Theoretically, yes. Practically, it's never that simple.

You could think about the Tuckman model as a chemical reaction that the team needs to pass through and eventually reach a mature state in which the team performs at its best. And chemical reactions can be speed up by use of catalysts or by having them occur in a certain environment, like one with a higher temperature, for example.

If you look at a team through the lens of the Tuckman model, teams mature faster if they work in an environment conducive to the activities and behaviors necessary for the team to pass from one stage to the other. A proper Agile environment I believe is more conducive to that.

In Agile, emphasis is placed on communication and collaboration. Each iteration, or at least on some short cadence, teams need to deliver something. This means real problems to solve, things to figure out and plan, conflict occurring that then needs to be addressed and resolved, etc. Going back to the earlier analogy, the chemical reaction occurs faster.

In Waterfall, communication and collaboration doesn't happen the same. People can easily end up just coordinating their work because work occurs in phases, which can be performed by different individuals within the team, work is passed from one phase to the other, etc. People can easily end up working on their own for much longer period of times than in an Agile implementation. In other words, the chemical reaction happens slower (and only increases in intensity towards the end of the project when things need to be put together and people are forced to now get fully involved with each other to integrate everything they worked on separately until then).

So I would say the yes, an Agile environment can speed up team maturity.

But I should also point out the obvious: it doesn't guarantee it. There are a lot of factors that contribute to teams reaching a level of maturity, or even the opposite of getting stuck in some stage or another of the Tuckman model or even going backwards: organizational culture, turnover within the team, experience of individuals and their motivation (e.g. mastery, autonomy, purpose), management style (e.g. Theory X and Y), clarity of goals and buy in into them, psychological safety, and so on.


The Tuckman model was solely based on observations made on teams. There is no comparison between the types of work, types of teams, industries, methodologies, framework and how any of those things might produce different results as a team matures. Also, I recall no discussion on how to "speed" up the maturity level and that these observed maturity levels were organically achieved, i.e., they occur normally. You can disrupt growth, but you cannot speed it up.

Follow-up on this question: The type of study that would have to be performed in order to statistically deduce which project lifecycle approach, or development methodology, would be a randomized trial with a study group using one type of method and a control group(s) using another...in the same industry to control for industry influences of maturation. Then you would have to have a reliable way to measure for maturity on a model that is quite ambiguous when the team jumps from one stage to another. When do you know you're out of storming? Or out of norming? Is it a sudden shift or degrees of shift?

I cannot imagine how a study would be put together for that. I think the beauty of this model is that it is a natural phenomena where the team goes up and down that ladder and that, when recognized, you respond as a leader with the proper interventions. I can imagine that trying to force what naturally occurs would likely disrupt it in an unfavorable way.


Yes, and perhaps we should remind ourselves that "software is a mechanism." It consists of a fairly-infinite number of "moving parts," each of which is quite capable of interacting with any other at any time. The "complexity" of such a system might well be "infinite." This is not true of "purely mechanical systems."

Therefore, it is very important to weigh strategies like Tuckman's in context. You must carefully decide for yourself whether their maxims actually apply to you. If you are dealing in the realm of "computer software," as so many of us are now doing, then it might well be said that "all bets are off – plan accordingly."


In software projects, some amount of "waterfalling" is necessary: you have to consider technical requirements and potential technical impacts far in advance.

I am also frankly very skeptical of terms like "maturity," especially as defined by a "strategy." I think that you should very-immediately focus on your case, your team, your requirements, and whether-or-not the team is reasonably achieving what is required of it. Get your feet on the ground and keep them there.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.