agile software development: theory and reality

1ICT

Agile Software Development:Theory and Reality

EuroSPI 2006 TutorialOctober 11th, 2006, 0900-1300

By Geir K. Hanssen, SINTEF ICT/Norway([email protected])

(This material may be reused but please put in a reference)

2ICT

About me

Geir Kjetil HanssenIndustrial experience as developer and project leaderResearcher at SINTEF ICT in Trondheim/NorwayStudying agile software development in four companiesPhD student at NTNU, Trondheim

About you Name and work-placeWork tasks/responsibilities/interestsWhy this course?

3ICT

The goal of this tutorial

I would like you tounderstand the basic ideas of Agile Software Developmentbe interested but skepticalcontribute with your opinions, views and questions

4ICT

Schedule

Introduction and presentation of us (approx. 20 m)Part 1: Theory (approx. 60 m. including 15 m. break)Explain the idea of agile software development

Task1: Likes and dislikes (approx. 20 m.)

Break 30 m.

Part 2: Reality (approx. 60 m. including 15 m. break)Look into challenges and potential problems

Task 2: Open issues/questions to be resolved (approx. 20 m.)

Directions for future learning (approx. 10 m.)

// Warning: This is just a plan //

5ICT

Learning tools

Input from me to you (lecture)Questions and comments from you to me and the others (corrections and focus)Tasks to make you think and have an opinionDiscussions

6ICT

Part 1: Theory

Scrum

Extreme Programming

DSDM

Lean

CrystalAgile Modeling

FDD Refactoring

TDD

Pair programming

Evo

7ICT

Part 1: Agenda

The term agileThe waterfall modelProcess flavoursSoftware complexity and failuresThe motivation for a changeComparing agile and traditional approachesThe core practices of agile software developmentThe origin of the ideasThe believers, the sceptics and the scientists viewAn example: ScrumTask 1: likes and dislikesSoftware projects trade-offsSoftware project contextWhat do we know?

8ICT

Agile

In the dictionary: easy, quick, flexible, nimbleA more mature version of light weightAgile methods is a group of related software development methodologies

Extreme Programming, Scrum, Crystal, Lean etcA reaction to heavy, formal, document-driven, bureaucratic processes

Extensive planning early in a project and often based on too low knowledge and experience (on both sides)Locked to plans and contract low flexibilityHard to focus on user needs (dont see what we need until we see it)No space for creativity (?)

9ICT

The waterfall model

(By M.C. Escher)

10ICT

The traditional approach

Plan-based/driven processesBig Design Up-Front (BDUF)Big Planning Up-FrontThe waterfall-model1

The ideaAll requirements andwork is planned in advanceA project follows the plan100% predictability100% control

Not according to reality

1) W. W. Royce. - Proceedings of IEEE WESCON, 1970

11ICT

The plan

13ICT

Royce continued

Royce identifies problems with the sequential approachRisky and invites failureTesting is the first point of feedback on the analysis

The solutionOpportunity to redo steps based on experienceIterative process!

(5-600 citations according to Google Scholarthe majority is probably incorrect)

14ICT

Alternative development processesStrategy

Waterfall

Incremental

Evolutionary

Define allreq. first?

Yes

Yes

No

Several cycles?

No

Yes

Yes

Distributeincrements?

No

Maybe

Yes

req.design

codetest

deliver

deliver

req.design

codetest

deliver

designcode

test

req.

design code

testdeliver

test

code

req.

design

deliver

req.

Source: Tore Dyb, Torgeir Dingsyr and Nils Brede Moe, Process Improvement in Practice - A Handbook for IT Companies. Boston: Kluwer, 2004, ISBN 1-4020-7869-2

15ICT

The agile life-cycle

Start-up TerminationEv

aluati

on

Priotitation

Dev./

test

Release

2-14 days

n * 1-4 weeks

a few days

16ICT

KLOC in Avionics System

A300B

A300FF

A310

A320

A330/340

A3xx

1

10

100

1000

10000

Airplane type

in K

LOC

A typical cell-phone now contains two million lines of software code; by 2010 it will likely have 10 times as many

General Motors Corp. estimates that by then, more than 50% of the development costs of their cars will be due to software

(Charette, R. N. Why Software Fails. IEEE Spectrum, Sept., (2005))

60% of software projects are completed late and that the average cost overrun is 30-40%

A substantial proportion of the late and under-budgeted software projects are outright failures(K. Molkken, M. Jrgensen, S.S. Tanilkan, H. Gallis, A.C. Lien and S.E. Hove (2004) A Survey on Software Estimation in the Norwegian Industry, Proc. 10th Int. Software Metrics Symposium (Metrics2004), Chicago, USA, pp. 208-219)

Software growth

17ICT

ANNUAL PRODUCTIVITY GROWTH 1998 - 2003

Source: http://www.economy.com

18ICT

Motivation

FasterIncreased demand for faster development and delivery?Early release of working software?

BetterBetter understanding of explicit and implicit requirements?Software with fewer errors and higher usability?

CheaperLow documentation costs?Pragmatic administration?Reduced risk of delays?

19ICT

Traditional and agile - compared

Continuous control of requirements, design and solutions. Continuous testing

Heavy planning and strict control. Late, heavy testing

Quality control

Organic (flexible and participative encouraging cooperative social action), aimed at small and medium sized organizations

Mechanistic (bureaucratic with high formalization), aimed at large organizations

Desired organizational form/ structure

The evolutionary-delivery modelLife cycle model (waterfall, spiral or some variation)

Development model

InformalFormalCommunication

TacitExplicitKnowledge management

Leadership-and-collaborationCommand-and-controlManagement style

High-quality adaptive software can be developed by small teams using the principles of continuous design improvement and testing based on rapid feedback and change.

Systems are fully specifiable, predictable, and can be built through meticulous and extensive planning.

Fundamental assumption

Agile developmentTraditional development

Table taken from: Nerur, S., Mahapatra, R. and Mangalaraj, G.., Challenges of migrating to agile methodologies, Communications of the ACM, May 2005, pp. 72 78.

20ICT

A reaction to heavy processes

The agile manifesto (www.agilemanifesto.org) says:Individuals and interactions over processes and tools

Direct, verbal communicationGiving the developers more responsibility and freedomSimplicity

Working software over comprehensive documentationFrequent delivery of working software is the best proof of progressThe customer gets early practical experience

Customer collaboration over contract negotiationThe customer is given a practical roleInside information

Responding to change over following a plan Planning is close to impossible(!), optimal handling of change is a better approachChange DO occur dont resist, deal with it

21ICT

Core practices investigated (1/3)

- Does the customer have time for this?

- Does this disturb the developers?

- Inside domain information- Dynamic requirements

management- Reduce unclearity

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

- Unhealthy pressure/stress?- No room for extensive

design

- Clearly shows progress- Always have a working

version - Wrong design found early

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

- What about the cost of rework?

- When to know when finished?

- Responsive process- Open to new ideas- No need to plan in detail

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

- How to deliver so frequent?

- Why? - Is it really interesting?

- Satisfied customer- Clearly shows progress

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

Sceptics viewBelievers viewAgile practices from the manifesto

22ICT


- What about dealing with surprises?

- No stress or overtime- No scamped work

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

- What about completeness?- Maximum visibility7) Working software is the primary measure of progress.

- What about tracability?- Large, distributed teams?

- Quick and direct communication

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

- Can people be trusted?- No management?- Works only with the very

best?

- Fun and motivating- Trusting good people- No need of detailed

management

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


23ICT


- No sceptic view on this one this is a good idea!

- Learn and improve from experience

- Obstacles are removed during the project

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

- How come? - Optimal architecture11) The best architectures, requirements, and designs emerge from self-organizing teams.

- What to decide whats (really) simple?

- Does not invest effort in unnessesary work

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

- Easy to say hard to do?- Technically good solutions

9) Continuous attention to technical excellence and good design enhances agility.


24ICT

Method map

(From Craig Larman)

25ICT

An interesting anecdote

Ivar Jacobson now says*:the most well-known variant of the Unified Process has grown its knowledge base beyond manageable limits.The Unified Process became too heavy

Promotes a new process: Essential Unified ProcessAn agile process

*) Jacobson, I., Ng, P. W. and Spence, I., The Essential Unified Process a Fresh New Start. 2006. (download from www.ivarjacobson.com)

26ICT

Methods and focus

From: Abrahamsson, P., Warsta, J., Siponen, M. T. and Ronkainen, J. New Directions on Agile Methods: A Comparative Analysis. In Proceedings of International Conference on Software Engineering (ICSE) 2003).

27ICT

The origin of the ideas

From: Abrahamsson, P., Warsta, J., Siponen, M. T. and Ronkainen, J. New Directions on Agile Methods: A Comparative Analysis. In Proceedings of International Conference on Software Engineering (ICSE) 2003).

28ICT

The terms used

4 values

12 principles

the agile manifesto

10+/- practices

8+/- methods

pair-prog., TDD, refactoring

Scrum, XP, Crystal, Evo,

Thousands of projects

29ICT

The believers view

Agile software development is cheaper, faster and better because:

Only whats needed will be developedMisunderstandings (with late rework) is discovered earlyCommunication is more efficient (internal and external)

Better conditions for creativityChanges can not be controlled better to emphasize change responseTeams self-organize

30ICT

The skeptics view

One customer representative does not have sufficient knowledge of:

Organizational knowledgeDomain knowledgeCoordinating contradicting needs

A customer will not be available 24/7Customers will not accept no plan no estimatesSmall releases only fit small problems and small projectsDoes not support good architectureAgile methods does not fit in traditional project management frameworksHackers excuse

31ICT

The scientists view

Trying to be objectiveLooking for evidenceComparing with alternatives

All of these are hard to do!

If somethings hard to do its not worth doingHomer Simpson, 2000

We choose to go to the moon in this decade and do the other things, not because they are easy, but because they are hard []

JFK, 1962

32ICT

An example: Scrum

An agile process aimed at controlling and managing software developmentA structure for use of existing techniquesA team-oriented approach for developing software iteratively and incrementally with frequent changesControl chaos by prioritizing based on knowledgeImproves communication and maximizes cooperationHelps to find and remove anything that does not add value to the developmentScalableEstablish comfort

33ICT

Scrum: the origin

The New New Product Development Game in Harvard Business Review, 1986.*:

The relay race approach to product developmentmay conflict with the goals of maximum speed and flexibility. Instead a holistic or rugby approachwhere a team tries to go the distance as a unit, passing the ball back and forthmay better serve todays competitive requirements.

Jeff Sutherland (1993), Ken Schwaber (1996) and Mike BeedleThe book in 2001

*) Takeuchi, H. and Nonaka, I. The New New Product Development Game.Harward Buisiness Review, (1986).

34ICT

In rugby football a scrummage or scrum is aof restarting the game, either after a minor infringement [], or when the ball has gononto the ground after a successful tackle [

35ICT

Scrum: Process components

RolesProduct OwnerScrum TeamScrumMaster(Stakeholders)

ArtifactsVisionProduct BacklogSprint BacklogBurndown Chart

ProcessSprint Planning MeetingSprintDaily Scrum MeetingSprint Review MeetingSprint Retrospective

Meeting

36ICT

An example: Scrum

(From www.controlchaos.com)

37ICT

Scrum: The Scrum master

Represents management to the projectTypically filled by a Project Manager or Team LeaderResponsible for enacting Scrum values and practicesMain job is to remove impediments

(From Mountain Goat Software)

38ICT

Scrum: The Scrum team

Typically 5-10 peopleCross-functional

QA, Programmers, UI Designers, etc.

Members should be full-timeMay be exceptions (e.g., System Admin, etc.)

Teams are self-organizingMembership can change only between sprints


39ICT

Scrum: Sprint

Scrum projects make progress in a series of sprintsAnalogous to XP iterations

Target duration is one month+/- a week or two

But, a constant duration leads to a better rhythm

Product is designed, coded, and tested during the sprint


40ICT

Each iteration implement the highest-priority requirements

Each new requirement is prioritized and added to the stack

Requirements may be reprioritized at any time

Requirements may be removed at any time

Requirements

HighPriority

LowPriority

Copyright 2004 Scott W. Ambler

Scrum: Requirements management

41ICT

XP in 10 seconds

(More on www.extremeprogramming.org)

42ICT

Task 1:

What do you like about agile software development?

What do you dislike about agile software development?

43ICT

The borders of a software project and its trade-offs

Time (to market)

CostResult

(scope and quality)

faste

r mea

ns h

igher

cost

Less

cost

mea

ns la

ter

more result means more cost

faster means less (quality of) result

more result m

eans more tim

e

less cost means less result

44ICT

Processes can not be copiedIndustry

best-practice?

From Pekka Abrahamssons EuroMicro 2003 Keynote

45ICT

Context-dependent applicabilityPersonnel

Dynamism (% Requirements-change/month)

Culture (% thriving on chaos vs. order)

Size (# of personnel)

Criticality (Loss due to impact of defects)

5030

105

1

90

70

50

30

10

3

10

30

100

300

35

30

25

20

15

Essential Funds Discretionary

Funds Comfort

Single Life

Many Lives

(% Level 1B) (% Level 2&3)

0

10

20

30

40

Agile

Disciplined

Source: Allistair Cockburn, used in Boehm, B. and Turner, R. Balancing Agility and Dicipline - A Guide for the Perplexed. Addison-Wesley, 2004.

Other axes?Domain complexity (simple-complex)Urgency (calm-urgent)Technical complexity(simple-complex)Novelty(plain-experimental)

46ICT

Agile homeground

From: Cockburn, A. Selecting a Project's Methodology. IEEE Software, (2000).

47ICT

Communication effectiveness

No QA

QA

(Adopted from Allistair Cocburn and Scott Ambler)

48ICT

Types of software engineering

ConsultancySales of head-power; individuals, teams or projects

Single-caseOne customer or a groupVery specific requirementsRelated to a specific domain

Product developmentLarge, diverse user massNo direct requirements from customersConstant refinement and new releases

49ICT

What do we know? (1)

Enormous interest in the industry2 large international conferences (XP and Agile)Extensive coverage in professional magazines and many booksA search for extreme programming on www.amazon.com gives 51 resultsagile gives 354 results

2 books criticizing XPStephens, M. and Rosenberg, D. Extreme Programming Refactored: The Case Against XP. Apress, 2003McBreen, P. Questioning Extreme Programming. Addison-Wesley, 2003

1 book as balanced and neutralBoehm, B. and Turner, R. Balancing Agility and Discipline - A Guide for the Perplexed. Addison-Wesley, 2004.

Weak documentation on effects, costs and limitations2946 articles addressing the topic found in a search821 abstracts on agile software development380 articles with empirical data39 good research publications

50ICT


51ICT

The hype curve

2006?

2000?

52ICT


Preliminary results from studyMainly focus on XPLow scientific quality on most studiesFew studies over timeFew studies on mature teams

Studies mostly focus onPair-programmingTest-driven developmentCustomer engagement

Conclusion: we have little knowledge on how agile methods affects development!

However many promising experiences in the industry!

53ICT

Quality criteria's

Screening questions (no on 1 or (2 and 3) meant exclude)1. Is this a research paper?2. Is there a clear statement of the aims of the research?3. Is there an adequate description of the context in which the research was

carried out?

Detailed questions:4. Was the research design appropriate to address the aims of the research?5. Was the recruitment strategy appropriate to the aims of the research?6. Was there a control group with which to compare treatments? 7. Was the data collected in a way that addressed the research issue? 8. Was the data analysis sufficiently rigorous? 9. Has the relationship between researcher and participants been adequately

considered? 10. Is there a clear statement of findings? 11. Is the study of value for research or practice?

(Applied on 821 papers)

54ICT

Announcement!

EuroSPI Keynote, Friday:Prof. Pekka Abrahamsson:

The concrete business impact of agile solutions -

3 times faster and 50 times better!

55ICT

BREAK(coffee and discussions)

56ICT

Part 2: Reality

Customers

Programmers

Project manager

Money

Time

Quality

Users

Management

Requirements

57ICT

Part 2: Agenda

Conditions for agilityResearch summaryResearch insights: pair programmingResearch insights: test-driven developmentResearch insights: customer engagementSupporting toolsTask 2: Questions and open issuesThe futureFinal advicePointers to further learning

58ICT

Conditions for agility (1)

Customer on-siteIs the customer willing to spend the time to be available?Can anyone represent an organization or other users?

How should the representative interact with his/hers organization?Has the customer good enough understanding of the requirements?Has the customer good enough domain knowledge?Is the customer able to respond to increments?

59ICT


Team co-locationHow to deal with geographically spread organizations?How to deal with team-members that work on multiple projects?Are the offices suited for teamwork?

Skilled individuals and teamsWill the team be able to self-organize?Does the team contain the skills needed?Is everybody in favor of working in a team?

60ICT


Customer acceptance of an agile contractWill the customer trust you?What should you do if the project fails?How to make the customers budget?Will the most important features be covered?What about documentation?What about future development?What about ISO9000, CMM etc.?

61ICT


Technical excellence (infrastructure)How to release each iteration?How to enable the customer to test and reply?

62ICT

Research summary

Just a few principles and practices are investigated thoroughly, e.g.:

Pair programmingArisholm et al. 2006

Test-driven developmentErdogmous et al. 2005

Active customer engagementHanssen and Fgri 2006

Missing evidence for e.g.:Self-organizing teamsAgile architectureRefactoringCreativityTrade-offSuggestions?

63ICT

Pair programming evidence*

*) E. Arisholm, H. E. Gallis, T. Dyb and D. Sjberg. Evaluating Pair Programming among Professional Java Developers, Submitted to IEEE Transactions on Software Engineering, 2006.

64ICT

Test-driven development: evidence*

*) Erdogmus, H. and Morisio, M. On the Effectiveness of the Test-First Approach to Programming. IEEE TRANSACTIONS ON SOFTWARE ENGINEERING, 31 (2005), 3.

(Test coverage) Test-First programmers write more tests per unit of programming effort(Productivity) A higher number of programmer tests lead to proportionally higher levels of productivity(Quality) Test-First programmers did not achieve better quality on average

(although they achieved more consistent quality results)

65ICT

Customer engagement: evidencePrerequisites

Only motivated (by benefit) customers will engage Customer engagement needs proactive managementLack of continuity has significant bad effects on the performance Selecting the right (expertise) stakeholders are essentialFrequent iterations leaves little room for unrestrained activityAn effective technical framework is essential

BenefitsClose customer cooperation has a highly motivating effect on thedevelopers Customers prioritizing of goals has increased developers confidenceThe process visibility can be beneficial for the rest of the organization

CostsExtra overhead in actually running the process and the human resources requiredThe technical infrastructure, being a prerequisite, is costly Short iterations with insufficient attention to management and process compliance increase fragility Reduced capability to capture the needs of other, non-appointed customers

66ICT

Supporting tools

Even an agile process may benefit from the right tools:Continuous integrationProcess monitoring and controlRequirements managementEstimation and prioritizingTestingRapid deployment and feedback management

Some examples follow:

67ICT

Tools: Requirements management (1)

Product backlog

68ICT


Sprint backlog

69ICT


70ICT

Tools: Progress monitoring

Burn-down charts

Backlog items burndown

05

101520253035

week

1we

ek 2

week

3we

ek 4

week

5we

ek 6

week

7we

ek 8

week

9we

ek 10

week

11we

ek 12

week

13we

ek 14

week

15we

ek 16

week

17we

ek 18

week

19we

ek 20

Time/iterations

rem

aini

ng b

ackl

og it

ems

Estimated work (hours) burndown

0

500

1000

1500

2000

2500

3000

week

1we

ek 2

week

3we

ek 4

week

5we

ek 6

week

7we

ek 8

week

9we

ek 10

week

11we

ek 12

week

13we

ek 14

week

15we

ek 16

week

17we

ek 18

week

19we

ek 20

71ICT

Tools: Test coverage

0

20

40

60

80

100

120

140

160

wee

k 1

wee

k 2

wee

k 3

wee

k 4

wee

k 5

wee

k 6

wee

k 7

wee

k 8

wee

k 9

wee

k 10

wee

k 11

wee

k 12

wee

k 13

wee

k 14

wee

k 15

wee

k 16

wee

k 17

wee

k 18

wee

k 19

wee

k 20

# tests definedaccumulated# tests passed accumulated

72ICT

Tools: Continous integration

From Trond Johansen, FIRM as, Norway

(Borland)

(Open-source)

(Open-source)

(Open-source)

(Microsoft)

Check out:http://www.martinfowler.com/articles/continuousIntegration.html

73ICT

Even more toolsXP StoryStudio (a project-management portal - free)TargetProcess (agile project management and bug tracking software - licenced)VersionOne (agile project management licenced)Xradar (system analysis report tool for Java - free)Jira (bug tracking, issue tracking, & project management - licenced)Extremeplanner (agile project planning and tracking - licenced)Fitnesse (acceptance testing framework - licenced)Ant/Nant (build tool free)Maven (software project management and comprehension tool free)CruiseControl (build support free)FXCop (code analysis tool free?)StartTeam (source code control licenced)Wiki (information sharing free)Clover/Nclover (test coverage tool free?)JUnit/NUnit/NUnitASP (unit testing framework free)Cobertura 1.6: (Java test coverage tool free)EasyMock 1.2 RC2 (Mock Object for Java interfaces free)Exactor 1.1.4: (framework for automated acceptance tests free)Jakarta Cactus 1.7.1: (Unit-testing server-side Java free)JasperReports 1.0.2: (Java reporting tool free)Jameleon 3.0.3: (Java tool for automated acceptance testing free)log4j 1.2.12: (Java logging tool free)and many many more

Do you remember the first agile value?

Individuals and interactions over processes and tools

74ICT

Task 2: Questions and open issues

What are the most important questions still to be answered?

Use your background (academic/industry)

75ICT

Future

Fundamentalism is (as always) not the best approach!Hopefully, the number of methods will converge into a few

Tailored for domains, technologies etc.Easier to find the right one

More validation by researchThe solution will be a balance between agility and discipline

76ICT

Maturing ideas

From Crossing the Chasm by Geoffrey A. Moore

77ICT

Boehm and Turnes conclusions*

1. Neither agile nor plan-driven methods provide a silver bullet

2. Agile and plan-driven methods have home grounds where one clearly dominates the other

3. Future trends are toward applications developments that need both agility and discipline

4. Some balanced methods are emerging5. It is better to build your method up than to tailor it down6. Methods are important, but potential silver bullets are

more likely to be found in areas dealing with people, values, communication and expectations management.

Boehm, B. and Turner, R. Balancing Agility and Dicipline - A Guide for the Perplexed. Addison-Wesley, 2004.

78ICT

Final advice*

A lot of experts selling silver bullets however:1. Read and understand yourself! Be interested but sceptical!2. Check recent research results! (learn from others experience)3. Try and evaluate! (learn from your own experience)4. Discuss with someone with practical experience5. Dont be fanatic be creative 6. Involve everybody the SE process is everybody's concern

*) Applicable for any hype (WebServices, MDD, Agile, SOA)!

79ICT

Appraising published studies

From:Dyb, T., Kitchenham, B. and Jrgensen, M., Evidence-Based Software Engineering for Practitioners, in IEEE Software. 2005. p. 58-65.

80ICT

Pointers to further learning www.agilealliance.org

Fresh info from the community

www.agilemanifesto.orgSimple documentation of the basic concepts

www.extremeprogramming.org

A good overview of XP basics

www.controlchaos.comScrum overview (some marketing)

www.wikipedia.orgDefinitionsLinks

Agile Software Development with SCRUM by Ken Schwaber and Mike Beedle

Balancing Agility and Discipline: A Guide for the Perplexed by Barry Boehm and Richard Turner

Takeuchi, H. and Nonaka, I. The New New Product Development Game. Harward Buisiness Review, (1986)

Boehm, B., Get Ready for Agile Methods, with Care, in IEEE Computer. 2002. p. 64-69.

Abrahamsson, P., Salo, O., Ronkainen, J. and Warsta, J. Agile software development methods - Review and analysis. VTT Publications 478, VTT Electronics, 2002.

Cohen, D., Lindvall, M. and Costa, P. Agile Software DevelopmentA DACS State-of-the-Art Report. Fraunhofer Center for Experimental Software Engineering Maryland and The University ofMaryland, 2003.

agile software development: theory and reality

Documents