- 10.3 Overview of Features
- 10.4 Benefits of Feature Preparation
- 10.5 Feature Preparation Activities
- 10.6 Timing of Feature Preparation
- 10.7 Assessing Readiness
- 10.8 Accounting for Preparation Work: Tasks and Spikes
- 10.9 Specifying Features and Their Acceptance Criteria
- 12.4 MVP Planning
- 17.3 Why Do We Need a Scaled Agile Approach?
- 17.4 Planning: Choosing an Approach That Supports Inter-team Collaboration
- 17.8 Scaling the Agile Organization
- 18.6 Agile Corporate Culture
- 18.7 Overview of Principles and Practices for an Agile Corporate Culture
- 18.8 Three Principles for Applying Agile Practices
This chapter is from the book
This chapter is from the book
This chapter is from the book
17.3 Why Do We Need a Scaled Agile Approach?
It’s common, in agile circles, to hear that a scaled agile organization should be composed of self-sufficient, independent teams.1, 2 If agile teams were, in fact, totally independent at scale, there would be no need for scaled agile frameworks (or this chapter); you would simply follow team-level agile practices and multiply them across the organization without any additional processes or roles. (As we’ll see, this is roughly the approach of the Large Scale Scrum [LeSS] framework.) Yet, in practice, dependencies among teams are the norm, not the exception, in scaled agile organizations. These persistent dependencies aren’t a bug. They’re a feature of a well-scaled organization, and it is neither possible nor desirable to eliminate them. Because agile teams in scaled organizations are interdependent—not independent—we need effective solutions for coordinating and integrating their work at scale.
First, we examine why teams are interdependent in a scaled agile organization. Then, we look at the following strategies for addressing that interdependence:
Planning: Choosing an agile planning approach that supports inter-team collaboration
Continuous Delivery: Integrating, testing, and delivering software continuously, safely, and sustainably at scale (DevOps/CI/CD)
Scaled Agile Culture: Creating a culture that supports innovation at scale
Scaling the Backlog: How to structure the product backlog in a scaled agile environment
Scaling the Organization: How to structure a scaled agile organization
Scaling the Process: Scaling the agile process to promote collaboration across teams
Scaling Tools: Tools and techniques for supporting scaled agile development and team coordination
Potential Issues in Scaling Agility: How to address challenges scaling agility, such as non-colocated teams and coordination with waterfall developers
17.3.1 Why Scaled Agile Teams Are Interdependent
Scaled agile teams tend to be dependent on each other because of the interconnectedness of a product’s features, technical complexity, and shared components. Let’s explore these issues.
17.3.1.1 Interconnected Features
Consider a mobile phone and the subproducts—or high-level features—it encompasses, such as a camera, photo-editing, messaging, and social-network capabilities. In a scaled agile organization, each of these subproducts is maintained by a feature team or team of teams.
The user can use each subproduct on its own, but the product’s full value lies in how all its subproducts work with each other. For example, customers can access photo-editing and messaging directly from the camera—enabling them to shoot, edit, and send images seamlessly. Because subproducts are designed to work together this way, rather than as standalones, they will inevitably have dependencies on each other—and so will the teams that develop and maintain them.
The same applies when the product is not a physical object but a software system. Consider Z-News, a fictional, digital news service. Z-News’s teams are organized by business areas (e.g., an order-processing team, a service-delivery team, a billings team). Now suppose that stakeholders have requested a new subscription service to deliver personalized news hourly to readers. This single request will require numerous teams working in concert with each other. The order-processing team will add the capability to order the new subscription, the service-delivery team will implement the delivery of customized news each hour, and the billings team will implement the monthly subscription charges for the new service. Across the value stream—from the subscription order to service delivery—each team relies on data produced by other teams. For example, the order-processing team captures subscription details, such as topics and sources, and the service-delivery team uses that information to determine what news items to deliver. Because the teams are interdependent, they need to coordinate their plans at the frontend of the development cycle, collaborate throughout development, and integrate and test their work continually as stories are done. How they do that effectively is the subject of this chapter.
17.3.2 Product Complexity
Another reason for team dependencies is that the competencies required to implement a feature for a complex product are usually too numerous to be accommodated in a small agile team of no more than ten members. Expertise is typically needed in UI design and coding, cloud services, the deployment framework, automated testing, the application stack, the software stack (infrastructure), open-source tools, database management, and business domain knowledge. Since a small team usually can’t cover all these competencies, the competencies are typically distributed among a group of interdependent teams.
17.3.3 Shared Components
Another reason that team dependencies can’t, and shouldn’t, be eliminated is that multiple teams often share software components and are dependent on the team that manages them. As we’ll explore later in this chapter, if we let feature teams change a component as they see fit, the result will be inconsistency in design and quality across the component. To ensure this doesn’t happen, a component team takes primary responsibility for it. However, component teams introduce dependencies—because if a feature team requires a change to a component, it’s dependent on the component team to implement it. Similarly, if the component team changes a component, the feature teams that depend on it are potentially impacted.