6. Waterfall
Struggles
• DocumentaMon
outdated
before
its
reviewed
• Change
is
painful
• Customer
dislikes
the
results
of
what
they
said
they
wanted
• Time
to
market
• Overkill
for
some
projects
• Hard
to
do
for
new
developers
9. Cowboy
Struggles
• Onboarding
new
team
members
• SoPware
ValidaMon
• Is
it
the
right
soPware?
• Determining
value?
10. IntroducMon
to
Agile
• Team
Member
• Scrummaster
– CSM
(April
2014)
– Chosen
as
SM
(Summer
2014)
• Product
Owner
– Owned
a
team
(June
2015)
– CSPO
(August
2015)
15. • What
is
needed
to
convey
what
the
Product
Owner
and
stakeholders
need?
• What
is
needed
by
the
team
to
transfer
knowledge
quickly
and
easily?
• What
is
needed
by
the
team
to
prove
that
they
have
done
the
work
required?
• What
is
needed
to
reduce
maintenance
costs
with
maintaining
the
soPware?
• Who
am
I
making
this
document
for?
DocumentaMon
QuesMons
16. Atypical
Scrum
Setup
• Team
consists
of
– 8
Developers
• PV
team
handles
product
validaMon
• UX
team
creates
a
consistent
look
and
feel
for
applicaMon
UI
17. My
Scrum
Team
• DocumentaMon
– Inputs
• System
SpecificaMon
• UI
SpecificaMon
– Outputs
• SoPware
Release
SpecificaMon
• TesMng
Notes
18. Summary
• DocumentaMon
can
be
useful
• Documents
should
only
be
created
to
fill
a
specific
need
and
have
a
specific
audience
• DocumentaMon
should
depend
on
the
complexity
and
size
of
the
work
• Let
the
team
and
stakeholders
have
input
• DocumentaMon
is
a
deliverable