The New (Agile) Methodology Martin Fowler Chief Scientist, ThoughtWorks www.martinfowler.com/articles/newMethodology.html

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

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

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

Agile Methodologies New breed of methodologies that have discipline without bureaucracy E.g.: XP (Extreme Programming) Crystal / Highsmith ASD Feature Driven Development SCRUM DSDM

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

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 www.agileAlliance.org

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

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

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

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

Adaptivity Requirements aren’t stable “Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.”

Controlling Adaptivity: Iterations Analysis Design Coding Testing D A C T D A C T D A C T

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”

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

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”

Self-Adaptive Process The process you start with shouldn’t be the one you finish with Review process regularly Everyone is involved in evolution

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.

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.

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.

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.

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…

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

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

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

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

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

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

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

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?

Highsmith / Cockburn Recent union of two methodologists Alistair Cockburn Crystal Family Jim Highsmith Adaptive Software Development

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

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?

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

Highsmith’s ASD ASD = Adaptive Software Development Primarily a philosophy underpinning agile development approaches Adaptive Cycle Speculate Collaborate Learn

Feature Driven Development Developed by Peter Coad and Jeff de Luca at TogetherSoft

FDD: Five Processes Initial Processes Develop an Overall Model Build a Features List Plan by Feature Iterative Processes Design by Feature Build by Feature

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

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

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

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

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