Monday, July 18, 2011

Using Scrum of Scrum (SoS) as an early warning system

Typically we use Scrum of Scrum (SoS) as a platform to address issues between teams on a multi-team agile projects. Mike Cohen has a good post on the basics of SoS. SoS (as the acronym aptly captures this intent) is a good way to synchronize teams and resolve issues as they arise. However, it is a reactive approach. A better approach would be to turn SoS into an early warning platform so that teams can be proactive about imminent issues and prevent them from becoming real issues. In the process save everyone "valuable" times, and probably frustrations.

With that intent in mind, I suggested the teams of a distributed Agile project that I'm coaching now to use these questions:
                         1.  Is anything slowing my team down or getting in my team's way?
                         2. Is my team about to put something in another team’s way (DB changes, interface changes, UI changes etc.)?
                         3. What stories or bugs have been completed by my team since we last met?

Question 2 primarily, and question 3 to some extent serve as the sources of early warning. However, I quickly realized that teams would not knowingly report that they are putting anything that would impede other teams. So, I changed the question to be more explicit about the intent:

                  2. Is my team going to make changes to any shared resources (DB changes, interface changes, UI changes etc.), or checking in significant codes by the end of today?

This seemed to have helped. The Scrum Masters now need to listen in their daily scrum meeting more carefully to understand and be able to answer questions 2 and 3. Additionally, the teams are also tracking any inter-team requests at the SoS meetings.

How do you use SoS on your project?

Friday, July 15, 2011

Remote team building on distributed Agile projects

Team camaraderie is important on any projects, but it is critical on Agile projects because Agile process requires close interactions. If you have distributed teams, it becomes challenging. It is important that you spend some time to make sure the teams gel together to get the best result for your Agile project.
 
Ideally, you would want to bring the teams together at one location for a sprint at the start of the project. The team members will get an opportunity to know each other while they start working on the project. You may want to do some explicit team building activities. Then you want to bring the teams together every so many sprints, maybe rotating the locations where they come together. Here is a nice case study on this.
 
Yes, it increases the cost of your project. Given how the economy is, you may not get the budget approved for the travel and associated costs. This is what happened to the project I'm working on as an Agile coach. As an alternative, we came up with a remote team building activity, which truned out to be very helpful.
 
Some backgorund on the teams
We wanted to faciliate a team building activity between two teams- one located in the West coast, and another in the East coast. The two teams did not know each other. This is the first time they are working together. One team was staffed by people from the client, and the other was by the vendor. As a result, there were some work culture differences. The teams were communicating through Scrum Masters and Proxy Product owners. Developers did not know each other and shyed away from communicating directly. Also getting in the way was the 3-hour time differences between the two teams. Overall, annonimity resulted in lack of trust and was contributing to the overall frustration between the teams.
 
Remote team building
We decided to faciliate a remote team buidling session using a vedio conferencing session. Prior to the event, we did the following:
 
1. We created a team profile for each team. It included some intro info about each person with a picture.
 
2. We paired each member of one team with another from the other team.
 
3. We sent them a list of questions and asked each pair to interview each other over the phone prior to the team event. A sample set of questions that we used to help prime the conversation:
 
                  1) What is your role on the project?
 
                  2) What is (are) your domain(s) of expertise?
 
                  3) What new capabilities are you learning on the project?
 
                  4) What are your pet peeves at workplace?
 
                 5) Tell us one interesting thing about you that no one knows.
 
                6) What is your favorite hobby? Why do you like it?
 
               Additonally we asked everyone to pick a question to ask their buddies.
 
4. The team event was divided into two parts. In the first part, we asked each pair to introduce their buddies to the whole team. In the second part, we made it free form (quizzed the team on what they learned about each other) with a deliberate effort to instigate conversations about things that the teams are struggling with.
 
Overall, everybody found the team building activity helpful. At the least, it broke the ice between the two teams, got them talking about issues (as you would expect in "storming stage" of a team/goup development), and opened up the communication. Some norms are starting to form from the storming.
 
I do not expect the trust to be built overnight. Still we need to continue to make deliberate efforts in making that happen. But, it was a good start. We plan to do this on a regular interval.
 
Some of the fun facts about these two teams
  •  One team is a all-women team.
  •  Eleven languages are spoken between the two teams.
  •  Six countries represented based on birth places.
Do you have a similar experience of team building?