Monday, November 22, 2010

Create the trust, not second class Distributed Scrum citizens

Whenever I drill-down a bit on distributed team horror stories, it helps me reflect a bit on how our efforts in Distributed Scrum teams have been widely successful by most standards.  I believe the primary factor behind our success was our focus on building trust and spending the time and energy to build that trust.

I'd like to say that we went into distributed scrum with a full-on strategy that enabled success, but only by comparing other companies less successful efforts does in become abundantly clear what we did differently:

1.  En-fused company culture in the distributed team by having the original distributed team's leadership originate from the home office.  We had a 2 technical managers that had 3 and 10 years with our company respectively that moved into the city that we opened a dual-source office in.  This gave use pseudo product owners who could fill in gaps based on previous experience.  They also explained the culture, smoothed over rough patches and helped bridge relationships between the new office and the home office.

2. Our distributed team members were converted to employees early on.  Nothing creates a second class citizen like having a contractor status, without employment rights, without insight into the companies direction and without a vested interest in the final solution.

3. The distributed team members covered the full range of skills, we didn't have the architects based in the US for example.

4. Product owners visited the dual source office often, including attending office events. 

5. Constant communication thru Skype

6.  US product owners willing to work crazy hours

Wednesday, September 29, 2010

Less Specification, More Interaction for Distributed Teams

When working with Distributed Teams, sometimes the "home" team will feel the need to be ultra prescriptive in their specifications and instructions to the "remote" team.  Fight this tendency!  More documentation will lead to a false sense of security and due to time zone / remoteness, and may discourage the Product Owner and remote team from interacting.

One of the keys to success in using distributed teams is to increase the level of interaction.  Product Owners and the distributed team should:

1.  Schedule pre and post Sprint Planning meetings to discuss upcoming and currently being worked on features.  Frequency and number depends on the length of time the team has been working together and historical track record of delivery to what the Product Owner desired.

2.  Schedule Sprint Demo's throughout the Sprint whenever a feature is ready to review visually, not just at the end of a Sprint.

3.  Schedule periodic face to face meetings, during Sprint Planning / Sprint Design for a major release would be a good time.

More interaction, less specification.

Monday, September 20, 2010

Agile Product Sprint Reviews - Do them often - not just at the end of a Sprint!

As an Agile practitioner and advocate, getting working software in the hands of users ASAP is a critical part of Agile's success in product development.  However, once our external clients were involved are Sprint Reviews, it became very apparent that we (the product managers) should have visual insight and confirmation well before the client.

To accomplish this, we have our Engineers conduct mini-Sprint Reviews whenever a feature is completed and passes their Unit Testing.

Tactically, we schedule a Sprint Demo every day for 1/2 hour so the product internal stakeholders have their calendar booked but we determine whether we should actually have a Sprint Demo during the Daily Scrum meeting.  We average 1-2 actual Sprint Demo's a week, usually 15 minutes long.


1.  Internal Product Stakeholders are able to review and provide feedback on completed features - visually
2.  Team Burn-down Confirmation - when an Engineer updates remaining hours to 0, the team knows the feature is completed
3. Quality Assurance gets better insight into what the feature is supposed to accomplish


1.  Unless the team is disciplined, scope creep can occur as product managers visually see useful enhancements that were not identified during Sprint Planning

2.  Extra team time spent (although benefits are well worth it)

Our experience has been increased productivity, as if Engineers were completely off the mark, we have a chance to re-work during the Sprint instead of during deployment.