Transcript Scrum and Organization

Scrum from an Organization
Perspective
Damian P. Evans
VP, Product Development, Qpass –
Amdocs Digital Commerce Division
9 Aug 2007
Scrum provides no organizational
guidance, but its impact on
organizations can be far reaching.
2
INTRODUCTION
SCRUM ADOPTION
ORGANIZATIONAL IMPACTS
3
About Qpass
• US leader in mobile commerce
• Started in 1997
• Independent division (for now) of Amdocs
acquired in May 2006
• Approximately 400 people worldwide (Amdocs =
17 000+)
• Sell to Network Operators who need to efficiently
manage their digital commerce
– products (license + maint/support),
– systems integration projects,
– managed application services
4
Characteristics of Qpass Product
Development (“PD”)
•
•
•
•
•
•
•
•
•
Great people
Humor, mostly snide/self-effacing
Mostly consensus-oriented
Not a yeller-screamer culture
Not very political
Somewhat risk averse
Some tendency to overanalyze
Process-belief (both good and bad)
Excellent relationship with Product Management
5
Current Status of Scrum at Qpass
Qpass Product Development only
• 12 teams
• 3 continents
• 100 people
• 5 products, with release collaboration req’d
…all doing Scrum
Other parts of Amdocs and Qpass very interested,
experimenting
6
INTRODUCTION
SCRUM ADOPTION
ORGANIZATIONAL IMPACTS
7
Functional Organization: 2005
VP, PD
PGM
Director, Arch
Arch sched
Director, Eng
Eng Mgrs
Dev sched
Program Managers
Schedule
Alignment
Director, QA
Mgr, Perf &
Platform
Test sched
Test Mgrs
Test sched
Perf Eng
Architects
Specs
Test, Tune
Engineers
Testers
Design, Code
Test
8
PD Management Involvement PreScrum
Vision, Strategy
$$ allocation (LOB level)
KPI
Objectives
Resource acquisition / creation
Value creation
Visibility
Resource utilization
Impediment removal
Risk management
Role of people PD mgmt
Role of bulk of PD staff
Business ownership / ROI
$$ allocation (Product / Project
level)
Value identification and
communication
Value delivery
Software process definition
Technology standards
Vendor management
IP management
9
Our Process Evolution
1998
2000
Daily Builds
2002
UML
SCM
2004
Automated
Unit Tests
RUP Attempt
Waterfall
Componentoriented
teams
Testing
Org
2005
2006
2007
Continuous
Integration
Scrum!
PMI Flair-up
Featureoriented
teams
Architects
as
demigods
Componentoriented
teams
Architects
as team
members
Testing
Org
10
Gone
RUP Phases and Qpass: 2005
Projects
numerous per
year, up to 6 in
parallel
Releases
2 to 3 per year
Inception
Elaboration
Construction
Transition
• Problem definition
and
conceptualization,
business case
• Initial estimation
(“ROM”)
• Specification,
implementation,
and planning
sufficient for a
date commitment
• Remaining
specification
work
• Software
implementation
• Testing
• Integration with a
release
• Sustaining
Engineering Bug
Fix Plan
• Minor Change
Request
Identification
• Target Milestone
Dates
• Clarifying
Requirements for
bug fix
• Minor Change
Request
Specification
• Bug Fixing and
Testing
• Minor Change
Request Coding
and Testing
• Integration of
Projects
• Performance
Benchmarking
and Tuning of
Release as a
whole
• Final
Documentation
and Packaging
• Train-the-trainer
• Support for First
Implementation
11
Problem Identification: July 2005
• Too much time spent in planning
• No code written in early phases
• Tester-developer schedule alignment (but
not teamwork) tough
• Risk deferral / weak definition of done
• Incessant debate about the “right way” to
do iterative development
 Find a coach
12
Scrum Roll-out Approach
• Experimentation
• Pilot
• Roll-out
13
Experimentation
• Found a coach (Danube)
• Used SDET team as guinea pigs of
process (and of coach )
• Shared results
14
Pilot
• Retained coach
• OpenMarket team (a new product) volunteered
to pilot
– Found all sorts of issues – management counterincentives the biggest
• PartnerCenter team (a feature on flagship
product) observed OM, picked up baton
– Found and corrected more issues – crappy SCM,
poor PO prioritization, ridiculous focus on design
perfection
15
Rollout
• Retained coach
• Took census of those doing Scrum – proceeded based
on result
• Organized engineering leadership team as “nearly-aScrum Team”
– VP as Product Owner; Scrum zealot as Scrum Master
– Backlog drawn from Scrum Adoption Playbook
– Major areas: training/learning, (minimal) process docs on wiki,
communication, cross-team collaboration, PM alignment
– Large CSM training, 4 hr training for non-CSMs
– Converted teams based on readiness vs. project cycle
16
Obstacle #1: Management Risk
Aversion
• All Scrum teams fail for the first few sprints, but
management has a need for predictability to
meet commitments to the market.
• Listen to your coach.
• Trust your people.
• Remember that you get paid the big bucks to
take risks/arrows for your people.
17
Obstacle #2: Architect morale
• Architects felt threatened by changing
definition of job.
• Architects join teams – tremendous
resource for overall design and
requirements
• Lead architect buy-in to help sell
18
Obstacle #3: Process alignment
with customers
• R&D, not bespoke, but PM communicated
dates to customers at RUP lifecycle
milestones
• Create a conceptual mapping for RUP
milestones to Scrum (not easy but
possible, at least for this purpose)
19
Obstacle #4: Chain of Command
• Scrum Master vs. Engineering Manager
• Engineering Manager is first point of
escalation, works with Product Managers
to stay in front backlog-wise
20
Obstacle #5: Compatibility
• Some people aren’t compatible, either
from a skills perspective or a personality
one
• Give people time and training to adjust…
but move them out if they cannot adapt
21
Obstacle #6: Maintenance
• Team focus key to success with Scrum,
but teams impeded by support burden
• Create separate maintenance organization
22
Lucky Factor #1: Great people
• Qpass has always hired great engineers,
testers, architects who care
• Would’ve been very tough to fight horrific
project management and horrific
engineering simultaneously
23
Lucky Factor #2: Executive
Empowerment
• President not an engineer, trusts VP to do
what’s right
• VPs can use their power for good, not just
evil, when their boss focuses on the ends,
not the means
• Lack of VP support would’ve been a killer
24
Lucky Factor #3: Great
Relationships with PM
• Product Managers take an “us”
perspective instead of a “them”
perspective, understood the things we
were trying to solve
• Getting this relationship healthy should be
first order of business in a Scrum rollout
25
Lucky Factor #4: Director of QA
was staunch advocate
• Jeff Heinen acted as thought leader,
instead of obstacle – actually cares about
quality of software, not a central quality
control process
26
Lucky Factor #5: I have no ego
• “Every time you point your finger, three
point back at you!”
– Sister Angelica, Holy Cross Elementary School,
Dover, DE
• Managers and executives: be prepared
that you are the source of many root
causes of problems
27
If I could do something different
• More engineer, tester, architect training on
Scrum
• Keep Agile forum alive
• Metrics would come in handy right now in
talking to our new parent company
28
INTRODUCTION
SCRUM ADOPTION
ORGANIZATIONAL IMPACTS
29
PD Management Involvement PostScrum
Vision, Strategy
$$ allocation (LOB level)
KPI
Objectives
Resource acquisition / creation
Value creation
Visibility
Resource utilization
Impediment removal
Risk management
Role of people nominally in PD exec mgmt
Role of bulk of PD staff
Business ownership / ROI
$$ allocation (Product / Project
level)
Value identification and
communication
Value delivery
Software process definition
Technology standards
Vendor management
IP management
30
Hybrid Organization
VP, PD
PGM
Budget /
Admin
Director, Arch
Directors,
Dev (3)
Tech Pubs
Tech
Standards
Eng Ownership of
Products
Doc
Standards
Mgr, Perf &
Platform
Perf Eng
Engineers
Architects
Scrum Masters
Testers
Writers
Manage, Test,
Tune
Manage, Design, Code, Test, Write
(2 fewer eng mgr;
1 fewer director)
(centralize functionally for
skill concentration/
refinement)
31
Role of PD Management
• VP kind of like the Federal Reserve –“intervene
under market failure”
• Long-range planning and budgeting
• Vision, Strategy
• Director: partner to PM, advise on backlog, first
point of escalation, uphold defn of done
• Separated “HR hierarchy” from “Project
hierarchy” except at most senior levels
– Role of direct reporting hierarchy is “mentor”
32
Tech Writers
• Works well when dedicated writer on team
• Writers much more engaged – must be
able to “dig in” to software and “write final
copy” instead of “edit docs from dev”
• Attempt to share amongst teams due to
staffing shortfall – very hard
33
Global Development
• To the extent possible, avoided “globally
distributed teams”
– Sometimes required for domain knowledge
• All teams equally empowered
• Must do time-shift for periodic coordination
34
Other Thoughts, Opinions
• Is it ok if the Scrum Master is in the chain of
command of the team?
– Yes, but it depends a lot on the attributes of the
individuals
– Requires sensitivity to “command and control” issues
• Could a functional org chart work under Scrum?
– Yes, when barriers to cross-functional selfmanagement are sufficiently broken down.
• E.g., functional org must stay out of way of project delivery;
first loyalty must be to team creating value instead of org
chart.
– Requires talented Scrum Masters.
35
Other Thoughts, Opinions
• Does Scrum of Scrums actually work?
– We’ve had better success with “Scrum swaps”
and sometimes “Personnel swaps” – 99% of
collaboration is 1 team:1 team
– Scrum Masters themselves add value with
coordination
• Shared team for shared components?
– Could work
– Qpass wanted to err on the side of YAGNI for
starters
36
Scrum provides no organizational
guidance,* but its impact on
organizations can be far reaching.
*and it shouldn’t…
Too much org variation
Let Scrum be for projects
37