Manage

How to use Scrum effectively: Book review and conversation with Elizabeth Woodward

Learn about Scrum methodologies and how best to collaborate and communicate for all development sizes in this book review and discussion with author and IBM employee Elizabeth Woodward.

Scrum, a popular agile software methodology, has often been touted as a methodology best used for small collocated teams. However, more and more teams are looking at ways of using Scrum for large-scale development with teams that have members all over the world. In A Practical Guide to Distributed Scrum, IBM employees Elizabeth Woodward, Steffan Surdek and Matthew Ganis describe how Scrum can be used effectively, regardless of project size or team distribution.

Four team configurations
The book begins with practical information describing the Scrum methodology and the importance of collaboration and communication in its success. Four team configurations are described:

Collocated - These are teams that have all members working together physically in the same location. This is the prescribed team configuration in most Scrum literature and is recognized as the easiest way to foster team communication and collaboration.
Collocated part time - These teams are available to work together physically as needed. Often some of the members telecommute or work from other regional offices. Though these teams start to meet with some challenges, collaboration tools or face-to-face meetings can often help in bridging the gap.
Distributed with overlapping hours - In this model, although teams are distributed across time zones, there are at least some overlapping business hours. This tier introduces complications of time zones, communication differences due to cultures, languages and the inability to meet face-to-face.
Distributed with no overlapping work hours - In this, the most challenging configuration, there is no opportunity to have a meeting during the business hours of all the people on the team. This will require at least some members to attend meetings outside of their normal business hours. Furthermore, the frequent communication throughout the project that is expected from a Scrum team cannot easily occur. It is this frequent and on-going communication, extending beyond email and IM, which can make the difference between a successful and unsuccessful project.

Challenges of distributed teams
Chapter two describes the challenges with vastly distributed teams. Much of the information in this chapter is relevant, regardless of software methodology being used. Even global teams that are not involved in software development would benefit from reviewing the challenges and recommendations for successful collaboration of distributed teams. Awareness of issues such as cultural differences, conference call etiquette, holiday schedules, time zone differences, language nuances and most importantly, processes and technologies that allow for productive remote teaming, are worth understanding. Any distributed team would benefit from identifying pain points the team is experiencing and exploring solutions for improving communication.

In an interview with Elizabeth Woodward at the Agile 2010 conference, I asked what she saw as the biggest challenge. She described the relationships that get formed when people see each other in the office every day. "We don't see each other face-to-face in that distributed environment," she said of distributed teams. The less rich communication channel, coupled with challenges between time zones, present challenges in forming connections as a team. We talked about the phenomenon where several team members might be located in one place and then there are others who are considered remote. Woodward advises, "You have to be one team; not the 'Austin team' and the 'China team' and the 'remote team.' You figure out how to stay in communication with one another. How are we going to make sure everyone's voice is heard for estimation and sprint planning stories and acceptance criteria?" While she doesn't discourage local face-to-face communication, she feels that conference calls and meetings that involve remote employees may be most effective when everyone calls in or uses the same technology for teaming, rather than having those that can't physically be present be at a disadvantage.

Using Scrum for large-scale projects on distributed teams
The majority of the book describes how Scrum can be used effectively on large-scale projects with distributed teams starting with project origination and ending with retrospectives. Just as chapter two is useful for all distributed teams, much of the content in these chapters would prove useful for any Scrum team. They include many principles, tools and techniques used on all successful Scrum teams. However, again, the book emphasizes how the specific challenges encountered in a distributed environment can be addressed.

One key point is that even with large projects, it is recommended that Scrum teams are limited to five to nine people, keeping in mind geographic closeness and distribution of skills. In an "isolated Scrum model," each team can work independently. A "distributed Scrum of Scrums" model, where there are dependencies between teams, uses a regular "Scrum of Scrum" meeting to coordinate between the teams. "Totally integrated Scrum teams" are those in which each team has members from different locations. In organizing teams, it may even be an advantage if features that don't require integration are developed in different parts of the world, allowing for a potential 24-hour work day. Woodward said that she felt the failures she's seen with Scrum, were more about difficulties with transitioning to Scrum than with the team distribution. "The first couple of sprints tend to be disastrous. They overestimate what they are going to accomplish. You have to communicate constantly and it takes learning. It takes time to figure out velocity." Woodward admits, however, that distribution adds a big layer of complexity. "Distributed is definitely harder. The communication is happening constantly throughout the two-week sprint."

When I asked Woodward why Scrum was chosen as the agile methodology used in the book, she answered that the book was initiated by the Scrum community and was chosen as an agile management framework, but the concepts and techniques could be applied to other agile methodologies. "The three core practices we employed were TDD (Test Driven Development), Test Automation, and Continuous Integration." Woodward feels the content would apply to any teams using an agile software methodology.

This was last published in August 2010

Dig Deeper on Scrum software development

Start the conversation

0 comments

Register

Login

Forgot your password?

Your password has been sent to:

Please create a username to comment.