Stephen Forte on Managing Distributed Projects

I found the one of the recent .NET Rocks podcasts to be particularly interesting (show #322). In it Carl and Richard had Stephen Forte on to discuss managing distributed projects, and in particular using Scrum to manage those projects. The thing that I found most interesting was how Stephen had grown this skill almost organically, like myself (and I think anyone), and especially with how much in alignment he was with my opinions on the topic. Given that I felt that it would be good to itemize and summarize some of the main topics in the discussion between these three gentlemen.

1) Software development lends itself well to distribution of tasks.

The question then becomes why distribute your software development? There are a number of reasons, two of which are primary:

• High quality talent is not always local
• Isolation works - can not get "do not disturb" around the office, and this is a real important issue. There are references given that for example one phone call to a developer will make them take 10-15 mins to get back on track

2) How do I mitigate / manage risk in a distributed project?

There are a number of answers to this since there are actually a number of types of risk to mitigate:

• How do I communicate effectively communicate over large distances?
• How do I cope with giving up control (not micromanaging by having to have everyone right there)?
• How can I tell if someone is thrashing from a distance?

Basically, you can and will lose control of developers even if they are colocated. The trick is to be able to identify it, with local or remote staff. Thrashing is when a developer gets stuck and will not ask for help. This can happen even in a cube, and for weeks at a time, so this is not new even with remote staff. The issue is again how to identify it.

The solution to these comes down to using Scrum as your project management methodology, and this will assist in identifying these issues. Through this you gain control over your through empowerment and even if they are not right there.

Which also leads to the question of isn’t it important to have face to face interaction? Well, it is to an extent. As mentioned later it is important to make sure that most people know each other by face having had some type of in person interaction so that you can “see” the person that is remote, meaning that you can get a read on what that person is saying between the lines. Several techniques for how to do this are given later. Also, stress that communications by e-mail for important items is not the most effective means of getting things done. Stress using phone, skype, webcams, or getting in person if possible.

3) Distribute software development leads to greater agility.

This is true when combined with Scrum and short cycles / iterations. Doing this can lead to very quick releases when properly defined. This is actually a large topic to discuss that I will elaborate on independently in another post.

4) Use available tools to assist in managing the distributed agile process.

There are a number of tools available to minimize distance between team members:

• Scrum: Methodology for collaboration and identifying / assigning work.
• TFS / eScrum: Tools for running Scrum in a distribute manner.
• Skype: for communicating amongst the team with low cost.

And make sure that the Scrum Master ensures that everyone uses them and collaborates daily through the daily Scrum.

5) Identifying and addressing “Thrashing” with remote members.

• How can thrashing be identified over Skype? This basically comes down to being able to ask a simple question: “Why are you working for so long on this?” If you then you get a long answer, basically a laundry list of seemingly unrelated statements to the problem at hand, then they have probably tried lots of things except asking for help.
• Also, if you run one week sprints, you don't have to care too much about thrashing as long as the work is done at the end of the sprint. If it is not done at that time, then you are never more then one week behind and you can then identify those people who need help through the lack of a deliverable.
• It is also important to start with several small architectural sprints (and put these in the wiki - my input). These can be used to define a baseline for how the system should be implemented and reviewed against.

6) How to perform Scrums with remote people

• Keep iterations short, perhaps just one to two weeks. This will ensure that thrashing does not exceed more than one iteration.
• Use TFS with eScrum feature to manage the work items in the iteration and allow all remote team members to collaborate.
• Extensively utilize Skype as well as plug-ins for whiteboarding and sharing. Skypecast daily and make sure you go around the horn and use PTI (pardon the interruption - time is up).
• Prevent “hiders” in the Scrums by making sure that ScrumMasters make sure everyone participates.
• Be diligent to make sure that Scrums do not devolve into status meetings; remember that they are for solving issues and giving marching orders.
• What's the effective size of a scrum - 10 people, then do scrum of scrums

7) Team collaboration

What techniques are there to build collaboration amongst the remote workers?

• Kick off the project in person with everyone present no matter the cost as it will be saved later and it will allow distributed people to get to know each other
• Explain the business in the kick off, as developers will need to understand this to work independently, and may also likely take control of business features through the Scrum process
• Get developers to think as a user, having them always think in the frame of reference of a user operating the system.
• Empower the developer to make decisions as it will mitigate thrashing, and make them feel free to ask for input on the next sprint while working on the current one.

8) How to keep remote developers feeling as through they are part of the team?

The problem(s) here are:

• How to keep remote staff happy and motivated
• How to keep remote staff feeling that they are a part of the team

Solutions are:

• Operate with a staff augmentation model
• Engage with local recruiters to find what local talent you can
• Do a staff rotation model, were every person in a particular office should within a 2 year timeframe work in other offices for extended periods (2-4 weeks), and always have one person from every office in another office to build true relationships.
• These techniques will also let you get to know the people so you can understand them in the e-mail

9) How about dealing with the cultural differences?

• It’s Stephen’s opinion that the younger generation is much more liberal and technology has transcended the cultural borders therefore mitigating those issues.

10) In General:

• It seems as scrum master merges with product manager a lot. This is something that I was aware of from experience, but it was nice to hear Stephen express it too.
• Stephen had a great example of how to use current tools to manage a crisis. A remote worker said he had a power outage. Stephen used google earth and local search to find him an Internet cafe to go work at.
• Carl asked if it would be possible to use second life for remote interaction? I kind of like this idea and may look into it.
• Richard feels that he can handle only a maximum of 0.25 interruptions per hour (2 per 8hr work day).