How Teams Dynamics Evolve and Mature
There are many Theories on Team Dynamics. Some Theories may be familiar, such as Belbin and Myers-Briggs, but the most frequently used Theory in Scrum is Tuckman’s.
Bruce Tuckman Developed a Theory on how all Teams go through 4 stages of team development. The final stage being a High-Performing Team. There are specific Team Dynamics that can be expected during the various Stages. Some of these dynamics are Positive and a few are Negative. In a Scrum Project there is the Role of the Scrum Master. The Scrum Master is required to be able to acknowledge Changes in Dynamics and Manage them Intuitively and Proactively.
His Task is simplified by the way Scrum is Structured. Many of the basic Principles of Agile motivate the Development of an Effective and Collaborative Team. The person chosen for this really important Role is Required to be a Leader, however not an authoritarian. They must be a “Servant-Leader” who ensures that the Team adheres to the Principles of Scrum,. This is done through Education and Facilitation, not Dictation.
Team Dynamics & Work
While the Dynamics of an Agile Team are never Static, there are specific Points where there is constantly Work to be Done, specifically:-.
- at the start of a Scrum.
- throughout the very first two Sprints.
- at the Team’s first Retrospective.
- what point the first Scope Change is Requested.
- when there is a Quality problem throughout a Sprint.
- what point a Team member leaves the Team.
- when a new Team member joins Mid-Project.
The knowledgeable Scrum Master knows the warning signs that he should be looking out for,. The Scrum Master knows which Tools and Techniques can be utilized to reestablish Stability to the Team.
Starting the Scrum: the First Planning Meeting.
We are assuming that all the Team members are strangers in at the start of the project. This can be much easier than the scenario where some Team members know each other well. We will discuss this later in the article.
A Team has been selected and introduced to each other. The first sprint is due to start and the first Sprint Planning Meeting is to be held. At this Point there is no Team; there is a group joined by the common purpose of the Product they need to Develop.
Each person is on the defensive, while trying at the very same time to size up other Team members. If any of the Team are experienced in Scrum, they will settle down quickly to Planning their Work. Team members who are brand-new to Scrum may require to be directed as to how the Sprint Backlog is developed. There is a crucial Team Dynamic between the Product Owner and the of the Development Team. The discussion of the Product Backlog and choice of User Stories for the Sprint Backlog is the Foundation for this shared relationship.
Team Dynamics Tools: Story and Task Estimation.
The Estimation of the Complexity of the User Stories is a powerful Tool and the first real Opportunity for Teamwork. Each User Story should be Assessed and given a score for Complexity. The aim is to reach an Agreement on how Complex the Work is. The aim is not to determine the hours of effort Required. An experienced team member will take less time to finish a Task than an intern. A common consensus of score (in Points) for each User Story should be reached before it can move into the Sprint Backlog. This offers everyone an Opportunity to have their say. The Scrum Master needs to ensure that everybody takes part. Gamification Techniques, such as “Planning Poker” can be presented to produce some enjoyment and engage anyone who is observing rather than taking part.
The very first Sprint Planning Meeting is the first Opportunity to Work as a Team. The team engage in debate and get to know each other. The Scrum Master sees the Team in action and has great insights into the different characters of the brand-new Team.
Our Favourite Agile Books
We found these books great for finding out more information on Agile Scrum:
Early Days in the Project: The First Two Sprints.
No 2 Teams will mesh at the same time or in the exact same method on any 2 Projects. It is possible that the very first Sprint will be enough time for the Team to form and surpass any personality clashes. This stage is what Tuckman calls “Storming”. Nevertheless, this also depends on the length of the Sprint. A two-week Sprint is not going to give sufficient time for the Team to begin bonding. Two Sprints may not be sufficient to get to the “Norming” Stage. The Norming Stage is where the Team is working as a Team and not a bunch of individuals.
Team Dynamics Tools: the Daily Standup.
This 15-minute Daily Meeting requires each Development Team member to make a brief comment. This comment is with regards to the Work accomplished the previous day and what they Plan to do before the next Meeting. The Scrum Master should have the ability to pick up if any Team member is feeling frightened or uncomfortable. The brevity of the Meeting offers just enough time for everyone to have their say without time for recrimination or blame.
Getting Rid Of the Blame Factor: the Retrospective.
This is where the Scrum Master utilizes the Retrospective to Demonstrate that honesty and openness is Valued (as it needs to be according to the Agile Manifesto), and that blame is not allocated to anybody, no matter the situations. The Retrospective is an effective Tool for stabilizing the Team, where they can Review what occurred in the Sprint that went well, as well as what must be avoided in the future, and what actions the Team ought to take.
Scope Changes: Calming Troubled Waters.
Agile not only expects Scope Changes, it welcomes them. That is all very well when you have been Working for the last few weeks on a Product Feature that the Stakeholders now want to scrap or Re-design. No matter how responsive one is to Change, such an action can be demoralizing. The Scrum Master should ensure that the Team member or members whose Work has been turned Topsy-Turvy do not take things personally and smooth some battered egos. The effect of Scope Changes on the Team are seldom discussed, however they can have a substantial negative effect on the Team and some of the members.
A comparable negative scenario is where a User Story for Review does not meet the Acceptance Criteria. The User Story cannot be marked as “Done”. This likewise has an unfavorable influence on one or all of the Team members. This can trigger dispute between the Team members and the Product Owner. The Scrum Master needs to restore morale and mood in such a case.
Changes in Team Structure.
While Scrum Projects are brief, and hopefully there is no Change in the Team during the Project, this does take place, and can actually set the Team back, especially if the Team member (or members) who left were popular and a good “Team player”. Any new member (or members) who is selected to replace them is an outsider and must be integrated into the Team. Ideally the Team does not go through a prolonged “Forming” and “Storming” stage. It is based on the personalities and the established Team Dynamics.
Managing Teams is complex and varied. There are many events that can stress the Team Dynamics in a Scrum. This is where the Role of Scrum Master is often Undervalued by some Companies; Forming and Nurturing a Team is not an easy Task. The problem is that a good Scrum Master has a great talent if he can form a Collaborative Team, akin to the conductor of an orchestra, but it is very difficult to Measure and Recognise. This is why there is often debate as to the Value of a Scrum Master and whether it is a full-time Role or not.
The ‘Agile Scrum Master Training Course With 59 Seconds Training‘ is now available for free. This free Scrum Master Certified Online Training Course provides an in-depth understanding of the Agile Scrum Master roles and responsibilities, where you find out what a Scrum Master does and how to do it. During this free course you will learn all of the tools needed to succeed as an Agile Scrum Master.
Thank you for choosing us to learn about the Agile Scrum Framework.