View
1
Download
0
Category
Preview:
Citation preview
The Good, the Bad, and the Ugly of
Pair Development A Spikers Story
February 6,2018
Contents
1
• Paired Programming – A little fun
• But we can’t pair all the time!
• Why Pair
• The Psychology of Working in teams
• How do you pair?
• What’s your flavor?
• The Ugly, The Bad, and The Good
• Spikers in Action
• Questions
• Does it really work?
• Doesn’t it slow you down?
• Does it hamper creativity?
• Doesn’t it cost more?
• We have an odd number
• Not everyone is in the office at the same time
• We have meetings where people disappear
• How do you overcome individuals not wanting to pair?
3
Pair Development: But we can’t pair all the time!
Why Pair
• Knowledge Transfer
• Code Review
• Skill Uplift
• Poly-Skill Opportunities
• Increased Focus
• Better Code
• Fewer Interruptions
4
The Psychology of Working in Teams
• Introverts vs Extroverts
– Believe it or not, there is a cause and effect
– The preference to work alone
– Can cause anxiety with team members
– Transparency will expose problems versus solving them
for the team
– A major reason why team members refuse to pair
– Understanding the definition of collective code ownership
5
The Psychology of Working in Teams
• The truth is in the numbers (metrics)
• A productive team is a successful team (lower error count,
predictive velocity, sustainable pace, etc.)
• Belief that pairs are more successful which makes the
team more successful
• Growth and team success with overcome the individual
fear of pair development
6
How do you pair?
7
Dev/Dev or
Test/Test / Bad Dev/Test / Good
Development or Testing
Requirements Development
or Testing
Requirements
Testing
Development
Execution Model
Silos / Ugly
What’s your Flavor?
• Dev/Dev
– Two developers one computer working on the same story card
• One is driving the work
• One is code reviewing
• Test/Test
– Two testers one computer working on the same story card
• One is driving the work
• One is code reviewing
• Dev/Test
– Two developers one computer working on the same story card
• One is driving the work from a development standpoint
• One is driving the work from a test automation stand point
• Both quality review each other’s work
8
The Good, the Bad, and the Ugly of the Spikers Line - During
Transition
9
The Ugly
• The team is formed
– Used the vendor methodology with a mix of NW Line
– Water-Scrum-Fall execution model
– Development in a sprint then testing in a separate sprint
• How did we bring testing into the model?
10
The Bad
• Started to incorporate standard work on the line
• Formal code review was done with Vendor
• Incrementally added pair development approach with team
resistance (dev/dev & Test-Test)
– How we overcame resistance
• Data
• Tough love
11
The Good, the Bad, and the Ugly of the Spikers Line - Steady
State
12
70 73
63 63 61
50
67
77 83 81 78
57
69
90
54
65 61
65
77
69 73
61 57
61 68
78
89 82
68 71 73 73
53
72
43
62
0
10
20
30
40
50
60
70
80
90
100
20
17-1
0
20
17-1
1
20
17-1
2
20
17-1
3
20
17-1
4
20
17-1
5
20
17-1
6
20
17-1
7
20
17-1
8
20
17-1
9
20
17-2
0
20
17-2
1
20
17-2
2
20
17-2
3
20
17-2
4
20
17-2
5
20
17-2
6
20
18-0
1
Po
ints
Iteration
Velocity
Actual Committed
6
5 5
4
0
6
5
6 6
7
3
5
4 4
1 1
0
0
1
2
3
4
5
6
7
8
Err
ors
/ P
oin
ts
Iteration
Iteration Error #
The Good
• Looked at Amigo, Entry and Exits as pairing
• Implemented Dev/Test pairing
– Followed a story card all the way to completion
– Poly-Skill (Dev is Test and Test is Dev)
• Major focus on TDD and ATDD
– All automation is created before development begins
13
Spikers In Action
14
15
Recommended