What this article is about. We shall talk about the most important, from my point of view, team’s trait - Helping Each Other. After discussion I will give you a powerful game that can help you to foster and promote real “one for all, all for one” team spirit.
Magic flip-chart. I have one magic flip-chart that I always use to demonstrate to all Development Teams when we start discussing Scrum, its principles and teamwork. Here it is:
Then, after we go through all the points, I ask the question: "Which of the following do you think is the most important thing, without which work in Scrum would be simply impossible?" And I get different answers. And usually from the 3rd – 5th attempt people point to the, in my opinion, right answer.
Helping each other
I firmly believe that if we miss this tiny point the rest becomes irrelevant and meaningless.
Let’s find out why helping each other is the most important trait and why missing it makes the rest quite irrelevant.
- Cross-functional - It remains (in case it has been), but in the case of any force majeure (illness, vacation, a valuable specialist leaving the team), no one takes the vacant place at once and does his/her work. Simply because they don’t help each other, instead focusing on their own work.
- Self-organizing - This is possible, but only if we understand that each individual only organizes his/her own work and does not care about what's going on around them. But it is not self-organization. It’s just a parody of it. A self-organized team has high morale, cohesion, and the desire to share the joys and sorrows, creativity and responsibility. These are people who are looking in the same direction and, of course, at the same time are willing to help each other.
- 6 ± 3 people(optimal size) - In fact it doesn’t really matter how many people are on the team if they are not helping each other. After all, everyone works for himself. It’s like being a member of a wolf pack.
- Commits to Sprint Goal - How can it be done effectively if everyone is working on his own and does not want to help the colleague by their side?
- Owns Sprint Backlog – This is purely nominal. Often, in teams where members are not helping each other, tasks are distributed during the Sprint Planning in advance. They decide who takes each task during the Sprint. Think about math and queuing theory. In what situation will the people’s crowd move faster - in several parallel queues to the booths, or where all of the people are standing in one queue and reach any booth that becomes unloaded? Without the help of each other the likelihood of plugging and blockages in isolated lines of the tasks is greater than ever.
- 2-3 years together * (It is not a mandatory Scrum requirement, so it has an asterisk on the flip chart). It does not matter because in this case it is irrelevant.
- Co-located * (It is not a mandatory Scrum requirement, so it has an asterisk on the flip chart) - see paragraph above.
Development Team. In Scrum, the Development Teams do not have any titles (it is strictly forbidden), we have just specific Scrum roles (Scrum Master, Product Owner, Development Team). And where have the testers, business analysts, coders, architects and other specialists gone? They are still there. People continue to perform their previous functions, but since, as they plunged into Scrum, they are equal and everyone becomes a developer and part of the Development Team. We move towards agreed goals only together.
- Who is responsible for the quality in a Scrum team? The Development Team.
- Who is committed to achieve the Sprint Goal? The Development Team.
- Who is responsible for developing features? The Development Team.
Broken Squares. This is a very useful and interesting game that I use in teams. I use it in order to explain why it is so important to work together and help each other when we are moving towards a common goal.
The game is designed for 3-6 players.
The Goal of the game is reached when everyone in team puts together the square from the fragments
If at least one member of the team doesn’t complete the square - the goal is not reached.
Rules of the game are as follows:
- Each participant is given an envelope with different set of square pieces, depending on the number of people (3-6). The picture above shows a scheme of how to generate sets for individual players. Cut the squares and put them in different envelopes labeled A, B, C, D, E, F.
- The team has 10 minutes to build the squares.
- Talking is not allowed.
- You cannot take away the fragments you can only give one at a time.
Here you can download the file in Word format and print it on colored paper (each team has a different color). All you need to do is work with scissors and package fragments of squares in separate envelopes (see photo below).
Play. Now it’s time for the true fun. Set the timer and start the countdown from 10 minutes. Enjoy the process. It makes sense to appoint one or two observers (people not participating in the game) that would walk between the tables and watch the process unfold. After game is over they will be able to share their observations with us. Here are a few game patterns that I have observed:
- A few people immediately collect their squares and lean from the table feeling relaxed. The work is done! Only a few minutes later it comes to them that they are just blocking the rest of the group. They begin helping others and get involved back in the game.
- The game delivers real fun. So do not be surprised if there is a lot of laughing heard in the room.
- The participants, especially in the case of almost exhausted time will often break the rules - showing gestures, trying to give signals to whom and what to give, etc. Let them do that, only insist on silence. Usually each team reaches the goal. This usually occurs at about the 7-9 minute mark of the game.
After game discussion. The most important part of the game, not oddly enough, happens after. This is debriefing. Trying to "pull" as many insights as possible from it, by asking open-ended questions:
- How did you feel during the game?
- What are your observations?
- What obstacles did you face?
- What would help you reach the goal faster?
- What else would you like to share with us?
Typically, a few participants say that they blocked the whole team and because of that lost a lot of time. From this comes the understanding that it is difficult to achieve the objectives of the game without the help of others. You have to see what your teammates need to be successful. Also, I often hear that the problem would be solved much faster if all the pieces were given as a common pile of pieces and not in separate envelopes (like common Sprint Backlog).
Play, discuss and have fun using this game. I hope it will help you and your teams to refresh the responsibilities and traits of the Development Team role in Scrum. I wish you good luck!
P.S. Want more games? Read Scrum Metaphors and Consensus Gradients.
Scrum ON!