1. The New (Agile) Methodology
Martin Fowler
Chief Scientist, ThoughtWorks

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 We Value: Individuals and Interactions
Process and Tools
over
Working Software
Comprehensive Documents
over
Customer Collaboration
Contract Negotiation
over
Responding to Change
Following a Plan
over

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
Analysis
Design
Coding
Testing D A C T D A C T D A C T

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 The Jeffries Model Metaphor Collective Ownership Coding
Standard
40 Hour
Week
Continuous
Integration
On-Site Customer
Planning
Game
Acceptance
Tests
Simple
Design
Pair
Programming
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 Power Business people make business decisions
Customer
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 decisions
Technical 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. Family of Methodologies tuned to team size and criticality
Crystal Family
Family of Methodologies tuned to team size and criticality
People
Comfort
Essential
money
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
Discretionary
Criticality

33. What is the sloppiest methodology that could work?
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