Cross Functional Team and Creativity

Recently I was reading the HBR article How Pixar Fosters Collective Creativity. Whether you know this or not, all the eight films released within a span of 13 years have been successful. I am sure you would seen atleast 4 out of these 8 films (A Bug’s Life; Toy Story 2; Monsters, Inc.; Finding Nemo; The Incredibles; Cars; Ratatouille; and WALL·E).

CEO of Pixar quotes that the reason for such a grand success is mainly due to Creativity in their team. He continues to say that,

Creativity involves a large number of people from different disciplines working effectively together to solve a great many problems.

If you carefully read the above lines, it is quite clear that, "people from different disciplines" is nothing but the cross functional teams as advocated by some of the Agile methods. It is also apparent that forming a component team with monotonic single disciplined team leads to failures, as compared to the multi disciplined Cross functional teams.

Role of Scrum Master - Dealing with Conflict Avoidance Teams

Have you come across teams where only a few speak and the rest listen ?

Have you seen any of your team members not sharing their thoughts or participating well during Scrum meetings, retrospectives or other activities ?

Have you come across any team where there is no conflict ?

Silent Teams
The teams where you don't see conflict, I would call them as "Silent teams" for the sake of this article are silent in speech, but not really silent in their mind. The people in this teams are like any other people but all their questions, frustrations, arguments everything is going only in their mind. They never speak up or discuss things in front of a group, especially if their ideas conflict with others. But there are chances that they go and share their frustrations with some one closer to them in the team during the cafe breaks or with any other close friend.

Why does this happen ?
According to Conflict Avoidance hurts Business... Individuals stay silent because....

• We are afraid others won’t like us if we speak up
• We fear the other person may say something worse about us
• We wait until we’re really angry and fear loss of our tempers
• We tried it before and things escalated or nothing changed
• We lack the skills and confidence needed to resolve conflict

Basically our identity getting hurt plays a key role here.

According to Ester Derby,

Groups that avoid conflict won't be able to face tough issues or handle the creative conflict that generates new ideas.

It has also been found that culture in certain Asian countries like Japan, China, Korea, India,etc have Conflict Avoidance Culture . People who are in these countries are ready to keep silent during conflicts so that it does not hurt the other person or as Craig says they remain silent to create "Social Stability". Scrum Masters especially from these countries need to be conscious of and ensure that conflicts are identified, brought out in open and resolved. The team should be taught how to resolve them among themselves and such teams tend to become self organizing much faster as compared to the conflict avoidance teams.

A Case study
Here is a case study in which the team conflict avoidance lead to drop in productivity. ..
An onsite customer was very brutal with the offshore development team members. He used to pick every day one of the team members and used to shout at them. Every day the conference call with the onsite customer used to be like attending a court where in, each team member was supposed to defend their work and explain what they did every hour of the day. The communication with the customer had always been one way, no discussions were encouraged. Even though every one in the team were fed up with the customer, no one had the courage to speak up and confront him. Every day after the call, the team used to wait until the customer drops off and then used to talk behind him. Over a period of time the frustrations and stress lead to a huge drop in the productivity of the team.

Does this sound familiar to you ?

Situations like these are all too common in organizations. As per Conflicts and Trust,

Fear of what might happen if conflict were confronted causes otherwise proactive people to hesitate, and the cost of this hesitation is significant.

Consider the cost of all those developers as their performance is dropping. The unresolved conflicts keep accumulating in people's mind and takes a huge hit on performance.

It is very important for the Scrum master to observe and understand the team dynamics. Craig Larman recommends Scrum masters to ask questions like

Are members avoiding discussion ?,

Is something hidden ?,

Are members truly committed to the team ?

Managing Conflicts
There are techniques to manage the conflicts too, one of the most popular techniques is the Ladder of inference.

Lean Primer by Craig and Bas

Recently, Craig and Bas have published a very nice primer on Lean software development. It is free and could be accessed from here

Inventing your own Light weight methodology - A Case study

In the past I had implemented a project by inventing my own light weight methodology and I am sharing my experience in this post.

Even though the inspiration came Agile values and principles, but didn't follow any specific methods like XP or Scrum as a whole.


Context:
1. "<5 " member team
2. Collocated team (dev team in India and technical SME in US)
3. Web application development
4. Team composed of members who are fresh out of college and in equal proportion experienced members
5. Team was well aware of the technology
6. The team members were passionate about learning the new technology and hard workers too.


I was an architect and also played a role somewhat like a Scrum Master.

1. Every day in the morning when the team had arrived, we used to sit in a circle and ask individuals plan for the day and if they need any help in resolving any issues. This could be compared to a scrum meeting except that we didn't ask the 3 questions nor we stood in a circle.

My observation is, it is not that the ceremony which matters but the values behind the ceremony that makes the difference.

2. When each team member used to speak out about his plan, I used to make a list of action items on a white sheet of paper. Let us call it as Action List.

If your team sits closely in cubicles and does not have access to huge team rooms, white boards or post-its, then the above method of writing on a white sheet of paper could help.

3. Many a times the onsite team would have done some review of the application and would have suggested changes through email. I would add them to the Action list

4. Once every one has completed sharing their action items and impediment list, they used to take a quick 10-15 minutes break and return back to work.

5. The action List was kept at a visible location so that everyone can see.

6. The team members used to glance through the Action list, depending on the priority (discussed verbally) they pick up the task and start working on the same.

7. After completing each task, they would come back to the Action list sheet, take a look at it, pick up one of the pending tasks voluntarily. As soon as they complete any task, they used to put a check mark on the same.

8. There was a progress review in the afternoon and at the end of the day another review on where we stand. It was more like a retrospective but without much rituals like +/Delta analysis or so.

9. At the end of the day before the team used to leave work, we used to quickly talk about the tomorrow's plan.

10. Informally the team used to discuss about the design, coding and other issues during the cafe breaks too.

11. As an architect I used to sit and code, and at the same time if any of the team member's are stuck then I used to jump in to help them out. If I can't help them, then I used to reach out to other experts through my contacts and get them the necessary help.

12. Estimation is done by the team. Since the team had experience with the domain and technology, based on past experiences, they used to come out with the estimates.

13. Couple of other good engineering practices include,

• Daily code reviews
• peer reviews
• Continuous integration
• Daily builds
• Regression testing using Selenium
• Unit testing using JUnits and EasyMock
  

14. Interestingly we didn't have a separate testing team, it was the developers responsibility to test it thoroughly and release it to the customer for UAT.

Above method that I had applied is a very simple one and does not have too many ceremonies attached to them.

This project was successful, team and the customer was happy.