Ever heard a team, while refining a product work item, such as a user story, say “we will need a DBA for this”? Does the team immediately freeze up because that means they will have to wait weeks, or even months, to get assistance?
Many software development organizations have adopted the practice of shared service teams as a solution to increasing efficiency. These teams, typically structured around specific skillsets like Quality Assurance (QA), User Experience (UX), or Database Administration (DBA), provide specialized expertise to multiple development teams.
While the rationale behind shared services teams – maximizing resource (people) utilization – sounds logical, it hides a critical tradeoff: a negative impact on product delivery flow.
Part of the theory behind shared service teams is that these skillsets are expensive so they must remain fully engaged all the time. In other words, management wants 100% utilization across these skillsets. The other part of the theory, less often discussed, is protecting management fiefdoms/silos comprised of a specialized skillset. This might include aspects of knowledge hoarding.
In this article I will illustrate how optimizing for resource efficiency, at the expense of flow efficiency, creates bottlenecks, dependencies, and adds orchestration overhead. These avoidable constraints result in a reduced speed and lower effectiveness of delivering value to customers.
The perceived benefits of shared services teams comes from the idea of resource efficiency. This focuses on keeping individual specialists busy and maximizing their utilization. For example, a dedicated QA team performs testing work for multiple development efforts, ensuring that testers are always working. Similarly, a centralized UX team can handle design requests and reviews from various product teams.
This approach appears cost-effective, as it minimizes perceived downtime and ensures that specialized skills are fully engaged.
However, this focus on individual utilization overlooks the critical aspect of flow efficiency. Flow efficiency measures the smooth and uninterrupted progression of work from idea to delivery, also known as from Concept to Cash.
Flow efficiency emphasizes minimizing delays, hand-offs and roadblocks that impede the overall development process. Shared services, while seemingly efficient from a resource perspective, often create significant impediments to flow.
Imagine a company that has 4 main value stream or product development teams (see image below). Within each of these value streams is the potential need to have UX, DBA and QA efforts on a more granular level, such as user stories. These needs are being serviced by 3 separate shared services teams with specific skills.
On the surface this seems OK, right? Send the work to the specialist needed at the time. But when you need assistance from a specialist on a shared services team they are not sitting around waiting for your request. They are already fully engaged servicing the needs of other teams with work items of varying priority. Your request may not go to the front of the line, it may not be “next”.
So while each member of the shared services teams might be busy, the majority of the work items requiring their assistance spends considerable time waiting in backlogs (queues) for availability. This is the problem with shared services teams. They introduce delays caused by:
- Hand-offs and Dependencies: Work items get queued up in backlogs, waiting for available resources in shared service teams. A feature might be fully coded but stuck waiting for UX review or QA testing, creating bottlenecks and delays. These delays might take weeks, or even months, to clear. The hand-offs themselves introduce potential for miscommunication and misunderstanding.
- Orchestration Overhead: As work moves between different teams with varying priorities and processes, communication complexity increases. This can lead to misunderstandings, rework and further delays. Imagine the number of emails and meetings required to clarify requirements, negotiate priorities and resolve issues across multiple teams. Maybe you don’t have to imagine it, maybe you already experience it.
- Context Switching: Specialists in shared service teams continually jump between work from different value streams or product teams. This context switching significantly reduces individual productivity and increases the risk of errors. It takes time to ramp up on a new work item, understand the context, and get into the zone.
- Reduced Ownership: If a delay occurs, it’s easy for each team to point fingers at others. These actions reduce feelings of ownership and complicate correcting issues. The Blame Game benefits no one.
- Longer Feedback Loops: The separation of skills slows down feedback cycles. If development, testing, and UX are siloed, it takes longer to identify and address issues. It takes longer to discover if we are building the right thing and building the thing right. This delays the development process and can lead to delivering a lower quality product that is of lower value to customers. Agile development aims to shorten all feedback loops to reduce these risks.
- Decreased Product Focus: Shared service teams often prioritize utilization metrics over product outcomes. This can lead to a focus on completing tasks rather than delivering value to the customer. For example, incentivizing testers to complete a certain number of work items per time period regardless of the impact on the individual products.
- Wrong Focus: Shared service teams make managing specialized work and people easier. They do not make doing the work easier, they make it harder for the reasons identified above. Making work easier to do is of far greater benefit to your customers.
The core issue is the fundamental difference between resource efficiency and flow efficiency. Optimizing for resource efficiency comes at the expense of flow efficiency. It’s the difference between rush hour traffic and a Sunday afternoon drive in country. During rush hour all the lanes are full of cars & trucks (high resource utilization) but the traffic is barely moving (low flow). On a drive in the country the lanes are pretty empty (low resource utilization) but you can cover the same distance as in rush hour in far less time (high flow).
Shared service teams operate at rush-hour utilization levels each day, all day.
“If you optimize for busy people you’ll get busy people. If you optimize for finished work you’ll get finished work. What has more value?” – Klaus Leopold
So, how can we improve product delivery flow, how do we find a better balance between resource efficiency and flow efficiency?
The solution is breaking down silos and moving towards organizational structures and systems that prioritize flow efficiency. Two common approaches are:
- Feature Teams/Cross-Functional Teams: These teams bring together all the necessary skills (development, QA, UX, DBA, etc.) within a single team. This structure reduces orchestration costs & hand-offs, improves communication, creates faster feedback loops, and increases ownership. The team is collectively responsible for the end-to-end delivery of value. Fully cross-functional teams are the building blocks of a more Agile organization.
- Product/Value Stream Teams: These teams combine to form the entire flow of value delivery, from initial idea to customer delivery, from concept to cash. They encompass all the roles and skills needed to take a product from concept to launch. This structure further optimizes flow by focusing on the entire process rather than individual teams. This is systems thinking where optimizing the whole is the overarching goal.
Let’s look at how this might be modeled on a Kanban board.
While this might still sound quite a lot like shared services teams, specialists still doing specialized things in a workflow, there is a fundamental difference. Your team’s work items are not competing with work items from other teams for attention. This is a game-changer for improving flow.
Transitioning from shared services teams requires careful planning and implementation. Organizations need to:
- Invest in Skill Development and Cross-Training: Enabling team members to perform multiple roles reduces dependencies on specialists and increases team flexibility. This is not the same as believing everyone should be able to do everything, which is a common criticism. People still have deep skills in an area or two, but, when the flow is bottlenecked at a different skill, others can assist to remove the blockage. Challenge teams with this goal, let them self-organize to decide how. The tactics used may be different for different teams.
- Form Effective Teams and Empower Them: Teams should have clear goals, autonomy to make decisions, and ownership of their work. Their work should align to strategy with clear prioritization. This improves their ability to work more independently.
- Manage Change Effectively: Moving away from familiar structures and roles can meet resistance. Effective Change Management, open communication, transparency, and training are crucial for reducing fear and managing this change successfully.
- Measure the Right Metrics: Track Lean metrics like lead time, cycle time and throughput to measure the impact of the transition and identify areas for continuous improvement. Tools like Improvement Katas will teach scientific thinking and improve experimentation quality. Form change hypothesis’, perform the experiment then validate with data.
Moving away from shared services and embracing cross-functional teams is not a quick fix. It requires a shift in mindset, a commitment to continuous improvement and a willingness to invest in people and processes.
Start small. Chose one shared service team to disseminate into cross-functional teams. Be sure to baseline performance of teams before the change. Give the new model a couple months for teams to stabilize within the new system. Form, Storm, Norm type behaviors. Measure again. What did you learn? What didn’t work as well as it might have? What will you do differently when distributing people from the next shared service team?
The long-term benefits are substantial. By optimizing for flow efficiency over resource efficiency organizations can significantly improve product delivery performance. This includes increasing customer satisfaction and reducing time to market.
Breaking down organizational silos is key to improving the effectiveness of your software development teams and systems.
Until next time!
