- Hello, VUCA World!
- What Is an Agile Organization Design?
- Typical Problems When Adopting Agility
- Avoid Copy–Paste Scaling: A Typical Scaling Approach
- Overview of an Agile Organization Design
- Summary
- References
This chapter is from the book
This chapter is from the book
This chapter is from the book
Typical Problems When Adopting Agility
It is relatively simple to achieve agility with one team that has all the needed competencies and technical skills; however, many larger organizations usually have multiple teams that need to work together on a single value proposition or product. They need to scale Agile across all those teams so that they can become adaptable at scale. But scaling what works so well for individual teams working separately to larger groups working together turns out to be a different and more difficult problem to solve. While each separate team might be Agile locally, that doesn’t mean the group will also be Agile. An important reason for this difference is that the more teams there are, the more likely it becomes that they will specialize in a single function, skill, or technology—for example, product management teams, marketing teams, IT teams, development teams, or manufacturing teams. In an organization with such a structure, interdependencies typically exist between the teams. The unfinished product moves from one group to the other, with each group adding something before the product is delivered to the customer.
Specializing the teams facilitates integration within the specialization but complicates integration across the groups. Why? The teams are responsible for completing their part and then handing the product over to the next unit; therefore, they do not feel the need to communicate frequently with other teams. When they do communicate, they might even have difficulty understanding the other teams’ perspectives. Numerous problems can follow from that. For example:
A lack of customer and market information from the business teams makes it difficult for development teams to deliver successful products.
The development teams might not necessarily focus on the requirements that the business department believes are the most important.
The development teams might ignore requirements regarding manufacturability that increase manufacturing time and cost.
The more the teams specialize, the more likely it becomes that they cannot deliver end-customer value, but only provide a part of the desired value. All these parts need to be identified, planned, integrated, and coordinated to yield the complete end-to-end value before an organization can comprehensively understand what is going on. Much of this activity is unnecessary and delays learning and, therefore, the ability to adapt in the right direction.
Systems Thinking theory focuses on the complete picture to improve the end-to-end process; it involves studying the broader system behavior over time and using that understanding to improve. The important insight from Systems Thinking theory is that the performance of an interdependent group of teams depends primarily on how the teams are tuned, not on individual team autonomy or how the teams perform as separate entities. In Chapter 2, “Systems Thinking,” we cover in more detail how to use this approach in Agile organizations.
The Functional Hierarchy Organization Design
Typical organization design is the functional hierarchy. As Peter Scholtes described in The Leaders’ Handbook,5 a severe accident between passenger trains in the year 1841 heavily influenced how we design our organizations today. According to Scholtes, the railroad company wanted to ensure that such an accident could not happen again. A decision had to be made about how to reorganize the railroad management system. The railroad had a choice between the two most well-known organization designs at the time—the military and the church. The military was a top-down hierarchical structure, whereas the church used a distributed structure. After careful consideration, the railroad opted for the top-down hierarchy because it optimized for control and enabled the company to find the cause of problems quickly. Its decision still influences current-day organizations, as illustrated in Figure 1.2.
)
Figure 1.2 Hierarchy organization design.
Specializing the Work
In the first half of the 1900s, Henry Ford and Frederick Winslow Taylor heavily influenced management thinking. Ford introduced the very successful automobile production line, while Taylor focused on his scientific management approach. Both liked to specialize the work and divide work into separate functional tasks. Narrow functional tasks enabled people to concentrate on doing a simple job, so that people with poor or no education could work efficiently.
Separate the Head from the Hand
Taylor also introduced the concept of separating the head from the hands. Educated people would design the process and partition the work into dumbed-down tasks, and then people could be attached to those tasks. Furthermore, Taylor stated that there was a best way of doing the work and that management’s job was to find that one best way and then let the workers do it. Along with the best way came measures, and later key performance indicators, and standard times for each of the tasks.
Ford had a similarly dim view of workers’ capabilities, complaining, “Why is it every time I ask for a pair of hands, they come with a brain attached?” In Ford’s system, people were only as valuable as the simple, repetitive tasks that they could perform. In essence, they were viewed as “interchangeable, nameless, and faceless.”
Fast Forward to Present Times
In organizations that do large-scale development, much of the thinking advocated by Taylor and Ford still prevails today. These organizations are designed as a series of functional groups, with the aim being that each of the groups work individually at maximum efficiency. The resulting silos are managed by single-function managers and have measures—key performance indicators—to assess how well they are performing. Figure 1.3 illustrates a typical example of such an organizational design in the context of software development.
)
Figure 1.3 Typical silo organizational design in modern times.
You can see domain groups that specialize in a part of the business—for example, billing. Next to that, you can see specialization in technology such as Java, as well as specialization along with functions such as testing or marketing. There is nothing wrong with this kind of functional hierarchy as long as its optimizing goals are in line with your organization’s goals and it helps you in reaching your business objectives. John Kotter, Professor of Leadership, Emeritus, at the Harvard Business School, highlights some important goals of this kind of hierarchy:
[A]t both a philosophical and a practical level, the Hierarchy (with its management processes) opposes change. It strives to eliminate anomaly, standardize processes, solve short-term problems, and achieve stopwatch efficiency within its current mode of operating.6
The Agile optimizing goals are not in line with the purpose of the functional hierarchy. This organizational design invites managers to optimize the silos separately, but customer value flows horizontally across silos—not vertically across the hierarchy. So, if you want the organization to learn fast and use that learning to correct its direction, you need to focus on how the silos interact, not on how they perform separately. This implies minimizing costs when switching between jobs and getting the work through your organization as effectively as required. But how do you do that? By minimizing task switching costs and transitioning from resource efficiency to flow efficiency. In the context of software development, for resource efficiency it is more important to ensure each team always has a feature to work on. For flow efficiency, it is more important that a feature is always being worked on. So, in an organization focused on resource efficiency, the work is likely queued before each team with the goal of always keeping them busy. In contrast, in an organization that emphasizes flow efficiency, the goal is for teams to always be ready to pick up work, which implies that teams are expected to learn to understand and work effectively on multiple topics; if there is nothing to work on, then the teams must be idle sometimes.
An excellent way to achieve agility is by redesigning your organization. If you are not willing to make this effort, then scaling Agile in an organization with a functional hierarchy design will get you into trouble quickly, as we will show next.