Top Ten Organizational Impediments to Large-Scale Agile Adoption
The authors' new book, Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Product Development with Large-Scale Scrum will publish December 2009.
Like this article? We recommend
Like this article? We recommend
Like this article? We recommend
When we were writing the Organization chapter in Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum we wanted to highlight some key issues. Therefore, we asked a group of agile development experts working in and with large companies about the most challenging organizational impediments. We aggregated their responses in the top ten organizational impediments. The list is worth reflecting on and was included in the Organization chapter and in this short article.
10. Jeff Sutherland, co-creator of Scrum, considers the failure to remove organizational impediments the main obstacle in large organizations. A common reason for not removing impediments is “That’s the way we’ve always done business.” We also frequently hear, “We won’t change because we invested so much in this.”
9. Peter Alfvin, an experienced development manager involved with introducing lean principles at Xerox, and Petri Haapio, head of the agile coaching department at Reaktor Innovations, both mention centralized departments looking for cost ‘savings’ and ‘synergy’ that leads to a local optimization as an impediment. Their examples included a centralized tool department forcing one tool, leading to slower development caused by the wrong tool for a job; furniture police forcing cubicles to standardize and minimize cost, leading to inefficient workplaces; IT department limiting video conferencing to lower network traffic, leading to less communication.
8. Sami Lilja, global coordinator of agile development activities at Nokia Siemens Networks, noticed that some organizations consider learning a waste of time and money. He believes this opinion is a major impediment because those organizations educate and coach people only “when there is time for it.” This view results in a vicious fire fighting cycle—mistakes made because of constricted developer skills, hasty emergency repairs, management unwillingness to allot time to analyze earlier mistakes, more mistakes made...
7. Larry Cai, a specialist at Ericsson Shanghai, mentions functional organizations (single-function groups) as one of the largest impediments. They create barriers for communication and abet finger-pointing among units.
6. Esther Derby, consultant, coach, expert facilitator, and author of two books related to organizational learning, considers systems that foster local optimization over global optimization a major barrier. She gave several examples, including Management by Objectives (MBO) and budgeting systems.
5. Mike Bria, a former agile coach at Siemens Medical Systems, mentioned “do-it-yourself home improvement” as an impediment. He highlighted the problem attitude of “we know how” after people read one or two books. In other words, the problem of failure to learn from outside expertise. The same is mentioned by Lasse Koskela, the author of Test-Driven—unwillingness to look outside the organization.
4. A. (name removed on request), a Scrum trainer at one of the largest e-commerce sites, mentioned individual performance evaluation and rewarding as a major obstacle. They frustrate developers and managers, hinder team performance, and foster command-and-control management.
3. Lü Yi, a Scrum trainer and department manager of a large development group in Nokia Siemens Networks in Hangzhou, considers “commitment games” and unrealistic promises to be the main organizational obstacle. They lead to shortcuts, continuous fire fighting, and legacy code. We cover this topic in more detail in the Legacy Code chapter of the companion book, Practices for Scaling Lean & Agile Development.
2. Diana Larsen, expert facilitator and, together with Esther Derby, the author of Agile Retrospectives, simply stated, “Assuming it’s all about developers.” We have seen this frequently—people who do not think they need to change because agile and lean involves only developers. They ask, “Why would it affect me?”
1. Almost everybody cited “silver bullet thinking and superficial adoption” as a major impediment. Dave Thomas, founder of OTI, large-scale lean product development consultant, and managing director of ObjectMentor, mentioned the misunderstanding of equating agility and productivity (rather than for adaptability), and the lack of educated executives. This leads to the belief that meaningful problems can be solved by saying “we do agile” and going through the motions, with no deep understanding or change by the leadership team—cargo cult process adoption. Ironically, this leads to no real change and no real result, and the eventual predictable abandonment of lean principles or agile development because “that doesn’t work.” A related impediment is the wishful thinking that significant improvement in large product groups can and will happen “fast,” within only a few years, rather than what we see as the more likely five or ten years—if there is sustained executive support.
In addition, for this article, we asked each other to add one more favorite organizational impediment.
Craig thinks that a culture of individual workers rather than real teams and teamwork is a key impediment. He visits many groups of individuals that are ostensibly adopting Scrum, and sees symptoms such as “Jill does Jill’s tasks, Raj does Raj’s tasks” and so forth, rather than a movement to “whole team together,” pair work, and multi-learning within the group.
Bas considers the gap between people in management roles and those doing the hands-on work to be a key impediment. Frequently, changes made at the management level have no impact (or at least, no positive impact) whatsoever on the actual value work. Similarly, decisions by hands-on developers are often not aligned with the direction of the organization. This gap is caused by managers who do not Go and See at the real place of work—they often lost the skill to do so. And by developers who do not think outside their normal job responsibilities—they are “retired on the job.” It leads to shallow agile and lean adoptions that happen either only on the management level—without any change in technical practices—or only on the development level—without any change in the organization. The lean practices of Go and See and managers-as-teachers help to reduce this gap.
The replies from the agile development experts validated our own experience and acknowledged that we were covering the right topics. The remainder of the Organization chapter in the book explores these organizational obstacles and what you can do about them.
About the Authors:
Craig Larman is a management and product development consultant in enterprise-level adoption and use of lean development, agile principles and practices, and large-scale Scrum in large, multisite, and offshore development. His books include (with co-author Bas Vodde) the best-sellers Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-Scale Scrum and Agile & Iterative Development: A Manager’s Guide.
Bas Vodde works as an independent product-development consultant and large-scale Scrum coach. For several years he led the agile and Scrum enterprise-wide adoption initiative at Nokia Networks. He is passionate about improving product development, an avid student of organizational, team management, and product development research, and remains an active developer.