Product Owner Consortium: Agile on a Tight Budget

Insights

• Agile is popular across industries and business functions and has been proven to deliver business value faster.
• In this case study, the IT development function of a global manufacturing firm chose Agile as its key delivery method
• But due to budget constraints, Agile required significant customization, with the use of a product owner consortium model
• In this paradigm, a single development team, with help from the proxy product owner role, supports IT development across regions and business lines
• The product owner consortium is still delivering business value, having been instituted three years ago

Agile has become a widely deployed approach that delivers significant value across business functions. Infosys Agile Radar 2021 research found that more than half of large incumbents have implemented the methodology beyond IT into operations, supply chain, finance, and human resources.¹

From an engineering standpoint, Agile delivers higher quality products and better outcomes with fewer defects. It has become popular in manufacturing circles, with firms such as Bosch, Intel, and even the iCETS arm of Infosys, using Agile to drive better value and innovative products.

However, with so much work done to get the product out of the door, progress usually becomes slow, innovation comes to a standstill and business outcomes are adversely affected.

The case of a manufacturing firm in the Americas

In this case study, we look at the American unit of a global manufacturing firm that drives value through high quality products, spanning electrification, automation, and digitization. It wanted to transform its regional IT delivery and institutionalize Agile at scale, but its teams across geographies didn’t have a budget to get a cross-functional team working effectively.

The solution was to modify Agile to suit its specific requirements. In partnership with Infosys, the firm established the product owner consortium model — the concept we have discussed in this paper. In this model, proxy product owners work together across business units to form a common Agile team to achieve desired results. These proxy product owners act as the bridge between business and IT teams to remove any friction in business processes.

The journey of developing this model was a steep learning curve for the firm and Infosys, with constant thought given to risks, methodologies, processes, and ultimately business outcomes. However, the end results were encouraging. The company could deliver expected results, irrespective of unit sizes and budget constraints.

Waterfall and its limitations

Before Agile, the manufacturing unit followed a waterfall methodology, where IT development used to follow a shared services approach. Developers worked with business units from the U.S., Canada, Brazil, and Mexico to provide IT development and enhancement services. All requirements were funnelled through a project management office (PMO), and each request was catered to all aligned business units depending on resource availability (Figure 1).

Figure 1. The unit’s traditional IT development flow

Execution challenges associated with the waterfall methodology delayed development and lost customer focus. Assets and resources such as new software and human capacity were assigned to multiple projects simultaneously, reducing speed, and productivity.

Prioritization, a mantra for working fast and better, was also difficult. The common development team constantly took directions from multiple business units without a clarity on the associated business objectives. This led to missed deadlines, as each developer had to multitask and address customer pain points simultaneously and in real time. As work flowed from multiple directions, prioritization became a significant issue, with business customers misunderstanding what was expected to be delivered at what time. And with several requests submitted to the product pipeline simultaneously, the shared IT services team focused on complex problems for large projects and left those with low budgets scrambling for attention.

There was also little workflow predictability — an essential part of all manufacturing operations — with stop-start scenarios and constant reshuffling of project priorities and allocations. For several teams on an extremely low budget, project closure took months rather than weeks. This limited their ability to deliver business outcomes such as increased revenue growth, better EBITDA, customer-centricity, and innovation.

Traditional Agile is not sufficient

Waterfall limitations brought attention to the Agile way. The mantra became “start finishing, stop starting”, following the Japanese method of product delivery coined at Toyota in the 1980s.² Workflow predictivity and removal of blockers was the key here, especially due to low resource availability. However, shoe-horning traditional Agile as-is led to a resource pool shared across many internal teams. Expenditures increased as timelines shifted to meet ever-threatening product releases.

Another problem with traditional Agile is how teams function. There are five to 11 members in any given team, including the scrum master (or Agile director) and the product owner. These teams spend a lot of time on initiatives, familiarizing themselves with products and any new features that are added to the product backlog. However, with the manufacturing behemoth, a few of the regional unit teams constantly battle low budgets and talent shortage to make teams of optimum sizes come alive. Using small two-to-three-member non-Agile teams reduces the cross-functional ability to sustain innovation and organizational momentum in the long term. Further, instituting product-centric value delivery, in which value chains are organized around business-oriented customer journeys, is an issue. Businesses across sizes, industries, and geographies go through budget-related troubles regularly. As happened in May 2022, companies such as Uber and Meta announced significant cost-cutting initiatives, especially focused on hiring.³ A customized, cost-effective Agile setup becomes crucial in times when corporations are pressed for funding, innovation, and value.

Product owner consortium for success

To solve this issue, Infosys helped the manufacturer develop the product owner consortium. In this model, the firm used a single Agile team that supported a group of product owners from different business units with small execution budgets. With a backlog of both large and small pieces of work, each business unit was synced in real time, with work outstanding linked in a common product backlog. The scrum team within the product owner consortium model then refined, prioritized, and leveraged this common backlog to deliver desired business outcomes.

In this consortium, the overarching Agile development team is resourced with diversified skillsets across business units. This means it has the right skills to solve problems quickly and in real time. With the common resource pool, this team can be sustained for up to a year, a lot longer than any individual business unit can afford.

Getting a right size team depends on several factors, including historical and projected spend; kind of work and way of working; available skillsets and talent; and a roadmap to ascertain the team can continue innovating even with less resources.

Why this construct works

This construct works well to deliver desired business outcomes. Teams using this model are more autonomous, self-organized, and cross-functional, helping multiple product owners. The proxy product owner is given the necessary control to deliver results. Our Agile Radar research found that Agile levers lead to significant business performance and growth. When instituted together, these levers can increase business growth by as much as 63%.⁴

Figure 2. Product owner consortium with proxy product owner role

Model institutionalization

The true Agile delivery is about getting work done, even in difficult times. For this, execution of the roadmap and ensuring associated benefits are all-important. To become successful, the firm’s product owner consortium needed to resolve a few outstanding challenges, with business and IT working together to understand:

• Prioritization of user stories across business units and applications.
• Resolution approach in case of any conflict between business units.
• Value delivered to each business unit.
• Assessment of performance-based funding received by each team.

The firm used a three-pillar setup to establish the role of proxy product owner; institute a business-first culture, supported by clear operating guidelines; and follow robust accounting practices.

Proxy product owner role

The role of proxy product owner is typically filled by an IT representative with domain knowledge, responsible for working with product owners across business units. The person acts as a bridge between business units and the consortium and is responsible for the common product and feature backlog, including prioritization.

The proxy product owner must have a good understanding of Agile concepts, with high emotional intelligence, humility, and understanding of data.⁵ They should practice Agile concepts such as better customer insights through transformed customer journeys, and the value of product-centric value delivery. This helps them understand business requirements, ask the right questions, elaborate user stories and assign the right priorities.

They should also know the concept of minimum viable product (MVP)-based funding, an appreciation for industry trends (and the wider ecosystem of products and vendors). That’s how organizations can transform from “doing Agile” to “being Agile”.⁶

For seamless operations and removal of blockers, the product owner consortium needs to have a high-level view of the responsibilities and duties for each team. (see Figure 3). These guidelines help product owners and proxy product owners understand the workflow and objectives of the consortium. Further, the guidelines ensure that the proxy product owner connects the right domain knowledge to the development team and helps the firm navigate subtle processes from different business units during backlog refinement and user story definitions.

Value-driven culture establishment

Beyond onboarding, the proxy product owner and mapping role responsibilities, the Americas unit also shifted from a tactical culture to a business value-driven approach. In a traditional setup, different business units are not aware of pending requirements from others fighting for resources. Hence, most business lines end up pushing their work to be finished ahead of others, creating inefficiencies and slowing the transformation of the whole firm. They are also unaware of the team level objectives and key results (OKRs), and hence, their own roadmap and way of working suffer.

To overcome this challenge, the product owner consortium shared regular updates on the common backlog to all business line owners. This meant that product owners had complete visibility of their team’s bandwidth and the associated challenges.

Figure 3. The product owner’s primary and secondary responsibilities

To further boost transparency, product owners within Agile teams across the manufacturing firm were kept up to date with business objectives and desired outcomes from a business-first standpoint. All product owners in the consortium met every week to bring all stakeholders together, increasing conversation, goodwill, and value. These meetings aimed to prioritize work to ensure each scrum team clearly understand their end goal. This led to increased collaboration among product owners and the scrum team.

Even with this level of transparency, misdirection can still occur. To effectively work, the company adhered to the definition of “ready” – the minimum requirements to move user stories into the common backlog. The manufacturing firm also followed a predefined prioritization mechanism for consistency of operations and ensured that goal setting was transparent and communicated throughout the organization.

That’s how an optimum Agile team was built. These working agreements, together with the additional role of proxy product owner, helped jumpstart Agile teams with small budgets through consolidation of their work through the proxy product owner and the associated guidelines.

A new way of funding initiatives

There was one last challenge to address: accounting. Since each business team was sponsoring only part of the Agile team, it was important that each team got value against their investments. Here, again the principles of Agile, ways of Agile estimation, and customs of calculating work done, posed challenges on balancing payments to work done.

In traditional scenarios, a request is handled by the PMO. They assign a small team to create hourly estimates, and those estimates are agreed on by the business before start of work. Any change to scope results in change requests and revision of estimates. In Agile, hourly estimates come late in the game and there is no need for change requests. There is no direct correlation between a story point and an hourly estimate as well. For long standing teams, they seem to map but for teams starting new, there were no benchmarks to rely on.

To address these, the manufacturing transformation team decided to use actual hours spent on the work. While story points were to be used for estimation and velocity was to be used for team consistency calculations, actual hours were used to address payments against the work done.

The basic Agile processes remained as-is. The addition was that each business unit had a cost center code that was used to report time when the team members were assigned work. Hours reported were only against the cost center, and not by every story, to make sure that the overheads associated with the reporting stayed minimum. These actuals were used to calculate the individual business unit spend per sprint and reported periodically by the proxy product owner (Figure 4).

Figure 4. Sample product owner consortium value reporting

Agile teams within the manufacturing firm were able to make informed decisions about the health of their story backlog and the budgets exhausted in developing finished stories. This mode of regular reporting helps:

• Teams understand their backlog health and decide whether to add more funds or groom the extra backlog (this is based on the stories planned versus the completed graph from Figure 4).
• Teams ascertain how much they have spent at any given point in time.

Based on the amount spent and the stories planned and in progression, business teams can decide if they should add more funds, extend the scrum, team, or rebalance the tasks to ensure each team receives its due value. This assessment is carried out quarterly so that each business unit has a continuous flow of work based on priority.

Toward customer success

Agile done well delivers customer-centricity, fast. Doing these three things — introduction of the product owner consortium concept; establishment of high-level guidelines; and agreement of team-level accounting — builds the foundation for implementing agility in small teams with low IT budgets.

While moving from almost a standing start, the manufacturing company successfully deployed the product owner consortium model, which led to better outcome predictability, faster delivery, and more customer-centric engineering products. Each business unit achieved desired outputs while remaining in budget. The testament to the model’s success is that the firm still uses this framework and methodology three years after it was first instituted.

As Agile expands across business functions, it will need fine-tuning and adjustments based on the businesses’ operating conditions. This fine-tuning extends across funding, legacy technology, culture, incentives, and C-suite involvement. The right Agile levers can help here.⁷

The building block of the consortium are fact-based accounting, rigorous roadmaps, intact business plans, and an OKR setup, where the firm’s mission statement is driven from the top down. Doing so will build bottom-up intelligence and ensure both stakeholders and shareholders are happy. In all, do it right, and the product owner consortium will increase productivity, customer satisfaction, and trust.

References

1. Agile Radar 2021, July 2021, Infosys Knowledge Institute.
2. The open secret of success, James Surowiecki, May 5, 2008, The New Yorker.
3. Uber CEO tells staff company will cut down on costs, treat hiring as a ‘privilege’, May 9, 2022, Deirdre Bosa and Ryan Browne, CNBC.
4. Agile Radar 2021.
5. Business Analysts: Agile Imposters or Value Drivers?, Suchitra Kulkarni and Harry Keir Hughes, Feb. 2022, Infosys Knowledge Institute.
6. Where Agile Goes Wrong, May 2021, Samad Masood, Alok Uniyal, and Harry Keir Hughes, Infosys Knowledge Institute.
7. Agile Radar 2021.

About Infosys Knowledge Institute

The Infosys Knowledge Institute helps industry leaders develop a deeper understanding of business and technology trends through compelling thought leadership. Our researchers and subject matter experts provide a fact base that aids decision making on critical business and technology issues.

To view our research, visit Infosys Knowledge Institute at infosys.com/IKI or email us at iki@infosys.com.

Download