agile methods - an overview - marc bless - 2009

Agile Methods – An Overview

Marc Bless Sept 25th 2009

Table of Contents

•  Mo@va@on •  History of Agile Methods •  The Agile Manifesto •  Overview: SCRUM and FDD •  How we do it @ MCC

Agile Methods – An Overview Marc Bless, Sept 25th 2009

Mo@va@on: Why Agile?

•  65% of all product features are hardly ever used •  65% of projects fail due to requirement issues

•  waterfall does not take this into account Source: Standish Group, Jeff Sutherland


Mo@va@on: Why Planning Fails

•  Planning is by ac@vity rather than feature –  Ac@vi@es do not finish early –  Lateness is passed down the schedule –  Ac@vi@es are not independant


Do this Do that

Do something Plan:

Do this Do that

Do something Lateness:


•  Mul@tasking causes further delays •  Features are not developed by priority •  We ignore uncertainty •  Es@mates become commitments


Do something Plan:

Do something

Mul@tasking: Do something

Lateness:


•  Developing so\ware is not building a house:


Developing So,ware Building a House

Time for Architecture All during development Short period at the beginning

Resources needed for architecture

Highly skilled Highly skilled

Time to Implement/Build

All during development Long period

Resources needed to implement/build

Highly skilled Low skilled, thus exchangable

Type of work Crea@ve thinkers Strong workers

Mo@va@on: Why Planning Fails •  Resul@ng Project Reality:


Plan:

Test

Design Implement

Test

Design Implement

Real:

Solu@on: feature by priority

Es@mated and commiaed date

Done and releasable

Done and releasable

Final Release

Agile is NOT •  No documents

•  No planning

•  No control

•  Anarchy


History of Agile Methods •  Ōno Taiichi, 1947: „Kanban“-‐System at Toyota, Japan

•  Frederick Brooks, 1960s: „The Mythical Man-‐Month“ –  Gutless es@ma@ng: based on op@mism and is wish-‐

derived –  Surgical team: architect, developer, editor, tester,

toolsmith are ONE team –  First ideas of modern pair programming: two brains

do beaer than one –  Stop sequen@al phases: crea@ve effort involves

dis@nct phases which can start in parallel (design, implementa@on, tes@ng)

•  1976, Tom Gilb: „evolu@on“ and „evolu@onary“


History of Agile Methods

•  1996 Kent Beck: Extreme Programming


•  1995 Ken Schwaber, Jeff Sutherland: Scrum

•  1995 Alistair Cockburn: Crystal Clear

History of Agile Methods •  2000, Jim Highsmith: Adap@ve So\ware Development •  1997, Jeff De Luca: Feature Driven Development •  1995: DSDM (Dynamic Systems Development Method) •  2001: The Agile Manifesto •  2005, Scoa Ambler: AUP (Agile Unified Process = „Agile RUP“)


The Agile Manifesto We are uncovering beaer ways of developing so\ware by doing it and helping others do it. Through this work we have come to value:

Individuals and interacCons over processes and tools

Working so,ware over comprehensive documenta2on Customer collaboraCon over contract nego2a2on

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 le\ more.


Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Mar@n Fowler James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick

Robert C. Mar@n Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas

© 2001, the above authors this declara@on may be freely copied in any form, but only in its en@rety through this no@ce.

The Seven Core Prac@ces of Agile Work

•  Self-‐Organizing Team à Whole Team (XP), Cross-‐Func@onal Team •  Deliver Frequently à Sprint, Itera@on, Timeboxing •  Plan to Learn à Inspect and Adapt, Adap@ve Planning •  Communicate Powerfully à Visibility, Whole Team and Team Room, War

Room •  Test Everything à Test-‐Driven Development •  Measure Value à Measuring Results, ROI, Running Tested Features •  Clear the Path à Removing Obstacles and Impediments, Stopping the Line

•  hap://www.agileadvice.com/archives/2006/09/prac@ces_of_ag.html

è Deming-‐Circle PDCA: Plan, Do, Check, Act


Agile Principle: Timeboxing •  Focus on doing the things that maaer most

•  Limit the @me spent on open ended tasks

•  Effec@ve tool against procras@na@on

è higher efficiency (more business value per @me)

•  Cri@cs: how to deal with tasks not being finished in a @mebox?


Agile Principle: Inspect and Adapt •  Con@nuos improvement of knowledge and processes

•  Based on „Lean“

•  Con@nous Deming-‐Circle PDCA: Plan, Do, Check, Act

•  Most important goal: remove any impediment instantly

è Higher efficiency and quality


Agile Principle: Pair Programming •  Knowledge transfer

•  Collec@ve code ownership

•  Less bugs

•  Implicit code review

è higher quality



FDD (30++)

•  Develop Overall Model •  Form Modeling Team •  Conduct Domain Walk-‐Through •  Study Documents •  Develop Small Group Models •  Develop Team Model •  Refine Overall Object Model •  Write Model Notes •  Build Feature List •  Form Features List Team •  Build Features List •  Plan by Feature •  Form Planning Team •  Determine Development Sequence •  Assign Business Ac@vi@es to Chief Programmers •  Assign Classes to Developers

•  Build by Feature •  Implement Classes and Methods •  Inspect Code •  Coduct Unit Tests •  Promote to Build •  Design by Feature •  Form Feature Team •  Conduct Domain Walk-‐Through •  Study Referenced Documents •  Develop Sequence Diagrams •  Refine Object Model •  Write Class and Method Prologue •  Design Inspec@on

Methods Compared

FDD: Overview •  1997 by Jeff De Luca •  Mixture of waterfall and itera@ve method

•  5 ac@vi@es with 24 sub-‐ac@vi@es, lots of roles, lots of ar@facts


Develop Overall Model

Build Feature List

Plan by Feature

Design by Feature

Build by Feature

Design by Feature

Build by Feature

Design by Feature

Build by Feature

Scrum: Overview •  1995, Jeff Sutherland & Ken Schwaber: Scrum


Scrum: Roles, Ac@vi@es, Ar@facts

Scrum

Roles

Product Owner

Scrum Master

Team

AcCviCes

Sprint Planning

Daily Stand-‐up Mee@ng

Sprint Review

Sprint Retrospec@ve

ArCfacts

Product Backlog

Sprint Backlog

Impediments Backlog

Burndown Chart

Working So\ware


The Scrum Board


Source: Henrik Kniberg

Scrum: Hyperproduc@ve Teams




Slow Upset Late

Pressure

Fast Happy Early

Improve



Constraints

Energy

Slow Upset Late

Pressure

Fast Happy Early

Improve



Constraints

Energy

Hyperproduc@ve teams can output 300% more results in the same @me in a much higher quality! This is proven by many case studies in the last years.

(Source: Jeff Sutherland)

Slow Upset Late

Pressure

Fast Happy Early

Improve

The V-‐Model Issue


•  V-‐Model: waterfall approaches are slow, late, unpredictable, and have low ROI

•  Standards (e.g. IEC 62304) do not imply the V-‐Model: any incremental and evolu@onary development process may be used

è huge organiza@onal changes are mandatory!

Bibliography Highly recommended!

•  Henrik Kniberg – Scrum and XP… •  Mike Cohn – Agile Es@ma@ng and Planning •  agilemanifesto.org


Bibliography •  Frederick Brooks – The Mythical Man Month •  Ken Schwaber – Agile Project Management With

Scrum •  Kent Beck – Test-‐Driven Development by Example •  Kent Beck – Extreme Programming explained: Embrace

Change •  Mar@n Fowler, Kent Beck – Refactoring: Improving the

Design of Exis@ng Code


[email protected] @marcbless

Marc Bless Sept 25th 2009

agile methods - an overview - marc bless - 2009

Business

agile rup agile methods

commitments agile methods

onary agile methods

mcc agile methods

independant agile methods

agile manifesto overview

overview marc

je sutherland agile