Posts Tagged ‘distributed’

I did this retrospective with one of my teams recently, and seeing as the feedback afterwards was really positive, I thought I would share. First off, kudos to The Virtual Agile Coach for creating this retrospective in the first place. I don’t have a paid Miro account so had to recreate the experience in Powerpoint (file attached), but he had done the heavy lifting and Miro templates are available on his amazing site for those with the power to import.

Some context to add is that I have had some push-back from the team in the past when it came to activities in meetings that they did not regard as “work”. For example, some people don’t like random check-ins while others complain when we have to interact with a visual aid (“can’t we just talk?”). As an experiment, for this retrospective, I explained the “why” behind each of the facilitation activities I was using. And I believe it helped 🙂

Another note is that although I have indicated the timeboxes I used, it’s worth mentioning that this was a fairly large group (14 people) which brings its own challenges. For example, if you have a smaller team, then potentially break-out rooms would not be necessary.

1) Setting the Scene [10 minutes]

First I shared the Miro board link in the chat (I had already shared it before the session, but wanted to make sure everyone could get there) while we were waiting for people to join.

Then we started with an activity. I pasted the following instruction in the chat:

Take turns to answer this
==========================
What FRUIT are you today? (and, if you want to share, why?)

We used https://wheeldecide.com/ (which I had set up with the team names and to remove an entry after each spin) to decide the order for people to share in.

I also gave the instructions verbally.

Before we started, I explained why we were doing the activity:
“When a person doesn’t speak at the beginning of a meeting, that person has tacit permission to remain silent for the rest of the session (and often will). We want to ensure that no one has a subconscious barrier to speaking up in our retrospective because it is important that everyone feels able to contribute equally.”

Remember to pause before you spin the wheel for the first time so people have a chance to think about what they will answer.

After the “fruit” check-in, we went to the Miro board and I reminded everyone why we did retrospectives (The Agile Principle) and the mindset we were meant to have during the discussion (The Prime Directive). I also ran through the agenda.

2) Gather Data (1): Silent Writing [4 minutes]

Gather Data

I pasted the next instruction into the chat before I started speaking (it included a link to the correct Miro frame):

Silent writing for 4 minutes. Add stickies to the sections on the Miro board.

I explained why we were doing silent writing:
“Some people need time to stop and think or are not able to think while other people are talking. We’d like to give those people a chance to gather their thoughts before we move into a stage where we want them to listen to the “speak to think” people in the room. Another reason we’re doing silent writing is it is easier for the human brain to stay engaged and focused when we engage at least two of our senses. So in this instance people are seeing and typing (movement). And having a whiteboard in general means you can capture notes (movement) and listen at the same time. Another reason it’s good to capture notes is sometimes people might have to step away, or will be briefly distracted, and then there is a visual representation of what they might have missed and they can catch up with the rest of the group. We also have some team members who cannot be here today, and this creates something they can refer to when they are back at work. Lastly, our brains can only hold 5-8 items at any one time, so by writing down our thoughts before we move into conversation, it means we can focus on listening rather than trying to remember what we want to say.”

I then reiterated the instruction and played the song “Another One Bites the Dust” while they performed the activity (because the length of the song is almost 4 minutes).

3) Gather Data (2): Conversation [6 minutes]

Once again, I started with pasting the instructions (the same link as for silent writing) into the chat:

--- Breakout Rooms: Discuss Queen ----
Discuss what's been written. Add any new thoughts.

I explained that we would be going into break-out rooms of 3-4 people randomly assigned by Zoom and that each group would have about five minutes to discuss what they could see on the board plus add any new thoughts out of the discussion.

I explained why we were using breakout rooms:
“We want everyone to have a chance to speak, and because we are so many people, to do so in one group would take a long time. Breaking up into smaller groups means we can have some of those conversations in parallel. It’s also easier for people to connect online when they are in a smaller group and our brains find smaller groups less tiring, particularly when using a tool like Zoom.”

I then repeated the instructions and sent everyone into break-out rooms.

4) Generate Insights [15 – 17 minutes]

Generate Insights

Once everyone was back, I added the next instruction to the chat (with a new link to the relevant frame on Miro):

----- Breakout Rooms: Generate Insights ---
Talk about what stands out? What surprised you? What patterns do you see? What is missing?
(You can add notes -> miro_link )

I then told the group we would be going into break-out rooms again (this time with new people) and this time the idea was to step back and look for patterns or trends. To try see things from a new/different perspective. I mentioned that the instructions were in the chat and that there was a space on the Miro board to add notes (if they wanted to). I also said that we would be having a debrief of what was discussed as a single group when everyone came back from the break-out rooms.

Before I opened the new rooms, I checked in as to whether the first break-out slot had been long enough. One group mentioned that they hadn’t really managed to get to everything so, as we were running ahead of schedule, I added an extra two minutes to the five-minute break-out room timebox.

While people were in the break-out rooms, I added a funny hat to my Zoom attire.

When everyone had returned from the break-out rooms, we made time for discussions. This is where, as a facilitator, you need to be prepared for awkward silences! Once the first group had had their turn, things flowed again. I was ready to add any additional comments/notes that came out of the debrief however, in this instance, there were none.

5) What could we do? [5 minutes]

The chat instruction:

Please add ideas for what we can try next sprint to the "Ideas" section -> miro_link
We will then have a 10 minute break until xx:xx

I explained that we had gathered data and highlighted any trends or observations, and now we had to decide what we wanted to try in our next sprint. The first part of that process was to capture and share our ideas. We would do this by having five minutes of silent writing, followed by a 10 minute break, and when we returned after our break we would discuss the ideas on the board. I told the team that I would be playing music for the silent-writing part, however people could use the time as they chose, as long as they had captured their ideas by the time we returned from our break. After checking for any questions, I started playing the song: “I want it all“.

While the song was playing, I kept my camera on as a visible indication that the break hadn’t officially started. When the song finished playing, I turned my camera and microphone off (we generally stay in the Zoom room for breaks) and re-iterated in the chat window what time everyone was expected to be back.

6) What will we do? [Remainder of the timebox – approx 30 min]

I changed my Zoom hat again for the final part of the session, and reminded the team that we were aiming to shape our ideas into at least one action or first step that we wanted to try in our next sprint. We started with a debrief of the ideas that had been added to the board, particularly the ones that were not so specific and more like thinking items (so that we could generate some specific ideas for what we could try).

Once we were done discussing, we used Menti to rank vote the actions we’d come up with. One could also use something like dot voting. I used Menti because my team are familiar with Menti and I find it’s quicker to update ‘just in time’. As an aside, before we rank vote, we also usually get the team’s input as to the impact/effort for each of the proposed actions. For this session, it actually led to further discussion, because one team member realised that they didn’t know enough about the action to be able to rate the effort to do it.

Effort vs Impact of Actions

Once ranked, we took the top ranked action and ensured that it was SMART. At that point we were out of time, so I asked the team if we were OK to end the session. Sometimes in the past we have decided to take more than one action into our sprint (but we try limit it to no more than three).

We also always do a fist-to-five to ensure everyone can live with the SMART action(s) as described. I like to use a Zoom poll for this.

7) Close

To close the session, I re-capped what we had done during the session (starting with the check-in activity) and that we had agreed to one action for the next sprint. I reminded people who had specific actions from our discussions about their tasks. Finally, I asked the team if they would give me feedback on Miro by

  1. Dragging a dot to rate the retrospective out of five
  2. Where they had comments (things to keep doing, things to stop doing), adding those thoughts to a sticky

And, with that, we thanked each other and ended our sprint retrospective.


If you give a similar retrospective a try, let me know how it goes. I would be interested what did and did not work for you and your team.

 

My team had been working together for three sprints. During this time we’d been grooming and delivering stories (into Prod) but we had not done any sizing. Our Product Owner and business stakeholders were getting twitchy (“how long will we take?” – see How big is it?) and it was time to use our data to create some baselines for us to use going forward (and, as a side benefit, to find out what our velocity was).

Besides the fact that it was a new team, this team was also very large (15 people), some of them had never done an Affinity Sizing type exercise before, and we were 100% distributed (thanks to COVID19). Quite the facilitation challenge compared to the usual exercise requiring nothing more than a couple of index cards, masking tape and some planning poker cards. This is what I did and how it worked out.

1. Preparation

First, I needed something I could use to mimic the laying out of cards in a single view. As we’d already done three sprints of stories, there were a number of cards to distribute and I didn’t want to be limited to an A4 Word document page or Powerpoint slide. This meant a whiteboard (unlimited space) was required and we eventually ended up using a free version of  Miro.

Second, with my tool selected, I needed to make sure everyone in the team could actually access/use the tool. Unfortunately, Miro does require one to create an account, so prior to the workshop I sent a request to everyone on the team to try and access an “icebreaker” board.

Third, I needed to prepare my two boards:

  • The Icebreaker board which was to serve three purposes:
    1. Give people something to play around with so they could practise dragging and interacting with Miro
    2. Set the scene in terms of how sizing is different to estimating. Hopefully as a reminder to those who already knew, or as an eye-opener to those who might not.
    3. Use a similar format/process to the board I would be using for the Affinity Estimation exercise so that the team could get used to the process in a “safe” context before doing the “real thing”.
  • The Affinity Estimation board and related facilitation resources.

The Icebreaker Board

Ball game start

This layout matched the starting point of the Affinity Estimation exercise.

There was a reminder of what “size” was for the purposes of the exercise in red (1) and instructions for how to add the items to the scale (2). The block on the left was for the “stories” (balls) that needed to be arranged on the scale.

The Affinity Sizing Board

(I forgot to take a screenshot of the blank version, so this is a “simulation” of what it looked like.)

same blank stories

“Simulation”

For the Affinity Sizing, besides the board, I also prepared a few more things:

  1. A list of the stories (from JIRA) including their JIRA number and story title in a format that would be easy to copy and paste.
  2. The description of each story (from JIRA) prefixed with the JIRA number in a format that was easy to copy and paste
  3. I asked one of the team members if they would be prepared to track the exercise and ensure we didn’t accidentally skip a story.

A reminder that at the point when we did this exercise, we were about to end our third sprint, so we used all the stories from our first three sprints for the workshop (even the ones still in progress).

2. The session

The session was done in Zoom and started with the usual introduction: what was the purpose and desired outcomes.

From there, I asked the team members to access the “icebreaker board”. In the end, I had to leave the team to figure out how to use this board for themselves while I dealt with some technical issues certain team members were experiencing, so couldn’t observe what happened. However, when I was able to get back to them, I was happy enough with the final outcome to move on.

balls 2

Round 1: Small to Large

To kick things off, I copied and pasted the first story from my prepared list (random order) into a sticky and the story description (in case people needed more detail) into a separate “reference” block on the edge of the whiteboard. The first person to go then had to drag the story to where they thought it best fit on the scale.

From the second person onwards, we went down the list and asked each person whether they:

  1. Wanted to move any of the story-stickies that had already been placed or,
  2. Wanted a new story to add to the scale

A note here – it might be tempting to have some team members observe rather than participate (e.g. your designer or a brand new team member); however, I find that because mistakes will self-correct, there is more benefit in including everyone in the process.

We repeated the process until all the stories had been placed on the scale. At this point, it looked something like this (again, a “simulation”):

round 1 Round 2: Buckets

At this point I used two data points to make an educated “guess” to create a reference point.

  1. I knew that our biggest story to date was of a size that we could probably fit 2-3 of them in a sprint
  2. I could see where the stories had “bunched” on the scale.

So I picked the first biggest bunch and created a bucket for them which I numbered “5”. Then I drew buckets to the left (1,2,3) and to the right (8,13,20) and moved everything that wasn’t in the “5” bucket down to below the updated scale/grid (but still in the same order left-to-right).

buckets

Before we continued, I checked with the team whether the felt all the stories in the 5-bucket were actually about the same size. They did (but if there had been one that they felt might not be, it would have been moved out to join the others below the buckets). After this point, the stickies that had been placed in bucket five at the start of the process were fixed/locked i.e. they could not move.

Then we repeated the process again where each person was asked whether they

  1. Wanted to move a story-sticky that had already been placed into a bucket, or
  2. Move one of the unplaced story-stickies into a bucket

Initially, some people moved a couple of stories on their turn into buckets, which I didn’t object to as long as they were moving them all into the same bucket. Again, I was confident that the team would self-correct any really off assumptions.

We had one story that moved back-and-forth between bucket 1 and 2 a few times, and eventually, the team had a more detailed discussion and made a call and that story wasn’t allowed to move again (I also flagged it as a bad baseline and didn’t include it in future sizing conversations).

Once all the story-stickies had been placed in a bucket, everyone had one last turn to either approve the board or move something. When we got through a round of everyone with no moves, the exercise was done:

stories

The actual outcome of the workshop

Even with technical difficulties and approximately 15 people in the room, we got all of this done in 90 minutes. This is still longer than it would usually take face-to-face (I’d have expected to have needed half the time for a collocated session), but I thought it was pretty good going. And the feedback from the participants was also generally positive 🙂

These stories (except for the one I mentioned) then became baseline stories for comparing to when we did future backlog refinement. Also, because I now knew the total number of points the team had completed in the three sprints (sum of all the stories), we also now knew what our initial velocity was.

Have you ever tried to use Affinity Estimation to determine baselines? Have you tried to do so with a distributed team? What tools did you use? How did it go?

 

download In my opinion, one way to make a team coach feel really useless, is distribute their team across multiple locations where it’s really hard to observe their interactions with one another. For me, a lot of my “obvious” work and channels disappeared when that happened and it’s taken me a while to find alternative ways to provide the insights and support that my team needs. I also had to take a step back and acknowledge that when working distributed, certain elements of effective co-located collaboration no longer matter or have negligible impact on team greatness, whereas new elements turn out to be important levers. The trick, it turns out, is to identify what exactly those are. And I suspect, as always, that they will be different for each team.

For example, the daily stand-up or Scrum. A time for the team to sync up and share what happened the day before so that they can plan and adjust for the day to come. An opportunity to celebrate achievements and adjust for disappointments. A good time to interact and build some team rapport. The standard method is everyone stands up (to help maintain focus and brevity) around a task board (for visibility) and speaks to what they achieved yesterday (speaking and moving their tasks to show progress and create psychological ownership) and what they hope to achieve today that will help the team achieve their sprint goal. The Scrum Master and Product Owner observe – and perhaps facilitate – and ask questions where blockers might be hiding in what the team has to say. And the outcome is everyone on the team walks away with a plan for how they will contribute to the team’s success today – and a commitment to each other that they will do their utmost to complete what they have agreed to do for the day.

There are some parallels when we are working distributed – the task board, for example. There are some practices that are just impractical – like standing up. And there are others that may detract more than they add (for example, in our case, it seems less confusing to have one “driver” for the session than to pass control during the stand-up). Sometimes the limitations are tool-related. Sometimes it’s just the nature of working as a distributed team.

So what changes have I tried when facilitating a distributed stand-up? So far, these ones seem to be working:

  1. I try to watch all of the faces. We use Zoom and there is a setting where you can view all of the attendees on a single screen. Whenever we have a distributed meeting – not only stand-up – I spend most of my time and attention watching the faces of the attendees. It’s a good way to notice how people are responding to the session and give clues as to when people are tired (my team can’t do distributed for much longer than 45 minutes), or confused, or distracted, or are trying to ask a question.
  2. I make a note of who has spoken or been “spoken for” in terms of the plan for the day. Basically I listen out for what each person or pair is doing today and at the end of the stand-up, I explicitly ask individuals to share where I haven’t managed to tick them off on my list of names. Note, this is less about everyone having a chance to speak, and more to ensure everyone has made visible to the team what they plan to do for the day. I’ve noticed it’s really hard for my team to keep track of this themselves in a distributed stand-up.
  3. I try to notice if people are trying to say something and find ways to ensure that they get a chance to speak without speaking over the person who is currently speaking. Sometimes this may mean providing an order for people to speak in (you then you then you) if a group happens to accidentally speak over each other.
  4. In my opinion, certain on-line tools (like a digital task board) may satisfy the superficial purpose of the physical tool (e.g. visible stories and tasks for the team to talk to), but not necessarily the deeper purpose (e.g. the psychological ownership that comes with writing and moving a physical sticky). So I’m continuously researching and experimenting with new ways to achieve these outcomes within the context of a distributed team.

For me, the following facilitation activities are still valuable when facilitating  a distributed stand-up

  1. When necessary, introducing the session to re-confirm the purpose and outcomes – especially if there are newer team members or things have started to go a little off-track
  2. Listening out for impediment words
  3. Using open-ended questions to help the team develop insights or notice information

One thing I have noticed, is paying attention in a distributed session is REALLY exhausting. It is also very difficult to split your attention between people “watching” and understanding the content. In my case, I have decided to prioritise the former over the latter, which sometimes leads to other interesting side-effects. On the upside, I’ve become great at asking “stupid questions” 😉

What have your experiences been with distributed stand-ups? What were the challenges? What were the opportunities?

I am currently working with a distributed team and we use JIRA for our sprint task board. We use it in our daily scrum (I can’t call it a stand-up) via Zoom. Over time, I’ve noticed that there are some things that come “for free” with a physical board, but are hidden or not as obviously visible on a digital board (at least not in JIRA). We have found workarounds for some and not for others and, perhaps, depending on the team, not having some of this information “in your face” might be OK. However, I thought I’d make a list of things to look out for if you happen to be using a digital rather than physical board for your team. Also this blog is all about learning 🙂

Please note, I’m only basing my observations on JIRA for this blog post because that is what we use. I suspect that most digital task boards have similar issues.

1. Who’s doing what?

My teams in the past have used personalised avatars to indicate who’s doing what task(s) for the day. We found this had two related benefits:

  1. You were naturally constrained to the number of avatars you happened to have available to you (although it was still fairly easy to take on more merely by initialing the sticky).
  2. It was very easy to see at a glance where a task had too many people, or where one person seemed to have spread themselves to thin, or where someone hadn’t committed themselves to a task.

When asking the question, “what do you notice about our focus?”, it was easy for the team to notice where they may have over- or under-committed themselves for the day. Or to notice and confirm where they were swarming for the day.

In JIRA, only one person can be assigned to a task. It’s not visually obvious where multiple people are working on a task. Also, because we usually only expand the story we’re currently talking about – and usually our full sprint of stories doesn’t fit into the view if we expand all rows – it’s very hard for the team to see good and bad patterns in how they have allocated themselves to tasks for the day.

2. Where are we stuck?

One of the tools one can use on a physical board when it seems a team is taking a while to get things done, is to start dotting tasks. The idea is that a task gets dotted for every day that it has been in progress and not finished. As the task develops measles, it’s pretty obvious where someone may be blocked or may need help.

JIRA does have the concept of task-dotting, but it’s very hard to see (it’s a light gray) and unfortunately the dots don’t stick around. They disappear as soon as someone moves the task to the next column on the board (so, for example, a task that may have been in progress for two days will suddenly have no dots when it moves to the show me column).

When dots have measles, it’s easier for the team to notice where tasks are dragging on for days and do something about it. You don’t really want tasks that have started to take more than a day to finish.

3. How big is our story?

This is probably (hopefully?) a JIRA funny. When we’re viewing the active sprint and sprint board, the story points aren’t visible. Assuming you use story points, they can be useful in helping the team notice when a story is taking too long – a supplement to the burn-down (see below) and tasks with measles (point 2 above). We have a workaround in that we add the story points to the end of the story title. It would be cool not to have to do this.

4. What’s our progress?

JIRA generates a pretty cool burn-down. But it’s not visible on the sprint task-board (which is the view we use for our Scrum meeting). How you’re doing on your burn-down is quite an important piece of feedback for how to adjust your plan for the day. Our workaround is to publish it on Slack before we meet, but it would still be useful to have it visible for the conversation.

5. What’s our goal?

I love (good) sprint goals. I find they give the team something specific to aim for that still allows for creative ways to respond to minor changes that emerge during the sprint. Goals are also a really useful way to bring the team back to the bigger picture in terms of sprint progress: “Are we on track to achieve our goal?”; “What are you doing today to help the team achieve the goal?”. So we create an awesome team sprint goal and ideally we want to have it front-of-mind when planning our tasks for the day. On a physical board, this is easy: it can be as simple as printing your goal on a piece of paper and sticking it to the board (ideally in colour and with sparkles). On a digital board, one needs to get a little more creative. In our case, we write the goal as a story at the top of the sprint and try remember to refer to it before we start our daily conversation. It seems to be working, but it does blend into all the other sprint work.

6. There are other aggregate data questions that are harder to answer

As Jacques de Vos once said: “If you have to scroll, you can’t see the whole“.

With a physical board, the team can usually notice useful things when answering questions like:

  • What do you notice about our tasks in progress?
  • Where do we seem to have the most focus?
  • What do we notice on the board about stories not started?
  • What do we notice about the state of our overall sprint in terms of stories in progress and not started?

Usually a quick glance at how stickies (whether stories or tasks) are grouped in the various lanes of the task board can provide a lot of insight into how things are going – especially if the distribution pattern is looking different to what the team is used to and/or expects to see. With JIRA, this view isn’t easily available. Expanding all of the rows creates a very busy view which is also not guaranteed to fit without the need to scroll. Collapsing the rows hides the task distribution (which may hide other things) and also the story status is represented by a word rather than the story’s location relative to the board’s columns and other stories.

7. There’s usually a driver

The way we use JIRA, someone screen-shares the taskboard in our Zoom session and that person automatically becomes the ‘driver’. What I’ve noticed about this is:

  • People are less likely to interact with the board during stand-up: they’d rather ask the driver to make updates or create emergent tasks
  • Some people are scared to drive (probably a tool thing – either JIRA and/or Zoom), so never do
  • The driver can get distracted by the mechanics of having the right story expanded, or making changes in JIRA, or whatever – so are not always fully present in the conversation
  • If the driver ends up being someone in a “leadership” position (e.g. a senior developer, the Product Owner), then sometimes they subtly control the decisions the team makes in terms of what they plan to do for the day because they can move things or assign things before the team have finished their discussion
  • All of the above means that the negative aspects of “you do it, you own it” sometimes sneak in…

I shared some of these challenges on the #zacoachclub channel in the Coaching Circles Slack Group and got some useful ideas to try out:

  • Write down in detail what information you really need the board to show so that it becomes your information radiator. Then lose all pre-conceived notions of how a board should look and how your tool sets up its boards. Based on the info you need: what could a board in your digital tool look like?
  • Try to represent the info you need in something other than your tool (i.e. JIRA) – maybe Google Draw or something. Once you have something that works, try implement that in your digital tool.
  • If the problem is too many things on the board, could your sprint/commitment be smaller to fit everything in one view?
  • Create a filter that filters out “old” done items and try to only work from the top story (limit work-in-progress).
  • Shift some of the information elsewhere e.g. Say pairs work on the story – they break down tasks in another place (Trello?) and feed back only relevant info to the greater team on the story which is in JIRA. Feedback to their mini team is much more granular and on another board/tool.

Do you use a digital board on your team? What challenges have you experienced? What did you try?

Scrum-Task-Board

This is a post in a series on the talks that I attended at my first ever Agile Africa Conference in Johannesburg. All posts are based on the sketch-notes that I took in the sessions. 

agileafricaSam and Karen started by clarifying what they meant by distributed teams: teams that don’t sit in the same location. They then categorised distributed teams into three main categories:

  1. Teams that work in the same time zone and/or the majority of their working/office hours overlap
  2. Teams that work in different time zones but there is some overlap of working/office hours
  3. Teams that work in different time zones or have different shifts so that there is no overlap of working/office hours.

For each, they then shared some common characteristics and where best to focus energy.

Full Overlap

These teams are characterised by synchronous communication. Here the best focus would be on technology and tools to ensure that communication is as easy as possible when people are distributed. They suggested some ideas like a video wall (expensive option) or running Skype continuously in the background (cheap option) to allow synchronous communication and cues to happen as naturally as possible.

Partial Overlap

Communication in these teams is largely asynchronous (e.g. email), so time together is valuable. Rather than use this time for things that can be communicated is an asynchronous manner, focus on using team time to create understanding. A practical example in the Scrum world is rather than use overlapping time for something like a stand-up (which can also be done via an update in most cases), use it for things like Grooming and Planning where more complicated conversations are required to flesh out understanding and work through difficult problems.

No Overlap

Their main ideas here related to being creative with

  • Tools e.g. creating a video for reviews and stand-up that can be distributed to the other team(s)
  • Rotating a team member who “takes one for the team” and changes their office hours so that there is some overlap with the other team(s).
  • Planning work to try to keep work where there are dependencies in teams that are working in similar time zones.

Besides the advice above, they also had the following general tips:

  • Use Good Technology
  • Have and Use Working Agreements
    • “Bottom Line” – a phrase used when people start to waffle and need to get to the point
    • Talking Over – agreement on what happens if people talk over each other. One idea is to give the facilitator permission to provide the order of who speaks in what order.
    • Multiple back-up plans – So if (when) the technology fails, everyone automatically knows which one to try next (and it doesn’t need to be discussed)
    • Silence – Silence is OK
  • Good Voice Trumps Bad Video
  • Same Experience for All
    • If one person needs to dial in, then everyone should dial in
  • Prepare
    • Prepare for sessions more than you would for face-to-face: agendas, tools, pre-reading, etc.

You can find more tips at RemoteAgileCoach.com.

I’ve shared some of my thoughts on distributed teams in a previous post. What have your experiences been with working on a Distributed Team?

chasm1I’m currently a member of a coaching circle and our topic last week was “Non co-located or distributed teams”. Then this week someone from our marketing department approached me. We’ve decided to bring our public website in-house and they need a new team, but history has shown us that finding new developers of the calibre we want is no easy feat. One option we haven’t explored to date is developers who work remotely (which would mean we could look farther afield) and he wanted to know what my opinions were. I offered to compile some information for him, including some of the conclusions from my coaching circle discussion, and then figured it was worth adding it to my blog too.

I have worked in distributed teams before – from formal project teams with developers on-site in Cape Town working with off-site analysts, testers and project managers in London; to informal ‘leadership’ teams across offices over three locations and two countries; to performance managing direct reports working in an office 2000 km away. The common point of success or failure every time? The people on the team. The next biggest point of frustration every time? The type and quality of communication tools available.

People

There is a lot of literature out there around the types of behaviours you want in agile team members and, obviously, each company also has its own set of values and culture it looks for in new hires. This list is a list of traits that stood out for me as things that made someone great to collaborate with when working in a distributed fashion. All too often, people without these traits made distributed collaboration quite difficult and sometimes impossible!

  • Emotional maturity – able to communicate without getting emotional about things; can handle openness.
  • Strong team norms – when the team agrees to try something or work in a particular way, this person will take accountability for whatever they have to do even if it wasn’t their preferred way of doing things
  • Effective communication – verbal and written. Can write and read well. Can get their point across and summarise well.
  • Takes responsibility for preparation – if things are distributed beforehand for people to read or prepare, then this work is done. Doesn’t walk into meetings “blind”.
  • Knows how to use tools and knows about conference call etiquette (this could be covered as training for the whole team).
  • Is proactive in staying ‘in the loop’ – will ask questions if they see something that they don’t know about (defaults to information gathering rather than assuming if it was important enough someone would let them know).
  • A T-shaped person – or at least someone who is prepared to do tasks that are not ‘part of their job description’

 

Other Success Factors

This list was compiled by my coaching circle:

  1. Face-to-face is necessary for initial trust building and to create coherence. Where possible, having everyone co-located for a period at the start of the project makes a huge difference. Also gets people used to the way others work without the ‘noise’ of not being co-located.
  2. Would be helpful to find ways to have online virtual interaction (outside of work) e.g. online games/ice breakers/other experiences.
  3. Face-to-face tools are a must.
  4. After an extended period, it helps to have team members ‘rotate’ as traveling ambassadors.
  5. Need to understand cultural differences. Probably worth having a facilitated session to highlight/understand these.
  6. If you have teams working in areas, then have an on-site SM/coach per team.
  7. Keep teams small.
  8. Try pair/collaborate with an offsite person as often as possible.
  9. If you have teams in different locations, have a dedicated facilitator in each location for meetings (like planning, review).

CoherenceCulture

Links

What has your experience been with working in or with distributed teams? What did and did not work for you?