Pairing with Developers
Sogeti Senior Consultant
What is a developer anyways?
Who are we?
How and why we started pairing.
Why we continued.
When we ﬁnished.
Our informal retrospective results.
You will leave with
At least one idea of how to start pairing.
A real example that worked in practice.
Two contacts who can help you.
Ideas that can be adapted to any context.
Ways to challenge existing role deﬁnitions.
Loading Project Background
1st Agile Project
Scrum Master Training (Woof)
Quality Initiative Dynamics
Distributed undersized Team with non-iterative goals
Very Late Delivery Expected
Grandiose Unit Test Coverage Planned
Define Software Developer
Anyone who codes?
What about TDD?
Are tests part of production?
What about the code we didn’t write?
Interacting with existing databases?
Marty is a Developer who tests sometimes.
His website is http://www.theﬂexguy.com/
He makes testing tools and ﬂex applications at
Adobe. Still, he is not the tester in this case. He is
the tools developer.
Define Software Tester
The tester is the person taking action to obtain
and provide current information about the
suitability of the product for the intended use by
Prior experience on agile projects == 0
Prior experience testing Flex Apps == 0
Prior coding experience?
Some .bat ﬁles
A few fancy excel spreadsheets
A few mouseovers in ActionScript
The Start of Pairing
What is the URL for that dashboard you are
It’s not really ready for test yet.
I understand, but can you show me what you are
working on so I can think of some test cases?
Sure! I’ll walk you through it!
Testing before Testing?
A test can be a question that hasn’t been
A test can be challenging an assumption someone
didn’t know they made.
A test is any question you can think of that the code
may not yet answer.
I came up with some tests and some questions.
Why don’t you stop by and we’ll go through them
Do you know how I could post some good data to
test the limits of _________?
How can I compare this value to know what I’m
seeing is right?
These parts are ready for some testing, but these
areas aren’t hooked up yet. Stop by and I’ll walk
you through it.
During small demo-What happens if? Why is it
showing that? Where is that time coming from?
Let me show you. Here I get the time and I pass
it,..wait? I did WHAT? Here, I can change that.
He showed me how to post a build.
I got source control to look at his changes
because I had to in order to post my test ﬁles.
He showed me how his dashboard used the
I found an example Python script and went to
town making ugly non-object oriented code, but
everyone got an automated acceptance test!
From that ugly ﬁrst test we worked together &
automated shipping all products at once!
Pairing-Why did it work?
A willing teacher who values testing skill.
A tester who understands the basics of
programming. Someone who can’t write pseudo
code and understand it should not try a code
More coding experience is better, but it doesn’t
negate the value of an early test perspective.
My code got better, and his code was stable
much sooner when the test expectations were
Why not just code review?
Marty left me a great comment about my
automation. He was excited.
Thanks for the comment, but I have no idea how
to do that. In fact, it isn’t even a word in my
Oh. Research these three things before our next
The code changes we made together made my
automation go down from taking 2 hours to
running in less than 2 minutes. Pairing is more
than a review.
Isn’t it a waste of time?
If you have a dev who thinks it is a waste
If you have a tester who is afraid to be wrong or
look a fool
If your goal is to have maximum documentation
over speed and learning
If your employees gaining new skills isn’t as
important as your very best people never being
If mentoring isn’t seen as a priority or rewarded
It could be.
Try pairing for a short time with many people.
Respect that not everyone wants to pair.
Ask for feedback on what is most productive and
adjust the focus from time to time.
Find the right time of day. 11am and 2pm were
good for us. 9am and 4:30pm sucked.
Start small. We met just once a week for an hour
at a time sometimes. It was enough to keep the
pairing going through the project.
Make a mandate.
Say all coders must test, all testers must code.
Say it is a choice, then layoff or demote anyone
who doesn’t oblige.
Insist that every pairing produce a deliverable.
Some of our best stuff only produced ideas to go
work on by ourselves.
Make introverts work with a tester staring at them
all day (awkward!) Agile Nazis are still Nazis.
“Explaining the function of the code helped ﬂush
out potential problems early on. Also, having
another perspective helped pull my nose off the
grindstone to get the big picture, which is good
for keeping the project going in the right
“As a developer, it is very easy to get lost in your
own little world, and you can develop blinders to
the big picture. Working with someone else,
especially a tester who can bring to the table a
completely different perspective, can improve the
quality of an application much faster than working
alone. I’m going to look for more opportunities to
pair routinely now that I see and reflect on the
value of it.”
Before you can test the code, you can test the
product if you expand what a test is.
Developers can make code more testable by
pairing with the right testers.
Teamwork can be good for productivity, morale,
and cross training your team.
It doesn’t matter if it is test code or product code.
You need quality craftsmanship for both.
Pairing works well when you let the amount ebb
& ﬂow as needed.