How to facilitate communication and peer reviews on a distributed scrum team?

Question

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.

Questions:

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.

Answer 1

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.

Answer 2

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.

Answer 3

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.

Answer 4

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.