- 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.8 Scaling the Agile Organization
As noted earlier in this chapter, an organization developing a complex product will inevitably require multiple interdependent teams in order to cover all the necessary competencies for all of its subproducts and components. For example, the top-level product for a large company might easily include more than twenty subproducts. Each of these, in turn, might be delivered over multiple channels (e.g., Web, mobile), each of which requires specialized technical competencies. For a company such as SAP (a vendor of enterprise resource planning software), this can require, in total, more than two thousand agile teams.23 In this section, we explore how to structure agile organizations of that size.
17.8.1 Scaling by Subproduct and Product Area: MyChatBot Case Study
The solution is to structure the organization by subproducts, also known as product areas. Let’s look at a fictional example, MyChatBot. MyChatBot is an innovative company and product based on the hypothesis that customers will want to use chatbots for common customer-engagement tasks in order to increase sales and customer outreach at minimal cost. The company has identified ten primary high-level tasks customers would use MyChatBot for, including Sales, Marketing, Customer Support and Engagement, Analytics. In circumstance-based market segmentation, these are identified as the jobs customers hire the product to do.
See Chapter 8, section 8.4, for more on circumstance-based market segmentation.
Figure 17.4 depicts how the MyChatBot organization is structured into levels of subproducts. For illustration purposes, I’ve included only four of its subproducts.
)
FIGURE 17.4 MyChatBot organization
As indicated in Figure 17.4, MyChatBot is the top-level product. Below are its subproducts—one for each primary usage of the product. Four of these usages are highlighted: Sales, Marketing, Customer Support and Engagement, and Analytics.
Each of these subproducts has numerous sub-subproducts, referred to as product areas. For example, the Customer Support and Engagement subproduct includes a product area for each of the following sub-subproducts:
Collaboration Tool Automation: To facilitate the collaboration of support staff
Ingest Content: To load Chatbot messages originating on social media and elsewhere
User Efficiency: To optimize the efficiency of customer-support users
Each product area is divided up into feature sets—groups of related product features. For example, Collaboration Tool Automation has one team for each of the following feature sets: tagging, triaging, and assigning messages using automation. In a larger organization, there might be multiple teams devoted to each feature set.
In addition to the feature teams, Figure 17.4 indicates component teams dedicated to commonly used components. For example, MyChatBot might have a component team dedicated to an API that manages outgoing messages to third-party products, such as social networks. Figure 17.4 also indicates competency groups—associations that supply the teams with members, shared resources, and support within a particular area of expertise, such as UX design.
17.8.2 Scaling the PO Role
As mentioned earlier in this chapter, high-performing organizations require leadership at every level. A product-level PO is responsible for the whole product, while area POs are assigned at all the intermediate subproduct levels down to the individual team. Each of these teams is led by a team PO or proxy PO. We’ve discussed the product-level PO. Let’s examine the other roles.
17.8.2.1 Area POs
An area PO should be assigned to each subproduct or sub-subproduct down to the level above the team level. (At the team level, a team PO or proxy PO is assigned, as described shortly.) Each area PO is responsible for a subproduct—a high-level use case, or job, customers hire the product to do. The role may be filled by a portfolio manager, program manager, product manager, or SAFe Release Train Engineer (RTE). Area POs have ultimate responsibility for prioritization decisions in their area—though (as noted earlier) other stakeholders are typically required for signoffs and approvals, and local decision-making should be devolved to lower-level POs. An area PO may also act as a PO for one of the lower levels.
17.8.2.2 Team POs
Each team is led by a team PO or proxy PO (described in the next section). The PO’s outward-facing activities include speaking with business executives to understand strategic objectives, interacting with salespeople and customers, attending trade shows, conducting surveys to understand the market, and talking to data analysts to understand how people are using the product. Inward-facing duties involve close day-to-day interactions with the team—requiring about ten hours or more per week.
The full complement of PO-related responsibilities is often too excessive for a single person, so the work is often distributed among roles. If there is a team-level PO, the team PO focuses on outward-facing activities, while the team analyst focuses on inward-facing responsibilities. If the team is led by a proxy PO, the area PO focuses outward, and the proxy PO takes on inward-facing tasks.
17.8.2.3 Proxy PO and Business Analyst
It’s hard enough for a PO to find sufficient time to work day-to-day with one team while fulfilling external-facing responsibilities. In practice, a PO is often required to support more than one team because of a scarcity of resources. An effective solution in this case is to use a proxy PO or business analyst at the team level to take on some of the PO’s responsibilities. The proxy PO or business analyst works full time with the team to answer detailed questions about the requirements and communicate higher-level goals to the team so that the PO can focus on external responsibilities.
Formally, this can play out in several ways. An area PO may be assigned to preside over a group of teams, with proxy POs at the team level. Alternatively, a team-level PO may be shared by a few teams, with team analysts taking on inward-facing responsibilities at the team level.
17.8.3 Portfolio and Program Structure
Another way to structure a scaled organization is by portfolios and programs. This structure is especially well-suited to initiatives that span departments or entire products. Figure 17.5 depicts the organizational structure for XComm, a fictional company loosely based on a real telecommunications company.
)
FIGURE 17.5 Portfolio and program organizational structure
As depicted in Figure 17.5, the organization is divided into products and services. The products division focuses on initiatives to improve the products XComm sells to its customers (e.g., mobile and Internet products). The services side focuses on quality improvements to its support services (e.g., call center improvements and network upgrades).
17.8.3.1 Portfolio Level
A portfolio is a broad initiative that may span departments, business areas, products, and systems. Figure 17.5 indicates that the products division contains prepaid mobile, TV, and Internet portfolios, each representing a line of business.
The portfolio is the largest organizing unit in SAFe, responsible for strategy and investment. Lean portfolio management (LPM) practices should be used. The focus of LPM is on providing resources to long-lived teams of teams24 so that they can realize strategic objectives and achieve desired outcomes. This contrasts with the traditional practice of funding one-time projects with specified outputs. LPM includes the lean startup practices covered in this book, such as MVP, pivot or persevere, lean techniques for eliminating waste, and cultural practices such as servant-leadership (discussed in this chapter).
Portfolio Epics
In SAFe, long-lived initiatives at the portfolio level are classified as portfolio epics. A portfolio epic can span multiple teams of teams—referred to in SAFe as Agile Release Trains (ARTs). The following format may be used to specify the hypothesis statement for a portfolio epic:25
Epic description: For [customers] who [perform some activity], the [solution] is a [what] that [delivers this value]. Unlike [competition/existing solution or non-existing solution], our solution [does something better].
Business outcomes (measurable benefits)
<benefit 1>
<benefit 2>
Leading indicators
<indicator 1>
<indicator 2>
Nonfunctional requirements (NFRs)
<NFR 1>
<NFR 2>