The acceptance of agile methods comes from its emphasis on real-time communication, preferably in person. Most agile methods attempt to minimize risk by developing software through iterations that typically last anywhere between one and four weeks. Over the last few years, agile practices have gained both acceptance and criticism from the software community, for their development processes that deviate from the rigid traditional linear sequence of the waterfall life cycle to a number of different iterative spiral life-cycle-based process families. Agile methods are mostly criticized for their somewhat undisciplined approach to software development. Each agile process is quite different from the others, but they all share the common iterative spiral life cycle. There are various agile processes, including Crystal, adaptive development, feature-driven development, Scrum (conventional and distributed), lead software development, and extreme programming.

The authors show how to apply conventional Scrum practices to large-scale distributed environments. Distributed Scrum is based on the core principles of conventional Scrum. Conventional Scrum focuses on frequent direct communication, accountability, and visibility to help development teams succeed. The conventional Scrum method consists of a process, multiple roles, and key artifacts. The process is an iterative agile methodology that breaks the work into sprints, which are time-boxed units. The purpose of each sprint is to design, build, and test a functional piece of software through requirements gathering, high-level design, architectural road maps, and integration testing. The meetings include sprint planning, a “daily Scrum,” sprint review, and sprint retrospective. A sprint planning meeting is held at the beginning of the sprint cycle. At the end of the sprint cycle, two meetings are held: a sprint review meeting and a sprint retrospective. The Scrum roles are Scrum master (the facilitator), Scrum team (those responsible for delivering the product), and product owner (the voice of the customer). The artifacts include the product backlog (a high-level list maintained throughout the entire period), sprint backlog (a list of work the team must address during the next sprint), and burn-down chart (a publicly displayed chart that shows the remaining work in the sprint backlog).

The authors point out that the evolution from conventional Scrum to distributed Scrum was brought about by a shift in the way software is developed, as well as pressures from globalization, outsourcing, competitors, time-to-market, telecommunication improvements, low collaboration barriers, and reduced development cost. It has been shown that there are benefits to globally distributed teams, including reduced costs, reaching the market more quickly, enabling expansion into new markets, promoting talent acquisition, and enabling innovation and thought leadership. The types of distributed teams are collocated, collocated part time, distributed with overlapping work hours, and distributed with no overlapping work hours. In addition, the ways in which these distributed teams are handled with the use of Scrum practices--specifically, for large-scale distributed environments--include isolated Scrums, distributed Scrum of Scrums, and totally integrated Scrums.

Once readers have an understanding of the conventional Scrum concepts, they have essentially covered chapter 1 of the book and are now ready for the challenges faced by a distributed team, in chapter 2. Chapters 3 to 9 take the readers on a journey through the life cycle of a distributed Scrum project, through the lens of IBM’s experience in distributed Scrum, from envisioning products and setting up teams to preparing for sprint planning and running retrospectives. Each chapter presents a baseline drawn from conventional Scrum, discusses additional issues faced by distrusted teams, and presents specific best-practice solutions, alternatives, and tips that the authors have identified through hard, empirical experience from the IBM Scrum community. Of particular interest is chapter 10, which is only two pages long. The authors suggest that the key to success as a distributed team is having a high commitment level from all team members. The way to good teamwork is for the team members to share the pain of being a distributed team, to get to know each other as people, and to foster frequent quality communication.

I recommend this book to readers who are new to Scrum, as well as to seasoned Scrum practitioners who want to take their investment with conventional Scrum to a whole new level and apply distributed Scrum to software development efforts for large-scale distributed environments. An important point with Scrum is that it can be adjusted by the Scrum team (for example, a conventional Scrum evolved into distributed Scrum). The authors ask that any adjustment to the Scrum approaches and solutions outlined in the book be shared with the global Scrum community, so that everyone can benefit and continue to improve.