Come hear the story of how a business unit at one of the world's largest networking companies transitioned to Scrum in eighteen months. The good-more than forty teams in one part of the company moved quickly and are going gangbusters. The bad-an adjacent part failed in its transition. The ugly-if you're in a large company with globally distributed teams, it's not hard to torpedo Scrum adoption. Steve Spearman and Heather Gray describe Scrum adoption challenges for a multi-million line, monolithic system developed across multiple locations worldwide. They share the techniques and tools that helped them implement Scrum in just two project cycles and the reasons part of the company failed to make the leap. Find out how they gained critical executive support, moved from component-based specialization to Scrum's generalizing specialists, found enough ScrumMasters, adjusted to twelve-hour time differences, and dealt with classical PMOs. Take away concrete approaches to improve your enterprise agile conversion-and an appreciation for problems you will surely face.
Agile at Scale with Scrum: The Good, the Bad, and the Ugly
1.
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 ∙ sqeinfo@sqe.com ∙ www.sqe.com
2.
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.
5. 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
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
9. And Project Managers?
• Transition or disappear in
some small organizations
ll
i ti
• Still critical in large ones
• Styles change
• A mix of old and new
skills work best at the
skills work best at the
project level
“It is not the strongest of the
species that survive, nor the
most intelligent, but the one
most intelligent but the one
most responsive to change.”
13
Moving Away from Components
Our Specializations seemed as diverse as stars in the sky
14
7
13. 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
• D di
Dedicated a crack
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
15. Management
Customer Focus
Feature Driven
• Assigning Tasks
• Constant overtime
• 100%+ allocated
• Self organizing
teams
• Dedicated teams
Value Driven
• Persistent teams
• Realistic
commitments
• Innovation time
25
Engineering
Feature Driven
• Component based
Component based
teams
• Big Serial phases
• Integration ‘hell'
Customer Focus
• Increasingly cross‐
functional teams
• Iterative
development,
smaller hand offs
• Continuous
Integration
Value Driven
• True cross
functional teams
functional teams
• TDD
• Collective code
ownership
26
13
16. The PMO
Feature Driven
•
•
•
•
•
•
Customer Focus
Value Driven
Long planning cycles
Long planning cycles
Established process
Protecting the plan
• JIT planning
Fighting change
• Lower ceremony
Questionable visibility • Continual
•
p
improvement
Crashing the path
Crashing the path
• Higher visibility
•
•
Minimally sufficient
ceremony
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
