Phases of Self-Organized Team
Phases of Self-Organized Team
The goal of every Agile leader should be creating a team that does not require the same amount of leadership that traditional teams need.
Join the DZone community and get the full member experience.Join For Free
A self-organized team is a utopian state where every Agile Coach or Scrum Masters strives to bring their Agile team. This transformation will not happen in a day or two, but it will require months to years, depending on the organization's alignment and priority in adopting Agile. It requires constant coaching from the Scrum Masters/Agile Coaches with periodic inspection and adaption into the team. This article is mainly about understanding the changes happening in a team while transforming into a self-organized team. The identification of these phases will enable the Scrum Masters/Agile Coaches to shift their focus areas accordingly.
The transformation happens on a phase-by-phase basis. And below are the identified phases as part of the real-time experience.
- Formation phase
- Cooperative phase
- Being Vocal phase
- Collaborative phase
- Pull way of working
- Stop, Solve and Adapt
In this initial phase, the team will try to get accustomed with the other team members in the new ways of working (Agile). There might be a lot of internal conflicts between the team members. The team's focus will not be towards a common objective; instead, each of them would pick up their tasks or work on their own priorities at their comfort level. The team will not be in a position to completely understand the terms "team commitment" or "team objective." The team will be expecting somebody like a manager to anchor and direct them with respect to the delivery and task prioritization.
The team completely works in push mode. In push mode, the team still expects the lead or the manager to assign the stories to the individual. Besides, the team will not strive to get the comprehensive view of the solution; rather they will have only a stunted view. Most of the team members will not open up or be vocal about their impediments and the associated risks, and it will be very difficult to find the pulse of the team as a servant leader.
Though there will not be any massive sharing or collaboration happening during this phase, there will be a change from the previous phase in terms of execution discipline.
The team will be getting into a rhythm of execution, but not yet delivery. They will understand and agree with the sprint commitment. This can be noticed when the team picks up the story into the sprint from the backlog. The individuals will be careful and well informed about their ability to achieve the commitment. The conflicts and difference of opinions will get reduced. There will be an improvement of idea sharing within the group. The team will also experience the improved degree of engagement within them. There will be a shift in focus on improving the throughput and velocity. At this stage, the team will have a lot of independent rock stars.
In this phase, the team will be calling out their needs, risks, and impediments during the backlog refinement or planning phase. There will be multiple instances where the team challenges the Product Owners on the requirement and there will be situations where the how gets discussed more and influences the what of the Product Owner. During this phase, a Scrum Master will end up spending more time timeboxing, channelizing, and scoping the meetings. Scrum Masters can witness the team members emotionally getting associated with the committed tasks. More than a blame game, the team will be vocal in calling out the weak links and processes explicitly. This is the stage where the retrospection board gets filled up with a lot of improvement and Continuous Improvement options. Subsequently, the team should focus on top 3 items using the "Fist to Five" method.
This is the phase where the team would have attained a higher level of maturity. More than mutual respect within the team, the team will witness the mutual trust between them. A higher degree of cross functions will happen during this phase. In other words, the team will not just stick to their core functions but they will extend their help in other functions. Teams will move towards a state of multi-faceted individuals. They will proactively look for any help and speak out to make sure they are in line with the commitment date. The discussions within the team will be more around the team's objective over individual performance. The team will clearly see the transition from "sharing knowledge" within the team to team "generating ideas" collaboratively and adapting it. A team will huddle up of their own accord about any blockers or impediments and bring the problems up to the management during the sprint duration.
Pull Way of Working
Instead of a push way of working, the team will adopt a pull way of working. To be specific, the team will not wait for the sprint to finish to work on a new story. Teams will go ahead and look at the prioritized backlog and try to pull the stories from the backlog of their own. And this is the juncture when a team should start looking to work in a Scrumban way. The team has shaped in such a way that it need not to work on a batch processing mode (Scrum) but rather work in a "build to production" mode where each card can be sliced such a way that production deployment will be part of the acceptance criteria. Product Owners will be challenged to keep the backlog healthy and prioritized because the team will be proactively pulling and looking for more work.
Stop, Solve and Adapt
In this final phase, the team has reached the state of "self-management" or "self-organization." A team will not wait for the planned periodic retrospection. But, whenever they see any impediments or blockers, they will be removed. Identify the gap, implement a process to fix the gap and adapt the process immediately. This whole cycle will be happening within the span of 2-3 days. This team doesn’t need a planned periodic retrospection but will resolve and feedback the new process and adapt it as quickly as possible. The discussions within the team will be always towards providing value to the customer and a faster go-to-market rather focusing on the throughput and velocity improvement. This team will publish their best practices as part of the confluence and will make sure the new ideas are getting followed by other teams. In short, this team will act as change agent.
To conclude, when the team attains the state of "self-organization" or self-management," that’s when there is no need for a Scrum Master for that team. And the team is autonomous enough to get their delivery done without a Scrum Master. It is the prime accountability of every Scrum Master and Agile Coache to enable any team to be self-managed or "self-organized.
Opinions expressed by DZone contributors are their own.