The document compares traditional waterfall and agile product development approaches. It summarizes research finding that agile projects succeed three times more often than waterfall projects. Key aspects of agile methodologies like Scrum are outlined, including roles, ceremonies, and values. Challenges of adopting agile approaches are also discussed.

1. Agile vs. Traditional Product Development
Watchdog Corp

2. 2
Waterfall Project Success Rates
Challenged: late, over budget, missed features
Success: on-time, on-budget, required features
Failed: cancelled, or delivered and never used
Agile Project Success Rates
"We have seen an increase in the number of
smaller projects and agile projects. Further,
we have seen a decrease in waterfall
projects."
50%
14%
57%
Performance
Agile Succeeds Three Times More Often Than Waterfall.
29%
Challenged
Success
Failed
50%
42%
49%
9%
Challenged
Success
Failed
CHAOS Manifesto, 2013

3. 3
CHAOS Manifesto, 2013
Feature Usage
Always & Often
Use always and/or often
Rarely
$1 million project, this
would save $190K
Sometimes
$1 million project, this
would save $160K
Never
Features that are never
used, and/or not known
45% 16%
19%
20%
“One of the biggest benefits from small projects
is the return on value is sooner rather than later.
So a small project has a much greater chance of
success, and therefore you will get a return
much faster.”
Opportunity Cost
Everything works perfectly on a whiteboard, don’t do big
up-front design.
64% Features rarely or never used.

4. The Agile Manifesto
It’s a Philosophy as well as a Methodology
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items
on the left more.

5. Agile Methodologies & Frameworks
Kanban
Scrum Lean
FDD
Scrum – Most start with Scrum as the
best foundational framework for people
that need to work together.
What is Agile?
We don’t do Agile, we become
Agile. Agile is a philosophy and a
number of methodologies &
frameworks.
53%
2–5 Years
19%
5+ Years
VersionOne, 2014 – “State of Agile”
survey 3,501 people
Agile
TDD

6. Scrum Values
Scrum is based on a set of fundamental core values that form the basis of our
actions & decision making.
Accountability
Being Agile means being open,
transparent & accountable to a team.
Remote & diverse teams need tools.
Interruptions
Agile teams have less meetings but
they need to report progress & issues to
team members & stakeholders.
Inspect & Adapt
At regular intervals, the team reflects on
how for be more effective, then more
efficient, this is central to being agile.
Scrum
Focus
Respect Openness
Courage Commitment

7. Development Comparison
DESIGN
CODE
INTEGRATE
TEST
DEPLOY
REQUIREMENTS
TIME
TIME
Process aren’t built for success, processes are built for
safety, and safety isn’t success ~Jeff Patton
Waterfall
Scrum
Highest Priority High Priority Medium Priority

8. Simplified Scrum Overview
3 Roles, 3 Artifacts, 5 Ceremonies
Requirements
Product Backlog
Sprint
Backlog
Sprint Planning
Sprint 1-4 Weeks
Daily Scrum
Retrospective
Sprint Review
Potentially Shippable Product
24 hrs.
01
02
03
04
05

9. The Agile Scrum Team
Scrum Team
Product Owner
ScrumMasterDevelopment Team
Stakeholders
Agile Coach
Scrum Team
Self organizing Development Team, & a
ScrumMaster, or the servant leader for the
team. The Product Owner determines what
to build, & prioritizing build features.
Agile Coach
Agile Coaches are responsible for the
process of Scrum, training, guidance &
leadership throughout the organization.
Stakeholders
Line of business leaders that work with the
Product Owner not directly with the team.
The people who do the work are the highest authorities about how best to do the work.
Project Team

10. Scrum Ceremonies
Sprint
Retrospective
Sprint Review
Daily Scrum
Sprint
Planning
1 Week 2 Weeks 3 Weeks 4 Weeks
2 hr
15 min
1 hr
.75 hr 1.5 hr
15 min 15 min 15 min
2 hr
4 hr
3 hr
6 hr
2.25 hr
4 hr
3 hr
8 hr
How much time should we allow?
Sprint Length

11. Team Time Spent on Scrum
Source: Scrumalliance.org
Daily Scrum
Sprint Retrospective
Sprint Review
Sprint Planning
Development
Time
Backlog Refinement 78.1%5%
2.5%
2.5%
10%
1.9%
People learn best by doing.

12. Understand Technical Debt
“Shipping first-time code is like going into debt.”
“Just as a business incurs some debt to take
advantage of a market opportunity developers
may incur technical debt to hit an important
deadline.”
“Quick-time to market & iterative development or
deployment involves technical debt, tools needed
to push/pull code quickly.”
“We don’t have
time for
design.”
“We must ship
now and deal
with the
consequences.”
“What’s
Layering?”
“Now we know
how we should
have done it.”
DELIBERATEINADVERTENT
PRUDENTRECKLESS
The faster you deliver, the more important QA and DevOps become.

13. 1
3
Sprint Reviews &
Release
Sprint Planning, Sprint
Reviews & *Daily Scrum
Initiates & Dictates
Product Changes
Sprint Reviews &
Releases
Daily Scrum, Sprint
Planning & Sprint
Reviews
Agile Feedback Loops
Scrum has several built-in feedback loops.

14. Human Nature, Egos & Politics…
We have to change the ways we traditionally communicate & challenge the status quo.
What do you see being communicated in
this picture?
Scrum is difficult, Scrum is disruptive,
that’s how you know you’re doing Scrum.
~Mark Layton
Body Language is 70% of
communications, as a team, you need to
communicate face-to-face first, then
Phone, then IM and as a last resort -
Email.

15. 5 Keys to Success
Conduct an implementation strategy
Build awareness & advertise internally
Identify pilot project that makes strategic sense
Train the team – more than once
Run sprints with a Certified Agile Coach
01
02
03
04
05

16. 5 Common Mistakes
Double Work Agile – doing Scrum & Waterfall
No formal training or workshops
An ineffective Product Owner
Tweaking & short-cuts – “death by 1000 cuts”
No professional transition support
01
02
03
04
05

17. Key Take-aways…
The Process is easy, People are Hard. ~Mark Layton
Brian Dreyer
• brian@watchdogent.com
• @Watchdog_Ent
• https://www.linkedin.com/in/bdreyer
Your ‘organization’ is perfectly engineered
to get the results you’re currently getting,
make a change.
Scrum as a framework is a system, and
systems only work when all the
components are present.