We have a Scrum team of 3 developers, a scrum master, and a product owner. Everyone works out of their home (except the product owner who works at his organization's headquarters).

In the past, we have used formal inspections for peer reviewing design and code concepts to facilitate communication among the development team. However, the peer reviews often get put on the back burner in favor of implementation. The peer reviews turn into "This is what I've done, let's document the review and move on" instead of "This is what I'm thinking about doing, what do you all think?"

We use Skype and Webex to communicate w/ screen-sharing, and we upload our design / code review documents to Sharepoint for easy access.

One of our long-term goals is to be appraised at CMMI level 3, so documenting and analyzing the results of our peer reviews works towards the verification of our work products. Although, I do not want to advocate peer reviews for the sake of documentation. I would like for the development team to want to communicate with their peers. I do not want to bog the team down with having to document every communication, but I do want to capture the benefits of peer reviews to analyze for process improvement.


  1. How can a distributed agile team facilitate communication without it feeling like a chore?
  2. What software products exist that can facilitate communication across a distributed team?
  3. What methods of peer review would match our goals of people-over-processes while effectively documenting the results for future analysis

Just for perspective, I am a junior developer who was moved from a separate project to start a QA branch for the company, so I am researching how to implement CMMI with our Scrum project management. We are working with very limited resources.

Thank you.

  • Could you please wait a little bit more the next time? I hardly had time to read the question and now there is an accepted answer already :-(
    – Zsolt
    Aug 8, 2012 at 14:21
  • 1
    Sorry, I will wait longer next time. I can always change the accepted answer if I find that another answer is more suitable. I assure you that all comments and answers will be read, appreciated, and taken into thorough consideration. Aug 8, 2012 at 14:27
  • @Zsolt - There is nothing wrong with answering a question with an accepted answer, if you have something of value to say. Remember, the posts aren't just for David, but for all the future visitors of this site as well. :) Go for it!
    – jmort253
    Aug 8, 2012 at 14:52
  • 1
    @jmort253, I know, but I like the fun - gamification - part when there are several questions and the best one is the winner ;-)
    – Zsolt
    Aug 8, 2012 at 15:00

4 Answers 4


Since no one has given much advice in terms of software products, I would just like to put forward that Team Foundation Server 2012 Preview is free for less than 5 users, and is a great resource for managing distributed teams and facilitating communication.

To highlight some of the ways it can help you:

  • Request Code Reviews - Any changeset can be shelved and sent to another developer for code review. The interface is very smooth, and the workflow is tracked by automatically creating a work item for you. Once the code review is complete, you can unshelve the changeset and merge it with your current version of the solution (think of it as very similar to a typical branch & merge scenario). If you wish to enforce a code review policy, this is a very good way to do it. You can set a gated check in policy that requires a completed code review before check in to be associated with the change set.

  • Web Access - It has been vastly improved from the 2010 version, making it much more useful. Pretty much everything you need to do an agile sprint planning is there. Re-prioritize and manage your backlog, assign work item, burndown charts, and a whole lot more.

To answer your questions in specificity:

1) Collaborative sprint planning and sprint review. Usually this is best to do in the middle of the week, because you want everyone to consistently be there. Spend the first half of the day doing spring review & retrospective, and the second half doing sprint planning (adjust as necessary, perhaps you only need half a day for both). This way you get a lot of the administrative overhead done on a single day. Try to be as unobtrusive as possible during these meetings. Do not dictate to your team how long something should take, gather their input on how long they believe each user story will take, bounce that off your backlog priority and add an acceptable amount of work to the current sprint. I think of project managers more as more of a project facilitator than anything else. Your job is to enable your developers to do theirs, and to run interference between them and anyone who would interrupt them from doing their job.

2) TFS 2012, as described above

3) Code review requests are great. You may need to enforce them by creating a gated checkin policy to begin, but eventually you could hopefully move away from that as you team sees their benefit in improved code quality. Documenting is taken care of as the review is part of source control as a work item, so it is always there. This also takes care of the problem of sacrificing code review time for development time. Code review time literally becomes part of development time, and your team won't feel like you are taking them away from their jobs to do something else.

And on a final note: I prefer putting team documents into source control rather than share point. In 2012, TFS will detect changes made from outside of VS, so they are easy to check in and maintain. I find that having a single repository makes it easier on the team to keep track of all documentation.

  • Thanks for the input. We use TFS for building, version control, and more. I will definitely check it out. Aug 11, 2012 at 0:54
  • Hi @aclear16, why would you say Team Foundation is a good solution? Please share your experience with this. Also, consider addressing the other two questions in David's post as some users may downvote your answer for being incomplete. On PMSE, we strive to post content that helps future visitors by explaining why our answers are correct. Welcome to our community, and good luck! :)
    – jmort253
    Aug 11, 2012 at 1:09
  • 1
    Noted, please see the edits. Aug 11, 2012 at 4:44
  • Thank you very much for taking the time to address all of my questions, @aclear16. If I may, I would like to ask for a small elaboration on your response to Question 1: Do you include a sprint retrospective on the administration-overhead day? Aug 12, 2012 at 14:25
  • Yes, sorry. I've edited the above to reflect that. Aug 15, 2012 at 16:59

You don't communicate for the sake of communicating. You do not deploy a communication vehicle if you have no message to deliver, no message to receive, no messenger, or no audience.

Part of your communication is the analysis of who, what, where, when, why, and how communications need to be conducted, i.e., NEED. If you are finding they do not want it, then perhaps they don't need it...or, they don't need the message you are delivering at that time in that way.

Communication is one of the biggest critical success factors for project success and it is very very difficult to get it right. The challenge is tailoring the methods to fit the project environment, culture, dynamics, and personalities you have onboard. And your entire draft reads like you have not overcome that challenge.

The first thing you need to do is get the expertise onboard on how to do this stuff. There are consultants who do nothing but specialize in this area. The second step is to conduct a stakeholder analysis, which is where you would answer most of the 5Ws and H questions above. If your analysis was performed right and you deploy the consequences of that analysis, communication should flow. Step three: tweaks.

Here's another hint: research personalty types and inherent behaviors. There is a personality type or two that is attracted to highly technical work. There are consistent behaviors attached to this type or types and you need to cater to it if you want your communications to improve. Rewarding and punishing will do very little.


While I generally agree with the comment of the first answer (you don't want to be purely punitive; you need positive incentives; etc.), it is possible to motivate people to move in this direction without explicit rewards.

  1. What management talks about with the developers is what they think about. If all management talks about is deadlines, that's what developers will work towards. If you start having a weekly meeting with your devs to discuss the process/tools of code reviews, you will find that they start to think more about this and engage in the process. If your developers are anything like my developers, the meetings alone are punishment (without explicitly calling anyone or the team as a whole out for punishment). :) Just having a quick 20-30 minute meeting once a week will help get them thinking more about the process and understanding that the CMM goal is important. And over time, talking about the process will lead to improvements in the process, and THAT is where you want to go. Giving the developers control to improve the process is a big positive incentive. Just be sure you lay out clear goals for the results, and let them figure out how to get there.

  2. Make things as easy as possible. This is why you need to engage with the developers rather than just impose a process on them. They know the tools better than you do (especially when it comes to code reviews). Create a laboratory-like environment where everyone can experiment to improve and simplify the process. Simplify, simplify, simplify. If the tool overhead for doing a code review is 2 minutes, you're going to get a lot more action than if the tool overhead is 15 minutes. Developers will go to ridiculous extremes to save themselves 15 seconds if it's something they have to do more than once a day. Example: We used Subversion at my previous shop. To do code reviews, the reviewee had to email the changed files to the reviewer who had to save the to the file system, be careful not to overwrite current files, do a diff, then carefully delete the reviewed files without screwing up his existing work. Then someone figured out that we could use Subversion patch files for code reviews. Suddenly the process was mail the patch file, reviewer saves the patch file and loads it in their client which shows which changed files and changes. There was no danger of overwriting their current source files and they could cleanup or not cleanup after the review. It didn't matter. Developers weren't happier to engage in code reviews, but they were less unhappy about it. And not to be understated, someone came up with an improvement; the improvement was acted on immediately; the developers felt better about things because they were allowed to improve the process.

Engage. Simplify. Repeat.

  • I like your SVN example of doing code reviews. We tried (briefly) doing e-mail pass-around reviews where the author would make a diff of the changed code with the line numbers and e-mail it to be reviewed. However, just looking at the code didn't give the reviewer enough insight into the overall purpose of the lines of code. If you don't mind me asking, how does your team convey overall design and purpose so that the reviewer can better understand the code? Aug 9, 2012 at 13:44
  • We had design docs in various forms, but I think those were rarely consulted by the reviewers. The reviewer just read thru the code. The would look for things like adherence to coding standards, obvious coding defects, error handling, and memory leaks. In our shop it was not up to the reviewer to determine whether or not the code achieved design goals. Whenever possible, the review would be conducted the developers most familiar with the system being reviewed.
    – Kent
    Aug 9, 2012 at 23:11

Generally people are not going to do something if there is nothing in it for them. So if there are no negative consequences for their current behavior and no reward/payoff for going through the peer review process they will continue to do what they are doing. Just finding a tool to do something isn't enough, you need motivation.

It is easy to have negative consequences for not doing e.g. peer reviews, just don't accept the product if it hasn't undergone a peer review and hold the producer accountable for the delay in his deliverable. Or force rework that would have been caught without peer review.

But just punishing isn't sufficient, and in the long run is going to be counter-productive to motivating the team. You need to reward the good behavior. The look & feel & shape of that reward will depend on the motivators of the producer.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.