Post on 27-May-2020
1ICT
Agile Software Development:Theory and Reality
EuroSPI 2006 TutorialOctober 11th, 2006, 0900-1300
By Geir K. Hanssen, SINTEF ICT/Norway(ghanssen@sintef.no)
(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 to……understand the basic ideas of Agile Software Development…be interested – but skeptical…contribute 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 ”agile”The 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 weight”Agile methods is a group of related software development methodologies
Extreme Programming, Scrum, Crystal, Lean etc…A 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 (don’t 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 “idea”All 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
12ICT
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 Scholar…the 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 Dingsøyr 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 TerminationEva
luation
Priotitation
Dev./te
st
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. Moløkken, M. Jørgensen, 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 (Metrics’2004), 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 role“Inside information”
Responding to change over following a plan Planning is close to impossible(!), optimal handling of change is a better approachChange DO occur – don’t 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
Core practices investigated (2/3)
- 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.
Sceptics viewBelievers viewAgile practices from the manifesto
23ICT
Core practices investigated (3/3)
- 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 what’s (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.
Sceptics viewBelievers viewAgile practices from the manifesto
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 believer’s view
Agile software development is cheaper, faster and better because:
Only what’s 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 skeptic’s 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 estimates”Small releases only fit small problems and small projectsDoes not support “good” architectureAgile methods does not fit in traditional project management frameworksHackers excuse
31ICT
The scientist’s view
Trying to be objective…Looking for evidenceComparing with alternatives
All of these are hard to do!
“If something’s hard to do – it’s not worth doing”Homer 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 development…may conflict with the goals of maximum speed and flexibility. Instead a holistic or ‘rugby’ approach—where a team tries to go the distance as a unit, passing the ball back and forth—may better serve today’s 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
(From Mountain Goat Software)
39ICT
Scrum: Sprint
Scrum projects make progress in a series of “sprints”Analogous 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
(From Mountain Goat Software)
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 results…”agile” 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
What do we know? (2)
51ICT
The hype curve
2006?
2000?
52ICT
What do we know? (3)
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
Conditions for agility (2)
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
Conditions for agility (3)
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
Conditions for agility (4)
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 Fægri 2006
Missing evidence for e.g.:Self-organizing teamsAgile architectureRefactoringCreativityTrade-offSuggestions?
63ICT
Pair programming – evidence*
*) E. Arisholm, H. E. Gallis, T. Dybå and D. Sjøberg. 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 Customer’s 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
Tools: Requirements management (2)
Sprint backlog
69ICT
Tools: Requirements management (3)
70ICT
Tools: Progress monitoring
Burn-down charts
Backlog items burndown
05
101520253035
week 1
week 2
week 3
week 4
week 5
week 6
week 7
week 8
week 9
week 1
0wee
k 11
week 1
2wee
k 13
week 1
4wee
k 15
week 1
6wee
k 17
week 1
8wee
k 19
week 2
0
Time/iterations
rem
aini
ng b
ackl
og it
ems
Estimated work (hours) burndown
0
500
1000
1500
2000
2500
3000
week 1
week 2
week 3
week 4
week 5
week 6
week 7
week 8
week 9
week 10
week 11
week 12
week 13
week 14
week 15
week 16
week 17
week 18
week 19
week 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 tools…XP 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 other’s experience)3. Try and evaluate! (learn from your own experience)4. Discuss with someone with practical experience5. Don’t 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 Jørgensen, 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.