Agile Software Agile Software DevelopmentDevelopment

An Alternate ApproachAn Alternate Approach

Umar K. MunroeUmar K. MunroeMSCS CandidateMSCS Candidate

Union CollegeUnion College

1/9/20041/9/2004

Topics of DiscussionTopics of Discussion

Why an alternate approachWhy an alternate approach Overview of Agile Software Overview of Agile Software

DevelopmentDevelopment Agile ProcessesAgile Processes Limitations of Existing Agile Limitations of Existing Agile

ProcessesProcesses Adoption & Future in IndustryAdoption & Future in Industry

Why an alternate software Why an alternate software development approach?development approach?

Traditional Approaches Traditional Approaches Slow & Slow & RigidRigid Highly structuredHighly structured Detailed process scriptsDetailed process scripts Required Artifacts (i.e. documents)Required Artifacts (i.e. documents)

Why an alternate software Why an alternate software development approach?development approach?

Internet & mobile technology increase Internet & mobile technology increase demand for software development todemand for software development to to be faster to be faster more responsive to changemore responsive to change

Traditional methods aren’t exactly Traditional methods aren’t exactly working wellworking well 13,522 IT projects (Standish Group, 2002)13,522 IT projects (Standish Group, 2002)

34% on-time, on-budget, sufficient functionality34% on-time, on-budget, sufficient functionality 51% late, over-budget, less functionality51% late, over-budget, less functionality 15% fail15% fail

Agile Software DevelopmentAgile Software Development

Quick developmentQuick development Responsive to changing Responsive to changing

requirementsrequirements Simple, straightforward processSimple, straightforward process Frequent customer involvement and Frequent customer involvement and

feedbackfeedback Guide developmentGuide development

Iterative, incremental developmentIterative, incremental development Provides flexibility, responsivenessProvides flexibility, responsiveness

Agile AllianceAgile Alliance

In 2001, software industry experts In 2001, software industry experts formed the Agile Allianceformed the Agile Alliance

Goals:Goals: Outline values and principles of agile Outline values and principles of agile

software developmentsoftware development Promote agile software development in Promote agile software development in

industry industry http://http://www.agilealliance.orgwww.agilealliance.org

Agile ManifestoAgile Manifesto

Value #1: Individuals and Value #1: Individuals and interactions interactions over process and over process and

toolstools ““A good process will not save the A good process will not save the

project from failure if the team project from failure if the team doesn’t have strong players, but a doesn’t have strong players, but a bad process can make even the bad process can make even the strongest of players ineffective.” strongest of players ineffective.” Robert Robert C. MartinC. Martin

people and their relationships most people and their relationships most important to a successful projectimportant to a successful project

Value #1: Individuals and Value #1: Individuals and interactions interactions over process and over process and

toolstools TeamTeam

motivated motivated good programmers (not necessarily good programmers (not necessarily

most talented)most talented) excellent communication skills excellent communication skills

Tools and environment built around Tools and environment built around team, not vice versateam, not vice versa

Value #2: Working software over Value #2: Working software over comprehensive comprehensive

documentation documentation Documentation produced only when Documentation produced only when

necessarynecessary Short – one or two dozen pages at most Short – one or two dozen pages at most

Less timeLess time Salient – describing the overall design rationale Salient – describing the overall design rationale

and only high level structures in the system and only high level structures in the system Details likely to changeDetails likely to change

Primary goal is working softwarePrimary goal is working software Demonstrated to customer frequentlyDemonstrated to customer frequently Measure of progressMeasure of progress

Value #3: Customer collaboration Value #3: Customer collaboration over over contract negotiation contract negotiation

"A contract that specifies the "A contract that specifies the requirements, schedule, and cost of a requirements, schedule, and cost of a project is fundamentally flawed." project is fundamentally flawed." Robert C. Robert C.

MartinMartin

Contracts govern the working Contracts govern the working relationship between developers and relationship between developers and customercustomer

Customer is intimately involved Customer is intimately involved Guide developmentGuide development

Value #4: Responding to change Value #4: Responding to change over over following the plan following the plan

Change is expectedChange is expected

Planning Strategy (iterative)Planning Strategy (iterative) a detailed plan over the next 2 weeksa detailed plan over the next 2 weeks a very rough plan for the next 3 monthsa very rough plan for the next 3 months an extremely crude plan beyond 3 an extremely crude plan beyond 3

months months

Minimize time wasted planning too far Minimize time wasted planning too far into the futureinto the future

Agile ProcessesAgile Processes

Typically,Typically, Less structuredLess structured Practices and rulesPractices and rules

Selected Agile ProcessesSelected Agile Processes eXtreme Programming (XP)eXtreme Programming (XP) ScrumScrum Dynamic Systems Development Method Dynamic Systems Development Method

(DSDM)(DSDM)

eXtreme Programming (XP)eXtreme Programming (XP)

Most famous and documented agile Most famous and documented agile processprocess

Rules & practicesRules & practices Developed by Kent Beck mid 1990’sDeveloped by Kent Beck mid 1990’s More info:More info:

http://http://www.extremeprogramming.orgwww.extremeprogramming.org

XP: Concepts/PracticesXP: Concepts/Practices

Customer Team MemberCustomer Team Member Highly accessible (on-site)Highly accessible (on-site)

User Stories over detailed User Stories over detailed requirementsrequirements Describe functionalityDescribe functionality Reduces unnecessary upfront restrictionsReduces unnecessary upfront restrictions

Simple DesignSimple Design Quick, easy, sufficientQuick, easy, sufficient

XP: Concepts/PracticesXP: Concepts/Practices Test Driven DevelopmentTest Driven Development

Tests written first, code written to make Tests written first, code written to make tests passtests pass

AutomatedAutomated

Acceptance TestsAcceptance Tests Verify user storiesVerify user stories Written before implementationWritten before implementation

Short CyclesShort Cycles 2-3 month releases2-3 month releases 2 week Iterations2 week Iterations

XP: Concepts/PracticesXP: Concepts/Practices

Pair Programming (2 people, 1 Pair Programming (2 people, 1 computer)computer) Generate production codeGenerate production code Transfer KnowledgeTransfer Knowledge Better Quality Better Quality Faster development Faster development

Collective OwnershipCollective Ownership Team knowledgeable in all aspects of Team knowledgeable in all aspects of

projectproject

Open WorkspaceOpen Workspace Easy access for conversationEasy access for conversation Limits team sizeLimits team size (<10 people)(<10 people)

XP: Concepts/PracticesXP: Concepts/Practices

Continuous IntegrationContinuous Integration

RefactoringRefactoring tiny transformations to improve the tiny transformations to improve the

structure of the code without changing its structure of the code without changing its behaviorbehavior

continuous continuous

MetaphorMetaphor Provides “big picture” of the systemProvides “big picture” of the system

XP: Concepts/PracticesXP: Concepts/Practices

Sustainable PaceSustainable Pace 40 hr week40 hr week

Planning GamePlanning Game Plan made at the start of each iteration Plan made at the start of each iteration

and releaseand release Customer decides which user stories to Customer decides which user stories to

implement nextimplement next

XP: Project LifecycleXP: Project Lifecycle

ScrumScrum Management approach using existing Management approach using existing

processes and practices processes and practices

empirical approach based in control empirical approach based in control systems theory systems theory

Developed (mid 90’s) & maintained by Developed (mid 90’s) & maintained by Advanced Development Methods (ADM, Advanced Development Methods (ADM, Inc) Inc) http://www.controlchaos.comhttp://www.controlchaos.com

Training and certification availableTraining and certification available

Scrum: Key Concepts/PracticesScrum: Key Concepts/Practices

Product BacklogProduct Backlog Defines everything needed in the final productDefines everything needed in the final product Goals, ResourcesGoals, Resources Constantly updated Constantly updated

Sprint (Cycles)Sprint (Cycles) ~30 days~30 days Production of an executable product incrementProduction of an executable product increment Requirements relatively frozen during SprintRequirements relatively frozen during Sprint

Scrum: Key Concepts/PracticesScrum: Key Concepts/Practices

Sprint Planning MeetingSprint Planning Meeting Goals and functionality of sprintGoals and functionality of sprint Decide an implementation approachDecide an implementation approach

Sprint BacklogSprint Backlog Items specific to the Sprint from the Items specific to the Sprint from the

Product BacklogProduct Backlog

Small teams (5 to 9 people)Small teams (5 to 9 people)

Scrum: Key Concepts/PracticesScrum: Key Concepts/Practices

Daily Scrum MeetingDaily Scrum Meeting ~15 minutes~15 minutes 3 questions addressed by each team 3 questions addressed by each team

membermember What did you do since the last meeting?What did you do since the last meeting? Any obstacles or issues?Any obstacles or issues? What will you do before the next meeting?What will you do before the next meeting?

Sprint Review MeetingSprint Review Meeting Demonstrate implemented functionalityDemonstrate implemented functionality Make decisions as to the next sprintMake decisions as to the next sprint

Scrum: Sprint LifecycleScrum: Sprint Lifecycle

Dynamic Systems Development Dynamic Systems Development Method (DSDM)Method (DSDM)

framework developed in the early 1990's framework developed in the early 1990's for rapid application development (RAD)for rapid application development (RAD)

Driving Principle:Driving Principle: Time and Resources are fixedTime and Resources are fixed Functionality is flexibleFunctionality is flexible

Very popular in EuropeVery popular in Europe Maintained by the DSDM ConsortiumMaintained by the DSDM Consortium

http://http://www.dsdm.orgwww.dsdm.org

DSDM: Key Concepts/PracticesDSDM: Key Concepts/Practices

MoSCoW PrioritizationMoSCoW Prioritization MMust Haves ust Haves critical to success critical to success oo SShould Haves hould Haves important but not important but not

criticalcritical CCould Haves ould Haves nice to have nice to have oo WWon't Have on't Have will not be implemented will not be implemented

DSDM: Key Concepts/PracticesDSDM: Key Concepts/Practices

TimeBoxingTimeBoxing Project end date is fixedProject end date is fixed Schedule broken into fixed 2-6 week Schedule broken into fixed 2-6 week

blocks of time (time box)blocks of time (time box) Assigned requirements of varying Assigned requirements of varying

prioritiespriorities Complete highest priority within the Complete highest priority within the

time boxtime box

DSDM: Key Concepts/PracticesDSDM: Key Concepts/Practices

PrototypingPrototyping Demonstrate business processDemonstrate business process Evaluate user interactionEvaluate user interaction Determine Performance/CapabilityDetermine Performance/Capability Demonstrate proof of conceptDemonstrate proof of concept

DSDM: LifecycleDSDM: Lifecycle

Feasibility StudyFeasibility Study Is DSDM appropriate?Is DSDM appropriate? Outline PlanOutline Plan

Business StudyBusiness Study Analyze requirementsAnalyze requirements Recommended technical approachRecommended technical approach Plan potential prototypesPlan potential prototypes

DSDM: LifecycleDSDM: Lifecycle

Functional Model IterationFunctional Model Iteration Build on requirementsBuild on requirements Prototype functionalityPrototype functionality

Design and Build IterationDesign and Build Iteration Prototype designPrototype design Refine prototypes into production Refine prototypes into production

ImplementationImplementation Transition from development to operationTransition from development to operation Provide TrainingProvide Training

DSDM: LifecycleDSDM: Lifecycle

Other Agile ProcessesOther Agile Processes

Feature Driven Development (FDD)Feature Driven Development (FDD) Framework with featuresFramework with features

Crystal MethodologiesCrystal Methodologies Processes based on size and criticalityProcesses based on size and criticality

Adaptive Systems Development Adaptive Systems Development (ASD)(ASD) Large, complex systemsLarge, complex systems

Limitations of Existing Agile Limitations of Existing Agile ProcessesProcesses

Limited support for large & distributed Limited support for large & distributed development teamsdevelopment teams Communication breakdownsCommunication breakdowns

Limited support for code reusabilityLimited support for code reusability Project specificProject specific

Limited support for large, complex softwareLimited support for large, complex software May require significant up front design and May require significant up front design and

planningplanning Incremental delivery may not be valuableIncremental delivery may not be valuable UnprovenUnproven

Agile AdoptionAgile Adoption

Adoption is slow but appears Adoption is slow but appears increasingincreasing

In March 2002, the Giga Group In March 2002, the Giga Group estimatedestimated ~10% of corporate IT groups are using ~10% of corporate IT groups are using

agile processesagile processes 2/3 are exploring use for future projects2/3 are exploring use for future projects

Future of Agile Software Future of Agile Software DevelopmentDevelopment

Processes still evolvingProcesses still evolvingi.e.) XP with Scrum i.e.) XP with Scrum

Won’t eliminate traditional Won’t eliminate traditional approachesapproaches Traditional approaches still valuableTraditional approaches still valuable

Here to stay? The new standard?Here to stay? The new standard? Only time will tell…Only time will tell…

Summary: Agile Software Summary: Agile Software DevelopmentDevelopment

Quick and Responsive developmentQuick and Responsive development Iterative, incrementalIterative, incremental Ample Customer Involvement Ample Customer Involvement

Different Processes availableDifferent Processes available

Alternative to Traditional MethodsAlternative to Traditional Methods

Questions / Comments ?Questions / Comments ?