- 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.4 Planning: Choosing an Approach That Supports Inter-team Collaboration
There are two necessary but distinct coordination issues to address in a scaled organization: What approach will the organization use to plan work across multiple teams, and how will it time the integration and delivery of software across multiple teams? In answering those questions, it’s essential to realize that the solutions to the two problems are not necessarily the same. In fact, it’s usually best to use a mixed approach—a timeboxed or hybrid approach to plan large features at the frontend and a flow-based approach at the back end to continuously implement, integrate, and deliver improvements to the customer. We addressed the issue of flow-based versus timeboxed approaches earlier in this book. Let’s revisit it now with a focus on scaled agile organizations.
17.4.1 Review of the Two Approaches
In a flow-based approach, each work item moves from step to step in the development lifecycle at its own pace, provided that work-in-progress (WIP) limits at each step are not exceeded. The aim is to achieve a continuous flow of each item without bottlenecks—from initiation through delivery. This is the approach used by the Kanban framework.
In contrast, with timeboxed planning, teams commit to all of the work items for a specified period (the timebox) at the start of the period. Two common timeboxes are the quarter and the iteration. A quarter refers to three months, but (as noted elsewhere) I use the term in this book as a shorthand for a release cycle, a SAFe program increment (PI), or any period of two to six months. An iteration is a shorter timebox, typically one or two weeks. Frameworks that incorporate iterations include Scrum, Extreme Programming (XP), LeSS, and SAFe. In Scrum, this period is referred to as a sprint. The maximum duration of a sprint is one month.
17.4.2 Which Approach Should You Use at the Frontend?
As a general guideline, feature teams benefit most from a mixed planning approach at the frontend, using flow-based (Kanban-style) planning for customer-driven features and quarterly (timeboxed) planning for large, strategic initiatives.
17.4.2.1 When to Use a Flow-Based Approach to Accept Requirements into Development
The flow-based portion of the budget enables teams to respond quickly to learning, rather than waiting a quarter or more to apply newly gained knowledge. This part of the budget should be set aside for small efforts that can be handled by a single team with minimal help from others. For example, the team might be exploring options to improve the conversion rate of browsers to subscribers or looking at different ways for a user to filter or sort content. To do so, they try out different options with customers and adapt them based on customer feedback. Since customers’ responses drive each inspect-and-adapt cycle, there is no sense in trying to predict and prioritize their preferences too far in advance. Consequently, a flow-based approach is advised.
17.4.2.2 The Pitfalls of Relying Solely on a Flow-Based Approach
However, many organizations with which I work have discovered that when they rely solely on flow-based planning, the product becomes fractured because the approach encourages teams to think locally about their aspect of the product instead of having a whole-product orientation. Moreover, they’re finding that an overdependence on flow-based planning makes it difficult to get big, product-wide changes off the ground. The reason is that, with each team working according to its own timetable, it’s rare for all teams required for a large initiative to be free at the same time. Also, because there is no designated time when all teams meet to consider the next planning cycle, there is no obvious opportunity for stakeholders to gather and make their case for major initiatives so that they can be compared and prioritized.