One of the 12 principles of the Agile manifesto states that “The best architectures, requirements and designs emerge from self organizing teams.” But how do you encourage these teams to form and how do you ensure they are sustainable?
Agile practitioners have proved time and again that self-organized teams form the core of Agile execution.
In an instruction-driven model, teams wait for tasks to be allocated, issues are discussed as per schedule and informal interactions are less. This affects the feeling of ownership and impacts the output by the team.
It is believed that if a team is shown trust, given freedom and allowed a less constrained environment, it will respond with high quality and productivity. When teams are empowered to take their own decisions, they self-organize themselves to decide goals, meet them and overcome any dependencies to reach the end goal.
All the empowerment and freedom alone does not ensure the self-organization of a team. Team members who have worked for years in an instruction-driven environment will find it difficult to adapt to this culture quickly. After all, it was much easier for them when the responsibility of decisions rested with the senior members.
In this article, we will discuss certain tricks to self-organize teams and ways to verify if the teams are self-organized and can sustain themselves through most of the problems independently.
Testing the Self-Organization of a Team
Consider an organization forming an Agile team and providing the required training to the team. Roles and responsibilities are agreed upon. Teams are also made aware that full participation is expected from everyone at every step of the project. Assuming that the teams are trained enough and the processes have been explained, the organization now expects them to start executing the project and be self-organized.
The journey begins here.
When to test?
The right time to test the self-organization of a team is when it is in a settled state. Having said this, the testing should not be restricted to the initial life cycle of a project. It should continue throughout the project on an intermittent basis. The prime reason of repeating these tests is that when teams do not face challenges they often go into comfort zones and a "smoother execution of sprints" is considered as the state of being self-organized.
How to test?
One of the ways to check self-organization is to introduce a disturbance in the system. Introducing a disturbance purposely will allow the team to recover safely from the disturbance with no impact on the project progress.
Proposed Disturbance Strategy
Here is a strategy which can induce the required level of self-organization and nurture a team to a more productive state.
- Disturbance: An activity intruding a team’s progress towards its goal.
- Observation: Observing a team’s behavior post inducing a disturbance.
- Teaser: An idea to create disturbance.
- Teaser Stack: List of teasers with prioritization.
- Impact: Positive or negative movement towards achieving the goal.
Consider a small example which will help explain the framework easily:
The scrum master for a project observes that the team is too dependent on her and doubts if it can perform well in her absence. So, she decides to take a leave for some time to check if the team can function efficiently in her absence. She asks a team member (in confidence) to observe the team’s behavior in her absence. The team mate passes on information about the team and the issues being faced by her absence.
If she feels that the team is getting too affected by her absence, she will return immediately else she will remain absent for the planned duration."
Figure 1: Process flow of Disturbance Strategy
Once she returns, she analyzes her team’s behavior and later, over a team retrospective, reveals the intent behind her absence. The team can then discuss as to what went well, what did not go well and what can be improved upon."
The table below shows every step of the process for teaser identification and implementation in disturbance strategy in relation to the above example.
|Process||In this example|
|Define Teaser Strategy||Scrum master or coach of the team observes the team’s behavior and identifies the areas in which the team’s self-organization may need to be tested.||The scrum master identified people dependency and process (daily standup) as the theme of focus.|
|Create Teaser Stack||After identifying the strategy for disturbance, the scrum master will identify teasers which can help disturb the team. Each teaser will carry multiple parameters as discussed in the example. A list of these teasers will be created and each teaser will be prioritized as per impact levels and value addition to the team. The scrum master can choose the parameters to decide the value for these teasers and for prioritization.||The scrum master's teaser information would look like the following:
|Choose a Teaser||The Scrum master chooses a top priority teaser or a teaser which is most appropriate to the current situation of the project.||The scrum master felt that the dependency on her is getting too critical and her absence would affect the team. So, she chose the particular teaser for execution.|
|Induce Disturbance||Scrum master takes the steps required to implement the chosen teaser. These steps are already mentioned in the teaser card.||The scrum master selected A as her confidante and explained the situation, shared instructions and proceeded on leave.|
|Monitor impact and take "continue/stop decision"||Scrum master monitors the teaser’s impacts and takes appropriate actions as required.||The scrum master is in continuous touch with A. Whenever the scrum masters feels that her absence is affecting the scheduled sprint delivery or she feels that the team has lost more than fourworking hours due to her absence, she will come back to work. Four hours was decided as the "continue/stop" decision in the teaser card because the scrum master felt that it is possible to recover from a loss of 4 hours but not more.|
|Observe||Team’s behavior towards disturbance is observed carefully and noted.||
a) Positive Observations: In her absence the team had to have a 15-minute emergency meeting in which they nominated person B as a temporary Scrum master. In addition, they quickly assessed the impact on B’s own work when B performs Scrum master’s duty. Team volunteered to cover-up the affected work and the team went back to developing working software. In between, person C faced some impediments but the temporary Scrum master B was successfully able to resolve it.
b) Negative Observations: Team did not understand the consequences of the missing Scrum master. When person C faced an impediment, C tried contacting the Scrum master. When that failed, C did not know what to do and could not progress on the task. C discussed the issue with D but D could not resolve it and went to do her own work. C could not progress. After some time, it was time for the daily standup. Since Scrum master was not available, the team decided not to conduct daily standup since there was no need to share the status with anyone other than the Scrum master.
|Analyze||Team’s behavior is analyzed based on the observations.||If there had been positive observations then a conclusion could be drawn that the team was well self-organized. Had there been negative observations, then it would indicate that the team is very dependent on the Scrum master and is not self-organized. Team members are not capable of identifying issues proactively and are not communicating enough (C did not discuss her problems with the team). It can further be concluded that the team does not understand the Agile process and assumed that daily standup is for providing status updates to the Scrum master.|
|Conclusions||Conclusions are discussed in retrospective meetings and conclusions of teaser executions are discussed with the team in retrospective meetings.||
If we assume that the team was not self-organized and the observation was negative, then the team realizes that their perception of the process was inadequate; they need to communicate more; the Scrum master is not the manager of the team; and they should not depend on the Scrum master for decisions.
On the other hand if team was found to be self-organized then positive outcomes can also be discussed.
Self-organization of Agile teams is the most important quality that will ensure that the team delivers as per its goals. It is important to find ways in which self-organization can be induced, tested and improved.
Disturbance strategy helps teams achieve self-organization by practical experiences. Since a disturbance is created on purpose, it is ensured that no one outside the team is proactively helping the team to solve a disturbance. The team is made to survive on its own and this brings out different aspects of self-organization to focus. As disturbances are discussed in retrospectives, a team realizes how they could have survived this disturbance better and what aspects of self-organization were put to test.
They will be more self-organized and will not display any random behavior that they might have displayed over disturbances going ahead. The purpose of being more self-organized will be achieved.
Editor's Note: Read more perspectives from this month's focus on employee engagement.
About the Author
Naga Raju Ede is a Project Manager with the Manufacturing unit of Infosys. He has more than 10 years of experience in IT. He is an Agile practitioner and a certified scrum master. He has extensively worked with various co-located and distributed teams under various delivery and contractual models.
- SharePoint is Already Legacy
- Are You Too Old to Work in Tech? IT's Midlife Crisis
- What to Do When Yammer Adoption Stalls
- Has Google Just Reinvented Gmail?
- Faking Big Data #strataconf
- Is Your Information Architecture Ready for SharePoint 2013?
- Web Content is Obsolete