Scrum from an Organization Perspective
Damian P. EvansVP, Product Development, Qpass – Amdocs Digital Commerce Division
9 Aug 2007
2
Scrum provides no organizational guidance, but its impact on
organizations can be far reaching.
3
INTRODUCTION
SCRUM ADOPTION
ORGANIZATIONAL IMPACTS
4
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
5
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
6
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
7
INTRODUCTION
SCRUM ADOPTION
ORGANIZATIONAL IMPACTS
8
Functional Organization: 2005
VP, PD
Director, QADirector, EngDirector, ArchPGM
Architects
Eng Mgrs Test Mgrs
Engineers Testers
Program Managers
SpecsSchedule Alignment
Dev sched Test sched
Design, Code Test
Mgr, Perf & Platform
Perf Eng
Test, Tune
Test schedArch sched
9
PD Management Involvement Pre-Scrum
Vision, Strategy$$ allocation (LOB level)KPIObjectives Resource acquisition / creation
Business ownership / ROI$$ allocation (Product / Project level)Value identification and communicationValue delivery
Software process definitionTechnology standardsVendor managementIP management
Value creationVisibilityResource utilizationImpediment removalRisk management
Role of people PD mgmt
Role of bulk of PD staff
10
Our Process Evolution
Daily Builds
SCM
19981998 20002000 20022002 20042004 20052005 20062006 20072007
Automated Unit Tests
WaterfallRUP Attempt
PMI Flair-upScrum!Scrum!
Component-oriented teams
UML
Architects as
demigods
Feature-oriented teams
Component-oriented teams
Testing Org
Testing Org
Gone
Architects as team
members
Continuous Integration
11
RUP Phases and Qpass: 2005Inception Elaboration Construction Transition
Projects numerous per year, up to 6 in parallel
• 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
Releases
2 to 3 per year
• 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
12
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
13
Scrum Roll-out Approach
• Experimentation
• Pilot
• Roll-out
14
Experimentation
• Found a coach (Danube)
• Used SDET team as guinea pigs of process (and of coach )
• Shared results
15
Pilot
• Retained coach• OpenMarket team (a new product) volunteered
to pilot– Found all sorts of issues – management counter-
incentives 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
16
Rollout
• Retained coach• Took census of those doing Scrum – proceeded based
on result• Organized engineering leadership team as “nearly-a-
Scrum 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
17
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.
18
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
19
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)
20
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
21
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
22
Obstacle #6: Maintenance
• Team focus key to success with Scrum, but teams impeded by support burden
• Create separate maintenance organization
23
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
24
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
25
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
26
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
27
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
28
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
29
INTRODUCTION
SCRUM ADOPTION
ORGANIZATIONAL IMPACTS
30
PD Management Involvement Post-Scrum
Vision, Strategy$$ allocation (LOB level)KPIObjectives Resource acquisition / creation
Business ownership / ROI$$ allocation (Product / Project level)Value identification and communicationValue delivery
Software process definitionTechnology standardsVendor managementIP management
Value creationVisibilityResource utilizationImpediment removalRisk management
Role of people nominally in PD exec mgmt
Role of bulk of PD staff
31
Hybrid Organization
VP, PD
Directors, Dev (3)
Director, ArchPGM
Architects
Tech Pubs
Engineers
WritersScrum Masters
Tech Standards
Budget / Admin
Manage, Design, Code, Test, Write
Testers
Mgr, Perf & Platform
Perf Eng
Manage, Test, Tune
Eng Ownership of Products
Doc Standards
(2 fewer eng mgr;1 fewer director)
(centralize functionally for skill concentration/ refinement)
32
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”
33
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
34
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
35
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 self-
management 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.
36
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
37
Scrum provides no organizational guidance,* but its impact on
organizations can be far reaching.
*and it shouldn’t… Too much org variationLet Scrum be for projects