1. A Case for Agile Development

2. From Nothing, to Heavy, to Light (1)
Most software development is a chaotic activity, often characterized by the phrase “code and fix”.
We’ve lived with this style of development for a long time, but we’ve also had an alternative for a long time: methodology.
The most frequent criticism of these methodologies is that they are bureaucratic (hence the name heavy methodologies).
We’ve lived with this style of development for a long time, but we’ve also had an alternative for a long time: methodology. Methodologies impose a disciplined process upon software development with the aim of making software development more predictable and more efficient.
The most frequent criticism of these methodologies is that they are bureaucratic. There’s so much stuff to do to follow the methodology that the whole pace of development slows down. Hence they are often referred to as heavy methodologies.

3. From Nothing, to Heavy, to Light (2)
As a reaction to these methodologies, a new group of methodologies have appeared in the last few years – the light methodologies.
They are less document-oriented and more code-oriented.
Lack of documentation is just a symptom of two deeper differences:
Light methods are adaptive rather than predictive.
Light methods are people-oriented rather than process‑oriented.
As a reaction to these methodologies, a new group of methodologies have appeared in the last few years. Although there’s no official name for them, they are often referred as light methodologies – signaling a clear reaction to the heavyweight methodologies.
Light methods are adaptive rather than predictive. Heavy methods tend to try to plan out a large part of the software process in great detail for a long span of time, this works well until things change. So their nature is to resist change. The light methods, however, welcome change. They try to be processes that adapt and thrive on change, even to the point of changing themselves.
Light methods are people-oriented rather than process‑oriented. They explicitly make a point of trying to work with peoples’ nature rather than against them and emphasize that software development should be an enjoyable activity.

4. The Self-Adaptive Process
Adaptivity is not only in the context of a project adapting its software frequently to meet the changing requirements of its customers.
There’s another angle of adaptivity: that of the process changing over time.
The first part of self-adaptivity is regular reviews of the process.
A consequence of self-adaptivity is that you should never expect to find a single corporate methodology.
There’s another angle of adaptivity: that of the process changing over time. A project that begins using an adaptive process won’t have the same process a year later. Over time, the team will find what works for them, and alter the process to fit.
The first part of self-adaptivity is regular reviews of the process. Usually you do these with every iteration. At the end of each iteration, have a short meeting and ask yourself the following questions: What did we do well? What have we learned? What can we do better? What puzzles us? These questions will lead you to ideas to change the process for the next iteration. In this way a process that starts off with problems can improve as the project goes on, adapting better to the team that uses it.

5. Agile Processes Introduction to Agile Methodology Agile Communication
Agile Manifesto
Impact of Agile on Requirements
Principles & Practices
Agile Communication
Sweet Spots
Self Adaptation
Specific Methods XP
Crystal

6. Welcome to Agile Techniques
What Agile processes try to avoid:

7. Manifesto for Agile Software Development
We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
Individuals and interactions over processes and tools Working software over comprehensive documentation Customer collaboration over contract negotiation Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
Robert C. Martin Steve Mellor Ken Schwaber Jeff Sutherland Dave Thomas
James Grenning Jim Highsmith Andrew Hunt Ron Jeffries Jon Kern Brian Marick
Kent Beck Mike Beedle Arie van Bennekum Alistair Cockburn Ward Cunningham Martin Fowler
© 2001, the above authors. This declaration may be freely copied in any form, but only in its entirety through this notice

8. Principles behind the Agile Manifesto
We follow these principles:
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale.
Business people and developers must work together daily throughout the project.

9. Principles behind the Agile Manifesto
(continued)
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get the job done.
The most efficient and effective method of conveying information to and within a development team is face-to-face conversation.
Working software is the primary measure of progress.
Agile processes promote sustainable development.
The sponsors, developers, and users should be able to maintain a constant pace indefinitely. .

10. Principles behind the Agile Manifesto
(continued)
Continuous attention to technical excellence and good design enhances agility.
Simplicity--the art of maximizing the amount of work not done--is essential.
The best architectures, requirements, and designs emerge from self-organizing teams.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.

11. Agile Methodologies XP (eXtreme Programming) Crystal
DSDM (Dynamic Systems Development Method)
SCRUM
ASD (Agile Software Development)
And others…
“Agile Methodologies” not only XP

12. Impact of Agile on Requirements
Traditional software convention is based on the assumption that:
A system should be clearly specified before beginning design and implementation.
A specification should be unambiguous, consistent, concise, traceable and implementation independent.
How is requirements engineering special in agile?
- Different assumptions
- Special Environmental conditions

13. … Impact of Agile on Requirements
Requirements and models are a valid expression of user needs
All requirements have equal value
Cost of changing requirements becomes more expensive as a project progresses.
Expression : they are able to verify that what they want is captured on paper.
By value we mean that all requirements will bring the same business value to the system, not the same as priority.

14. … Impact of Agile on Requirements
But agile processes have little upfront analysis/design, minimal documentation and little structure for ensuring consistency and traceability, how can it work effectively as a software methodology?
After all, reports show that poor requirements gathering is responsible for 45% of cancelled projects.
Common criticisms.

15. … Impact of Agile on Requirements
Of delivered systems, most did not provide the expected business value.
Agile approaches allow requirements which provide the most value to the business emerge during development.
Most users cannot intelligently respond to only requirements and models.
Agile assumptions

16. … Impact of Agile on Requirements
Agile processes focus on business value :
Business value = f(cost,time,functionality,quality)
Example : DSDM supposes that 80% of a systems value is delivered by 20% of a systems requirements.

17. … Impact of Agile on Requirements
New development tools, testing tools, source management tools and version control tools allow for solid development environments which support the ability to rapidly generate high quality re-factored releases of a system.
Agile approaches have emerged in the past ten years.
tools can even generate certain diagrams from code
no need to maintain diagrams manually.

18. … Impact of Agile on Requirements
To be successful, Agile techniques must possess tools to cope with a constantly changing and poorly defined environment.
Communication must be strongly supported, encouraged and practiced by all participants.
Self evaluation and modification is vital.
Other engineering techniques are in same environment
They try to control it
Agile works with it

19. Agile Principles Assume Simplicity Embrace Change
Software is Your Primary Goal
Enabling the Next Effort is your Secondary Goal
Incremental Change
Maximize Stakeholder Investment
Model with a Purpose
Assume Simplicity
Simplest solution is best
No extras until needed
Embrace Change
requirements change
People change
Understanding changes
Software is Your Primary Goal
documents
Management processes
Models
All means to an end, software is that end
Enabling the Next Effort is your Secondary Goal
Project can still be failure even if successfully delivered
Part of the game is to set up the next game
Incremental Change
unlikely you will get it right the first time
Detail is not a goal
Can always throw out incomplete model or add to one
Maximize Stakeholder Investment
use customer resources as best as possible
Empower the customer to make certain decisions
Model with a Purpose
gain understanding
Communicate ideas to others
Create documentation for next team

20. … Agile Principles Multiple Models Quality Work Rapid Feedback
Travel Light
Multiple Models
each job will likely need multiple models to describe it
Which ones are needed is project specific
Quality Work
needed to be sustainable (refactoring)
Needed for durability
Needed for debugging/maintenance/upgrading
Rapid Feedback
Critical
Eliminates miscommunication and wasted effort
Travel Light
Every time you decide to keep a model you trade-off agility for the convenience of having that information available to your team in an abstract manner (hence potentially enhancing communication within your team as well as with project stakeholders). Never underestimate the seriousness of this trade-off. Someone trekking across the desert will benefit from a map, a hat, good boots, and a canteen of water they likely won't make it if they burden themselves with hundreds of gallons of water, a pack full of every piece of survival gear imaginable, and a collection of books about the desert. Similarly, a development team that decides to develop and maintain a detailed requirements document, a detailed collection of analysis models, a detailed collection of architectural models, and a detailed collection of design models will quickly discover they are spending the majority of their time updating documents instead of writing source code.

21. Agile Practices Active Stakeholder Participation
Apply the Right Artifact(s)
An artifact is a modeling technique (graphical or textual) used during application development
Collective Ownership
Consider Testability
Create Several Models in Parallel
Active Stakeholder Participation
Acceptance
Feedback
Investment
Relationship
Apply the Right Artifact(s)
know what to use when
Know various techniques
Collective Ownership
get everyone to buy in
Sharing info
Sharing responsibility
Implementing suggestions
Consider Testability
can’t test it? Why doing it?
Create Several Models in Parallel
one model cannot capture all
One model may not convey something clearly, acurately

22. … Agile Practices Create Simple Content Depict Models Simply
Display Models Publicly
Iterate to Another Artifact
Model in Small Increments
Model with Others
Prove it with Code
Use the Simplest Tools
Create Simple Content
do not add future features
Simplify models, architectures when possible
Depict Models Simply
Do not put too much detail in one diagram
Make series, with each going into more detail.
Display Models Publicly
WOW, modeling wall
Open honest communication
Can be virtual but must be accessible
Iterate to Another Artifact
if you get stuck, go to another artifact
Model in Small Increments
increases agility
Deliver product more often
Allows for changes in direction without large losses
Model with Others
model with purpose – often model for someone
Often need the input of the people you will be modeling for
Prove it with Code
will it work?
Use the Simplest Tools
use simple tools – paper, whiteboard, cards
Increases participation and rapid feedback

23. Agile Communication

24. Sweet Spots Two to Eight People in One Room Onsite Usage Experts
One-Month Increments
Fully Automated Regression Tests
Experienced Developers
Drastically increase the effectiveness
Requirements
Planning
Design
Coding
Mention that these vary…

25. Self Adaptation
Traditional Software techniques, if at all, rarely do post-evaluations
Agile techniques use on-the-fly self adjustment to fine tune the methodology to the project.
Communication, trust, relevance and openness is key to success in agile processes.
Changing the team, the tools and the goals.

26. A Self Adaptation Technique
When ?
Right now
At the start of the project
In the middle of the first increment
After each increment
In the middle of subsequent increments

27. A Self Adaptation Technique
Ask to see one sample of each work product produced.
Ask for a short history of the project
Ask what should be changed
Ask what should be repeated
Identify priorities
Find Holes

28. Adaptation Conclusion
Post project Review ?
Reflection Workshops.
Most important rule of stabilizing and maintaining communication in agile processes :
BOTHER TO REFLECT

29. Specific Methods
Specific Agile methods and how they deal with requirements
XP (eXtreme Programming)
Crystal

30. eXtreme Programming (XP)

31. Extreme Programming
Not this kind of extreme…

32. Context
The roots of XP lie in the Smalltalk community, and in particular the close collaboration of Kent Beck and Ward Cunningham in the late 1980’s.
The crucial step from informal practice to a methodology occurred in the spring of 1996:
The Chrysler C3 project (Chrysler Comprehensive Compensation).
The roots of XP lie in the Smalltalk community, and in particular the close collaboration of Kent Beck and Ward Cunningham in the late 1980’s. Both of them refined their practices on numerous projects during the early 90’s, extending their ideas of a software development approach that was both adaptive and people-oriented.
The crucial step from informal practice to a methodology occurred in the spring of Kent was asked to review the progress of a payroll project for Chrysler. The project was being carried out in Smalltalk by a contracting company, and was in trouble. Due to the low quality of the code base, Kent recommended throwing out the entire code base and starting from scratch his leadership. The result was the Chrysler C3 project (Chrysler Comprehensive Compensation) which since became the early flagship and training ground for XP.

33. Values Communication Simplicity Feedback Courage ... Respect
Values. A value in the XP sense is a description of “how software development should feel”.
The value of communication represents the XP belief that communication between project members is key to a successful project (and hence needs to be supported by practices). Communication is viewed as the main enabler of coordination and collaboration in a project. In the XP sense, communication always means verbal communication.
The value of simplicity represents the XP belief that you should not invest into the future but only into your immediate needs. If future needs materialize as immediate needs at some point in the future, the proper application of XP practices will have put developers into a situation that lets them successfully cope with the new need. Underlying this value is the assumption that the future can not be reliably predicted and that taking care of it today is economically unwise.
The value of feedback represents the XP belief that it is important to have a running system at any time that gives developers reliable information about its functioning (here feedback is not feedback between humans but rather feedback about the development state). Effectively, the system and its code base serve as the incorruptible oracle to report about the progress and state of development. Feedback serves as a means for orientation and deciding where to go.
The value of courage represents the XP belief that humans are the single most significant aspect of software development. It is human courage that solves problematic situations and lets a team leave local optima behind to reach greater goals. The value of courage represents XP’s fundamental trust in humans to make a project succeed.
Respect. If members of a team don’t care about each other and what they are doing, XP is doomed.

34. Fundamental Principles
Rapid feedback
Assume simplicity
Incremental change
Embracing change
Quality work
The values are too vague to give us much help in deciding which practices to use. We need to distill the values into concrete principles we can use.
Principles. A principle in XP is something that we use to determine whether a practice is something that can be used successfully in an XP context.
Rapid feedback. Time between an action and its feedback is critical to learning. So, one of the principles is to get feedback, interpret it, and put what is learned back into the system as quickly as possible. The business learns how the system can best contribute, and feeds back that learning in days or weeks instead of months or years. The programmers learn how best to design, implement and test the system, and feed back that learning in seconds or minutes instead of days, weeks, or months.
Assume simplicity. Treat every problem as if it can be solved with ridiculous simplicity. In many ways, this is the hardest principle for programmers to swallow. We are traditionally told to plan for the future, to design for reuse. Instead, XP says to do a good job (tests, refactoring, communication) of solving today’s job today and trust your ability to add complexity in the future where you need it.
Incremental change. Big changes made all at once just don’t work. Any problem is solved with a series of the smallest changes that make a difference.
Embracing change. The best strategy is the one that preserves the most options while actually solving your most pressing problem.
Quality work. Everybody likes doing a good job. If you don’t enjoy your work, you don’t work well, and the project goes down the drain.

35. Activities Coding Testing Listening Designing
Testing. While all processes mention testing, most do so with a pretty low emphasis. However XP puts testing at the foundation of development, with every programmer writing tests as they write their production code. The tests are integrated into a continuous integration and build process which yields a highly stable platform for future development.
Design. Designing is creating a structure that organizes the logic in the system.

36. Practices (1/2) The Planning Game Small Releases Metaphor
Simple Design
Testing
Refactoring
Practices. A practice in XP is a technique that project members use to successfully carry out any of the aforementioned activities.
The Planning Game. Quickly determine the scope of the next release by combining business priorities and technical estimates. As reality overtakes the plan, update the plan.
Small Releases. Put a simple system into production quickly, then release new versions on a very short cycle.
Metaphor. Guide all development with a simple shared story of how the whole system works.
Simple Design. The system should be designed as simply as possible at any given moment. Extra complexity is removed as soon as it is discovered.
Testing. Programmers continually write unit tests, which must run flawlessly for development to continue. Customers write tests demonstrating that features are finished.
Refactoring. Programmers restructure the system without changing its behavior to remove duplication, improve communication, simplify, or add flexibility.

37. Practices (2/2) Pair Programming Collective Ownership
Continuous Integration
40-Hour Week
On-Site Customer
Coding Standards
Pair Programming. All production code is written with two programmers at one machine.
Collective Ownership. Anyone can change any code anywhere in the system at any time.
Continuous Integration. Integrate and build the system many times a day, every time a task is completed.
40-Hour Week. Work no more than 40 hours a week as a rule. Never work overtime a second week in a row.
On-Site Customer. Include a real, live user on the team, available full-time to answer questions.
Coding Standards. Programmers write all code in accordance with rules emphasizing communication through the code.

38. Strategies Management Strategy Facilities Strategy
Splitting Business and Technical Responsibility
Planning Strategy
Development Strategy
Design Strategy
Testing Strategy
Strategies. Strategies describe experiences and heuristics of how to successfully execute practices in the real world.

39. XP: User Stories One thing the customer wants the system to do
1-5 programming weeks
Should be testable

40. Note that it is quick and Dirty, simple

41. XP: Types of Risk addressed
Scheduling slips
Project canceled
System goes sour
Defect rate
Business misunderstood
Business changes
False feature rich
Explanation of each how XP addresses them:
1) Scheduling slips
Risk: Unable to complete by delivery date; have to delay delivery
2) Project cancelled
Risk: after numberous slips, project gets cancelled. Never implemented
3) System goes sour
Risk: put into production, but after a time cost of changes or defect rate make it necessary to replace the system
4) Defect rate
Risk: software put into production, but defect rate is so high it never gets used
5) Business misunderstood
Risk: software produced, but it does not solve the business problem it was designed for
i.e. req’ts error
6) Business changes
Risk: software produced, but business problem it was designed to solve six months ago has been replaced by a more pressing problem
7) False feature rich
Risk: many interesting features, few of which make any money for the customer
The ones that are related to requirments are (and illustrated in the story)…
XP attempts to reduce the risks of these by:
Scheduling slips
Short release cycles => scope of a slip is limited.
Highest priority features 1st => normally features that slip past are lower priority; can wait
2) Cancelation
If client has direct input and can prioritize the req’ts, still get business value up front
Customer is part of the team
Both customer and team learn more about software/needs as we progress
Shorter release cycle => less change during development of 1 release
Customer can substitute new functionality for functionality not yet completed
Highest priority tasks 1st
XP contract:
Can make it based on passing tests based on stories rather than implementation of req’ts
i.e. get paid in full if 80% of the tests pass, 20% less if only 60%, etc…
OR can make it based on some type of monthly burn rate…

42. XP: Strengths Negotiation and Cooperation, not Adversarial
Customer Involvement
Customer Ownership
IN TERMS OF REQ”TS
Cust Inv - availabilty of customers/experts minimizes delay from question to answer
Cust own - customers take ownership of the process by providing req’ts actively through user stories
more confident in the outcome

43. XP: Weaknesses Requires a lot of customer’s time
Absence of documentation
Restriction to small teams
Allegiance to current project
IN TERMS OF REQ”TS
requires a lot of the customer’s time
No doc – hard for new members to get up to speed
Pair programming helps though…
Small teams only
Needs tweaking to work for larger ones, but sometimes can
Allegience to current project
Tacit knowledge
Future maintenance – what if old team is gone?
Maybe video tape to help?

44. One reason XP avoid work products (like UML diagrams)…

45. Crystal Clear

46. Crystal: Goals & Core values
“Software development is viewed as cooperative game of intervention and communication, with a primary goal of delivering useful, working software and setting up the next game”
Cockburn, 2001
Family of shrink-to-fit, human-powered software development methodologies
Meant to be “ultralight”
- Reduces paperwork

47. The Crystal Family Criticality Number of people involved . . . Life
Prioritized for Legal Liability
Prioritized for Productivity & Tolerance
Life
(L) C6
C20
C40
C100
C200
C500
C1000 D6
D20
D40
D100
D200
D500
D1000 E6
E20
E40
E100
E200
E500
E1000 L6
L20
L40
L100
L200
L500
L1000
(defects cause loss of...)
Criticality
Essential
money
(E)
Discretionary
money
(D)
Comfort
(C)
1 - 6
- 20
- 40
- 100
- 200
- 500
- 1,000
Crystal Clear
Number of people involved
+20%

48. The Crystal Family of Methodologies
Crystal Clear
The Crystal Family of Methodologies
The Crystal family of methodologies is predicated in two things:
Capturing the elements that successful projects repeatedly cite as cause for their success
Give the team members the most latitude possible in doing their work
Different kinds of projects require different kinds of methodologies. Typically, projects differ in:
The number of people in the project
The consequences of errors
Alistair Cockburn has been working on methodology ever since he was tasked by IBM to write about methodology in the early 90’s. His approach is unlike most methodologists, however. Instead of building on solely personal experience to build a theory of how things should be done, he supplements his direct experience with actively seeking to interview projects to see how they work.

49. Crystal Clear
What’s Crystal Clear?
The Crystal Clear methodology addresses 4‑6 person projects.
Pretends to be the lightest full methodology that will still produce good results.
Recommendations from project members on these types of projects include:
Reduce the bureaucratic load
Increase communication
Increase the rate of feedback back to the team

50. Values Strong on communications. Light on deliverables.
Crystal Clear
Values
Strong on communications.
Light on deliverables.
Keep the communications paths short, rich and informal.
Deliver frequently.
Reduce overhead.
More deliveries and better communication reduce the need for intermediate work products.

51. In compliance with Crystal Clear (1/2)
You have short, rich communication paths.
You deliver increments regularly, no longer than 3 months apart.
You have a real user on the project, even if only part time.
You have a project mission statement, you are using usage-based requirements, probably use cases, and you have a description of the system design.
You have short, rich communication paths. That means you visit each other, draw on each other’s whiteboards (or better yet, printing whiteboards), look over each other’s shoulders at your programs and tests. You are sitting very close together, preferably one big room. You might be sitting in adjacent rooms, if there are really only 4-6 of you and you visit each other a lot. Recognize that the quality of communication drops the moment you have to pick up the phone or walk out the door.
You deliver increments regularly, no longer than 3 months apart. You schedule and track the project by milestones, preferably code execution milestones, not by document completion milestones.
You have a real user on the project, even if only part time. Your user helps you construct your screen sketches and both validates and breaks your UI designs. You get the system reviewed by real users al least once per increment prior to delivering it.
You have a project mission statement, you are using usage-based requirements, probably use cases, and you have a description of the system design using one of the many description techniques you can invent.

52. In compliance with Crystal Clear (2/2)
You have a clear ownership model for your work products.
There is a regression testing framework and you have regression tests for your system. You do some form of code peer reviewing.
You have a clear ownership model for your work products. For each class or module or use case, you know who it is that can change, update or, most importantly, delete parts of it. The answer may be either a single person, anyone in a given sub-team, or, rarely but possibly, anyone on the team. You should never have to have the whole team sit around the screen and ask, “Who put this in here? What is it doing here? Can we delete it?” If you have to do this, you know you have a breakdown in the ownership model.
There is a regression testing framework and you have regression tests for your system. You do some form of code peer reviewing. It might be daily, weekly or per increment.

53. Crystal Clear (2) Workproducts: release sequence
schedule of user viewings
use cases or feature descriptions
design sketches
common object model
running code
migration code
test cases
user manual
Each of these is officially “required”, but not strictly defined
Can take one out if not needed
Project documentation
Required, but not defined
Can be simply be pics of whiteboard drawings
Use cases written by business owners

54. Sample Lightweight Documentation

55. Crystal: Requirements Techniques
Use Cases
Communication tools
Anything from other methods…
Use cases written by business owners
Understanding that develpers need background knowledge and terminology to undertand them.
Will not magically understand req’ts from use cases
Case studies of using Crystal included:
user stories
Prioritizing cards and affinity analysis
JAD

56. Crystal: Strengths Scalable Variable project risk Adaptable
Based on human communication

57. Crystal: Weaknesses Lack of defined structure
Does not optimize production or documentation

58. Comparison of Agile Processes

59. Agile and SASD Agile SASD Business value for the customer/user
Develop as quickly and cheaply as possible
Use models and work products to ensure quality
Involve the user in development
User is involved early on, but not during development
Iteratively elicit requirements (negotiation/emergence)
With req’ts established, sequentially follow process model
Priority on eliminating unneeded req’ts
Priority on traceability and work products
amount of documentation can be a benefit for either one
For SASD, gives new team members something to work from
For Agile, less work…
NO checkmarks…

60. Conclusions

61. Should you go light?
The following factors suggest an adaptive process:
Uncertain or volatile requirements
Responsible and motivated developers
Customer who understands and will get involved
These factors suggest a predictive process:
A team over fifty
Fixed price, or more correctly a fixed scope, contract

62. Which Adaptive Process?
Team size and discipline.
XP imposes a stronger discipline than any of the others.
ASD focus on developing good-enough software.
Crystal Clear appears to be the “lightest of the light”.
Take charge of your process, monitor it and adapt it to your circumstances.

63. References

64. References (1/3)
Martin Fowler. “The New Methodology”. Abridged version published in Software Development Magazine, December 2000.
Dirk Riehle. “A Comparison of the Value Systems of Adaptive Software Development and Extreme Programming: How Methodologies May Learn from Each Other”. SKYVA International, 2000.

65. References (2/3)
Jim Highsmith. “Messy, Exciting and Anxiety-Ridden: Adaptive Software Development”. Published in American Programmer Magazine, April 1997.
Jim Highsmith. “Adaptive Software Development”. Presented at OOPSLA 2000.
Kent Beck. Extreme Programming Explained: Embrace Change. Addison‑Wesley, 2000.

66. References (3/3)
Mike Beedle, Martine Devos, Yonat Sharon, Ken Schwaber, Jeff Sutherland. “SCRUM: A Pattern Language for Hyperproductive Software Development.” In Pattern Languages of Program Design 4. Edited by Neil Harrison, Brian Foote, and Hans Rohnert. Addison‑Wesley, Page
Alistair Cockburn. Crystal “Clear”. AOL, 2000.

67. Sources Adapted from “Lightweight Methodologies” by Dias
(Slides 2-4, 32-38, 48-53, 61-62,64-66)
“Requirements Engineering in Agile Approaches” by Balas, Fournie, & Luo
(Slides 5-6, 12-28, 31, 39-44, 46, 54-59)