How do Agile requirements scale to the enterprise level?
There are a few ways to think about how Agile requirements management would scale to the enterprise level. The first is a bit of a "common sense" view— individual product teams don't operate primarily at an enterprise level; they focus on their individual areas of responsibility, so their approach to implementing the requirements is the same as if they weren't part of an enterprise.
From that point of view, their day-to-day operations are the same as if they were part of a smaller organization, and therefore "Agile" requirements are treated exactly the same, operationally, as for any other Agile team.
However, a healthy enterprise will be collectively executing a cohesive and coordinated strategy. That implies coordination among teams— both in satisfying complementary objectives and in synchronizing product development and delivery activities. This drives two other lenses through which to view Agile requirements management in the enterprise.
Each product manager and product owner team will be managing both a longer term product roadmap and a shorter term product backlog. The relative priorities of items in the roadmap will be set—for any Agile team—as the balance of stakeholder goals and market objectives.
For the product manager, working in an enterprise adds both simplicity and complexity. The simplicity comes from someone at a corporate strategic level articulating how goals for the product fit into the enterprise strategy—the product manager is not cutting a strategy from whole cloth.
The complexity comes from the required additional understanding of the roles that other products play in that strategy, and exploring the requirements of complementary goals and the opportunities to discover substitute solutions. Substitute solutions would be cases where a particular goal, assigned to one product (to meet enterprise goals) could instead be assigned to a second product.
There may be opportunities for the two products to more effectively meet enterprise objectives if product managers explore the possibility of rethinking the "ownership" of the enterprise goals. Regardless, the team will be operating the same way, once the added work in roadmap development is complete.
The final aspect— the one that visibly impacts teams—is synchronizing delivery. When goals are coordinated at a high level, delivery often must be synchronized in detail. Once the product managers have aligned their roadmaps at a thematic level (to coordinate the goals), the product owners need to coordinate their deliveries at the sprint level to enable interdependent functionality to be tested for interoperability, and to get feedback from customers (users and buyers). Teams can—and should—develop with mocked API responses or other techniques to minimize code-writing dependencies, allowing them day-to-day freedom of operation. They will, however, need to work together to establish and evolve those APIs.
There will be times when two teams will choose to not complete codependent feature-development in the same sprint due to other, overriding priorities. When that happens, the code that is developed first will lie fallow until the other team can deliver it.
One goal of Agile is to minimize the time that code sits on the shelf without customer feedback. Remember that timing in Agile is usually guided by doing things "at the last responsible moment." The value of synchronizing is just an additional factor in defining "responsible."
When more than two teams are coordinating, the problem is only larger in scale, and not different in principle. When the number of teams that are synchronizing delivery grows, the efficiency of one-on-one coordination conversations drops, and teams will adapt by introducing a Scrum of Scrums— a daily stand-up meeting where product owner and Scrum master representatives update each other on the completed and planned coordination activities, and identify blockers to their teams that impact other teams.
This was first published in July 2012