1

The New (Agile) Methodology

Martin FowlerChief Scientist, ThoughtWorks

www.martinfowler.com/articles/newMethodology.html

2

Code and Fix

» Still the most popular approach» Development builds features

– Little control over schedule– Frequent changes of requirements

» Painful test and integration– Hard to say when it ends

3

Methodology

» Bringing Engineering Discipline to software– Break projects down into stages– Control changes to requirements– Documentation

4

Is Methodology Considered Harmful?

» Bureaucracy– Lots of “pretty pictures”, but nothing that

works– Harder to change documentation

» Rigidity– Cannot change when need to– Deliver what customer asked for, but not

what customer needs.– Difficult to tune for specific project – even

with tailoring

5

Agile Methodologies

» New breed of methodologies that have discipline without bureaucracy

» E.g.: – XP (Extreme Programming)– Crystal / Highsmith ASD– Feature Driven Development– SCRUM– DSDM

6

A Meeting at Snowbird

» Alistair Cockburn» Jim Highsmith

» Kent Beck» Ward Cunningham» James Grenning» Ron Jeffries» Robert Martin

» Jon Kern

» Mike Beedle» Ken Schwaber» Jeff Sutherland

» Arie van Bennekum

» Andrew Hunt» Dave Thomas» Brian Marick» Steve Mellor» Martin Fowler

7

Agile Manifesto

Individuals and Interactions

over Process and Tools

Working Software

over Comprehensive Documents

Customer Collaboration

over Contract Negotiation

Responding to Change

over Following a Plan

We Value:

www.agileAlliance.org

8

Warning

» Agile methods are not for all projects– Still very new– Boundaries are not yet understood

» There’s a lot of zealotry about– Both positive and negative

9

What makes “light” right?

» Most people focus on “light”– i.e.: lack of documents and the processes

that create them» We think the priorities are

– Adaptivity– vs. predictivity

– People orientation– vs. process-orientation

10

The Engineering Metaphor

» Figure out what you need– Understand, stabilize, and sign off

requirements» Produced a detailed design

– UML or similar» Hand off to Construction

– Programming

11

Requirements Engineering

Requirements are the things that you should discover before starting to build your product. Discovering the requirements during construction, or worse, when you client starts using your product, is so expensive and so inefficient, that we will assume that no right-thinking person would do it, and will not mention it again.

Robertson and Robertson, Mastering the Requirements Process

12

Adaptivity

» Requirements aren’t stable– “Welcome changing requirements, even late

in development. Agile processes harness change for the customer's competitive advantage.”

13

Controlling Adaptivity: Iterations

AnalysisAnalysis DesignDesign CodingCoding TestingTesting

DD

AA CC

TT

DD

AA CC

TT

DD

AA CC

TT

14

Agile Iterations

» Delivering software is a key feedback mechanism– “Working software is the primary measure of

progress”» Short iterations and frequent delivery

– “Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale”

» Long term plans are fluid– “Welcome changing requirements, even late in

development. Agile processes harness change for the customer's competitive advantage”

15

The Agile Customer

» Agile development does not fit well with fixed-price / fixed scope– “Business people and developers must work

together daily throughout the project”» Customer needs to steer project

– Must be closely involved– Responsible for success or failure

16

People First

» Software is built by people: not by Plug Compatible Programming Units

» The methodology must fit your people, not vice-versa

» The people doing the work figure out how to do it best– “Build projects around motivated

individuals. Give them the environment and support they need, and trust them to get the job done”

17

Self-Adaptive Process

» The process you start with shouldn’t be the one you finish with

» Review process regularly» Everyone is involved in evolution

18

Principles (1)

» Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.

» Working software is the primary measure of progress

» Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.

19

Principles (2)

» Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.

» Business people and developers must work together daily throughout the project.

» The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.

20

Principles (3)

» Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.

» Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely.

» The best architectures, requirements, and designs emerge from self-organizing teams.

21

Principles (4)

» Continuous attention to technical excellence and good design enhances agility.

» Simplicity--the art of maximizing the amount of work not done--is essential.

» At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

22

XP (Extreme Programming)

» Developed by Kent Beck– Based on Smalltalk projects in the 90’s– Collaboration with Ward Cunningham

» First “done” on C3– Smalltalk Payroll system for Chrysler

» Now an informal community– Ron Jeffries, Robert Martin, Chet

Hendrickson, Jim Newkirk, Don Wells, Ken Auer, Bill Wake…

23

XP Practices

Metaphor

CollectiveOwnership

CodingStandard

40 HourWeek

ContinuousIntegration

On-SiteCustomer

Planning Game

Acceptance Tests

SimpleDesign

PairProgramming

Test-First Design

Refactoring

Small Releases

The Jeffries Model

24

XP Values

» Communication– Rich informal networks of communication

» Feedback– Build in a rich set of feedback loops so we

know where we are» Simplicity

– Try the simplest things that could possibly work

» Courage– Play to win

25

Balance of PowerCustomer» Itemize “stories”

(features) of useful function

» Decide on business value of stories

» Prioritizes stories » Defines acceptance

tests for stories» Can change plan at

any time

Programmers» Provides estimates for

stories» Builds the function » Maintains high quality

at all times» Sustainable pace

Business people make business decisionsTechnical people make technical decisions

26

Boundary Conditions

» Size– Up to 20 developers

» Location– Co-located team

» Requirements– Volatile or not well understood

» Acceptance– All involved must want to use it

27

SCRUM

» Developed by several people in the patterns community– Mike Beedle, Martine Devos, Yonat Sharon,

Ken Schwaber, Jeff Sutherland» Planning process based around short

agile iterations– Scrummers often use XP’s

design/development practices

28

SCRUM’s Sprints

» Scrum iterations are called sprints– Usually around 30 days

» During sprint requirements are fixed for that sprint

» Produces working software with Demo at end

» Team chooses appropriate process for sprint

29

SCRUM: Backlog

» Prioritized list of work items» Backlog may change continuously» Only one person controls backlog» Sprint team selects items from backlog to

do in next sprint– Sprint team chooses what it thinks it can

achieve in collaboration with backlog manager

» Multiple sprint teams may work off one backlog

30

SCRUM meetings

» Short Daily Meeting– ~15 minutes

» Whole sprint team attends, plus outsiders– Pigs and Chickens

» Topics– What did you do since last scrum?– What are your blocks?– What will you be doing in next 24 hours?

31

Highsmith / Cockburn

» Recent union of two methodologists» Alistair Cockburn

– Crystal Family» Jim Highsmith

– Adaptive Software Development

32

Crystal Family

People

Comfort

Essentialmoney

Life

1 - 6 - 20 - 40 - 100 - 200 - 500 - 1,000

C6 C20 C40 C100 C200 C500 C1000

D6 D20 D40 D100 D200 D50 D1000

E6 E20 E40 E100 E200 E500 E1000

L6 L20 L40 L100 L200 L500 L1000

Discretionarymoney

Cri

ticality

Family of Methodologies tuned to team size and criticality

33

The Tolerant Crystal

» Observing Methodology Use– The people on the projects were not interested in

learning our system. – They were successfully able to ignore us, and were

still delivering software, anyway» Strong People Orientation

– People are communicating beings, doing best face-to-face.

– People have trouble acting consistently over time. – People are highly variable.– People generally want to be good citizens.

What is the sloppiest methodology that could work?

34

Shrink to Fit

» At project start team chooses its own methodology following Crystal guidelines– Talk to people about previous projects, and

company culture» Review process at end of every iteration

– What’s working?– What can we do better?– What puzzles us?– Also review mid way if more than 3 weeks

35

Highsmith’s ASD

» ASD = Adaptive Software Development» Primarily a philosophy underpinning agile

development approaches» Adaptive Cycle

– Speculate– Collaborate– Learn

36

Feature Driven Development

» Developed by Peter Coad and Jeff de Luca at TogetherSoft

37

FDD: Five Processes

» Initial Processes– Develop an Overall Model – Build a Features List – Plan by Feature

» Iterative Processes– Design by Feature – Build by Feature

38

FDD: Team Organization

» Multiple Teams– Features assigned to chief programmer

» Chief Programmer– Responsible for overall design of feature– Gathers class owners to work on feature– Coordinates and mentors class owners

» Class Owners– Work on particular classes

39

DSDM

» Dynamic Systems Development Method» Originated in the UK

– Consortium of end user and IT development organizations

– Spreading across Europe and into the US» Many ‘serious’ methodology trappings

– Detailed manuals– Accreditation and training

40

DSDM: Basic processes

» Feasibility and Business Study» Functional Model Iteration

– Modeling and prototyping» Design and Build Iteration

– Evolutionary build with integrated testing» Implementation

– Handover from development to operations» Each process is one or more iteration

– Up to six weeks in length– Carry out in any order

41

RUP ?

» Rational Unified Process– Developed by Rational Software led by

Philippe Kruchten– Really a process framework

» Large Process– Many artifacts and roles– Process and tool oriented

» Needs a lot of trimming to be agile– Robert Martin: dX– Craig Larman: Agile UP

42

Final Thoughts

» New Breed of Methodology» Suited for some kinds of software

development– Volatile environments

» Early days– Boundary conditions not well understood

» More in common than differences– Lots of inter-method borrowing