When new developers and testers join the company, we want them to learn the “way we do software here.” So we give them the “stone tablets”―the volumes of process documentation― to study. However, the problem is that the details in this documentation are primarily for beginners and don’t give practitioners what they need to perform at a high level. Paul McMahon has found a better way to achieve and sustain high performance—by focusing on common patterns that repeat in organizations to help practitioners make better decisions. Join Paul as he shares common software development patterns he has observed, questions practitioners should be asking, and tips and warnings to help them make better decisions. Take away practical and easy-to-use techniques to identify and communicate repeating patterns specific to your organization, patterns that can help less experienced practitioners learn faster and consistently perform at a higher level.

1. 6/2/15
1
Enough
About
Processes,
Lets
Use
Pa9erns
Paul
E.
McMahon
Principal,
PEM
Systems
ObjecDves
• Explain
common
mistakes
• MoDvate
and
explain
a
be9er
approach
• Share
approach
with
examples
Copyright
2015
PEM
Systems
2

2. 6/2/15
2
Background
and
MoDvaDon
Copyright
2015
PEM
Systems
3
What
is
SoOware
Development?
How
can
we
do
be+er
helping
so3ware
prac44oners
with
the
common
challenges
they
face
each
day?
Reusing
Design
Pa9erns
Copyright
2015
PEM
Systems
4
…But
so3ware
development
extends
far
beyond
just
design
and
programming

3. 6/2/15
3
Typical
SoOware
Developer’s
Day
• Design
0.5
hour
• Programming
1.0
hour
• Requirements
gathering/analysis
0.5
hour
• Customer
support
0.5
hour
• EsDmaDng/statusing/improvements
0.5
hour
• TesDng/bug
fixing
2.0
hours
• Admin
tasks
(email,
meeDngs)
3.0
hours
Copyright
2015
PEM
Systems
5
For
every
1.5
hours
of
programming/design,
typical
developer
spends
3.5
hours
working
other
common
so>ware
development
ac?vi?es
1.5
hrs
3.5
hrs
Another
QuesDon
• Are
there
other
pa9erns
beyond
design
and
programming
–
that
we
haven’t
been
paying
close
enough
a9enDon
to–
that
could
help
soOware
pracDDoners
with
the
common
challenges
they
face
each
day?
Copyright
2015
PEM
Systems
6

4. 6/2/15
4
Pa9erns
Beyond
Design
and
Programming
Copyright
2015
PEM
Systems
7
Uses
pa9erns
as
aids
to
get
you
thinking
about
how
to
balance
conflicDng
ideas
MoDvaDng
“Thinking
Pa9erns”
Copyright
2015
PEM
Systems
8
Why
wouldn’t
it
make
sense
to
build
and
deploy
the
prac?ces
we
want
our
developers
to
follow
in
small
slices?

5. 6/2/15
5
PracDce
slice
and
thinking
pa9erns
Copyright
2015
PEM
Systems
9
A
prac?ce
slice
is
a
common
scenario
or
a
small
set
of
related
scenarios
that
a
soOware
pracDDoner
typically
faces
each
day
A
thinking
paDern
is
the
essenDals
of
a
pracDce
slice
with
key
related
quesDons,
Dps
and
warnings
added
in
More
MoDvaDon
for
Thinking
Pa9erns
Copyright
2015
PEM
Systems
10
• PracDces
then
become
a
vehicle
to
help
pracDDoners
perform
be9er
• What
if
organizaDons
viewed
their
soOware
pracDDoners
as
their
customer
for
their
organizaDonal
pracDces?
• “Study
this
because
it
contains
how-­‐we-­‐
expect-­‐you-­‐to-­‐operate”

6. 6/2/15
6
What
We
Have
Done
in
the
Past
Copyright
2015
PEM
Systems
11
• Processes
so
light
they
become
useless
• Extremely
heavyweight
processes
What
prac??oners
really
need
falls
in
between
these
two
extremes
• Requirements
Before
Design
• Design
Before
Code
• Test
Before
Release
What
pracDDoners
need
to
help
them
perform
(two
types
of
informaDon)
Copyright
2015
PEM
Systems
12
• Basic
informa?on
about
pracDces
– How
to
conduct
the
pracDce
– Competencies
need
– Checklists
• To
be
prepared
• CompleDon
criteria
TradiDonal
processes
have
done
reasonably
good
job
Where
thinking
pa9erns
can
help
most
• Things
to
watch
out
for
when
conduc?ng
the
pracDce
– Including
how
to
handle
common
scenarios
where
difficult
decision
needed

7. 6/2/15
7
How
we
discovered
“thinking
pa9erns”
Copyright
2015
PEM
Systems
13
I
don’t
know
how
I
can
apply
these
principles
in
the
“fog
of
war”
of
my
real
project
Pa9ern
#1:
“I
don’t
understand
a
requirement”
or
“Fly
high
go
fast”
• User
story:
“As
a
so9ware
developer,
I
want
more
guidance
in
what
I
should
do
when
I
don’t
understand
a
requirement,
so
that
I
can
build
the
best
so9ware
in
the
least
amount
of
Cme
to
meet
my
customer’s
needs
&
my
commitments.”
Copyright
2015
PEM
Systems
14
We
need
simulated
missiles
that
fly
high
and
go
fast!

8. 6/2/15
8
Pa9ern
#1:
“I
don’t
understand
a
requirement”
or
“Fly
high
go
fast”
(cont.)
• Ques?ons
to
ask:
– Is
my
customer
collaboraDve
and
working
closely
with
me
to
discover
the
requirements?
– Do
I
have
a
fixed
schedule
and
cost?
• Tips:
– Do
nothing
different
if
customer
understands
cost
of
iteraDng
to
discover
requirements
and
is
working
closely
with
you
– Raise
a
risk
if
non-­‐collaboraDve
customer
and
fixed
cost/schedule
Copyright
2015
PEM
Systems
15
Fly
high,
Go
Fast
Pa9ern
#2:
“My
tesDng
is
taking
too
long”
or
“How
much
is
enough?”
• User
story:
“As
a
so9ware
developer
(or
tester),
I
want
to
know
what
to
do
when
my
tesCng
is
taking
too
long,
so
that
I
can
respond
to
the
pressure
from
my
manager
to
finish.”
Copyright
2015
PEM
Systems
16
I
need
to
run
all
these
tests
to
be
sure
everything
is
perfect!

9. 6/2/15
9
Pa9ern
#2:
“My
tesDng
is
taking
too
long”
or
“How
much
is
enough?”(cont.)
• Ques?ons
to
ask:
– Does
soOware
have
life-­‐criDcal/high
cost
failure
consequences?
– Does
my
project
have
an
agreed
way
of
working
with
respect
to
tesDng?
If
so,
have
I
reviewed
my
tesDng
opDons?
• Tips:
– Consider
focusing
your
low
level
tesDng
just
on
areas
you
have
changed,
if
allowed
by
your
agreed
way
of
working.
– Consider
focusing
tests
on
high
risk
areas,
if
allowed
by
your
agreed
way
of
working.
• Warnings:
– Be
sure
to
assess
any
risk
involved
in
reduced
tesDng
such
as:
–
Missing
key
dependencies.
–
Not
following
the
agreed
way
of
working.
Copyright
2015
PEM
Systems
17
Pa9ern
#3:
“How
should
I
handle
a
design
risk?”
or
“I’m
a
new
developer”
• User
Story:
“As
a
so9ware
developer,
I
want
more
help
in
how
to
handle
a
design
risk,
when
the
alternaCve
design
is
going
to
extend
the
schedule,
so
that
I
can
respond
to
the
pressure
to
finish
on
Cme.”
Copyright
2015
PEM
Systems
18
Why
don’t
you
just
ask
Fred?
He’s
an
expert
in
that
system.

10. 6/2/15
10
Pa9ern
#3:
“How
should
I
handle
a
design
risk?”
or
“I’m
a
new
developer”
• Ques?ons
to
ask:
– Have
I
discussed
my
design
with
an
experienced
coworker
or
colleague
who
has
implemented
a
similar
design?
– Have
we
teamed
up
new
developers
with
mentors?
• Tips:
– Call
for
a
peer
review.
– Call
for
a
limited
peer
review
with
key
people
focusing
just
on
the
design
risk,
if
allowed
by
your
agreed
way
of
working.
• Warning:
– Less
experienced
pracDDoners
someDmes
hesitate
asking
for
help
for
fear
of
being
perceived
as
lacking
competency
Copyright
2015
PEM
Systems
19
Ask
for
help
Is
training
in
common
pa9erns
enough?
• Does
performance
improvement
always
result
just
from
making
pracDDoners
aware
of
pa9erns?
• Also
need
to
recognize
pa9erns
when
faced
with
a
similar
situaDon
Copyright
2015
PEM
Systems
20

11. 6/2/15
11
Example:
Pa9ern
recogniDon
from
non-­‐soOware
development
domain
• Story
about
Tom
Brady,
Quarterback,
New
England
Patriots,
NaDonal
Football
League
– Brady’s
posiDve
a9ribute:
“decision-­‐making”
– “I
don’t
know
how
I
know
where
to
pass.
There
are
no
firm
rules.
You
just
‘feel’
like
you
are
going
to
the
right
place….And
that
is
where
I
throw
it.”
Copyright
2015
PEM
Systems
21
Tom
says
he
doesn’t
know
how
he
knows
where
to
pass,
but
do
you
know?
Spending
hours
reviewing
videos
of
next
opponent
before
the
game
• Brady
spends
hours
and
hours
looking
at
videos
of
the
team
he
is
about
to
face
looking
for
strengths/
weaknesses
of
his
next
opponent
Copyright
2015
PEM
Systems
22
• Do
you
think
soOware
pracDDoners
can
learn
anything
from
this
example?

12. 6/2/15
12
Two
sides
to
our
brain
• Quick
thinking
emoDonal
side
(System
1)
• Slow
thinking
logical
side
– (System
2)
• Quick
thinking
emo?onal
side
– In
charge
inside
most
of
us
and
makes
most
decisions
– Loves
pa9erns
Copyright
2015
PEM
Systems
23
To
make
beDer
decisions,
need
to
recognize
“right
paDerns,”
But
how?
What
is
Brady
doing
when
he
is
spending
hours
watching
videos?
• He
is
preparing
(or
pracDcing)
– You
prepare
by
thinking
ahead
of
Dme
about
what
you
are
about
to
face
• Using
slow
thinking
logical
side
to
refresh
the
right
pa9erns
for
your
fast
thinking
emoDonal
side
• You
know
what
they
are
be9er
than
anyone
else!
• Do
you
want
to
become
an
expert
fast?
– Kahneman
tells
us
expert
intuiDon
is
nothing
more
and
nothing
less
than
pa9ern
recogniDon
and
it
only
comes
from
sufficient
opportunity
to
pracDce
Copyright
2015
PEM
Systems
24

13. 6/2/15
13
So
how
might
this
relate
to
a
soOware
pracDDoner’s
work
day?
• Recall
all
those
other
acDviDes
beyond
design
and
programming
that
a
soOware
pracDDoner
typically
does
each
day
– Ask
yourself:
• Which
will
be
most
challenging
for
me
today?
• What
are
the
pa9erns
that
will
help
me
respond
most
effecDvely?
• What
decisions
might
I
face?
• What
opDons
do
I
have?
Copyright
2015
PEM
Systems
25
More
Sample
Scenarios
&
Guidance
to
Kick-­‐Start
Your
Pa9ern
Development
• With
quesDons,
Dps
and
warnings
• Based
on
real
experiences
(“real
stories”)
that
tend
to
repeat
in
many
organizaDons
• Includes
soOware
supporDng
roles
Copyright
2015
PEM
Systems
26

14. 6/2/15
14
Pa9ern
#4:
“How
can
I
help
my
team
improve
performance?“
or
“Coachable
moments”
Copyright
2015
PEM
Systems
27
Should
I
re-­‐start
my
2
hour
weekly
meeDng?
• User
Story:
“As
a
team
leader,
I
want
more
guidance
in
what
I
should
do
when
my
team
isn’t
following
the
new
expected
behavior,
so
that
we
can
benefit
from
our
new
improved
pracCces.”
Pa9ern
#4:
QuesDons,
Tips,
Warnings
• Ques?ons
to
ask:
– Have
you
worked
through
any
conflicts
between
new
agreed
way
of
working
and
org.
policies,
culture?
– If
using
mulDple
coaches,
have
you
agreed
on
way
of
working?
• Tips:
– Consider
using
a
head-­‐coach
for
consistent
guidance
– Examples
where
issues
might
arise
include:
• Constraints
on
who
can
sign
up
for
certain
task
types
• Capacity
planning
and
risk
assessment
expectaDons
• ExpectaDons
on
basis
of
task
esDmates,
velocity,
burn-­‐down
charts
– Watch
for
“coachable
moments”…
“Have
you
considered…”
• Warnings:
– Keep
an
eye
out
for
coaches
who
just
coach
to
their
own
experiences
and
are
not
a9une
to
needs
of
your
organizaDon
Copyright
2015
PEM
Systems
28

15. 6/2/15
15
Pa9ern
#5:
“The
Non-­‐Engaged
Stakeholder”
or
“We
need
test
data!”
Copyright
2015
PEM
Systems
29
We
need
test
data!
• User
Story:
“As
a
sub-­‐
contract
manager,
I
want
more
guidance
in
what
I
should
do
when
a
stakeholder
won’t
give
me
the
data
we
need,
so
that
we
can
meet
our
schedule
and
cost
commitments.”
Copyright
2015
PEM
Systems
30
Pa9ern
#5:
QuesDons,
Tips,
Warnings
• Ques?ons
to
ask:
– Have
you
let
your
customer
know
immediately
when
they
are
impacDng
your
performance?
– Has
a
stakeholder
representaDve
been
appointed?
– Have
they
agreed
to
take
on
their
responsibiliDes?
• Tips:
– If
fixed
cost/schedule
and
impacted,
alert
customer
at
once
– OOen
stakeholder
reps
have
not
been
appointed
or
don’t
realize
impact
– Second
step,
dig
to
see
if
you
can
uncover
root
cause
– Example
of
possible
reasons
include:
• Too
much
work
on
their
plate
• Lack
of
communicaDons/understanding
of
real
need
• Poor
processes
within
subcontractor
organizaDon
• Lack
of
authorizaDon
• Warnings:
– Don’t
hesitate
to
alert
customer
– Keep
an
eye
out
for
stakeholder
reps
who
lack
authorizaDon

16. 6/2/15
16
Pa9ern
#6:
“Why
can’t
we
hit
our
schedule
commitments?”
or
“That
won’t
work!”
Copyright
2015
PEM
Systems
31
Our
product
backlog
is
never
properly
prepared!
• User
Story:
“As
a
team
lead,
I
want
more
guidance
in
what
I
should
do
to
help
my
team,
so
that
we
can
consistently
meet
our
schedule
commitments.”
Copyright
2015
PEM
Systems
32
Pa9ern
#6:
QuesDons,
Tips,
Warnings
• Ques?ons
to
ask:
– Are
we
esDmaDng
our
future
work
based
on
our
real
recent
velocity/performance?
• Tips:
– Keep
personal
data
on
actual
Dme
spent
clarifying
backlog
items
as
well
as
other
common
soOware
acDviDes
– Use
actual
recent
personal
data
to
esDmate
• Warnings:
– OOen
teams
fail
to
consider
real
velocity
when
predict
– Keep
on
lookout
for
“going
through
the
moDons”
in
retrospecDves,
not
a9acking
the
“hard
problems”

17. 6/2/15
17
• Another
Tip:
– If
the
culture
in
your
organizaDon
is
one
where
management
uses
power
to
pressure
pracDDoners
to
make
esDmates
they
are
not
comfortable
with-­‐-­‐-­‐
• Keep
in
mind
the
story
of
Korean
Airlines
in
the
1990s
– PotenDal
devastaDng
effects
of
inappropriate
deference
to
authority
(e.g.
“miDgated
speech”)
Copyright
2015
PEM
Systems
33
Pa9ern
#6:
QuesDons,
Tips,
Warnings
(cont.)
A
simple
way
to
pilot
the
thinking
pa9ern
idea
in
your
organizaDon
• Set
up
a
brainstorming
session
where
you
ask
parDcipants
to
share
real
stories
related
to
common
challenges
faced
• Include
at
least
1
or
2
experts
to
sDmulate
discussion
to
understand
issues,
ask
key
quesDons,
share
Dps,
and
warnings
• Capture
scenario
essenDals,
key
quesDons,
Dps,
and
warnings,
prioriDze
based
on
consensus
and
select
small
set
to
train
to
wider
group
• Provide
on-­‐the-­‐job
pa9ern
reminder
aids
and
conduct
survey
to
determine
if
useful
Copyright
2015
PEM
Systems
34

18. 6/2/15
18
Capturing
pa9erns
on
cards
as
reminder
aids
Copyright
2015
PEM
Systems
35
Could
add
memory
jogger
reference
to
“real
story”
Reference:
“Fly
high,
go
fast”
What
makes
thinking
pa9erns
any
be9er
than
checklists?
• Gives
your
pracDDoners
context
• SDmulates
“criDcal-­‐thinking”
through
the
quesDons,
Dps,
and
warnings
leading
to
be9er
decisions
• They
are
fun
to
create
and
stories
are
great
memory
aids!
Copyright
2015
PEM
Systems
36

19. 6/2/15
19
How
to
avoid
non-­‐value-­‐add
pa9erns
• Select
only
pa9erns
– That
are
common
and
tend
to
repeat
– Where
pracDDoners
oOen
need
help
making
related
decisions
– That
present
potenDal
significant
impact
to
performance
• Prune
pa9erns
regularly
– When
add
new
pa9erns
consider
deleDng
older
pa9erns
that
are
not
providing
payback
Copyright
2015
PEM
Systems
37
Conclusion
• Pa9erns
don’t
replace
your
company
processes,
or
what
your
team
is
doing
today
• They
are
an
aid
that
can
help
your
team’s
criDcal-­‐thinking
and
decision-­‐making
Copyright
2015
PEM
Systems
38

20. 6/2/15
20
Contact
InformaDon
• Paul
E.
McMahon,
Principal,
PEM
Systems
• www.pemsystems.com
• pemcmahon@acm.org
• Phone:
607-­‐798-­‐7740
39
Copyright
2015
PEM
Systems