agile at scale with scrum: the good, the bad, and …...agile at scale with scrum the good, the ,...
TRANSCRIPT
AT9 Concurrent Session 11/8/2012 3:45 PM
"Agile at Scale with 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 ∙ [email protected] ∙ 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 [email protected].
1
Agile at Scale with ScrumThe GOODGOOD, the , and the
Steve [email protected]
Heather [email protected]
1
Why Make the Change?
2
Dante’s Inferno illustration, Botticelli circa 1640
2
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…TheThe GOODGOOD ‐ 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…
TheThe ‐ lots of challenges!
4
3
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 locations6 Development locations– 4 US Time zones + India & China
• > 400 Engineers• > 50 component teams• 5 Major Product Lines5 Major Product Lines• 12‐18 month release cycles
6
4
High Level ApproachVision / Mandate
Transition Team
Change Org & Inspect/Adapt CommunicationCommunication
Scale & Fill Key Roles
Train & Coach Globally
7
Executive Support
We had a Mandate
So what’s the Problem?
8
5
Forming Teams
Start with… the Matrix
9
ProjectCore Team
Scaling Approach
Area Team 2 AreaTeam 3 AreaTeam 4
Sub Teams
Scrum Teams
AreaTeam 1
Sub Teams
Scrum Teams
Scrum Teams
Scrum Teams
10
6
Where Do We Find SM’s & PO’s?
11
• Role confusion at first
What About Managers?
• 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
7
And Project Managers?
• Transition or disappear in ll i tisome small organizations
• Still critical in large ones• Styles change• A mix of old and new skills work best at the
“It is not the strongest of the “It is not the strongest of the species that survive, nor the species that survive, nor the most intelligent but the onemost intelligent but the oneskills work best at the
project levelmost intelligent, but the one most intelligent, but the one most responsive to change.”most responsive to change.”
13
Moving Away from Components
Our Specializations seemed as diverse as stars in the sky
14
8
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
9
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
10
Other Transition Team Learnings
• Perils of Part timers • Synchronized sprints• Scrum ‐> Kanban• Beware “Central Agile”• Portfolio change is hard
19
• Automation
Scrum Teams Across Geographies
20
11
Integration NightmaresThe Problem• Complex and very large
builds – 2 days to get a build done
and verified.• Developed on 30+ branches
creating ‘Integration hell’ llupon collapse
• Automated Regression took 2 days with questionable coverage
21
Continuous IntegrationThe Answer
D di d k• Dedicated a crack 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 releasebranches to 1‐10 per release– Reduced regression test to 16
hours• Same team helped
automate testing
22
12
Automated TestingThe Automation Framework you use depends on what you are testing.
We end up using all of these at some point:
23
The BusinessCustomer FocusFeature Driven Value Driven
• Multiple priorities• Massive releases• No involvement after planning
• Constant change requests
• 1‐n priority list• Part of the team• New PBI to manage
hrequests• Feature Bloat
change• Focus on providing value not content
• Actual customer engagement
• No CCB24
13
ManagementCustomer FocusFeature Driven Value Driven
• Assigning Tasks• Constant overtime• 100%+ allocated • Self organizing
teams• Dedicated teams
• Persistent teams• Realistic commitments
• Innovation time
25
Engineering
• Component based
Customer FocusFeature Driven Value Driven
Component based teams
• Big Serial phases• Integration ‘hell'
• Increasingly cross‐functional teams
• Iterative development, smaller hand offs • True cross
functional teams• Continuous Integration
functional teams• TDD• Collective code ownership
26
14
The PMO
• Long planning cycles
Customer FocusCustomer FocusFeature Driven Value Driven
• Long planning cycles• Established process• Protecting the plan• Fighting change• Questionable visibility• Crashing the path
• JIT planning• Lower ceremony• Continual improvement • Minimally sufficient Crashing the path p
• Higher visibility ceremony• Even more visibility• Value Stream Mapping
27
Where Did it End Up?Never done, but….
“OUR” Team The “Other” TeamOUR Team The Other Team
28
15
29