Remote Team Members with Agile Scrum

Even under the best circumstances, not having Agile Scrum teams collocated is difficult. There are lots of issues some of which have fairly easy answers, and some don't. We have a partial team in Cost Rica and our teammates in CR have done a great job given the physical separation from the main teams, however it has been lots of issues and difficulties (which I'm sure they can attest to).

• Scrum is about face to face problem solving, decision making, and team collaboration. Some collaboration can be done online and some just happens as talk goes back and forth in the team area. Going overboard with electronic communication in this area (in addition to regularly scheduled communication) is the only way to really address it. Setup web cams, chat clients, and even team area web cams (to catch banter, team play, team work, and all that happens). Of course meetings have to all be connected with audio and visual (use VOIP and remote sharing for low cost solutions). We also did bring the remote developers in-house for a month training. I would consider this essential to starting team relationships that will are ultra-critical for Agile (and three months would be a better time frame than the one month we used).
  
  
• Ultra clear communication required. This is not indigenous to Agile, but applies to any type of non-collocated project team. Having worked at HP for over 10 years with multiple teams around the world, I know that working together with my remote partners required constant vigilance for changes, plans, retro's etc. The big problem is that, with traditional waterfall there is typically much more well defined requirements and milestones that remote teams can work from/toward. With Agile, we have only just enough of everything, including documentation, forcing frequent and face to face communication. This is a tough problem, no matter how good your people are. Of course there are other aspects of communication, from User Stories and Conditions of Satisfaction, to non-verbal communication (which is very difficult with remote teams), and team building. These all have to be addressed and solved.
  
  
• Meetings. Scrum is lightweight. The meetings are essential and critical to success. This means that remote locations (or team members) need to be included for Sprint Planning, Scrums, Reviews/Demos, and Retrospectives. Scrum also requires frequent impromptu meetings, where decisions are made. (Our Product Owners sit with the teams, further increasing the potentially for quick change and decision making). If the team doesn't communicate or connect like it should, there could be serious consequences. The only real workable solution in my opinion lies in making the remote location a team(s) of their own, and they need to be co-located with each other. This can be difficult in terms of economies of scale if you only want to keep a few remote team members - with more team mates remotely together you can save on fixed costs.

From my experience with remote teams in both Traditional and Agile environments, having remote team members will require lots of additional work, usually money, and lots and lots of patience. If you must have remote teams using Scrum, I highly recommend having them be their own team, make sure they have the communications technology and protocols in place, and remain as consistently Agile "by the book" as possible. <><

References:

1. http://tinyurl.com/non-it-scrum

More about Barriers

Barriers between the team and the Product Owner can come in the form of the old “us vs them” mentality, a lack of following process (stories, conditions of satisfaction, poor tasking, lack of commitment, etc), a lack of understanding of what's being asked for, and good old fashioned lack of trust. The SM can help remove barriers by keeping some of the following in mind.

Ensure that the PO is part of the team. If the PO is treated or acts like someone not on the team, there won't be trust and willingness to interact in a positive and persistent way. The team (including the PO) needs to be able to check their egos at the door and be able to ask questions, challenge assumptions, accept ideas and differences, and at the end of the day remember that they are all shooting for the same thing - working software at the end of the sprint.

Emulate correct behavior. This applies to interpersonal behavior (being reasonable, inquisitive, respectful) as well as following team rules, culture, and accepted practice (except where that interferes with delivering working software at the end of the sprint).

Ensure that the team and the Product Owner are on the same page. Do this by asking questions of both sides, by checking assumptions, and facilitating regular and adhoc communication. Ensure that the schedule is followed and be proactive in anticipating events that might impact it (certain stakeholder must be there but can't be, technical limitations such as development or UAT environment issues, etc).

Ensure that the Product Owner is involved closely with the team on a daily basis. The PO should be attending the daily Scrum so that he can hear if there are impediments that require his attention (clarification of conditions of satisfaction or a story, priority decisions, etc). If possible, the PO should be co-located with the team so that they are building a relationship and learn how to deal with one another on a daily basis. Also, the PO can pair with programmers to develop/understand/clarify requirements as questions arise, not later when it's too late.

The ScrumMaster should take personal responsibility to own the process and the interaction between team and the PO. Whether by title or personal charisma, the SM needs to take personal responsibility and ownership for how the team and the PO behave together. This may be demonstrated by orchestrating adhoc meetings, helping keep things on an even keel when tensions right high, or encouraging dependency on each other. It should be done “covertly” in the sense that the SM is just helping to facilitate the relationship, not necessarily be present at every connection.

The ScrumMaster can be an abstraction layer between the team and external forces that get in the way. In some cases the SM may act as a barrier between forces that tend to impede progress. Many times there are multiple competing priorities that the PO is having to sift through to make the best decision for the customer. The SM can help by facilitating organizational or social change, helping the team to understand why the backlog may look like it does, or simply being there as a resource for the PO to take advantage of for bouncing ideas around or getting technical feedback.

Publicize the success of the team. The SM needs to publicly praise the good efforts of the team and the PO. Since the PO is the “single-wringable-neck” they need the support of the team, just like the team needs the support of the PO when their scope has to be reduced or when they push back on a feature request and ask for more design review. When the SM tells the organization of the success of the team and PO, trust is built in this delivery mechanism, which helps all parties be more engergized, motivated, and empowered.

Preserve openness and transparency between team and the PO. One of the foundation aspects of Agile is transparency. Agile brings out the good and bad, so keeping a commitment to respect between all parties is essential. This doesn't come overnight, but the SM can help bridge the gap by working to build a relationship with the PO and their stakeholders as well as the team. When issues seem to be running under the surface, the SM can ask questions (at the right time) about what is going on? He can help parties save face, but at the same time accept responsibility. This takes a willingness to be on the edge of conflict sometimes, but done well, can enable the team to build an open relationship with themselves and the organization.

Inspect and adapt. This is also part of the core of the Agile framework. The SM can help remove barriers by ensuring that the Agile inspection and adaptation process is followed as intended. It is also where the SM needs to ensure that follow up happens with retrospectives, with impediments, and with team productivity.

Push for continuous improvement of the process. The SM needs to remember that in most organizations, not every aspect of Agile will be implemented all at once, or done to the vanilla optimum that may be needed. The SM needs to have patience and ask the team and PO to grow at the pace they can readily absorb change. This will be faster or slower depending on the people and organization.

Help the team and PO to deliver the most value possible. Keep the team and PO focused, not on positions, but on objectives and purpose and goals. The goal is to deliver as much value as possible. When the team or the PO gets focused elsewhere, it becomes an impediment, no matter how cool or nifty it may seem. Keep the simple dictum, “a little better than before.”

Removing barriers is the core of the ScrumMaster's role. Learning how to be an expert at this will enable the team to do more than they could have done on their own. <><

Some of this discussion was taken from my linkedin q&a. Thank you to all those that contributed to that discussion.