untitled INTRODUCTION The future ain''t what it used to be. --Yogi Berra We sat down in the meeting room with our hot coffee. Outside was a bitter-cold north European winter morning. In came our new client and we shook hands. "Thanks for visiting," he said. "First, you should know that our product group is not large, maybe only eighty developers." We once met a group adopting agile development that was not sure if they could grow to very large-scale development: 12 people. People have different scales in mind regarding ''large.

'' To some it means only 50 people or even less. To others, much more. We define a large product 1 group as one whose members'' names you could not remember if you were all together in a room. We work typically with single-product groups in the range of 100-500 people that are adopting Scrum, lean principles, and agile development practices, usually on software-intensive embedded systems. So by this definition--at least with our limited memories--this is the realm of ''large.'' On to our key recommendation: After working for some years in the domains of large, multisite, and offshore development, we have distilled our experience and advice down to the following: Don''t do it. There are better ways to build large systems than with many developers in many places. Rather, build a small group of great developers and other talents that can work together in teams, pay them well, and keep them together in one place with product management or whoever acts as the voice of the customer.

But of course you are still going to do large, multisite, or offshore development. This is because your existing system is already structured that way, or because--in the case of large groups--there is the mindset that "big systems need lots of people." We regularly coach groups that ask, "How can we calculate how many people we will need?" Our suggestion is, "Start with a small group of great people, and only grow when it really starts to hurt." That rarely happens. Since large, multisite, and offshore development is going to happen, we would like to share what we have tried or seen at the intersection of these domains with lean and agile product development principles and practices. 2 Thinking and Organizational Tools When Bas was a member of the leadership team of a large product group, he frequently (in meetings) asked, "Why do we have this policy? . What will happen to the organizational system if we do that?" Months later a member of the team told Craig, "It drove me nuts to keep hearing those questions. But later, I appreciated it.

" Bas wasn''t trying to be annoying; he was trying to suggest and encourage systems thinking--a thinking tool (1) to consider the deeper dynamics of the development system as a whole, (2) to understand how a system became the way it is, and (3) to reconsider assumptions underlying the existing organization. When people are introduced to Scrum with its short timeboxed development iterations, they first see it as a localized practice to incrementally grow a product in small manageable steps, with learning and corrective actions toward a goal. Consequently, people will say, "Oh, ''agile'' doesn''t affect me; that''s a development practice." But there is a bigger picture and a potential higher-level learning loop beyond the lower-level development learning cycle: a learning organization of people that repeatedly re-examine the structures and policies that define and surround agile product development. The result of adopting Scrum or lean principles in very large product groups inevitably leads to this higher-level organizational learning challenge. Example: Consider an enterprise whose R&D division tries to be more adaptive by adopting Scrum. The Sales division continues in their old mode: Maximize personal commissions and quarterly sales by promising the moon and the stars to customers, combined with almost boundless optimism for what "our great people in R&D can do." Faced with unattainable ''commitments'' R&D did not themselves design or make, R&D is then blamed for not meeting "our promises," and it is concluded that "Scrum doesn''t really help.

" If this were a book about adopting Scrum only in one small 20-person single-product group within a large enterprise, systems thinking and organizational tools would be interesting but non-vital topics. But they are vital to a successful adoption when Scrum is being scaled to a 400-person single-product group, probably within a larger R&D organization in the thousands that is also making the transition, with deep connections to the Sales and Delivery groups, and constrained by traditional Human Resource and Enterprise Governance policies on team structures, reporting, measurement, milestones, contracts, and rewards. Consequently, this book suggests that one cornerstone for large-scale Scrum and agile development is people who learn and apply various thinking tools, including (but not limited to) systems thinking, mental-model awareness, lean thinking, queueing theory, and recognition of false dichotomies. 3 With those thinking tools in place, it will become increasingly clear that the existing organizational design inhibits flow of value, leading to pressure for redesign. Hence, this book suggests a second cornerstone of organizational tools, including feature teams, requirement areas, and many other changes in structure, process, task, people, and rewards. ACTION TOOLS In parallel with adopting thinking and organizational tools, many action tools--specific development practices--help the product group get going on large, multisite, and offshore agile development. The effective use of these action tools--shared in the companion Practices book--is somewhat dependent on organization redesign. Many practices can be tried without deeper structural change, but constraints on benefit will be felt.

So the tools in this book could be seen as prerequisites for the actions tools of the companion book. Yet in reality, practices will be adopted first--because that is where people want to start. And that will eventually invite a look back at thinking and organizational tools. We suggest that coaches and other change agents involved in the adoption of large-scale Scrum or lean development acquaint themselves early with thinking and organizational tools, while in parallel helping to introduce action tools. At some point the situation will be ripe--people will be ready--for a turn in the discussion from "How do we do large-scale continuous integration?" to "Do existing HR policies prevent real teams?" and "What is flow of value and what inhibits it in our organizational design?" EXPERIMENTS: TRY. AND AVOID. Scrum emphasizes empirical process control; there is too much complexity and variability for a cookbook approach to processes for development. Therefore, the tools in both books are presented as a series of tips that start with Try.

or Avoid. to suggest experiments, nothing more. They certainly may not work in your circumstance. The approach both in Scrum and in the lean thinking practice of kaizen is to first inspect and grasp the existing situation. Then, second, to adapt with new improvement experiments. The attitude of endless experimentation is vigorously encouraged in lean thinking; perhaps the only bad process-improvement experiment is the one not tried. At Toyota, Taiichi Ohno--arguably the key contributor to lean thinking--would visit an area and inspect any written standards document. If it was covered with dust or otherwise not recently changed, he would grow quite impassioned and urge people to always evolve their ''standards.

'' In Scrum this inspect-and-adapt (experiment) cycle repeats every two- or four-week timeboxed iteration as long as the product exists. And in lean thinking, this continuous experimentation and improvement cycle applies both to individual products and to the enterprise as a whole. LIMITATIONS There is still much for us to learn about these domains. What we have written here and in the companion book reflects our current (limited) experience and understanding, which we hope will evolve in the coming years. For example, although we have lived for some years in China and India, we feel we have barely scratched the surface in terms of our multicultural experience and insight in relation to offshore and multisite agile development. Nevertheless, our sincere wish is that these tips are of some value to you. We welcome further insights and stories from our readers. Large-scale Scrum can influence almost all aspects of a product-centric enterprise.

To keep the scope of this material manageable and because of our limited experience in some of these areas, we bounded or deferred subjects that are worthy of more discussion. These include: budgeting and finance sales product development not involving any software marketing deployment/delivery hardware development field support Essentially, this book is relevant to general-purpose product development. Scrum and lean product development are not limited to software systems NT86. However, the bias is toward software-intensive systems (usually embedded) because of our background and because of the ever-growing ubiquity of software in everyday devices, from washing machines to shoes. Especially in this book we dissect some assumptions and policies in traditional organizations that inhibit flow of value and effective teams. This analysis may come across as startling or challenging at times. We do not mean to give offense, but organizational redesign to support lean and agile development will not happen without increased scrutiny of traditional assumptions and incre.