April 22, 2002 Agile, Traditional or In Between Software Development Methodologies Agile, Traditional or In Between: Development Methodologies for a Rapidly

April 22, 2002April 22, 2002 Agile, Traditional or In BetweenAgile, Traditional or In BetweenSoftware Development MethodologiesSoftware Development Methodologies

Agile, Traditional orAgile, Traditional orIn Between:In Between:

Development Methodologies for a Development Methodologies for a Rapidly Changing WorldRapidly Changing World

David Berman, PMP, MCSDDavid Berman, PMP, MCSD

Managing ConsultantManaging Consultant

Quilogy, IncQuilogy, Inc

April 22, 2002April 22, 2002 Agile, Traditional, or In BetweenAgile, Traditional, or In BetweenSoftware Development MethodologiesSoftware Development Methodologies

Table of ContentsTable of Contents

IntroductionIntroduction Historical perspectiveHistorical perspective Traditional Traditional vs.vs. agile agile The The rightright methodology methodology Implementation tipsImplementation tips



IntroductionIntroduction Historical perspectiveHistorical perspective Traditional Traditional vs.vs. agile agile The The right right methodologymethodology Implementation tipsImplementation tips


About the SpeakerAbout the Speaker

Business Information Systems Business Information Systems majormajor

17 years in local IT industry17 years in local IT industry 15 years programming 15 years programming

experienceexperience 10 years using structured 10 years using structured

methodologiesmethodologies 6 years project management6 years project management


Digital ConsultingDigital ConsultingStrategyStrategyCreativeCreativeTechnologyTechnology

Net ServicesNet ServicesManaged HostingManaged HostingHosted ApplicationsHosted ApplicationsWireless ApplicationsWireless Applications

Technical EducationTechnical EducationPublic Training Center ClassesPublic Training Center ClassesPrivate or Onsite ClassesPrivate or Onsite ClassesOnline ClassesOnline Classes

About QuilogyAbout Quilogy


The Quilogy AdvantageThe Quilogy Advantage

Integrated Business SolutionsIntegrated Business Solutions Quilogy Runs on the Solutions We Quilogy Runs on the Solutions We SellSell QP ensures Quality and QP ensures Quality and ProductivityProductivity Vendor Partnerships and Vendor Partnerships and CertificationsCertifications


About the SessionAbout the Session

““Change alone is unchanging ” Change alone is unchanging ” (Heraclitus)(Heraclitus)

““If the facts don't fit the theory, If the facts don't fit the theory, change the facts.” change the facts.” (Einstein)(Einstein)

““Learning is not compulsory... Learning is not compulsory... neither is survival.” neither is survival.” (Deming)(Deming)

““To be a man of knowledge one To be a man of knowledge one needs to be light and fluid.” needs to be light and fluid.” (Yaqui knowledge)(Yaqui knowledge)


DefinitionsDefinitions

Methodology: Methodology: • ““A series of related methods or A series of related methods or

techniques” techniques” (Miriam-Webster)(Miriam-Webster)

Size:Size:• Number of control elementsNumber of control elements

Density:Density:• Level of detailLevel of detail

Scope:Scope:• Range of lifecycle and rolesRange of lifecycle and roles




April 22, 2002April 22, 2002 Agile, Traditional or In BetweenAgile, Traditional or In BetweenSoftware Development MethodologiesSoftware Development Methodologies

A Brief History of A Brief History of Software DevelopmentSoftware Development

Dawn o

f Tim

eSto

ne Tools

First S

oftwar

e Bug

Indust

rial R

evolu

tion

TodayFutu

re

First C

alcu

latin

g Mac

hine

First P

unchca

rd M

achin

e

First A

bacus

Source: www.softwarehistory.org www.cyberstreet.com


A Brief History of Software A Brief History of Software DevelopmentDevelopment

1950s1950s• Extensive use of computers in Extensive use of computers in

businessbusiness• First standard methodologiesFirst standard methodologies

Study Organization Plan (IBM)Study Organization Plan (IBM) Accurately Defined Systems (NCR)Accurately Defined Systems (NCR)

Source: www.softwarehistory.org www.csis.american.edu/museum www.computerhistory.org



1960s1960s• First contract programming firmsFirst contract programming firms• First $1M software contractFirst $1M software contract• NATO conferences on software NATO conferences on software

qualityquality• IBM unbundlesIBM unbundles




1970s1970s• First PCs and PC software First PCs and PC software

companiescompanies• Early CASE researchEarly CASE research• Mythical Man Month (1975)Mythical Man Month (1975)• Concept of structured programmingConcept of structured programming




1980s1980s• ““Monumental” methodologiesMonumental” methodologies

Summit, Method/1, FoundationSummit, Method/1, Foundation

• CASECASE• Object oriented designObject oriented design




1990s1990s• Quality initiativesQuality initiatives

Continuous ImprovementContinuous Improvement TQMTQM CMMCMM

• User-centered softwareUser-centered software• Iterative developmentIterative development• Open sourceOpen source




Today and the FutureToday and the Future• ComponentsComponents• Software as servicesSoftware as services• New processesNew processes• Adapting to changeAdapting to change



The Value of MethodologyThe Value of Methodology

Reduce

Err

ors

Impro

ve Q

ualit

y

Respond T

o Chan

geM

easu

re S

ucces

s

Incr

ease

Pro

ductiv

ity


Development StylesDevelopment StylesW

ater

fall

Incr

emen

tal

Spiral

Itera

tive

Agile

Customer InvolvementProcess centered. . . . . . . Code centered


Development StylesDevelopment Styles

Traditional MethodologyTraditional Methodology• Engineering-basedEngineering-based• Fixed requirementsFixed requirements• Unchangeable designsUnchangeable designs• Long development cyclesLong development cycles


WaterfallWaterfall

Well-defined phasesWell-defined phases• AnalysisAnalysis• DesignDesign• ImplementationImplementation• TestingTesting

One phase must finish before the One phase must finish before the next beginsnext begins

Entry points to successive phase Entry points to successive phase are outputs of predecessorsare outputs of predecessors


IncrementalIncremental

Uses the four phasesUses the four phases Delivers a software product in Delivers a software product in

incrementsincrements Each release adds functionalityEach release adds functionality

• New or increasedNew or increased



Iterative MethodologyIterative Methodology• Each cycle contains the four phasesEach cycle contains the four phases• Requirements and design may Requirements and design may

change in any iterationchange in any iteration• Risk management dictates Risk management dictates

development sequencedevelopment sequence


SpiralSpiral

Uses the four phasesUses the four phases Development proceeds in iterationsDevelopment proceeds in iterations Each phase is represented in every Each phase is represented in every

iterationiteration• AnalysisAnalysis• DesignDesign• ImplementationImplementation• TestingTesting

Each iteration delivers functionalityEach iteration delivers functionality• New or increasedNew or increased


Unified ProcessUnified Process

Tools and templatesTools and templates Team rolesTeam roles Best practicesBest practices

• Iterative DevelopmentIterative Development• Component ArchitectureComponent Architecture• Requirements managementRequirements management• Continuous quality monitoringContinuous quality monitoring• Change managementChange management• Visual modelingVisual modeling

Source: RUP 2002 www.rational.com



Agile MethodologyAgile Methodology• Projects centered on team, not Projects centered on team, not

phasesphases• Responding to change IS the planResponding to change IS the plan• Uses simplest toolsUses simplest tools• Functionality delivered oftenFunctionality delivered often

Source: The Agile Manifesto, 2001


CrystalCrystal

Scale determined by size of Scale determined by size of project teamproject team

Artifacts determined per projectArtifacts determined per project Interactive communicationInteractive communication

Source: www.crystalmethologies.org


AdaptiveAdaptive

Project MissionProject Mission CollaborationCollaboration Emergent solutionsEmergent solutions

Source: Adaptive Software Development, 2000


ExtremeExtreme

Plan for changePlan for change Customer is part Customer is part

of the teamof the team Very short cyclesVery short cycles

Source: The New Methodology Fowler, 2000 www.extremeprogramming.org


What about Object Oriented?What about Object Oriented?

OO focuses more on designOO focuses more on design OO techniques translate to other OO techniques translate to other

development environmentsdevelopment environments OO development can be used OO development can be used

with any methodology stylewith any methodology style Most iterative and agile methods Most iterative and agile methods

came from OOcame from OO




??


Traditional Methodologies are:Traditional Methodologies are:

MonolithicMonolithic Heavy Heavy RigidRigid Averse to changeAverse to change

RigorousRigorous RichRich PredictablePredictable RepeatableRepeatable


Agile Methodologies are:Agile Methodologies are:

Barely SufficientBarely Sufficient UnpredictableUnpredictable ChaoticChaotic HackingHacking

LightLight Accepting of Accepting of

changechange People-centeredPeople-centered PrincipledPrincipled


Waterfall = SuccessWaterfall = Success

Works well Works well • In stable environmentIn stable environment• With known requirements With known requirements

Lets project team know where Lets project team know where they arethey are

Knowledge is leveraged in future Knowledge is leveraged in future projectsprojects

Resource costs are lowerResource costs are lower All other methods are based on itAll other methods are based on it


Waterfall = RiskWaterfall = Risk

Requires process knowledge Requires process knowledge Significant time to produce Significant time to produce

artifacts artifacts Cost of change increases with Cost of change increases with

timetime Functionality delivered late in Functionality delivered late in

lifecyclelifecycle


Agile = SuccessAgile = Success

Control of unpredictable Control of unpredictable requirements requirements

True customer-driven True customer-driven developmentdevelopment

Change is expectedChange is expected Working software delivered Working software delivered

throughout lifecyclethroughout lifecycle

Source: The New MethodologyFowler, 2000


Agile = RiskAgile = Risk

Reliance on tacit knowledge Reliance on tacit knowledge Co-locating team essentialCo-locating team essential Rationale for decisions is lostRationale for decisions is lost Large systems cannot be put Large systems cannot be put

into production in bits and into production in bits and piecespieces

Source: Cockburn, Mellor Cutter IT Journal, 1/2002


Project Management ContextProject Management Context ControlControl

• EstimatingEstimating• SchedulingScheduling• Requirements managementRequirements management

Team RolesTeam Roles CommunicationCommunication

• MeetingsMeetings• StatusStatus• ProgressProgress• User/customer interactionUser/customer interaction

Configuration ManagementConfiguration Management• Change controlChange control• Release managementRelease management• QAQA


Conclusion:Conclusion:

Traditional is not the opposite of Traditional is not the opposite of AgileAgile

Strengths and weaknesses in Strengths and weaknesses in bothboth

Methodology must fit culture, or Methodology must fit culture, or culture must changeculture must change

Methodology must fit Methodology must fit circumstancescircumstances





The Business CaseThe Business Case

Projects ARE unpredictableProjects ARE unpredictable• Requirements changeRequirements change• Technologies changeTechnologies change

Frequent iterations IS a better Frequent iterations IS a better way to deliver softwareway to deliver software• Usable functionality in every cycleUsable functionality in every cycle• Lessons Learned feed future cyclesLessons Learned feed future cycles

Customer involvement is criticalCustomer involvement is critical


Issues to ConsiderIssues to Consider

Project environmentProject environment Motivation to changeMotivation to change Tolerance for changeTolerance for change Project scaleProject scale Pareto’s LawPareto’s Law Improve your processImprove your process

Source: Essentials Newsletter www.spc.ca


Agile Development Values:Agile Development Values:

Individuals and interactions over Individuals and interactions over process and toolsprocess and tools

Working software over Working software over comprehensive documentationcomprehensive documentation

Customer collaboration over Customer collaboration over contract negotiationcontract negotiation

Responding to change over Responding to change over following a planfollowing a plan

Source: The Agile Manifesto www.agilealliance.org


Things to KnowThings to Know

Agile methods can control cost Agile methods can control cost or scope but not bothor scope but not both

Agile methods must be scaled to Agile methods must be scaled to the job at handthe job at hand

Agile methods require strong Agile methods require strong leaders and team commitmentleaders and team commitment

Organizational knowledge must Organizational knowledge must survivesurvive


Project Management ContextProject Management Context PlanningPlanning

• EstimatingEstimating• Iteration planningIteration planning• Requirements managementRequirements management

Team RolesTeam Roles• Physical locationPhysical location• Motivated individualsMotivated individuals

CommunicationCommunication• MeetingsMeetings• DocumentationDocumentation• User/customer interactionUser/customer interaction

Configuration ManagementConfiguration Management• Change controlChange control• Build and/or Release managementBuild and/or Release management• QAQA

Source: Kruchten, 2000 www.agilealliance.org


Process Scales to the ProjectProcess Scales to the Project

Use the simplest toolsUse the simplest tools Leave the fewest artifactsLeave the fewest artifacts Take face-to-face interaction Take face-to-face interaction

over sign offsover sign offs Implement a Implement a processprocess frameworkframework





Requirements ManagementRequirements Management

DocumentingDocumenting TraceabilityTraceability PriorityPriority MeasurementMeasurement


ModelingModeling

Use to CommunicateUse to Communicate Intermediate models aren’t Intermediate models aren’t

project artifactsproject artifacts Use simplest toolsUse simplest tools Model collaborativelyModel collaboratively Update only when it hurtsUpdate only when it hurts Apply modeling standardsApply modeling standards

Source: www.agilemodeling.com www.sdmagazine.com


CommunicationCommunication

Open and HonestOpen and Honest Use Meetings effectively Use Meetings effectively Promote mutual accountabilityPromote mutual accountability


Project Management ContextProject Management Context

Organizational structureOrganizational structure Lifecycle phasesLifecycle phases ReworkRework Status and progress reportingStatus and progress reporting


Best PracticesBest Practices

Start smallStart small Be realisticBe realistic Rely on customer inputRely on customer input Focus on resultsFocus on results Leverage existing practicesLeverage existing practices


Process FrameworkProcess Framework

One size doesn’t fit allOne size doesn’t fit all• No single process right for all No single process right for all

companiescompanies• Suite of processes prevents Suite of processes prevents

transitiontransition Process components within a Process components within a

metamodelmetamodel• Size to fitSize to fit• Customized to projectCustomized to project


Process FrameworkProcess Framework

MetamodelMetamodel• Defines the rules of the process Defines the rules of the process

componentscomponents RepositoryRepository

• Instances of the metalevel process Instances of the metalevel process elementselements

Usage GuidelinesUsage Guidelines• Tailor process to specific problem Tailor process to specific problem

or contextor context

Source: Henderson-Sellers Cutter IT Journal, 1/2002


Activities and TasksActivities and Tasks

Activities

Tasks

Activity Activity AA

Activity BActivity B Activity CActivity C Activity DActivity D Activity EActivity E

Task 1Task 1 MM RR OO OO FF

Task 2Task 2 DD OO RR MM MM

Task 3Task 3 FF RR RR OO OO

Task 4Task 4 FF DD MM RR RR

Task 5Task 5 DD DD FF FF OO

M = mandatory D = discouragedR = recommended F = forbiddenO = optional

Source: Henderson-Sellers Cutter IT Journal, 1/2002


How To Be Agile:How To Be Agile:

Know what you’re doingKnow what you’re doing Know what to do nextKnow what to do next Scale your attitudeScale your attitude

Documents

April 22, 2002 Agile, Traditional or In Between Software Development Methodologies Agile, Traditional or In Between: Development Methodologies for a Rapidly