This document discusses how being truly agile is challenging for many roles. It notes that while the principles of agility seem simple, living them out requires discipline, courage, and a willingness to change. Developers must write quality code, accept responsibility, and continuously improve. Testing specialists need strong analytical skills and must teach others. DevOps specialists must automate processes and refactor frequently. Product owners must spend time with customers while still supporting teams. Leadership must trust others while dealing with organizational demands. Coaches need to influence culture within time constraints by consistently demonstrating good practices. True agility ultimately requires soft skills and an ongoing effort to avoid chaos through self-discipline.

1. We
said
it
was
simple
Andy
Longshaw
Advanced
Legal
@andylongshaw

2. A
wise
man
once
said

3. It’s
simple
Individuals
and
interac/ons
over
processes
and
tools
Working
so4ware
over
comprehensive
documenta;on
Customer
collabora/on
over
contract
nego;a;on
Responding
to
change
over
following
a
plan
Agile
manifesto
Courage
Simplicity
Feedback
Communica/on
Respect
XP
values

4. Well,
reasonably
simple
Working
so@ware
is
the
primary
measure
of
progress.
Agile
processes
promote
sustainable
development.
The
sponsors,
developers,
and
users
should
be
able
to
maintain
a
constant
pace
indefinitely.
Con;nuous
aEen;on
to
technical
excellence
and
good
design
enhances
agility.
Simplicity-­‐-­‐the
art
of
maximizing
the
amount
of
work
not
done-­‐-­‐is
essen;al.
The
best
architectures,
requirements,
and
designs
emerge
from
self-­‐organizing
teams.
At
regular
intervals,
the
team
reflects
on
how
to
become
more
effec;ve,
then
tunes
and
adjusts
its
behavior
accordingly.
Our
highest
priority
is
to
sa;sfy
the
customer
through
early
and
con;nuous
delivery
of
valuable
so@ware.
Welcome
changing
requirements,
even
late
in
development.
Agile
processes
harness
change
for
the
customer's
compe;;ve
advantage.
Deliver
working
so@ware
frequently,
from
a
couple
of
weeks
to
a
couple
of
months,
with
a
preference
to
the
shorter
;mescale.
Business
people
and
developers
must
work
together
daily
throughout
the
project.
Build
projects
around
mo;vated
individuals.
Give
them
the
environment
and
support
they
need,
and
trust
them
to
get
the
job
done.
The
most
efficient
and
effec;ve
method
of
conveying
informa;on
to
and
within
a
development
team
is
face-­‐to-­‐face
conversa;on.

5. How
hard
can
it
be?

6. Developers
• It’s
not
easy
for
them
because
they
need
to…
• take
responsibility
• have
the
discipline
to
follow
their
process
under
pressure
• say
“no”
when
things
can’t
be
done
• have
the
judgment
and
courage
to
ask
for
help
when
they
need
it
• follow
through
on
their
retrospec;ve
ac;ons
• seek
feedback
and
keep
improving
• keep
refactoring
un;l
it’s
simple!

7. Tes;ng
specialists
• It’s
not
easy
for
her
because
she
needs
to…
• be
more
proac;ve
• get
really
good
at
(business)
analysis
skills
• learn
some
coding
• get
really
good
at
exploratory
tes;ng
• spend
a
lot
of
;me
teaching
people
about
what
makes
good
tests
• oh,
and
see
“Developers”

8. Devops
specialists
• It’s
not
easy
for
them
because
they
need
to…
• automate
all
the
things
• master
the
different
tools
for
deployment,
tools
for
build,
tools
for
test
and
containers
• refactor
the
pipeline
again
to
include
a
new
technology
• oh,
and
see
“Developers”

9. The
product
owner
• It’s
not
easy
for
her
because
she
has
to…
• spend
a
lot
of
;me
out
of
the
building,
visi;ng
customers
and
understanding
the
market
• be
available
to
answer
ques;ons
when
the
team
needs
her
to
&
take
part
in
3
Amigos
sessions
• find
;me
to
do
enough
work
on
the
backlog
so
that
it’s
coherent
and
ready
for
the
team
• deal
with
various
bits
of
the
organisa;onal
square
on
behalf
of
the
team,
like
communica;ng
“bad
news”
(honesty)
about
changes
in
delivery
;mescales
or
the
features
(not)
in
a
release

10. The
organisa;on’s
technical
leadership
• It’s
not
easy
for
them
because
they
have
to…
• recruit
good
people
who
can
fulfill
all
of
this
• trust
them
to
make
good
decisions
and
priori;se
and
to
ask
for
help
when
they
need
it
• deal
with
the
other
bits
of
the
organisa;onal
square
on
behalf
of
the
team
that
the
product
owner
doesn’t
deal
with
• let
people
get
on
with
making
mistakes
and
learning
as
they
do
some
stuff
that
you
can
probably
already
do
&
that
you
would
probably
rather
be
doing
than
all
this
management
crap

11. I
know,
we’ll
get
a
coach
in…
• It’s
not
easy
for
them
because
they
have
to…
• try
to
influence
the
team
culture
and
codebase
in
a
couple
of
days
a
week
• set
a
consistent
example
of
how
to
be
a
good
agile
developer
• teach
people
the
same
stuff
over
and
over
in
different
ways
without
going
postal

12. It’s
not
easy,
because…
• You
need
discipline
to
avoid
a
cynefin-­‐style
slide
into
chaos
• Most
of
the
challenges
are
around
so@
skills
-­‐
not
a
techie
strong
point
• You
have
to
change
yourself
• You
have
to
learn
when
to
have
iron
discipline
and
when
it’s
OK
to
improvise
• Your
organiza;on
is
square
and
you
are
a
circle

13. But
mostly…
• It’s
not
easy
because…
• …nobody
has
sold
the
wider
business
on
working
in
an
agile
way
and
agile
so@ware
development
doesn’t
deliver
the
benefits
unless
the
wider
business
works
with
the
grain

14. We
ain’t
gonna
take
it
• This
is
why
most
organisa;ons
end
up
in
Tommy
mode
– "We
ain't
gonna
take
it"
hEps://www.youtube.com/watch?v=sKDO19Y0KWg
– flaccid
scrum,
cargo
cult,
etc.
• But
XP
(and
other
agile
approaches)
only
work
when
they
have
the
dials
turned
up
to
10

15. So
remember…
• We
didn’t
say
it
was
easy.
We
said
it
was
SIMPLE
• If
you’re
finding
agile
so@ware
development
easy,
you’re
probably
doing
it
wrong