Integrated Scrums
Wednesday, May 28, 2008 – 8:48 AMI finished reading “Adaptive Engineering of Large Software Projects with Distributed/Outsourced Teams“, Sutherland, Viktorov & Blount last night. The authors describe an Integrated Scrums model which deliberately splits Scrum teams across different geographical locations, rather than co-locating teams and using the scrum-of-scrums approach.
The paper outlines the principle challenges of distributed teams:
- Strategic: Difficult leveraging available resources, best practices are often
deemed proprietary, are time consuming and difficult to maintain.- Project and process management: Difficulty synchronizing work between
distributed sites.- Communication: Lack of effective communication mechanisms.
- Cultural: Conflicting behaviors, processes, and technologies.
- Technical: Incompatible data formats, schemas, and standards.
- Security: Ensuring electronic transmission confidentiality and privacy.
While the paper was not as descriptive as I’d hoped it did include some pointers as to additional best practices when working with distributed teams:
- Each team member answers the three daily scrum questions by email before the standup. This shortens the teleconference and helps overcome language barriers.
- Local sub-teams have an additional standup meeting at the start of their day. This is in addition to the main standup meeting.
- Scrum Masters, Product Owners and Architects are centrally located to improve consistency across the distributed teams.
- User stories needed to be more detailed to deal with questions that the Product Owner might not be available to answer when needed and clarify potential misunderstandings due to cultural differences.
- Communication needs to be enhanced to account for distribution using; teleconferencing, IM and email.
- Choose an appropriate configuration management and source code control system. This may need to be augmented with proxy servers to cut down on bandwidth related issues.
I thought it was worth noting that the principle driver for using a distributed model was enhancing technical capability and thus productivity not cost savings, which were a secondary driver.
Currently listening to:
The Clash – London Calling
Sorry, comments for this entry are closed at this time.