Tips for Working Effectively with Distributed Team Members

In a few classes I have taught recently, we have had some interesting conversations around working on distributed agile teams.  I always recommend trying to keep your Scrum team co-located whenever possible but in today’s world, distributed teams are unavoidable.  Here are some suggestions to help keep your distributed team members more involved:

 

1.    If the majority of your team is in one location and a few members are remote, get a large stuffed animal, blow up doll (not the adult variety please), etc to represent your distributed team members.  Bring the doll, stuffed animal, etc to all of your meetings and put them in a chair.  You can even write the names of the people it represents on a sticky note and stick it on the doll. The visual reminder of the people on the phone helps keep the folks in the room aware of the team members on the phone.

2.    Draw a table on a whiteboard where the meeting is initiated.  Write the names of all attendees on the phone around the virtual table.

3.    Use an on-line, real time collaboration tool that all team members can access during meetings. The Scrum Master can then put relevant data here for everyone to see.  If you have a distributed team, a physical card wall may not be a good choice.  Look into using tools like the GreenHopper plug-in for Jira or Rally.

4.    Get a web-cam and use it often.  I know a company that has a webcam running all the time in each office and has it is pointing to the task board.  Everyone can log in and see it whenever they need to.  The web cams are also used for daily stand-ups, etc.

5.    In meetings where the purpose is to gather information and form an action plan such as planning meetings, retrospectives, etc, try using the round robin style of gathering information.  Go around the virtual room and ask each person to contribute.  This way, everyone has a chance to be heard.

6.    Publish any decisions made somewhere where the entire team can see it.  Don’t bury information on an intranet or share point site that no one goes to. 

7.    Create some simple, fun games with prizes that encourage team members to visit the place (intranet, wiki, etc)  where you keep important information (like action items from retrospectives, etc).  For example, put trivia questions from Jeopardy on the site and give a fun award at the end of your stand-up to whoever responds first with the correct answer.  Or, you can track the results each day during the sprint and then give an award at your sprint demo.

8.    Devote a few minutes during each retrospective to discuss remote team issues and to brainstorm on how to make things better.  Follow-up with an action plan and re-visit it after it sprint.

9.    Pick a few times a year where everyone travels to the same location at once.  This gives everyone a chance to meet each other face to face.

10.   If you are not remote, then act like a remote employee for a day every now and then (i.e. work from home).  See first hand what the remote people experience so you can better understand the challenges they may be facing.

 

The point here is to get creative and go beyond simple conference calls.  Your Scrum Master should own the responsibility of managing effective communication and collaboration with distributed team members.  Make sure you are getting regular feedback from your team members on what is working well and what isn’t.  Collaboration on your distributed teams should be a top priority and you should be willing to make the necessary investments to ensure that all team members feel like they are heard and are part of the team.

Quick, great read on agile testing

This blog post by Simon Baker is excellent and does a great job describing the role of a tester on an agile team.  http://www.think-box.co.uk/blog/2008/05/testers-in-our-agile-team.html

STP Conference Day 2

The morning started off with a Keynote from Robert Sabourin called “What is so Different about Testing in Scrum.”  I wouldn’t say the title of the talk really fit the talk itself but it was a good kick-off for the day.  If you have seen him speak before, then you know he is high energy and enthusiastic. 

His talk essentially gave a brief overview of Scrum and then walked through some case studies of teams he has worked with that were adopting Scrum and what some of their challenges and proposed solutions were.  It wasn’t surprising to hear that the challenges were centered on either lack of product ownership and/or testing team challenges.  I was hoping he would actually dive into some of the key differences in testing in Scrum like the title of the talk mentioned but he really didn’t go there.  No one seems to go there…again, another topic for another time. 

 

I went to 4 different talks.  Two of these talks were topics around agile testing.  I was disappointed by both of these talks in that they really didn’t get into any meat on the topics.  It was all high level principles with no actual techniques or take-aways on what to do and how to do it. 

 

One talk was on metrics.  The speaker was good and had good content for the most part.  However, I would argue that several of the metrics that were discussed really don’t provide any value to an organization.  For example, she mentioned tracking requirements stability as a metric.  Let’s say you do this and you discover that 40% of your requirements change.  So what.  What is that metric going to do for your team or organization?  Requirements always change.  Period.  We all know that…we should all be prepared for it.  Spending a significant amount of time (and therefore money) tracking how many requirements change doesn’t really help you to handle those changing requirements.  Why not invest that time and money into something that will help your team work effectively in the changing requirement world?

 

I ended the day with a talk by Matt Heusser called “Software Testing from the Ground Up.”  The published excerpt on the talk didn’t seem to match the talk itself.  I did enjoy some of the comparisons he made between testers and other professions, though. 

What makes a ScrumMaster a “good” ScrumMaster?

I was recently asked to help form a job description for a new ScrumMaster (SM) position in a company.  So, it got me thinking about what qualities and skills make up a good SM.  I thought back on teams I have been on that had good and some not-so-good SMs.  Most of the skills that come to mind when I think of a good SM are more of the “soft” skills.  Here are the ones I came up with: 

Intimately familiar with Scrum.  Since the SM owns the process, they must be intimately familiar with how Scrum works and be able to guide a team to find solutions to help them succeed.  This takes experience.  Most SMs come fresh out of CSM training and jump into the role.  The challenge here is that they often do not have an experienced SM available to mentor and coach them.  If at all possible, hire someone with proven experience or get help from an experienced coach. 

Excellent facilitator.  SMs organize and facilitate several of the Scrum meetings.  This requires organizational and excellent facilitation skills.  If you are a SM today and are looking for help in this area, I highly recommend the Collaboration Explained class (see previous posts on this class).  Facilitation is very different from controlling meetings.   

Highly available to the team.  If your SM has a full time role elsewhere in the company and just runs in for the daily standup, they are not going to be very helpful to the team.  They need to manage impediments and be available as needed to the team to work through any roadblocks.  The SM should always know the status of the team and how things are going. 

Be quiet.  This is a tough one.  Often times, skills that make a person a good SM are the same skills that make it hard for them to keep their mouth shut.  I have seen several SMs that can’t help themselves and start telling team members what tasks to do in the daily standup or start questioning the team’s estimates during estimation sessions.  As a SM, you need to know when to keep your mouth shut and when to step in.  You are not a traditional project manager and you should not operate in a command and control style. You are a “servant leader.” 

All About the Team.  As a SM, you are always focused on the team, not on yourself.  You need to thrive in watching the team succeed and do whatever it takes to help them do so.  If you need a lot of personal recognition and praise, then a SM may not be the best job for you.  

Collaboration Explained Class – Day 2 (Last Day)

I can honestly say that I have never been so exhausted after a 2 day class/workshop.  The last 2 days were filled with so much great information that my head is spinning.  Jean and Ronica did an amazing job with this class.  I don’t want to list out too much detail around my key take-aways.  If I did, this blog post would likely be a novel and I also don’t want to give away all my new found “subtle skills.”  That said, here are 3 things that really hit home for me (in no particular order):

  1. I talk too much 🙂  As I am writing this, I swear I can hear my friends and family laughing.  Seriously, when I am in a facilitator role, I talk too much and don’t listen enough.  I really learned just how important it is to be quiet and neutral as a facilitator.  I think this is an area that most facilitators can improve on as well.
  2. I don’t prepare enough for the meetings I run.  If Jean and Ronica had prepared for this class the way I prepare for my meetings, it would have been a disaster.  I am committing to myself to spend the appropriate amount of time preparing for meetings I facilitate (if I am planning a 2 hour meeting, then I need to spend 4 hours preparing for it).  If people are going to give up time in their day to come to a meeting I set up, then I owe it to them to make it a productive and worthwhile use of their time.
  3. Managing conflict isn’t easy but I now feel very well equipped with new tools and techniques to do this.  I am no longer afraid of having conflict in meetings but am actually looking forward to the opportunity to use some of my new found skills to help with this.

One of the real benefits of this class that I was not expecting was how much I learned about myself and what type of person I am.  I am much more aware (painfully so 🙂 ) of some character traits I have that I am hoping to improve on in the work place.

I would highly recommend this class for any and all CSM’s.  I can guarantee that you will come out of it prepared to really facilitate collaborative decision making on your agile teams.

Collaboration Explained Class – Day 1

I am currently in Boulder taking the Collaboration Explained class at Rally.  We just completed day 1 of 2 and so far, this class has been just awesome!

One of my biggest pet peeves around the Certified Scrum Master class/workshop is that anyone that wants to go and sit in on a 2 day class and pay the money for it is suddenly a “certified” ScrumMaster.  I know from personal experience that by getting “certified” I was no where near being equipped or qualified to serve as a good Scrum Master on my team (or any team for that matter).

In my opinion, THIS class would be a much better CSM class.  This class is all about giving you the tools and techniques needed to be a good servant leader and facilitator.  I am already overloaded with a ton of great tools and techniques that I will be able to take back to my job and start using immediately.  

I am a huge fan of the Collaboration Explained book by Jean Tabaka and this class is the greatest compliment to it.   If you haven’t read the book, do so as soon as you can.  Once you have read it, do everything you can to attend this class – it is well worth it! 

I am going to wait until the class is over to post my favorite moments and take-aways.

Mini-Waterfall Smells – How agile are you Really?

More and more companies are adopting agile development practices (or are trying to).  Instead of delivering software once a year, more companies are now able to deliver every quarter.  More projects are working from a product backlog instead of massive requirements documents.  An increased number of developers are practicing TDD.   However, achieving true agility on a project requires much more then delivering software 4 times a year. 

Just how agile are you really?  It seems that a lot of organizations that call themselves “agile” are really just doing mini-waterfall iterations instead.  Here are my top 10 smells that your team is in a mini-waterfall rut instead of true agile development. (these are not in any particular order)

  1. Your development team has a code freeze several days before the end of the sprint so you can get your testing cycle done. 
  2. Your QA team is testing the previous sprint while the developers are working on the current one. 
  3. None of your tests are automated.
  4. You can’t pull the next story off the backlog to work on because the requirements for it have not been through the sign-off process yet.
  5. Your product backlog is not ranked by priority.
  6. Your user stories do not have any business value assigned to them.
  7. You are only tracking development tasks in your iteration and on your burndown.
  8. Stories are considered “done” when development is done coding them.
  9. You have a full sprint dedicated to bug fixing every few iterations.
  10. Your QA team is a separate team that gets scheduled builds once or twice a week.