From Waterfall to Agile - from predictive to adaptive methods

  • View
    1.741

  • Download
    1

  • Category

    Business

Preview:

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)

Recommended