Embed Size (px)
DESCRIPTION
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.
Citation preview
From Waterfall to Agile & touching on Scrum
From predictive to adaptive methodsDecember 2010
Björn Brynjar Jónsson
From Waterfall
1970 Winston 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)
Underlying Assumption
Underlying Assumption
Predictability
Underlying Assumption
Predictability(low) uncertainty - project estimates are within fixed boundary set by the golden triangle
Underlying Assumption
Predictability(low) uncertainty - project estimates are within fixed boundary set by the golden triangle
Does this assumption hold for all IT Projects?
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?
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?
The Chaos Report
1995
31% of IT Projects cancelled
69%
31%
Not Cancelled
Cancelled
53% will cost over 189% of original estimates
47%53%
189% Overbudget
0
48
95
143
190
16% on time and on budget
84%
16%
Not on timeNot on budget
On timeOn budget
Large Organizations even worse
91%
9%
Not on timeNot on budget
On timeOn budget
0 50 100
42Features complete
Small Organizations are better
78%
22%Projects complete
and put in use
On timeOn budget
0 50 100
72Features complete
Two questions:
Why do IT projects fail?What makes them successful?
Why do IT projects fail?
Lack of User InputIncomplete Requirements
Changing Requirements
Lack of Executive Support
Technology incomplete
Lack of ResourcesUnrealistic Expectations
Unclear Objectives
Unrealistic Time Frames
New Technology
What makes them successful?
User InvolvementExecutive Support
Clear Requirements
Proper PlanningRealistic Expectations
Smaller Project Milestones
Competent StaffOwnership
Clear VIsion & Objectives
Highly Complex Environment
“Adding manpower to a late software project makes it later”, Frederick Brooks (1975)
• Detailed Requirements are difficult to capture upfront
• Requirements change after project is started
• New technologies appear and old loose ground quickly
-Concrete Examples-
Furthermore
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.
to Agile
SCRUM
eXtremeProgramming
DSDM
CrystalClear
Feature Driven
Development
Lean Software
Development
Adaptive Software
Development
1995+ lightweight methods resurface
Feb 2001 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
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.
Principles behind the Agile Manifesto
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts
its behavior accordingly.
Principles behind the Agile Manifesto
Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change
for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a
preference to the shorter timescale.
Business people and developers must work together daily throughout the project.
Build projects around motivated individuals. Give them the environment and support they
need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a
development team is face-to-face conversation.
Visually Agile Development
Key Characteristics successful Agile Projects share
Releases and Fixed length iterations
Running, tested software
Value Driven Development
Continuous Adaptive Planning
Small, Cross functional Teams
Emergent Feature
Discovery
Underlying Assumption
Underlying Assumption
Adaptability
Underlying Assumption
Adaptabilityuncertainty is part of the environment, adapting to change rather than follow a plan
Underlying Assumption
Adaptabilityuncertainty 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?
Differencebetween predictive and adaptive methods worth noting
touching on Scrum
Scrum Process
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)
Scrum Roles
Scrum Roles
Scrum Process
Sprint Planning Meeting
Sprint
Daily Scrum
Sprint Review Meeting
Sprint Planning Meeting
Sprint
Daily Scrum
Sprint Review Meeting Sprint planning
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
SprintTeam 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
Sprint Planning Meeting
Sprint
Daily Scrum
Sprint Review Meeting
Daily Scrum meeting
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
Sprint Planning Meeting
Sprint
Daily Scrum
Sprint Review Meeting
Sprint review meeting
• 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
Sprint Planning Meeting
Sprint
Daily Scrum
Sprint Review Meeting
tracking Progressusing Burndown charts
Can methods that stress Adaptability over Predictability work in your environment?
Question and Questions
ReferencesWikipedia
http://en.wikipedia.org/wiki/Agile_software_developmenthttp://en.wikipedia.org/wiki/Winston_W._Roycehttp://en.wikipedia.org/wiki/Waterfall_modelhttp://en.wikipedia.org/wiki/Fred_Brookshttp://en.wikipedia.org/wiki/Brooks's_law
Standish Grouphttp://www.it-cortex.com/Stat_Failure_Rate.htm
Otherhttp://agilemanifesto.orghttp://www.versionone.com/Agile101/Agile_Hallmarks.aspÞorvaldur Örn Arnarsson (MPM 2009)
