1 FEAURE EAM PRIMER by raig Larman and Bas Vodde Version 1.2 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 4. Figure 4 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 specialiszes in part of the product from a customer perspective. Each Requirement Area has several s working from the Area Backlog, as shown in Figure 5. Figure 5 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 3 summarizes the differences. 7
8 Feature eam Primer able 3 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
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
The Scrum Guide The Definitive Guide to Scrum: The Rules of the Game July 2013 Developed and sustained by Ken Schwaber and Jeff Sutherland Table of Contents Purpose of the Scrum Guide... 3 Definition of
USE-CASE 2.0 The Guide to Succeeding with Use Cases Ivar Jacobson Ian Spence Kurt Bittner December 2011 USE-CASE 2.0 The Definitive Guide About this Guide 3 How to read this Guide 3 What is Use-Case 2.0?
Microsoft Solutions Framework White Paper Published: June 2002 For more information on MSF, see: http://www.microsoft.com/msf MSF Process Model v. 3.1 Contents Abstract... 4 Overview of Frameworks... 4
lights-out testing for end-to-end business process validation Contents Executive Summary...3 The Evolution of Testing...3 Lights-Out Testing Defined...4 Why Don t You Have It Already?...5 How Do You Get
Problem Management Contents Introduction Overview Goal of Problem Management Components of Problem Management Challenges to Effective Problem Management Difference between Problem and Incident Management
CHAOS MA NIFES T O 2013 Think Big, Act Small THE CHAOS MANIFESTO TABLE OF CONTENTS PREFACE Introduction......................................... 1 Executive Management Support...............................
Introduction to OpenUP (Open Unified Process) Different projects have different process needs. Typical factors dictate the needs for a more formal or agile process, such as team size and location, architecture
Course: Quality Management, DPT404 Teacher: Conny Johansson Department: IDE, University Of Karlskrona/Ronneby The V-Model Prepared for Conny Johansson Conny.Johansson@ide.hk-r.se IDE, University Of Karlskrona/Ronneby
An introduction to Service Integration and Management and ITIL Kevin Holland AXELOS.com White Paper January 2015 Contents Foreword 3 Introduction 4 Models for SIAM 7 Principles and considerations 9 The
CMMI for Development, Version 1.3 CMMI-DEV, V1.3 CMMI Product Team Improving processes for developing better products and services November 2010 TECHNICAL REPORT CMU/SEI-2010-TR-033 ESC-TR-2010-033 Software
Kanban kick- start By Tomas Björkholm at Crisp, April 2011 INTRODUCTION... 1 AN APPROACH TO GET STARTED WITH KANBAN... 2 STEP 1 GET TO KNOW YOUR SYSTEM... 2 STEP 2 IDENTIFY YOUR SOURCES AND PRIORITIZE...
Contracting Guidance to Support Modular Development June 14, 2012 Table of Contents I. Purpose and Scope... 2 II. Overview... 2 III. Background... 3 IV. Modular Development: Key Terms, Principles and Risks...
Unlocking Potential: Understanding and Applying Tools to Identify and Develop Learning Agility By George S. Hallenbeck Jr., Ph.D. A usage guide Key Takeaways: Identifying and developing learning agility
A Process for COTS Software Product Evaluation Santiago Comella-Dorda John Dean Grace Lewis Edwin Morris Patricia Oberndorf Erin Harper July 2004 TECHNICAL REPORT ESC-TR-2003-017 Pittsburgh, PA 15213-3890
SPECIFICATION BY EXAMPLE How successful teams deliver the right software Gojko Adzic MANNING Shelter Island Brief Contents 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 Preface xiii Acknowledgments xxii
Why Good Developers Write Bad Code: An Observational Case Study of the Impacts of Organizational Factors on Software Quality Mathieu Lavallée, Pierre N. Robillard Département de génie informatique et génie
Focus Groups as Qualitative Research PLANNING AND RESEARCH DESIGN FOR FOCUS GROUPS Contributors: David L. Morgan Print Pub. Date: 1997 Online Pub. Date: Print ISBN: 9780761903437 Online ISBN: 9781412984287
Two Value Releases per Year How IT Can Deliver Releases with Tangible Business Value Every Six Months TABLE OF CONTENTS 0 LEGAL DISCLAIMER... 4 1 IMPROVE VALUE CHAIN AND REDUCE SG&A COSTS IN FAST CYCLES...
Accepted for the 13th International Software Product Line Conference (SPLC 2009) August 24-28, 2009, San Francisco, CA From Software Product Lines to Software Ecosystems Jan Bosch Intuit, 2500 Garcia Avenue,
Rational Unified Process Best Practices for Software Development Teams A Rational Software Corporation White Paper Rational Unified Process Best Practices for Software Development Teams WHAT IS THE RATIONAL
Rob Davis Everyone wants a good process. Our businesses would be more profitable if we had them. But do we know what a good process is? Would we recognized one if we saw it? And how do we ensure we can
Scrum Metrics for Hyperproductive Teams: How They Fly like Fighter Aircraft Scott Downey Owner, Rapid Scrum LLC Scott@RapidScrum.com Jeff Sutherland, Ph.D. CEO, Scrum Inc. Jeff@ScrumInc.com Abstract Scrum
General Principles of Software Validation; Final Guidance for Industry and FDA Staff Document issued on: January 11, 2002 This document supersedes the draft document, "General Principles of Software Validation,
Behind Every Great Product The Role of the Product Manager Martin Cagan Silicon Valley Product Group BEHIND EVERY GREAT PRODUCT Martin Cagan, Silicon Valley Product Group Every member of the product team
A STUDY ON COMPONENT BASED SOFTWARE ENGINEERING A MASTER S THESIS in Computer Engineering Atılım University by MURAT GÜNEŞTAŞ JANUARY 2005 A STUDY ON COMPONENT BASED SOFTWARE ENGINEERING A THESIS SUBMITTED