Scrum Challenge: Keeping a new team honest

As we all know, Scrum teams work best when they are co-located and within koosh-ball-tossing range, not when they are working at disparate sites. We also know that teams who have not worked together before can come up against challenges with communication, unmet expectations, productivity and quality, among others.  Both of these conditions can significantly increase risk on a project.  Throw them into a consulting environment on a fixed-bid project and the problems can increase dramatically.

To some degree, this is the norm for IT consulting companies.  Teams are transient, and are assembled from the best - and available - resources for a specific project.  Perhaps some of the team members have worked together before, but it's likely there will be some that haven't.  There may be subcontractors working on the team because they have special skills, but no knowledge of the company culture or of the client's business.  There also may be team members who have to work remotely for various reasons.  These things can make creating a high performing team a real challenge.

We encounter this situation at some level on almost every project we do, and over the years we've developed some tools and techniques to deal with it. Most of these are nothing earth-shattering - voice conferencing, video conferencing, internal team kickoffs, mandatory days in the office each week, etc.  These are all great tools, and help with on-boarding and communication, but they don't address some of the special challenges of working in a Scrum environment.

The two biggest challenges we have faced with this type of team and Scrum, are:

• Keeping people honest about their progress.  Let's face it, people want to look good in front of their peers.  Sometimes this makes them exaggerate the progress they've made, or makes them minimize issues they are having. In Scrum though, team members have to be brutally honest about where they are and if they're roadblocked so the team can help them get back on track.  It can take awhile for a new team member to feel comfortable with that level of honesty, but on most of our projects, we don't have time to wait.
  
• Having developers stay true to the architecture of the product they are working on.  Almost all developers and architects who have been around awhile have their preferred way of doing things, and their own ideas about the best architecture to solve a particular problem. New team members - especially when working remotely - have a tendency to isolate themselves and create 'architecture drift'.  This can result in quality issues, problems with extensibility, less reuse, and increased development and maintenance costs.

 The technique we've adopted and are seeing relatively good success with is something we all did in kindergarten - Daily Show and Tell, or the Daily Demo.  Each day after the Scrum, at least one member of the team demos what they completed the day before, including a walkthrough of the code structure - classes, methods, tests, etc. This isn't at any great level of detail, but enough that the technical lead and/or other team members can see that standards are being followed, agreed-upon patterns are being used, and the team member has been honest in the Scrum. Best case, the team is potentially learning a better way to do something. Worst case, issues are caught before they become huge problems.


This technique is working for us, but I'd like to know how others are solving this problem.  Share your ideas!