by Craig Larman and Bas Vodde Version 1.1

Size: px

Start display at page:

Download "by Craig Larman and Bas Vodde Version 1.1"

Thomasine Simon
6 years ago
Views:

1 FEAURE EAM PRIMER by raig Larman and Bas Vodde Version 1.1 Feature s and Requirement Areas are key elements of scaling lean and agile development. hey are analyzed in depth in the Feature eam and Requirement Area chapters of Scaling Lean & Agile Development: hinking and Organizational ools for Large Scale Scrum. his short paper summarizes a few key ideas and can also be found in Practices for Scaling Lean & Agile Development: Large, Multisite, and Offshore Development with Large-Scale Scrum. INRODUION O FEAURE EAMS A, shown in Figure 1, is a long-lived, 1 cross-functional, cross-onent that letes many end-to-end customer s one by one. Figure 1 Feature Backlog customercentric Feature : - stable and long-lived - cross-functional - cross-onent potentially shippable product increment eam has the necessary knowledge and skills to lete an end-to-end customer-centric. If not, the is expected to learn or acquire the needed knowledge and skill. 1. Feature s stay together for years, implementing many s. 1 opyright (c) 2010 raig Larman and Bas Vodde

2 Feature eam Primer he characteristics of a are listed below:. Feature eam long-lived the stays together so that they can jell for higher performance; they take on new s over time cross-functional and cross-onent ideally, co-located work on a lete customer-centric, across all onents and disciplines (analysis, programming, testing, ) osed of generalizing specialists in Scrum, typically 7 ± 2 people Applying modern engineering practices especially continuous integration is essential when adopting s. ontinuous integration facilitates shared code ownership, which is a necessity when multiple s work at the same time on the same onents. A common misunderstanding: every member of a needs to know the whole system. Not so, because he as a whole not each individual member requires the skills to implement the entire customer-centric. hese include onent knowledge and functional skills such as test, interaction design, or programming. But within the, people still specialize preferably in multiple areas. Features are not randomly distributed over the s. he current knowledge and skills of a are factored into the decision of which works on which s. Within a organization, when specialization becomes a constraintlearning happens. A organization exploits speed benefits from specialization, as long as requirements map to the skills of the s. But when requirements do not map to the skills of the s, learning is forced, breaking the overspecialization constraint. Feature s balance specialization and flexibility. 2

3 Feature eam Primer able 1 and Figure 2 show the differences between s and more traditional onent s. able 1 s vs. onent s onent optimized for delivering the maximum customer value a focus on high-value s and system productivity (value throughput) responsible for lete customer-centric modern way of organizing s b avoids onway s law leads to customer focus, visibility, and smaller organizations minimizes dependencies between s to increase flexibility focus on multiple specializations shared product code ownership shared responsibilities supports iterative development exploits flexibility; continuous and broad learning requires skilled engineering practices effects are broadly visible provides a motivation to make code easy to maintain and test seemingly difficult to implement optimized for delivering the maximum number of lines of code focus on increased individual productivity by implementing easy lower-value s responsible for only part of a customer-centric traditional way of organizing s follows onway s law c leads to invented work and a forever-growing organization dependencies between s leads to additional planning d focus on single specialization individual/ code ownership clear individual responsibilities results in waterfall development exploits existing expertise; lower level of learning new skills works with sloppy engineering practices effects are localized contrary to belief, often leads to low-quality code in onent seemingly easy to implement a. he different optimization often makes the feel slower from the local view. b. Relatively modern as s have a long history in large-scale development, for example, Microsoft and Ericsson. c. Mel onway observed this undesirable structure in 1968, he did not recommended it in fact, quite the opposite. d. his additional planning is visible in more release planning meetings or release trains and more management overhead. 3

4 Feature eam Primer Figure 2 vs. onent s omponent s Feature s system system Item 1 Item 2 Item 3 Item 4 A eam B eam A B Item 1 Item 2 Item 3 Item 4 eam Wei eam Shu A B eam eam Wu Work from multiple s is required to finish a customer-centric. hese dependencies cause waste such as additional planning and coordination work, hand-offs between s, and delivery of low-value items. Work scope is narrow. Every letes customer-centric items. he dependencies between s are related to shared code. his simplifies planning but causes a need for frequent integration, modern engineering practices, and additional learning. Work scope is broad. he table below summarizes the differences between s and conventional project or groups. able 2 Feature s vs projects stable that stays together for years and works on many s shared responsibility for all the work self-managing results in a simple single-line organization (no matrix!) members are dedicated 100% allocated to the group or project temporary group of people created for one or project individual responsibility for their part based on specialization controlled by a project manager results in a matrix organization with resource pools members are part-time on many projects because of specialization Most drawbacks of onent s are explored in the Feature eams chapter of Scaling Lean & Agile Development, Figure 3 summarizes some of these. 4

5 Feature eam Primer Figure 3 some drawbacks of onent s Iteration 1 Iteration 2 (probably later) Analysis Iterations 3-5 (probably later and more) At least iteration 6 (probably later) Backlog Item 1 Backlog Item 2 Item 1 Analyst Design not available until the analyst is finished System Engineer Implementation not all s start Item 1 at the same iteration; they are multitasking on multiple s omp A eam est system testers cannot start immediately on Item 1; they are multitasking on multiple s requirement details for Item 1 'backlog' by onent omp B eam omp eam code System esters omponent s lead to a sequential life cycle with handoff, queues, and single-specialist groups and not true cross-functional s without handoff. What is sometimes not seen is that a onent structure reinforces sequential development (a waterfall or V-model), with many queues with varying-sized work packages, high levels of WIP, many handoffs, and increased multitasking and partial allocation. hoose omponent eams or Feature eams? A pure organization is ideal from the value-delivery and organizationalflexibility perspective. Value and flexibility, however, are not the only criterion for organizational design, and many organizations therefore end up with a hybrid especially during a transition from onent to s. aution: hybrid models have the drawbacks from both worlds and can bepainful. A frequently expressed reason in favor of a hybrid organization is the need to build infrastructure, construct reusable onents, or clean up code work traditionally 5

6 Feature eam Primer done within onent s. But these activities can also be done in a pure organization without establishing permanent onent s. How? By adding infrastructure, reusable onents, or cleanup work to the Backlog and giving it to an existing as if it were a customer-centric. he temporarily for as long as the wishes does such work and then returns to building customer-centric s. ransitioning to Feature eams Different organizations require different transition strategies when changing from onent to s. We have experience with many strategies that workedand failed in a different context. A safe but slow transitioning strategy is to establish one within the existing onent organization. After this performs well, a second is formed. his continues gradually at the speed the organization is comfortable with. his is shown in Figure 3. able 3 gradual transitioning from to onent s Feature eam Red contains ex-members from onent s A, B, and, and from analysis, architecture, and testing groups system Item 1 Item 2 Item 3 Item 4 tasks for A tasks for B tasks for A tasks for B tasks for A tasks for omp A eam omp B eam omponent A omponent B omp eam omponent 6

7 Feature eam Primer INRODUION O REQUIREMEN AREAS Feature s scale nicely, but when their number goes above ten s about a hundred people additional structure is needed. Requirement areas provide this structure and lement the concepts behind s. A requirement area is a categorization of the requirements leading to different views of the Backlog. he (PO) groups every Backlog item under exactly one requirement category its requirements area. After this, he generates different views on the overall Backlog called an Area Backlog. he Area Backlogs are prioritized by an Area who specializes in part of the product from a customer perspective. Each Requirement Area has several s working from the Area Backlog, as shown in Figure 4. Figure 4 requirement areas performance area s Area Backlog Backlog Item 1 Performance Backlog Items 1 Backlog Items 2 Protocols Backlog Item 3 Backlog Item 4 Area protocols area s Requirement areas are scaled-up s. Scaling up by structuring s according to the product s architecture is called development areas. able 4 summarizes the differences. 7

8 Feature eam Primer able 4 requirement areas vs. development areas Requirement Area organized around customer-centric requirements no subsystem code ownership temporary in nature; should change over the lifetime of the product, but not at every iteration focus on the customer, using customer language Development Area organized around product s architecture code ownership per subsystem tends to be more fixed over the lifetime of the product focus on the architecture, using technology language Finally, an Area is different than a supporting someone that works with one or two s to help a busy overall. An Area has different responsibilities and focus, and works with (probably) at least four s, not just with one. his avoids local optimization toward the activities of one. ONLUSION Feature s are stable s that are given lete customer-centric s. hese s resolve local optimizations and extra coordination overhead caused by onent organizations. However, s are not without challenges themselves. Requirement areas scale the concept by creating customer-centric views on the overall Backlog and thus creating a structure that allows s to be scaled up to any size. 8

Scrum hapters: 9 Large-Scale Scrum est Management Planning oordination Requirements

9 Feature eam Primer REFERENES hapters: Introduction Systems hinking Lean Queueing heory False Dichotomies Be Agile Featurea eams eams Requirement Areas Organization Large-Scale Scrum hapters: 9 Large-Scale Scrum est Management Planning oordination Requirements Design Legacy ode ontinuous Integration Inspect & Adapt Multisite Offshort ontracts

Scaling Scrum with Feature Teams

basv@odd-e.com Scaling Scrum with Feature Teams Agenda Introduction Before we start -> Some basics Feature teams and component teams 2 Introduction 3 or! Practices for Scaling Lean & Agile Development