When we were writing the "Organization" chapter in Scaling Lean & Agile Development: Thinking and Organizational Tools for Large-scale Scrum we asked a group of agile development experts working in and with large companies about the most challenging impediments their organizations faced. We aggregated their responses into a list of what we call the top ten organizational impediments.
10. Failure to Remove Organizational Impediments
Jeff Sutherland, co-creator of Scrum, considers the failure to remove organizational impediments to be the main obstacle facing large organizations. Common reasons for not removing impediments are "That's the way we've always done business" and "We won't change because we invested so much in this."
9. Misguided Cost Savings and Synergy Efforts
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 mentioned centralized departments looking for cost savings and synergy, leading to local optimization as an impediment. They offered several examples of these misguided efforts. The first was a centralized tool department that required all departments to use the same tool. This well-intentioned savings slowed development efforts for at least one group because the "mandatory tool" didn't fit the job they were doing. Also cited was a time when the so-called furniture police forced all groups to use cubicles in order to standardize and minimize cost. This led to inefficient workplaces for many teams. Another example was the IT department limiting video conferencing to lower network traffic, which hurt teams who depended on that method of communication.
8. Lack of Training
Sami Lilja, global coordinator of agile development activities at Nokia Siemens Networks, noticed that some organizations seem to consider learning a waste of time and money. Those organizations tend to educate and coach people only "when there is time for it." This distorted view results in a vicious fire-fighting cycle—mistakes made because of constricted developer skills, followed by hasty emergency repairs and a management team unwilling to allot time to analyze the causes of the mistakes, then more mistakes made.
7. Single-Function Groups
Larry Cai, a specialist at Ericsson Shanghai, mentions functional organizations (single-function groups) as one of the largest impediments to becoming agile. These single function groups create barriers for communication and abet finger-pointing among units.
6. Local vs Global Optimization
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 to success. She gave several examples of these systems, including management by objectives(MBO)and budgeting systems.
5. Assumption that Book Learning is Enough
Mike Bria, a former agile coach at Siemens Medical Systems, mentioned what he called "do-it-yourself home improvement" as an impediment. He said that many people mistakenly believe that they "know how now" after reading one or two books, proving the truism that a little knowledge is a dangerous thing. These organizations usually do not bring in outside expertise, electing instead to do it themselves. Lasse Koskela, the author of Test-Driven, mentions a similar impediment, what he calls an "unwillingness to look outside the organization."
4. Individual Performance Evaluation and Reward
A trainer (name removed on request) at one of the largest e-commerce sites, mentioned individual performance evaluation and reward as a major obstacle he had noticed. These archaic practices frustrate developers and managers on agile teams, hinder team performance, and foster command-and-control management.
3. Unrealistic Promises
Lü Yi, an agile trainer and department manager of a large development group in Nokia Siemens Networks in Hangzhou, considers "commitment games" and unrealistic promises to be a leading organizational obstacle. Unrealistic expectations 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. Assuming Agile Is All About Developers
Diana Larsen, expert facilitator and, together with Esther Derby, author of Agile Retrospectives cited this impediment, "Assuming it's all about developers." Too often, organizations mistakenly assume that agile and lean involves only developers. They don't understand that a successful move to agile requires a shift in thinking and behavior at multiple levels of the organization.
1. Silver bullet thinking and superficial adoption
Almost everybody we interviewed cited some version of silver bullet thinking and superficial adoption as an impediment. Dave Thomas, founder of OTI, large-scale lean product development consultant, and managing director of ObjectMentor, spoke eloquently about this problem. He said that many companies make the mistake of equating agility with productivity, rather than with adaptability. This, coupled with a lack of educated executives, leads to the mistaken notion that agility is some kind of silver bullet. This, in turn, fosters the belief that meaningful problems can be solved by saying "we do agile" and going through the motions of doing so, with no deep understanding or change by the leadership team. Ironically, because this behavior leads to no real change and no real result, these same organizations eventually abandon lean/agile principles because they "don'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. In reality, significant improvement in large organizations can take five or ten years—if there is sustained executive support.
Our Two Cents Worth
After publishing this top ten list, we decided to add our own personal favorite organizational impediments to the list. The first impediment we have uncovered is a culture of individual workers rather than real teams and teamwork. Too many groups of individuals disguised as teams are ostensibly adopting Scrum, yet they still have the mindset of "Jill does Jill's tasks, Raj does Raj's tasks and so forth." These organization have yet to move as a whole team together, pairing and multi-learning within the group.
The second impediment we see is the gap between people in management roles and those doing the hands-on work. Frequently, changes made at the management level have no impact (or at least, no positive impact) whatsoever on the actual 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 the real place of work—sometimes because they have lost the skill to do so—and by developers who do not think outside their normal job responsibilities—they are "retired on the job." The gap 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.