Evolving Your Agile Organizational Framework
By Cesario Oliveira Ramos
Meet Sara, a driven product director who’s always up for a challenge. But with ambitious targets to attract 10,000 new clients, increase customer satisfaction by 35%, and keep top talents on board, she’s starting to worry if her organization is up for the task.
Determined to find a way to meet her goals, Sara knows that her organization needs to step up and embrace new capabilities. With the way things are currently set up, there are too many dependencies between teams, conflicting goals, and coordination issues that are holding them back. It’s like trying to run a race with one foot tied to a rock – they’re not getting very far.
Despite working hard, her teams seem to always get bogged down in low-value tasks, unable to focus on what really matters. It’s frustrating, and Sara is not happy with the current situation at all. It’s time for a change – a new approach that will get everyone working together towards a common goal.
So, she had a meeting with her management team to discuss how to improve the current situation. The result is a list of capabilities they believe will enable her group to deliver on the ambitious goals.
Agile for Customer-Centric Development: Sara’s Plan for Success
Sara strongly believes that her organization requires three critical capabilities to succeed. The first is the ability to deliver new functionality rapidly and efficiently. The second, equally important capability is to understand and quickly adapt to their customers’ needs. She acknowledges that they are currently gathering feedback from their customers, but the feedback loop is too lengthy and needs improvement.
Sara also recognizes the importance of the capability to allocate her teams to work on the most important product functionality, rather than simply having the teams focus on their areas of expertise. Therefore, she seeks the capability of broadly specialized teams..
With these capabilities in mind, Sara is eager to take action and explore different avenues to achieve them. She’s even considering implementing some of the latest scaling frameworks to help her organization..
So, she calls in her agile coach Kim to help her on this matter.
After explaining her problems and required capabilities, Kim starts explaining the impact it will have on her organization and management style.
Resource Efficiency vs. Flow Efficiency: Striking the Right Balance
Kim starts with the topic of efficiency: Which efficiency do you mean? There are two types of efficiencies that are important for us to consider. Resource and Flow efficiency and it is very hard to score high on both. Therefore, it is important to prioritize which one to focus on.
Let me explain: Resource Efficiency is about making the best use of your team’s time and expertise. For example, if your team has five days available to work and they work full-time for five days, they are considered 100% utilized. Conversely, if your team only works 2.5 days, their utilization rate drops to 50%. Resource Efficiency also involves using your team’s expertise most efficiently. A UX specialist who works solely within their area of expertise is considered more efficiently used from their perspective than when working outside their area of expertise. Optimizing your resources is key to improving Resource Efficiency.
On the other hand, Flow Efficiency focuses on how efficiently your team can take an idea and turn it into a solution that’s ready for your customer. For instance, if a feature could be developed in five days without any delays, but it takes ten days due to delays, coordination issues and conflicting goals, the flow efficiency rate drops to 50%. To achieve high Flow Efficiency, teams need to be ready to work on the feature at any given moment, without any delays or pauses. This means e.g. that they cannot be busy with other tasks as that would create delays. Flow Efficiency helps achieve faster results and shorter feedback loops from customers, enabling you to learn more about them.
But there is a catch, to achieve your goals of fast delivery, you need to accept lower Resource Efficiency and adjust your actions accordingly.
Kim elaborates further on the concept of flow efficiency, emphasizing that it is necessary but not sufficient for allocating teams to work on the most critical functionality. If teams have high flow efficiency but work on a narrow domain, they may be fast but not adaptable at the overall product level. To illustrate this point, imagine multiple teams, each responsible for a specific domain. While each team can efficiently solve problems within its domain, they cannot help with work outside of it. When the most important work happens to be in a domain that is overloaded, the other teams cannot assist, resulting in the group being unable to work on the most important tasks.
Let me draw it for you, that makes it easier to understand.
Each of these domain teams is cross-functional and super fast, you give them a problem and they can solve it end-to-end. But, each can only work on its domain. Look what happened when e.g. the most important work is in the red domain.
The red team A becomes overloaded, but the other teams cannot help because they only know about their specific domain. So, teams B, C and D still work on something, but it is not the most important work. The result is that the group has low adaptability and cannot focus on the highest-value work.
To effectively change direction, it’s crucial that the cost of making such a change is minimal. For instance, if a feature took six months in budgeting, planning, analyses, and design, but then deemed unnecessary in the first weeks of development, the costs associated with dropping it would be high. This would create hesitation among stakeholders and teams because of sun costs. Therefore, it’s necessary to have a low-cost adaptation strategy in place to ensure that you can prioritize high-value work. This can be achieved by limiting the work in progress, working in short iterations, minimizing the learning costs associated with stopping existing work and starting new work, as well as reducing the expenses associated with repeating tasks and overhead activities like coordination, deployment, and testing through automation.
So, I hope this explanation clarifies the impact required for the group to achieve the desired capabilities.
Align Organization Design With Strategic Focus
Unfortunately, you cannot buy the capabilities, instead, we need to develop them over time. Developing Agile capabilities requires unlearning ineffective practices and adopting new ones. Over time, these new practices replace old habits and become ingrained in the organization’s culture. To achieve this, it’s important to create the right working environment.
A useful analogy is the process of developing a healthy lifestyle. If someone wants to be able to party all night, have energy for daily life, and look good on the beach, they might start with a daily full-body workout. However, if they continue to eat fast food and get only three hours of sleep per night, progress will be slow. Instead, they need to combine their workout with a healthy diet and regular sleep to see real improvements. Over time, these elements reinforce one another, leading to better results.
In the same way, an organization needs to align its structure, processes, people practices, and reward systems to build Agile capabilities.
The example below shows your current setup; it is a poorly aligned design that makes it difficult to achieve your required capabilities.
Example of poorly aligned organization design components
Instead, a well-aligned design as shown below should be created to ensure that all components work together to reinforce the desired Agile capabilities.
Example of properly aligned organization design components
The longer and more you work in the new design, the better the result.
Consider To Evolve Your Own Framework
Implementing an Agile framework can be useful for organizations. It provides a ‘safety net’ that ensures well-defined rules, processes, and established roles. With all the critical mistakes you could make in your organizational design, Agile scaling frameworks can help minimize those risks and keep things running smoothly.
However, with so many options out there, choosing the right framework can be a difficult task. There is a whole spectrum of frameworks. One framework may have minimal rules, while another might be packed with extensive guidelines and more roles than a Broadway play. The wrong choice could result in frustration and unnecessary details that don’t align with your needs. And let’s face it, you do not want to be hindered by a framework that just doesn’t fit your product group.
But, be aware that without the support of a framework, we have to make all design decisions ourselves, and there are many to consider and many mistakes to be made. As the famous chess player Savielly Tartakower once said at the start of a game: “The mistakes are there, waiting to be made.” However, after you’ve been through all that, the end results will better meet your specific needs and more importantly your teams will feel ownership of their process because they build it themselves.
We can follow Agile organization design guidelines to avoid making unnecessary mistakes that are painful and costly. I’ll tell you about them shortly, but let’s begin by taking a step back to gain a broader perspective.
Optimize The Whole: Your Product Group
Our ultimate goal is to achieve high performance at the group level. This requires a systemic approach, based on four key principles of systems thinking that are vital to consider when making decisions about organization design.
The first principle is that the performance of a system depends on the interactions between its parts. For instance, if team members focus solely on their individual goals and neglect the team’s objectives, the team’s overall performance will suffer. Conversely, if team members work together collaboratively towards a shared goal, they will likely outperform a group of individuals who work independently. The same idea applies across teams, we want them to work collaboratively too.
In general, the behavior of each part of a system can impact the performance of the system as a whole, so it’s important to foster positive interactions between parts.
The second principle is that a system cannot be divided into separate parts. Just as a car requires all of its essential parts, such as the engine, to function properly, a product group needs all of its essential elements, including people, processes, systems, and skills, to fulfil its purpose. Removing any critical component will impede the group’s performance and reduce adaptability..
The third principle is that optimizing a system may cause one or more of its parts to be sub-optimized. Similarly, optimizing one or more parts of a system may lead to sub-optimization of the system as a whole. For example, when one team becomes overloaded with work, the other teams may not be able to help because they lack knowledge of the relevant domain. To ensure the group focuses on its most important work, other teams may need to work outside their main areas of expertise, thereby optimizing the performance of the group at the cost of their local performance.
Define The Product Group, Then Optimize The Interactions
To optimize the system, we first define the entire system. In our case, the system is the product group, including all teams, systems, and functions, and then enhance the interactions between them. Below you can see an example of how your product group might look like.
Example of Sara’s product group with all essential parts.
Next, we de-couple the product group from the rest of the organization as much as possible, allowing it to act autonomously and change direction without being slowed down by the organization. In the end, will have a semi-autonomous product group with some shared services. Below you can see a prototype Agile organization setup with four loosely coupled product groups with some shared services.
Prototype of Agile Organization Structure Semi-independent Product Groups
To summarise the steps
- Step 1: Define the product group
- Step 2: Loosely couple the product group to the rest of the organization.
- Step 3: Improve the interactions of the parts within the product group.
Okay, I will explain step by step how to come to the Product Group. I will use three critical guidelines that help you avoid common mistakes and show how your product group and larger organization can be built up from scratch.
Identify Essential Parts of Your Product Group
Our goal is to identify all the essential components of your product group, including teams, individuals, processes, services, and systems, necessary to accomplish its purpose or mission.
To begin, we define the product, which involves two steps.
- First, we determine which of these components are required to develop, enhance, or maintain the product.
- Second, we identify the revenue stream associated with the product, as it is a critical indicator of its viability.
To identify the product, we start with the customer or customer segments and determine their needs or problems that the product aims to solve or satisfy. Then, we select a set of features, that users would use to address their needs or problems. For each feature, we then identify the teams and individuals who need to develop, configure, or update it, as well as the systems, processes, and components that require updating or configuring. This process results in a comprehensive list of organizational elements. The picture below shows the whole idea I just talked about.
Outside in Product Definition
Now, some of these elements will be required more often than others. For example, in the graphic below you can see that the Sales Force team is involved in 4 features while Web team only needs is only involved on a single occasion.
Feature HeatMap An X means the team is required for the corresponding feature
Also, note that Sales Force, Siebel and ESB teams are required most of the time in developing a feature. This type of information is useful to decide which skills are required in cross-functional teams. Obviously, creating teams with Sales Force, Siebel and ESD skills likely gives you the most adaptability.
So, based on this exercise we created the initial setup of the cross-functional teams. See the graphic below.
In the second step, we analyze whether these elements together create an end-to-end revenue stream and deliver on the mission. If not, we identify and add the missing components.
That brings us to guideline 2. Guideline 2 is about making well-informed decisions regarding the selection of skills for your cross-functional team, as well as determining which functions to incorporate into your product group. To do so, it’s necessary to gather additional information. One effective method is to assess the nature and intensity of the dependencies involved.
Uncertainty and Frequent Two-Way Dependencies
Let’s consider three types of dependencies – pooled, sequential, and reciprocal. Let me explain why. The graph below shows the coordination cost associated with each type of dependency. Reciprocal dependencies have a coordination cost that is approximately twice as high as the other types.
Reciprocal interdependence occurs when teams depend on each other’s work and need to coordinate regularly. Sequential interdependence occurs when the output of one team is the input for another. Pooled interdependence occurs when teams rely on shared resources.
Therefore, when selecting skills for inclusion in cross-functional teams, it is advisable to prioritize those with reciprocal dependencies first, followed by sequential and pooled dependencies. Units or skills that have sequential or pooled dependencies could potentially be separated into a distinct unit within the product group and not included as part of the cross-functional teams.
Should a skill be in or outside the cross-functional teams?
Using insights into the types of dependencies and their strengths, you can then determine which skills should be in the cross-functional teams and which could be separate units. In the graphic below you can see the reciprocal dependencies contained within each cross-functional team and separate teams with sequential and pooled dependencies.
So, this already starts looking like a product group that can deliver on its purpose, don’t you think?
We’ve been working on identifying the essential parts of our product group and improving the interactions within it. However, we also need to decouple the product group from the larger organization to be adaptable. To achieve this, we need to understand an important aspect of coupling that may seem counterintuitive.
Let me share the third guideline that we can use for decoupling the product group.
Coupling With Units Outside Your Product Group
While we want decoupled components in a software system to make changes easily, we need loosely coupled product groups so each can change direction without affecting others.
In a standard product-based organization, there are various functions, such as product development, sales, marketing, IT, as well as administrative functions such as staffing, planning, and budgeting. The key question from an Agile organizational design standpoint is how to assign these functions to different units within the organization in a manner that best serves adaptabiltiy. The simplest approach to organizational design involves assigning each function to a distinct unit. However, this can get us into trouble rather quickly.
Previously we saw a bottom up study of dependencies to determine the cross-functionality of the teams, now we are looking top-down to identify any coupling of the functions (e.g. KPI’s) of each unit (e.g. department).
The ideal scenario is for each unit to perform its tasks and make decisions that enable them to achieve its goals without hindering the ability of other units to fulfil its own functions and achieve its respective objectives. Nonetheless, when functions are interdependent, it can result in significant issues.
“Coupling between unit functions is associated with increased coordination costs, goal conflicts, ineffective or dysfunctional government, loss of productivity, and, most importantly, lower ability to respond to change. “
—Organization Design, N Worren
So, we need to decouple these unit functions so that your product group can change direction easily.
In general, there are three ways to resolve the coupling:
- Restructure and transfer responsibilities between units or to a separate unit.
- Merge units so that they share measures of success or customer outcomes.
- Redefine functional goals to remove overlapping and conflicts between units.
A result of decoupling could be that a responsibility is added to your product group. For example, imagine that sales are an essential part of your product group to achieve its mission, then it could be that you will need your specific product sales in your product group. Sales skills would not be needed inside the cross-functional teams but these would be placed inside the product group as you can see in the graphic below.
There is much more than we ended to take into consideration, but by following these three guidelines you will minimise your biggest risks. Anything else I can help you with?
I understand that, but it is already getting late and I really need to go home, so let’s leave these topics for another day, okay?