This note has a slightly more formal tone than my last few posts. I've decided to start capturing or creating some process nugets that I can use in my next position where ever that may be. Hence I'm posting them here for anyone to comment on.
One of the key processes in an Agile Scrum development is the daily stand up or Scrum meeting. Yet there are many teams who seek to be Agile but are part of distributed or virtual teams. This article describes a mitigation for the the lack of collocation either due to permanent distribution as in geographically distributed teams or “plan B” meetings on “snow days”. This virtual daily scrum process cannot replace the benefits for a real scrum meeting with rich non verbal communication but it can be a very effective process in a distributed or “Scrum But” environment.
“Necessity is the mother of invention. “ After having had the experience of leading Agile teams and doing some consulting on Agile adoption I found myself in a new situation with a widely distributed team that was enthusiastic about moving to an Agile development process but couldn’t change the fact that they were distributed across 3 continents. I was well aware that a truly effective Agile team is collocated yet we had some people working from home and others 10.5 time zones away. What could we do? My sense was that we were not alone and distributed teams are very popular and not just unique to my organization.
Thinking about this I noted that my children were utilizing various types of social media mechanisms to share information about all sorts of things that teens and twenty something’s talk about. (Twitter, FaceBook, text messages, etc) These kids have very little in the way of financial resources yet they have a better communication infrastructure than I do in my for profit organization with a million dollar project budget! The conclusion I came to is that we could have a virtual daily scrum as one of the corner stone communication processes in our distributed team that wanted to be Agile. We couldn’t do conference calls on a daily basis because we were already doing weekly team meetings. The imposition and personal stress that live daily teleconferences would involve on a daily basis would be too much for many of the team members. That left us with the written word as the communication medium.
We ran for a while with a specially customized team discussion SharePoint web part but later settled on using Yammer after one of the team members discovered and suggested using this for the virtual daily scrum meeting. See http://Yammer.com . There are also a growing set of tools that support collaboration among Agile team members. I suspect if they haven’t already, some will support this process. My team was financially constrained and we were lucky in that we could deploy Yammer without getting approval for spending money.
Yammer is a web site which resembles Twitter but is designed for business. A key difference from Twitter is that one can control the scope of communication with a Yammer group. With Yammer communication is implicitly limited to individuals with the same email domain name. Hence with Yammer one can only communicate with co workers. However with a Yammer group, a Scrum Master or some team member can invite and further control who can participate and view messages that are posted to the group. The Yammer group then consists of everyone who would participate in a typical daily Scrum team meeting. If your organization has even more stringent administration or security requirements there are for fee models of Yammer usage.
The primary activity for a team member when participating in a Virtual daily Scrum is to post a simple short message (under 140 characters) that answers the daily question “what are you working on and what if anything, is blocking you”. They should also “listen to” or review the most recent postings of other team members in the same group.
Yammer supports two different communication models. One is “following” individuals; the other is “Group” communication. Yammer allows people to “follow” other people in the same company to view and reply to messages posted just as is done in public with Twitter but that communication is outside and beyond this process description. Whoever facilitates the introduction of Yammer and virtual daily scrums to the team should discourage but not forbid people from “following” other people. For people where this is a new communication process “following” people will just make initial adoption more confusing. On the other hand if they understand and are enthusiastic about following people let them go ahead. Just explain that “following” is beyond the virtual daily scrum meeting process that you are trying to facilitate. It is important that all understand the two different types of communication with different goals otherwise people will view it as one Yammer blob.
One of the members serves as a moderator. One of the members of the group leads by making their own postings and monitoring what is going on just as a Scrum Master would do in a normal live meeting. Yammer has the role of group administrator. This person invites people to participate in the group and accepts of rejects requests for membership in the group. Ideally a group will be self organizing and establish norms that best serve the group. The following norms have arisen in successful groups in past projects.
• Every project team member creates one post per day. If you are familiar with the “pigs and chickens” metaphor, each “pig” should post one message every work day. Chickens (people who monitor the project) may be part of the Yammer group but should just read messages and follow up off line.
• The group moderator limits membership in the group to project team members. It can inhibit communication if too many people are present in the group. An especially tricky situation to manage is if the CIO, CTO or other executive asks to be part of this group. The Scrum master should personally discuss the pros and cons with the executive. Consider asking if this was a real meeting would they attend and indicate that you are attempting to emulate a real meeting.
• 80% or more of the content is project related. As in any meeting, an occasional comment about a sports team or new baby keeps things interesting but if discussion deviates too far from project work someone should bring things back to focus.
• Minimal use of the “reply” to group message. Hopefully the messages posted in the Yammer group will in some cases lead to conversations, phone calls, email, instant messages or other follow up communication. This is similar to the norm in a real scrum meeting of follow up discussion offline only with affected parties.
• Do not use Yammer as a platform to challenge or disagree with someone. The communication bandwidth is too low. Pick up the phone or arrange a real meeting.
Controlling the scope of communication with a Yammer group is important because it helps provide the same dynamic as limiting the standup meeting to 15 minutes. If one is expected to post a message and view the messages of several dozen people, this process is likely to break down. The fuzzy boundary and time commitment to view the postings of a large number of people slows adoption. With this process supported by Yammer we don’t forbid people from “following” others as they may do with Twitter but “following” people is a completely extraneous use of Yammer for a virtual daily scrum.
This is different and one can’t achieve the same benefits as a real daily scrum meeting that a collocated team can have but my distributed team adopted this process without much promotion. People seem to realize these benefits.
• Greater sense of community or team that couldn’t be achieved otherwise.
• Use of textual communication is sometimes easier for people who don’t all have English as their primary language.
• Support for a picture of the person is a nice touch and seems to foster more communication by making team members more aware of each other as people. Yammer helps this to happen in a really low overhead fashion. I’ve never prompted people to post their picture, 90% naturally just do it.
• Greater awareness of what each other is doing promotes more sharing and discourages working in silos and the subsequent integration issues. Working in silos is a greater risk when teams are distributed.
• Writing down each day what you hope to accomplish with it visible for all encourages faster learning. When you create a post each day using Yammer the words you wrote yesterday are right in front of you. The stage is set to encourage the personal reflection that promotes growth and learning. Hopefully, thoughts arise such as the following without anyone’s intervention- “Yesterday I said I’d complete unit testing of X, now it seems I still need another day. What did I miss that caused me to miss my estimate? Can I really get it done today?” In this respect it might actually encourage more leaning and accountability than a verbal comment in a real Scrum meeting where the words one said yesterday are not quite as present the next day.
A real scrum meeting is optimal and it is not suggested to use this when there is a choice. There is a lot that gets communicated by gestures, facial expressions and tone of voice that one can’t get with virtual daily scrum. Yet there is also a benefit to having the persistent written word to foster reflection on reality that encourages learning. Having the virtual daily scrum in your process tool box is a good idea someday you just may need to use it.