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.
However,…
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 sunk 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.
Read the full episode at Creating Agile Organizations.