"Agile at Scale w ith Scrum: The Good, the Bad, and the - PDF document

AT9 Concurrent Session 11/8/2012 3:45 PM "Agile at Scale w ith Scrum: The Good, the Bad, and the Ugly" Presented by: Heather Gray, Cisco Systems Steven Spearman, AgileEvolution Brought to you by: 340 Corporate Way, Suite 300, Orange Park, FL 32073 888 ‐ 268 ‐ 8770 ∙ 904 ‐ 278 ‐ 0524 ∙ sqeinfo@sqe.com ∙ www.sqe.com

Heather Gray Cisco Systems Heather Gray was introduced to agile when the senior vice president of her organization issued a mandate to “Be Agile.” That mandate was the start of an occupational awakening beginning first with an understanding of what agile meant and then rolling out agile practices across her large organization. Heather has worked for the past eighteen years with software development teams using strict waterfall process, no process at all, and now finally agile practices. Her most recent role was senior manager for Cisco Systems' IP Communication Business Unit where, in addition to managing the Program Management Office, she led the business unit’s transformation to agile. Steve Spearman AgileEvolution With more than thirty years of development experience, Steve Spearman brings a wealth of real-world experience to his role as an Agile Coach and Trainer. With a background in enterprise development, he enjoys the opportunity to help teams of any size succeed in their own agile transitions. Steve is active in the Agile Denver and Agile Boulder communities. As a reformed project manager and PMP, Steve is passionate about working with multiple PMI chapters to roll out agile principles, teaching the PMI-Agile Certified Practitioner (ACP) prep class, and volunteering with the PMI-ACP support team. Steve works with AgileEvolution and can be reached at steve@agileevolution.com .

Agile at Scale with Scrum The GOOD GOOD, the , and the Steve Spearman Heather Gray steve@agileevolution.com hgray@agileevolution.com 1 Why Make the Change? Dante’s Inferno illustration, Botticelli circa 1640 2 1

The Overview … Successful business unit at one of the world’s largest networking companies. ‘Mandated’ to BE AGILE ! Transitioned to Scrum in eighteen months. 3 The BIG Picture … The GOOD The GOOD ‐ forty+ pilot teams , moved quickly and are rocking today. The The ‐ an adjacent part of the BU failed in its transition and failed in the market too… The The ‐ lots of challenges! 4 2

Learnings from Our Challenges • Acquiring the RIGHT executive support. • Moving away from component ‐ based specialization . • Finding the right people for the key roles. • Forming and scaling teams. • Shortening Our Integration Cycles • Shortening Our Integration Cycles. • Handling the geographic challenges . 5 The Organization • 6 Development locations 6 Development locations – 4 US Time zones + India & China • > 400 Engineers • > 50 component teams • 5 Major Product Lines 5 Major Product Lines • 12 ‐ 18 month release cycles 6 3

High Level Approach Vision / Mandate Change Org & Transition Communication Communication Inspect/Adapt Team Train & Coach Scale & Fill Globally Key Roles 7 Executive Support We had a So what’s the Mandate Problem? 8 4

Forming Teams Start with… the Matrix 9 Scaling Approach Project Core Team AreaTeam 1 Area Team 2 AreaTeam 3 AreaTeam 4 Sub Teams Sub Teams Scrum Teams Scrum Teams Scrum Teams Scrum Teams 10 5

Where Do We Find SM’s & PO’s? 11 What About Managers? • Role confusion at first • Self ‐ organizing versus self ‐ managing • Eventual changes in span of control • Managers can be PO’s • Managers can be PO’s and maybe even SM’s! (but only in certain places) 12 6

And Project Managers? • Transition or disappear in some small organizations ll i ti • Still critical in large ones • Styles change “It is not the strongest of the “It is not the strongest of the • A mix of old and new species that survive, nor the species that survive, nor the skills work best at the skills work best at the most intelligent but the one most intelligent but the one most intelligent, but the one most intelligent, but the one most responsive to change.” most responsive to change.” project level 13 Moving Away from Components Our Specializations seemed as diverse as stars in the sky 14 7

Moving Away from Components So we formed Scrums from diverse expertise areas 15 Moving Away from Components Each Release, we ask Teams to expand knowledge a little 16 8

Moving Away from Components Over time, teams’ capabilities grow but ownership stays stable 17 Meanwhile, On the Other Side of the Organization…. Agile is attempted …. As a Cargo Cult??? 18 9

Other Transition Team Learnings • Perils of Part timers • Synchronized sprints • Scrum ‐ > Kanban • Automation • Beware “Central Agile” • Portfolio change is hard 19 Scrum Teams Across Geographies 20 10

Integration Nightmares The Problem • Complex and very large builds – 2 days to get a build done and verified. • Developed on 30+ branches creating ‘Integration hell’ upon collapse ll • Automated Regression took 2 days with questionable coverage 21 Continuous Integration The Answer • Dedicated a crack D di d k development team – Got the build down to 4 hours in most cases – Highly parallel builds & a server farm – Reduced development branches to 1 ‐ 10 per release branches to 1 ‐ 10 per release – Reduced regression test to 16 hours • Same team helped automate testing 22 11

Automated Testing The Automation Framework you use depends on what you are testing. We end up using all of these at some point: 23 The Business Customer Focus Feature Driven Value Driven • Multiple priorities • Massive releases • No involvement • 1 ‐ n priority list after planning • Part of the team • Constant change • New PBI to manage requests requests change h • Feature Bloat • Focus on providing • Actual customer value not content engagement • No CCB 24 12

Management Customer Focus Feature Driven Value Driven • Assigning Tasks • Constant overtime • 100%+ allocated • Self organizing teams • Dedicated teams • Persistent teams • Realistic commitments • Innovation time 25 Engineering Customer Focus Feature Driven Value Driven • Component based Component based teams • Increasingly cross ‐ • Big Serial phases functional teams • Integration ‘hell' • Iterative development, • True cross smaller hand offs functional teams functional teams • Continuous • TDD Integration • Collective code ownership 26 13

The PMO Customer Focus Customer Focus Feature Driven Value Driven • Long planning cycles • Long planning cycles • Established process • Protecting the plan • JIT planning • Fighting change • Lower ceremony • Questionable visibility • Continual • Minimally sufficient improvement p • Crashing the path Crashing the path ceremony • Higher visibility • Even more visibility • Value Stream Mapping 27 Where Did it End Up? Never done, but…. “OUR” Team OUR Team The Other Team The “Other” Team 28 14

29 15