Professional Documents
Culture Documents
DAD 3 Hour Tutorial PDF
DAD 3 Hour Tutorial PDF
Mark
Lines
mark@sco7ambler.com
Mark_Lines
IntroducEons
• A
big
group
so
we
won’t
do
individual
introducEons
• Does
anyone
have
something
specific
that
they
want
to
learn
about
Disciplined
Agile
Delivery
today?
Valida-on
Do
conEnuous
regression
tesEng,
and
be7er
yet
take
a
Test-‐Driven
Development
(TDD)
approach
Collabora-on
Work
closely
with
their
stakeholders,
or
a
stakeholder
proxy,
ideally
on
a
daily
basis
Self
Are
self-‐organizing
and
work
within
an
organiza-on
appropriate
governance
framework
Improvement
Regularly
reflect
on,
and
measure,
how
they
work
together
and
then
act
to
improve
on
their
findings
in
a
Emely
manner
• For
5
minutes,
rate
yourself
and
your
organizaEon
on
a
scale
of
one
to
five
for
the
following
criteria:
– Business
value
(1
=
Infrequent
releases,
3
=
Quarterly
Releases,
5
=
Weekly
or
be7er
releases)
– ValidaEon
(1
=
Separate
testers
do
the
tesEng,
3
=
Developers
do
some
regression
tesEng,
5
=
test
driven
approach)
– CollaboraEon
(1
=
We
mostly
see
stakeholders
at
beginning
and
end
of
project,
3
=
We
have
weekly
stakeholder
contact,
5
=
Daily
stakeholder
contact)
– Self
OrganizaEon
(1
=
Management
plans,
3
=
The
team
plans,
5
=
The
team
plans
and
is
governed
in
an
agile
manner)
– Improvement
(1
=
We
have
a
project
post
mortem,
3
=
We
have
regular
retrospecEves,
5
=
We
have
retrospecEves
and
measure
our
progress)
Source:
www.agilemanifesto.org
©
Sco7
Ambler
+
Associates
7
Agenda
cru m-‐fall!!
er-‐ s
i s
NO T
Wat
DAD
Advantages
*
*
OpEon
Goal
Issue
Disadvantages
Default
Op/on
ConsideraEons
Source
Team
size
Team
structure
Form
the
Co-‐located
Team
members
IniEal
Team
ParEally
dispersed
Geographic
distribuEon
Fully
dispersed
SupporEng
the
team
Distributed
subteams
Availability
• Delivery
focus
Disciplined
• Risk-‐value
driven
lifecycle
Agile
• Self-‐organizaEon
with
appropriate
governance
Delivery
• Goal
driven
• Enterprise
aware
• ConstrucEon
focus
Agile
• Value
driven
lifecycle
• Self-‐organizing
teams
• PrescripEve
• Project
team
aware
Agenda
Scrum Roles
Primary
Roles
Team
Lead
Product
Team
Stakeholder
Architecture
Owner
Member
Owner
Secondary
Roles
(for
scaling)
Independent
Specialist
Domain
Technical
Integrator
Tester
Expert
Expert
Stakeholder
• Stakeholder
is
more
than
a
customer
• Anyone
impacted
by
the
outcome
of
the
system
• Types
of
stakeholders
– End
users:
Users
of
the
system
– Principals:
Decision
makers
that
pay
for
and
put
the
system
to
use
– Partners:
People
who
make
the
system
work
in
producEon
– Insiders:
Members
of
the
development
team
and
people
who
provide
business
and
technical
services
to
the
team
Product
Owner
• The
Stakeholder
“proxy”
• Go-‐to
person
for
informaEon
on
the
soluEon
requirements
• PrioriEzes
all
work
for
the
team
• ParEcipant
in
modeling
and
acceptance
tesEng
• Has
access
to
expert
stakeholders
• Facilitates
requirements
envisioning
and
modeling
• Educates
team
in
business
domain
• May
demonstrate
soluEon
to
key
stakeholders
• Monitors
and
communicates
status
to
stakeholders
• NegoEates
prioriEes,
scope,
funding,
and
schedule
Team
Member
• Is
a
cross-‐funcEonal,
generalizing
specialist
• On
small
teams
every
team
member
is
typically
a
developer,
but
on
larger
teams
non-‐developers
may
appear
• Volunteers
to
do
any
work
that
allows
the
team
to
most
efficiently
delivery
the
work
commi7ed
to
for
the
iteraEon
• Seeks
to
both
learn
about
other
specialEes
as
well
as
coach
others
on
their
own
specialty
• Goes
to
the
product
owner
for
domain
informaEon
and
decisions
• Works
with
the
architecture
owner
to
evolve
the
architecture
• Follows
enterprise
convenEons
and
leverage
and
enhance
the
exisEng
infrastructure
Team
Lead
• Responsible
for
the
effecEveness
and
conEnuous
improvement
of
the
team’s
process
• Facilitates
close
collaboraEon
between
team
members
• Keeps
the
team
focused
on
the
project
vision
and
goals
• Removes
impediments
for
the
team
and
escalates
organizaEonal
impediments
• Protects
the
team
from
interrupEons
and
external
interferences
• Maintains
honest
communicaEon
between
everyone
on
the
project
• Coaches
others
in
the
use
of
agile
pracEces
• Prompts
the
team
to
discuss
and
think
through
issues
when
they
are
idenEfied
• Facilitates
decision
making
(but
does
not
make
decisions
or
mandate
internal
team
acEvity)
Architecture
Owner
• Guides
the
creaEon
and
evoluEon
of
the
soluEon’s
architecture
• Mentors
and
coaches
team
members
in
architecture
pracEces
and
issues
• Understands
the
architectural
direcEon
and
standards
of
your
organizaEon
and
ensures
that
the
team
adheres
to
them
• Ensures
the
system
will
be
easy
to
support
by
encouraging
appropriate
design
and
refactoring
• Ensures
that
the
system
is
integrated
and
tested
frequently
• Has
the
final
decision
regarding
technical
decisions,
but
doesn’t
dictate
them
• Leads
the
iniEal
architecture
envisioning
effort
Agenda
©
Sco7
Ambler
+
Associates
15
Disciplined
Agile
Delivery
Tutorial
JusEfy Project
IniEal EsEmate
IniEal
Requirements
©
Sco7
Ambler
+
Associates
36
• ConsideraEons:
– Schedule
– Cost
– Work
allocaEons
– How
many
releases
and
Eming
of
each?
– Length
of
iteraEons?
• 73%
of
agile
teams
produce
an
iniEal
high-‐level
esEmate,
and
18%
of
agile
teams
produce
a
detailed
one*
• 77%
of
agile
teams
produce
an
iniEal
high-‐level
schedule,
and
12%
of
agile
teams
produce
a
detailed
one*
2 weeks 51%
3 weeks 15%
4 weeks 10%
> 4 weeks 2%
HeurisEcs:
• Shorter
is
generally
be7er
than
longer
• Teams
at
scale
may
require
slightly
longer
iteraEons
IncepEon
Goal:
Form
the
IniEal
Team
Infrastructure/DevOps
Independent Testers
Product Owner
• IncepEon
is
complete
and
you
can
enter
the
ConstrucEon
phase
when:
– Your
stakeholders
agree
that
it
makes
sense
to
proceed
based
upon
the
achievable
scope,
schedule,
budget,
constraints,
and
other
criteria
related
to
your
business
case
– The
risks
have
been
idenEfied
and
seem
tolerable
– There
is
agreement
on
using
a
minimalist
and
agile
process
for
building
the
soluEon
– The
team
and
environment
have
been
set
up
or
are
in
the
process
of
being
so,
that
supports
collaboraEve
teamwork
– The
process
and
governance
strategies
have
been
agreed
to
by
both
your
team
and
your
stakeholders
• Typically
outlines:
– Goals
of
the
project
team
and
who
is
on
it
– High-‐level
scope
of
the
current
release
– Technical
overview
of
the
soluEon
– Outline
of
the
plan
to
do
the
required
work
– Could
include
feasibility
informaEon
• AnE-‐pa7erns
– No
support
for
skills
development
– No
support
for
dedicated
faciliEes
– AutocraEc
project
management
pracEces
– Jumping
into
ConstrucEon
– Overly
detailed
work
products
– Analysis
paralysis
Agenda
• A
Disciplined
Agile
Manifesto
• An
Overview
of
Disciplined
Agile
Delivery
(DAD)
• DAD
Roles
• The
IncepEon
Phase
• The
ConstrucEon
Phase
• The
TransiEon
Phase
• Governing
Disciplined
Agile
Teams
• Comparing
the
DAD
and
SAFe
Frameworks
• Ongoing
– Fulfill
the
project
mission
– Improve
team
process
and
environment
– Grow
team
members
– Leverage
and
enhance
exisEng
infrastructure
– Address
risk
A ConstrucEon IteraEon
• IteraEon demonstraEon
• On-‐demand demonstraEons
• None
ConstrucEon
Pa7erns
• The
team
can
be
reliably
depended
on
to
demonstrate
increments
of
sohware
at
the
end
of
each
iteraEon
ConstrucEon
AnE-‐Pa7erns
• A
work
item
list
that
is
too
big
to
easily
manage
and
comprehend
• Ina7enEon
to
risk
miEgaEon
• Assuming
that
the
architecture
will
work
without
proving
it
with
code
• Assuming
that
an
iteraEve
approach
alone
ensures
that
you
will
build
the
right
soluEon
in
an
effec%ve
manner
• One
or
more
of
your
team
members
are
working
on
other
projects
in
addiEon
to
yours
• A
work
item
isn’t
done
• Last
iteraEon
we
planned
for
X
points
but
delivered
Y
(less
than
X),
but
we
sEll
commit
to
X
this
iteraEon
• During
the
iteraEon
we
missed
some
tasks
when
iteraEon
planning
• During
the
iteraEon
we
realized
we
missed
a
requirement
that
another
depends
on
• During
iteraEon
planning
sessions,
the
product
owner
is
reprioriEzing
the
backlog
or
is
uncertain
of
requirement
details
• Defect
counts
are
increasing
in
each
iteraEon
Agenda
• Ongoing
– Fulfill
the
project
mission
– Improve
team
process
and
environment
– Grow
team
members
– Leverage
and
enhance
exisEng
infrastructure
– Address
risk
Agenda
DAD Milestones
Sufficient funcEonality Does it make sense to release the current soluEon?
• Disciplined
pracEces:
– Risk-‐value
lifecycle
– Explicit
light-‐weight
milestones
– Follow
enterprise
development
guidelines
– Work
closely
with
enterprise
professionals
– Development
intelligence
via
automated
dashboards
PotenEal Metrics
Agenda
• A
Disciplined
Agile
Manifesto
• An
Overview
of
Disciplined
Agile
Delivery
(DAD)
• DAD
Roles
• The
IncepEon
Phase
• The
ConstrucEon
Phase
• The
TransiEon
Phase
• Governing
Disciplined
Agile
Teams
• Comparing
the
DAD
and
SAFe
Frameworks
Con
IncepEon
Domain
Scaling/Tailoring
Complexity
Factors
Complexity
Straightforward
Geographic
Team
Very complex
Distribu-on
Size
motivates
mo Technical
Co-located 2 %va
tes
Complexity
Global
1000s
Straightforward
mo
va
rie
Very complex
%
mo%vates
va
s
b
tes
y
Organiza-onal
Team
Compliance
Distribu-on
Culture
affects
Single varies
by
Agile
None
Outsourcing Rigid
Life critical
s
ect
s
ect
aff
aff affects
Project
Type
Organiza-onal
Culture
Multiple
Release
Single Release Agile
Rigid
© Scott Ambler + Associates 98
3 Vote
102
Thank
You!
mark@sco7ambler.com
@mark_lines
DisciplinedAgileDelivery.com
DisciplinedAgileConsorEum.org
Sco7WAmbler.com
Recommended Resources