Below is an excerpt from the introduction of the book: Creating Agile Organizations.
A Systems Thinking Approach to Creating an Agile Organization
Why do people repeat the same unsuccessful behavior in organizations? Why do certain problems in organizations seem to appear again and again? Why aren’t improvement actions leading to the expected results? What is probably going on is that the improvement actions are anti-systemic, acting on independent problem events without paying close attention to their relationships and deeper causes.
An organizational design includes, among other things, decisions about the division of work and the assignment of responsibility among units. When units coordinate to get the job done, they create complex interactions and feedback loops—the system’s structure—that generate the observable recurring problems. You address these problems by understanding the system’s structure and then redesigning the organization to create new interactions at the workplace.
A classic example of system effects: We observe a slight decrease in productivity in a software development team and the team gets behind schedule. As a quick fix, project management pressures the developers to step up and “just make it happen.” This quick fix solves the problem for the upcoming release because the developers take shortcuts and lower quality to meet the schedule. For the next release, the team works with a lower-quality system, so their productivity is worse than before owing to the accumulation of the technical debt. What will likely happen is project management pressuring the development team again, worsening the situation. Both parties behave “rationally” from their point of view with good intentions.
When you see how the system of work constrains people’s behavior, you realize that the recurring problems are mainly due to the system, not to the people themselves. Thus, working on the people when the problem is actually systemic in nature is not the right path to go down. You can achieve minor improvements at best.
The Importance of Self-Organization for Agility
The basis for agility is an environment of exploring new possibilities for improvement. Such an environment cannot overly constrain people’s exploration with detailed procedures and rules because that reduces the space for innovative ideas—precisely the opposite of what is needed. Instead, management needs to support self-organization by establishing a few simple rules, a clear goal, and short feedback loops.
No single person can understand or know everything about the Agile transformation and solve all the problems. You cannot have one person telling a large group of people exactly what to do. But you also cannot have a large group of people doing whatever they want when they want to. What you can do is provide clear focus and direction, ensure that people take responsibility for solving the problems that they own, and provide the support they deserve. Such an approach provides control and makes better use of the individuals’ intellect, but also simultaneously gives them flexibility to explore solutions.
A New Role for Management
The role of operational management is likely to change. From our experience, many Agile organizations end up with fewer operational management roles. Why? Because a lot of the operational work becomes the responsibility of the teams. For example, a product person now makes decisions about the product, and the self-managing teams take care of coordination and decide how to do their work. Therefore, operational managers no longer need to divide the work, decide what people should do, or coordinate between people or teams. Instead, they can devote their whole intellect to making it possible for the teams to be successful. Improving the organizational system of work and mentoring people on problem solving is the new reality for them.
A Learning Organization
A large part of Agile adoption focuses on learning how to work with self-managing teams in short iterations of learning. People need to learn new things—for example, new work practices, teamwork, and ways to lead Agile teams. Also, the decision-making process, communication structures, and measures of progress are subject to change. A second part of Agile adoption is the change to a mindset of continual improvement. This covers a broad spectrum of people—from R&D, business, and management to sales, marketing, and other disciplines.
There are roughly two ways to begin the transformation: either the organization is starting from scratch, or it has already been working with Agile for some time. In the former case, you have the benefit that you can start with a greenfield. A downside is that you are at the start line, and a long bumpy road lies ahead. But the latter case might be even worse! The organization might have been doing Agile for a long time—just doing it wrong and not getting the expected benefits. You will need to repair misunderstandings and facilitate relearning to help it take the next step.
Ownership for Continual Improvement
In an article published in The Journal of Personality and Social Psychology,3 Ellen J. Langer of Yale University described an experiment with lottery tickets to illustrate the phenomenon known as the illusion of control. Two groups were involved in this experiment. The people in the first group received lottery tickets that were preselected for them, while the people in the second group got to choose their tickets and numbers. When they had their tickets, the experimenter asked people in both groups to sell back their tickets. As predicted, the people who got to choose their tickets wanted to receive a higher amount of money than the ones who got a ticket assigned. Why does this happen? To quote the paper:
[W]hen a chance situation mimics a skill situation, people behave as if they have control over the uncontrollable event even when the fact that success or failure depends on chance is salient.3
The people who chose their tickets also felt more ownership of them, which is an essential observation for us. When you create something yourself, you feel ownership of it, and once you own it, you might care enough to improve it. You can say the same thing about teams that create their work process: They feel ownership of their approach, which makes them take responsibility for improving it. Once teams discover and learn what works for them, they can share that learning with other teams across the organization. This process of lateral learning enables the organization to discover which changes it needs to make to build a model that works in its context.
Empirical Process Control
Successfully bringing agility into an organization is a journey of discovery and learning. There is no fixed end-state when you can say, “The transformation is done.” Instead, the end-state is a dynamic one, in which new insights are continually used to improve the product, processes, and organizational design.
The challenge is that one cannot know upfront exactly what needs to change or precisely how the future state should look; it is a complex problem of innovation. Such a problem cannot be solved by centralized control, imposed order, and prediction. Instead, you must use an empirical process in which you take an informed step forward, inspect the results, and then adapt your plan based on what was learned.
A Quick Tour of the Book
This book shares how we applied many research findings to our Agile transformations as effectively and painlessly as possible. Readers will find the book most valuable if they have a good understand- ing of the Scrum framework. We don’t intend for this book to be an introduction to Scrum.
The book can be roughly divided into two parts. The first part, Foundational Concepts, includes systems thinking, basics of flow and resource efficiency, guidelines for organizational design, preferred coaching approach, and guidelines for productive change. The second half of the book, Applying the Concepts, offers practical tools for large-scale organizational Agile adoption—for example, defining a product workshop, tools for preparing and facilitating large-scale Agile events, and guides for working with teams and leadership. The tools are explained using various real-life examples of organizations, Product Owners, and teams on their journey to becoming an Agile company.
The examples show how to prepare, structure, and guide large-scale Agile adoptions. They provide real-life examples of organizational designs, challenges, solutions, and pitfalls that you can learn from.
Finally, we share a few case studies that illustrate how Scrum can be used to apply agility success- fully at a large scale.