In this introduction into Agile methods, the background and environment of Software Development is discussed. Results of the 1995 Chaos report are mentioned, as well as interests in adaptive "lightweight" methods. Agile methods are explained in general and Scrum method taken as a concrete sample.

1. From Waterfall to Agile &
touching on Scrum
From predictive to adaptive methods
December 2010
Björn Brynjar Jónsson

2. From Waterfall

3. 1970Winston Royce introduces the Waterfall model
“I am going to describe my personal views about managing large
software developments. I have had various assignments during
the past nine years..”, Winston Royce (1970)

4. Underlying Assumption

5. Underlying Assumption
Predictability

6. Underlying Assumption
Predictability
(low) uncertainty - project estimates are within
fixed boundary set by the golden triangle

7. Underlying Assumption
Predictability
(low) uncertainty - project estimates are within
fixed boundary set by the golden triangle
Does this assumption hold for all IT Projects?

8. Underlying Assumption
Predictability
(low) uncertainty - project estimates are within
fixed boundary set by the golden triangle
Does this assumption hold for all IT Projects?
Is this assumption in place in your field?

9. Underlying Assumption
Predictability
(low) uncertainty - project estimates are within
fixed boundary set by the golden triangle
Does this assumption hold for all IT Projects?
Is this assumption in place in your field?
Does it hold for projects all in our field?

10. 1995
The Chaos Report

11. 31 of IT Projects cancelled
%
Cancelled
31%
Not Cancelled
69%

12. 53% will cost over 189% of original estimates
189% Overbudget
190
143
47%
53% 95
48
0

13. 16% on time and on budget
On time
On budget
16%
Not on time
Not on budget
84%

14. Large Organizations even worse On time
On budget
9%
Not on time
Not on budget
91%
Features complete 42
0 50 100

15. Small Organizations are better On time
On budget
22%
Projects complete
and put in use 78%
Features complete 72
0 50 100

16. Two questions:
Why do IT projects fail?
What makes them successful?

17. Why do IT projects fail?
Lack of User Input
Incomplete Requirements
Changing Requirements
Lack of Executive Support
Technology incomplete
Lack of Resources
Unrealistic Expectations
Unclear Objectives
Unrealistic Time Frames
New Technology

18. What makes them successful?
User Involvement
Executive Support
Clear Requirements
Proper Planning
Realistic Expectations
Smaller Project Milestones
Competent Staff
Ownership
Clear VIsion & Objectives

19. Highly Complex Environment
-Concrete Examples-
“Adding manpower to a late software project
makes it later”, Frederick Brooks (1975)
Furthermore
• Detailed Requirements are difficult to capture upfront
• Requirements change after project is started
• New technologies appear and old loose ground quickly

20. Bridge metaphor
“..in today's fast moving business environment, a frozen
design does not accommodate changes in the business
practices. Therefore a more flexible model must be used.

21. to Agile

22. 1995+ lightweight methods resurface
SCRUM
eXtreme
DSDM
Programming
Feature Lean Adaptive
Software Software Crystal
Driven
Development Development Clear
Development

23. Feb2001 Snowbird ski resort in mountains of Utah
“..seventeen people met to talk, ski, relax, and try to find common ground.. .What
emerged was the Agile Software Development Manifesto. Representatives from
Extreme Programming, SCRUM, DSDM,Adaptive Software Development, Crystal,
Feature-Driven Development, Pragmatic Programming, and others sympathetic to
the need for an alternative to documentation driven, heavyweight software
development processes convened.”, www.agilemanifesto.org

24. Agile Software Development 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.

25. Principles behind theAgile Manifesto
Working software is the primary measure Simplicity--the art of maximizing the
of progress. amount of work not done--is essential.
Agile processes promote sustainable
development. The sponsors, developers, The best architectures, requirements, and
and users should be able to maintain a designs emerge from self-organizing teams.
constant pace indefinitely.
At regular intervals, the team reflects on how to
Continuous attention to technical excellence
become more effective, then tunes and adjusts
and good design enhances agility.
its behavior accordingly.

26. Principles behind theAgile Manifesto
Our highest priority is to satisfy the
Business people and developers must work
customer through early and continuous
together daily throughout the project.
delivery of valuable software.
Welcome changing requirements, even late in Build projects around motivated individuals.
development. Agile processes harness change Give them the environment and support they
for the customer's competitive advantage. need, and trust them to get the job done.
Deliver working software frequently, from a The most efficient and effective method of
couple of weeks to a couple of months, with a conveying information to and within a
preference to the shorter timescale. development team is face-to-face conversation.

27. Visually Agile Development

28. Key CharacteristicssuccessfulAgile Projects share
Releases and
Fixed length
iterations
Small,Cross Running,tested
functionalTeams software
Emergent
Value Driven
Feature
Development
Discovery
Continuous
Adaptive Planning

29. Underlying Assumption

30. Underlying Assumption
Adaptability

31. Underlying Assumption
Adaptability
uncertainty is part of the environment,
adapting to change rather than follow a plan

32. Underlying Assumption
Adaptability
uncertainty is part of the environment,
adapting to change rather than follow a plan
Are projects in your field that would benefit from making
this assumption rather than assuming predictability?

33. Difference
between predictive and adaptive methods worth noting

34. touching on Scrum

35. Scrum Process

36. Scrum Roles
Scrum Team
• 5-10 people
• Cross Functional Team
• Self organizing
• Team commits to deliver sprint goals
Scrum Master
• Facilitates the Scrum process
• Manages daily Scrum meetings
• Works with management
• Removes impediments to progress
• Protects team from outside
Product Owner
• Key stakeholder
• Represents users, customers and other stakeholders
• Defines requirements in collaboration with other stakeholders
• Prioritizes the Product Backlog (requirements)

37. Scrum Roles

38. Scrum Process
Sprint
Planning
Meeting
Sprint
Review Sprint
Meeting
Daily
Scrum

39. Sprint
Planning
Meeting
Sprint planning Sprint
Review
Meeting
Daily
Scrum
Sprint
Collaborative meeting to kickoff each Sprint
First Part:
• Determine Sprint Goals
• Review the Product Backlog
• Clarify Requirements and Reestimate effort
• In details what is planned to be complete?
• Participants: Product Owner, Scrum Master, Scrum Team
Second Part
• Create the sprint backlog
• What Stories can realistically be complete at the Sprint end?
• Team commits to completing all tasks they estimate can be completed
• Participants: Product Owner, Scrum Master, Scrum Team

40. Sprint
Planning
Meeting
Sprint Sprint
Review
Meeting
Daily
Scrum
Sprint
Team collaboratively works towards fulfilling Sprint Goals
• Sprint Duration 2-4 weeks
• Team is committed to completing all tasks rather than individuals members
• Team is protected from outside disturbances
• Sprint Starts with Sprint planning
• Sprint delivers product functionality in small increments
• Sprint ends with Sprint Review and Sprint Retrospective

41. Sprint
Planning
Meeting
Daily Scrum meeting Sprint
Review
Meeting
Daily
Scrum
Sprint
Short 15minutes meeting held every day
• Participants: Scrum Master, Team, (and Product Owner)
• Every team member answers 3 questions:
• What did you do since last Scrum meeting?
• What are you going to do until next Scrum meeting?
• What is stopping you from getting on with the work?
• The meeting is all about keeping everyone up to date on what is being worked on
• Identifies questions, issues to be resolved

42. Sprint
Planning
Meeting
Sprint review meeting Sprint
Review
Meeting
Daily
Scrum
Sprint
• Demonstration of Business Value created during the sprint
• Is held at the end of each Sprint
• Participants: Scrum Team, Scrum Master, Product Owner (any interested stakeholder)
• Typically takes 1 hour
• Team members themselves present the demo
• Answer questions about implementation details
• Often discussions about next steps, what to improve. New tasks added to backlog
• The review meeting if typically followed by a Sprint Retrospective meeting

43. tracking Progress
using Burndown charts

44. Question and Questions
Can methods that stress Adaptability over
Predictability work in your environment?

45. References
Wikipedia
http://en.wikipedia.org/wiki/Agile_software_development
http://en.wikipedia.org/wiki/Winston_W._Royce
http://en.wikipedia.org/wiki/Waterfall_model
http://en.wikipedia.org/wiki/Fred_Brooks
http://en.wikipedia.org/wiki/Brooks's_law
Standish Group
http://www.it-cortex.com/Stat_Failure_Rate.htm
Other
http://agilemanifesto.org
http://www.versionone.com/Agile101/Agile_Hallmarks.asp
Þorvaldur Örn Arnarsson (MPM 2009)