Loading presentation...

Present Remotely

Send the link below via email or IM


Present to your audience

Start remote presentation

  • Invited audience members will follow you as you navigate and present
  • People invited to a presentation do not need a Prezi account
  • This link expires 10 minutes after you close the presentation
  • A maximum of 30 users can follow your presentation
  • Learn more about this feature in our knowledge base article

Do you really want to delete this prezi?

Neither you, nor the coeditors you shared it with will be able to recover it again.


Agile Scrum v/s Waterfall

No description

Stephen Phillips

on 30 May 2014

Comments (0)

Please log in to add your comment.

Report abuse

Transcript of Agile Scrum v/s Waterfall

Two Laws of Development
Requirements are always

Software is never

Tame complexity
Improve quality
Reduce Cost
Increase Speed
Enable Forecasting
Long Term Planning
The first formal description of the waterfall model is often cited as a 1970 article by Winston W. Royce,although Royce did not use the term "waterfall" in this article. Royce presented this model as an example of a flawed, non-working model.
"I believe in this concept, but the implementation described above is risky and invites failure."
Managing the Development of Large Software Systems; Royce, Dr. Winston W.
To truly capture the full complexity of the software requires a larger effort than creating the software.
Because it is nearly impossible to accurately estimate the full extent of a project at start, change requests become the rule instead of the exception.
Large amount of time and energy is wasted creating and developing to requirements that are irrelevant by the time the software is released.
Waterfall treats software development like an assembly line
When in reality it is much more like research and development
The Waterfall model originated in the manufacturing and construction industries
Roots in Lean manufacturing principles
Expects Change
Empirical - source of knowledge acquired by means of observation or experimentation. From the Greek word for experience.
Agile Manifesto
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
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.
Types of Agile
Why is it Called Scrum?
Hirotaka Takeuchi and Ikujiro Nonaka published a study called "The New New Product Development Game" in the Harvard Business Review 1986
Used a rugby team as a example of how to make software development teams operate more effectively
Teams should work together to reach a common goal as opposed to the traditional sequential approach.
Doesn't mention the word Scrum
Says team members fit together like pieces of a puzzle
Jeff Sutherland found this article in 1993 when trying to 'fix' his development process. He called his new process Scrum.
Ken Schwaber developed a similar process independently at his company.
The 2 worked together to codify Scrum and presented it at OOPSLA in 1995.
Product Owner
Works with the customer to determine requirements
Defines and prioritizes the Product Backlog
Ultimately responsibility for success or failure
Product evangelist
Single source for requirements
Ordered by priority
Always changing/never complete
Created and ordered by the Product Owner
Estimated by the team
The Team
Cross functional
Small: 3-9 members
Generally full time on the team
Self organized
No titles
Members only change between sprints (if at all)
Choose the Sprint Backlog
Build the software

Set of Product Backlog items chosen for a sprint
Controlled by the Team in negotiation with the Product Owner
Not changed during sprint (except under special circumstances and only by the
Scrum Master
Enacts and enforces scrum values and practices
Facilitates meetings
Keeps things running smoothly
Removes Impediments
Shields team from external interference
Timebox of 2 to 4 weeks
A done increment is created that is useable and potentially releasable
Length cannot change within sprint
Ensures inspection and adaptation of progress
Limits risk to one timebox worth of cost
It is called a sprint because it is short
Pace should be sustainable indefinitely
Each Sprint will have a Sprint Goal which is the overall objective of the sprint
Burn Down/Burn Up
Sum of all product Backlog items completed during a sprint combined with all work from previous sprints.
Must be done and meet definition of "Done" (DoD)
Useable regardless of whether PO decides to actually release
Each project has its own DoD
DoD is expected to get more stringent as teams mature
A Sprint can be canceled while in progress
Only by the product owner
If it no longer makes sense
Company changes directions
Market or technology conditions change
If it is no longer possible to reach the sprint goal
Rarely ever happens
Timeboxed to 15min
Always at the same time and place
Answer 3 questions
What did I do yesterday?
What will I do today?
Do I have or see any impediments?
If anything needs to be discussed further it happens offline or at another meeting.
Not a status update for the SM or PO, this is a self organizational process for the team
Timeboxed to 8hrs or less
Team takes items from the top of the Product Backlog to create the Sprint Backlog
Estimations performed as required
PO may negotiate
Team and PO determine the Sprint Goal
Team decomposes and plans out first section of work
Timeboxed to 4 hours or less
Attendees include the scrum team, SM, PO and stakeholders invited by the PO
"Done" work is demoed
No slides and no partially completed work are presented
Future goals and new requirements may be discussed
His son Walker Royce was VP of Rational and now IBM's Rational Lab.
Timeboxed to 3 hours or less
Inspect how the Sprint went: people, relationships, process, and tools
Scrum Master participates in this meeting instead of just facilitating
Identify items that went well and potential improvements
Create a plan for implementing improvements
Estimation/Backlog Refinement/Grooming
Usually not more than 10% of team's time
Sprint Review/Demo
Agile v/s Waterfall
The CHAOS Manifesto 2012 by the Standish Group shows that Agile projects are three times more successful than Waterfall projects. The CHAOS Manifesto was based on data collected from 2002-2010.
Building a House
Waterfall is like having your house built from blueprints while you are on an extended business trip in another country.
Agile is like living in or near your house as it is being built.
Full transcript