Team Stages, Dysfunctions and Toxins
Team development stages were described by Tuckman and his theory is already a classic. I want to have a look on how this theory applies to agile environment. Another theory describes team dysfunctions as a pyramid or layers and finally team toxins are a kind of behavior patterns that can be flying in the air as viruses - harmless to some extend but capable to poison the whole team or organization when the concentration exceeds certain limits. I want to compile these things into something short and understandable.
Stage #1 - Forming
Every team starts as a group of individuals. People are working according to their habits and maintain silos. They're focusing on their speciality and they don't care of others too much. ScrumMaster's main job at this stage is to teach scrum principles, help to see benefits and understand expectations.
Stage #2 - Storming
As people start working together the artificial harmony of the previous stage disappears. Tension grows and soon or later first conflicts appear because scrum challenges the way how people are taking responsibility and how do they commit to the common effort. They also have different habits and different needs. They tend to call for an authority that could say who is right and which process they should follow but there is no such authority. It is up to the team to find a way how to work together and to set up their own rules they want to follow. The path to self-organization is neither straight nor easy. The team might be calling for a leader but the ScrumMaster should resist the temptation to take the leadership in this critical phase. Instead he should see and take every chance to help the team to figure out how powerful they can be when they are not afraid to take control and to be responsible for their own decisions. His main state of mind should be facilitation at this stage. Nobody likes conflicts but in fact they can be great opportunities to learn and move forward.
Stage #3 - Norming
Finally, everything is great. People know how to work together and with others. They are able to solve most of the problems themselves and the team is self-confident and self-organized. This stage is a nice place to be. It finally works and everybody is happy. In fact this state is quite dangerous because it is like "we're good enough, there's nothing to improve". Our mission is not to reach our limits but get beyond them! We are good team but we want to be high-performing team. ScrumMaster needs to apply coaching in order to help the team to see where they can still improve which is one of the most difficult skills.
Stage #4 - Performing
The team is truly self-organized and cross-functional.They don't need anybody to facilitate scrum ceremonies like stand-ups or retrospectives, they are excellent in planning and they have "life is great" tribal culture (which I'll describe later). And finally, they basically don't need the ScrumMaster any more and he can focus on the higher level (as described above). But there is still one important thing for him to do - observation. Because any change can cause return to previous stages.
So these are team development stages and again Shu-Ha-Ri principle applies. No stage can be skipped.Lets move to the team dysfunctions.
Absence of Trust
This is the base layer of a pyramid representing the team dysfunctions concept. It is quite natural - without trust there is no team but just a group of individuals. People in the team don't have to love each other but they have to trust each other. To build the trust can be difficult and fragile process. A good way how to start working on it - in my opinion - is to create rules of engagement and review them with the team time to time. To make sure that we are not missing any and to remove those that we don't want to follow. It is quite full time job for the SM during the forming and storming stage. Continuous observation and proper facilitation is very important during these phases. Absence of trust is not necessarily clearly visible and team members will not admit it directly almost for sure. It can be observed as a lack of communication and a split of the team work to individual members with poor collaboration.
Fear of Conflict
Nobody likes conflicts. But each conflict can be a good opportunity to learn important lesson. About others and about oneself. Fear of conflict is a second layer which means that you have to build trust first and then you can encourage people to open a discussion even (or especially) if it has a potential of conflict. It is not easy to detect this dysfunction as it appears as an artificial team harmony but it silently kills collaboration. People trying to avoid conflicts naturally don't collaborate and hide behind tasks.
Lack of Commitment
In agile environment, this is a typical dysfunction of teams that just "do" scrum because they "have to" or teams that are at the beginning of scrum adoption process. If team members don't trust each other and fear conflicts they are not able to make a commitment. So if we see a lack of commitment we need to look for the cause in lower layers of the pyramid.
Avoidance of Accountability
"We did our best and that we didn't deliver all the stories is just an exception because this or that was broken, we were blocked by 'them' and first of all some of the stories were not very well prepared by PO." This is a typical example of this dysfunction. Teams that suffers from this also usually say that they canceled sprint retrospectives because it was not useful to do them. Accountable team takes real responsibility as described here. When they don't deliver the sprint commitment they're looking for root cause and they will not take the same amount of work under the same circumstances into the next sprint. To take the responsibility is pretty difficult because there is a plenty of easier options in the responsibility model like 'blame' for example. A matured experienced scrum team needs neither to blame somebody nor call for processes. Their reaction to criticism is change because they can change anything. Either themselves or even the people that criticized them. And they need no rules except those that they created themselves. And again, these can be changed anytime.
Inattention to Results
The top of the pyramid. This dysfunction means that the team doesn't have or doesn't understand the common goal. A particular team member focuses on his tasks and then says "I'm done." But nobody is actually done until "We are done all together." This is easy to understand at the sprint commitment level but that's just a basic or initial step. There is always better next and a really good scrum team is actually never done. The team should be able to define their vision. Where they want to be, why and how to get there.
Every ScrumMaster needs to observe and recognize where is his team in the pyramid because it determines what to teach and how to coach the team. Quite a good start can be to focus on team toxins emerging in the team communication.
Blaming
Very natural, easy and comfortable approach to any problem. The only drawback is that it doesn't bring any solution. "You didn't run the build and now we have it broken", "PO didn't update the story", "SM was supposed to make sure that I knew that".
Defensiveness
Another frequent toxic behaviour that we want to avoid in a good team. It's usually a response to blaming. "Running the build takes too long and I had to go. You could do it yourself.", "I didn't know that it need an update, you didn't ask","Everybody else knew about it". And again there are no winners of such a discussion.
Stonewalling
This is about defending own idea at every costs or decisions splitting. "I always do it this way". But that's not a team work at all. ScrumMaster can apply "Everyone is right but only partially" principle here.
Contempt
A very dangerous one. Usually disguised as a joke or innocent irony but the destructive potential is great. "Sure, you're the most important here.", "He's totally wrong, you can mute him". The line between funny irony and harmful sarcasm is thin.
ScrumMaster's job is making these toxins visible so the team realizes them and tries to avoid them. This sole fact can improve the communication in the team very significantly and it's a good start to build trust and remove fear of conflict.
6/10/2017
Komentáře
Okomentovat