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.