Developer
to
Developer
Accountability
Tim
Rayburn
–
AgileDotNet
Dallas
2013
Slide 2
Slide 2 text
Accountability
Should
not
be
scary!
Slide 3
Slide 3 text
No content
Slide 4
Slide 4 text
No content
Slide 5
Slide 5 text
No content
Slide 6
Slide 6 text
What
can
cause
a
failure
of
Accountability?
Slide 7
Slide 7 text
The
Hierarchy
of
Pains
* True
technology
problems
are
very
rare.
But
are
also
often
relatively
easy
to
solve.
* The
good
news
is
that
there
are
lots
of
ways
to
approach
this
problem.
Tech
Process
Team
Character
Slide 8
Slide 8 text
The
Hierarchy
of
Pains
* Process
problems
exist
when
a
process
does
not
serve
its
one
true
purpose,
to
guide
the
team
towards
value.
* Process
can
and
should
be
flexible,
because
value
can
be
derived
in
so
many
different
ways.
Tech
Process
Team
Character
Slide 9
Slide 9 text
The
Hierarchy
of
Pains
* A
team
of
great
individual
contributors
does
not
guarantee
a
great
team.
* Tools
such
as
the
DISC
profiles
can
help
you
put
together
strong
teams
Tech
Process
Team
Character
Slide 10
Slide 10 text
The
Hierarchy
of
Pains
* These
are
the
tough
ones.
You
need
to
provide
room
for
personal
growth,
but
one
bad
apple
can
and
will
spoil
the
bunch.
* “The
good
of
the
many
out
weighs
the
good
of
the
few
…
or
the
one.”
Tech
Process
Team
Character
Slide 11
Slide 11 text
Conquering
the
Problems
Slide 12
Slide 12 text
I
don’t
know
what
Tim’s
doing…
* Task
boards
aren’t
just
for
Project
Managers
or
SCRUM
Masters.
* If
you
have
chronic
offenders,
have
everyone
touch
the
task
they
are
talking
about
during
your
morning
meeting.
Slide 13
Slide 13 text
I
don’t
know
what
Tim’s
doing…
* If
your
team
is
distributed,
then
a
tool
like
Team
Foundation
Server
2012’s
built
in
task
board
can
be
very
helpful.
Slide 14
Slide 14 text
Tim
gets
upset
when
you
critique…
* This
is
first
and
foremost
a
character
issue.
And
needs
to
be
addressed.
* Using
comments
on
work
items,
and
not
having
to
“sit
through”
a
review
can
be
helpful.
Slide 15
Slide 15 text
No content
Slide 16
Slide 16 text
Tim
checks
in
untested
code…
* This,
again,
is
a
character
issue
and
should
be
addressed.
* Tools
can
help
here,
monitoring
code
coverage,
and
gated
check-‐ins.
Slide 17
Slide 17 text
The
great
thing
about
Object
Oriented
code
is
that
it
can
make
small,
simple
problems
look
like
large,
complex
ones.
#UnitTesting
Tim
checks
in
untested
code…
Slide 18
Slide 18 text
Tim
violates
“the
architecture”…
* This
is
a
process
smell,
but
if
it
provides
value
then
we
should
really
look
at
tools
to
automate
this.
* Tools
like
FXCop
or
the
Architecture
Explorer
can
be
very
useful
in
this
regard.
Slide 19
Slide 19 text
Tim
claimed
something
is
done,
and
it
isn’t.
Whoo-‐hoo-‐hoo,
look
who
knows
so
much.
It
just
so
happens
that
your
friend
here
is
only
MOSTLY
dead.
There's
a
big
difference
between
mostly
dead
and
all
dead.
Mostly
dead
is
slightly
alive.
Slide 20
Slide 20 text
Tim
claimed
something
is
done,
and
it
isn’t.
* We
want,
we
need,
tasks
which
are
all
dead,
aka
all
done.
Mostly
done,
is
not
done.
* Tasks
will
take
as
long
as
they
will
take,
don’t
fudge
this.
Slide 21
Slide 21 text
But
wait,
there’s
more
…
Slide 22
Slide 22 text
* Pushed
code
to
production
or
QA
without
approval.
* “Fixed”
a
bug,
but
not
told
QA
it
was
fixed.
* Didn’t
let
the
product
owner
know
that
a
release
was
complete.
* And
oh
so
many
more…
Tim
might
have…
Slide 23
Slide 23 text
* Drive
for
accountability
on
your
team,
person
to
person.
This
isn’t
a
management
thing,
it’s
a
team
dynamic
thing.
* Encourage
teams
to
hold
each
other
accountable,
we’re
trying
to
achieve
value.
* Remember
this
is
not
about
confrontation,
it’s
about
accountability.
Visibility
as
to
where
things
are
so
that
WE
can
achieve
our
goals.
Call
to
Action