This article is a part of the blog series about the book: Creating Agile Organizations - A Systemic Approach, by Cesario Ramos & Ilia Pavlichenko.
The Titanic sank on the night of April 14-15, 1912 after colliding with an iceberg. The liner was moving almost at a top speed of 42 km/h. High speed in waters occupied by ice was a common practice at that time. They hoped that the lookouts would notice an obstacle and the liner would change its course. Despite this, the Titanic did not manage to avoid a collision.
Figure 1: Titanic
Believe it or not, this story is playing out again today in the world of product companies. In the quest for short-term gains and rapid productivity, organizations are sacrificing their long-term agility and adaptability, just like the Titanic did. But fear not! We can learn from history and prevent ourselves from meeting the same fate. So, let's explore how companies can avoid becoming the next Titanic and instead chart a course for long-term success.
Product Fragmentation
In organizations we frequently observe a dynamic that is called product fragmentation. Let's say one or more teams are working on a product. Market trends and demands change. How to respond to a sudden change that teams are not able to absorb? A quick solution is to hire more teams and/or developers in a product area that is currently under pressure. The issue is temporarily resolved. But the market changes again and the organization applies a quick solution once more.
Figure 2: Reduced adaptability while increasing specialization
Along with hiring, management increases teams’ specialization, assigning them to narrower areas of the product. While the most valuable work lies in product areas experiencing peak loads, other teams do not help. First, because they are not aware of it. They work with local “Product Owners” from local “Product Backlogs”. Second, because they are not capable. They do not have proper domain and technical skills. Nevertheless, that doesn’t mean they stay idle. They “efficiently and productively” occupy themselves with less important work from the overall product perspective, pumping up the product with unnecessary functionality, complicating the architecture and increasing the cost of product ownership.
Figure 3: Low adaptability makes it impossible to deal with peak loads
The cycle is repeated many times. As a result, over the years organizations end up with a complex architecturally and functionally product that is being developed by dozens, and sometimes hundreds of teams. Teams can even remain partially cross-functional and deliver features to the market on their own, but only from a narrow product area, and, of course, often not the most important ones from the overall product perspective. With each cycle, the ability of the product group to adapt to changes in demand reduces along with an increase in teams’ specialization.
If you are familiar with systems thinking, the story can be illustrated with a causal loop diagram (CLD):
Figure 4: Adaptability reduces over time
This is a typical Fixes That Backfire archetype, in which a quick solution (balancing loop B1) helps only temporarily. The problem returns with more severe symptoms because the negative effects of the quick solution accumulate over time (reinforcing loop R2).
This is how product Titanics are born.
Why do smart people do this?
Why do smart people take actions that reduce organizational adaptability in the long run? Most management decisions are focused on improving individual parts. This approach is driven by education. Business schools teach each of the functions of a corporation separately—production, marketing, finance, personnel, and so on—and never address or inadequately study how they interact. Management is used to dividing the whole into parts and managing them separately. A mental model is dominating:
To improve the whole we need to improve the parts
Is it so? Imagine what you would experience if your organs (heart, lungs, circulatory system) began to work at their highest possible productivity. For example, the heart would beat at a frequency of 250 beats per minute, and the number of respiratory cycles, which is normally no more than 20, would increase to 50?
When the performances of the parts of a system, considered separately, are improved, the performance of the whole may not be (and usually is not) improved. No part of a system should be changed without understanding its effect on the whole and determining that this effect is beneficial (Ackoff, Russell L.. Re-Creating the Corporation).
How to avoid fragmentation and develop adaptability?
So, you want to create an Agile organization that is capable of quickly responding to changes in a market demand and work on the most important stuff. What should you do? Let's get back to systems thinking. In order to optimize the whole, we must re-subordinate the purposes of parts to a larger purpose - adaptability!
Therefore, the proper organizational design must meet several conditions:
- It should create transparency on what items are the most valuable in terms of the overall product.
- Teams should be able to deal with the peak loads.
Seems like a good old scaled Professional Scrum might help. We see multiple teams working from a single Product Backlog sharing a single Product Owner.
Figure 5: Adaptability - every team can pick up any item
Imagine a product group with 8-10 cross-functional teams. Each team can pick up any feature that comes into the product group, which means that all teams in the product group can always work on the most critical work. Also, imagine that all teams optimize for delivering a feature in short cycles (e.g., two weeks) from an idea into the hands of the end user, which means that they have fast feedback for learning. As a final step, imagine that the teams split large work items into small items, which they then work on during each cycle. Such a product group has the conditions to be maximally Agile. If the product is so large and more than 8-10 teams are involved in its development, then consider using the Value Area pattern and split the product into large parts, removing the cognitive load from the teams and the Product Owner.
Yes, but that won’t work in my organization...
I bet you're thinking, "This sounds great in theory, but it won't work for my team." It's natural to feel that way, but let me tell you - you're both right and wrong at the same time.
You're right that your team won't become adaptable overnight. It takes time and effort to regain skills that may have been lost due to product fragmentation over months and years. But don't give up just yet! Like athletes who train their bodies to lift heavy barbells or run marathons, your team can learn to be more adaptable with the right training and support.
Don't believe me? Give your team an organizational design that encourages adaptability on a daily basis. The more they work on projects from unfamiliar areas, the more adaptable your product organization becomes over time. It's like building muscle - the more you work at it, the stronger you become.
With patience, persistence, and the right tools, your teams can become adaptable.
I hope this was helpful. I wish you maximum adaptability in your product organization! )))
Are you interested in learning more about how to create agile organizations? Welcome to the site www.CreatingAgileOrganizations.com