UNIT 1: AGILE

• Agility
○ "The ability to both create and respond to change in order to profit in
a turbulent environment."
• Agile
○ Philosophy and a set of Guidelines for software development
○ Philosophy
 Customer satisfaction
 Early incremental delivery
 Small, highly motivated project teams
 Overall development simplicity
○ Guidelines
 Active continuous communication and Collaboration between
developers and users
• Benefits
○ Customer satisfaction, by rapid delivery
○ Welcome changing requirements, even late in development
○ Working software is delivered frequently, weeks rather than months
○ Working software is the principal measure of progress
○ Co-location - face to face conversation
○ Simplicity
○ Self-organizing teams
• Agile Methods
Agile methods are processes that support agile philosophy

Randula Tharaka

Page 1
 Randula Tharaka

Page 2
○

 Scrum

 Lean
1993 by Robert Charette
□ Five-Core Pillars
 Value
 Value Stream
 Flow
Randula Tharaka
Pull
Page 3
 Randula Tharaka

Page 4
  Pull
 Perfection
□ 7-principles
 Eliminate Waste
 Amplify Learning
 Decide as Late as Possible
 Deliver as Fast as Possible
 Empower the Team
 Build Integrity in
 See the Whole

 Kanban
It uses a system of physical card to limit the quantity of work-in-
progress at any given stage in the workflow.
□ 3 - Basic Principles
 Start with what you do now
 Agree to pursue incremental, evolutionary change
 Respect the current process, roles, responsibilities &
titles
□ 5 Core Properties
 Visualize the workflow
 Limit Work In Process (WIP)
 Mange Flow
 Make Process Policies Explicit
 Improve Collaboratively

 Extreme Programming
□ Improve Software Quality and responsiveness to changing
customer requirements
□ Frequent releases in short development cycles
□ Improve productivity and regular checkpoints with the
customer
□ Paired programming

• Agile Practices
Agile methods consist of individual elements called practices
 Version control
 Coding standards
Randula Tharaka

Page 5
 Randula Tharaka

Page 6
• Agile Development
Focuses on achieving
 Personal Successes
 Technical Successes
 Organizational Successes
• Agile Manifesto
○ Individuals and interactions over processes and tools
○ Working software over comprehensive documentation
○ Customer collaboration over contract negotiation
○ Responding to change over following a plan

• 12 - Principles - behind the agile manifesto

1. Customer satisfaction by rapid, continuous delivery of valuable
software
2. Welcome changing requirements, even in late development
3. Working software is delivered frequently (weeks rather than months)
4. Close, daily cooperation between business people and developers
5. Projects are built around motivated individuals, who should be
trusted
6. Face-to-face conversation is the best form of communication (co-
location)
7. Working software is the principal measure of progress
8. Sustainable development, able to maintain a constant pace
9. Continuous attention to technical excellence and good design
10. Simplicity- the art of maximizing the amount of work not done-is
essential
11. Best architectures, requirements, and designs emerge from self-
organizing teams
12. Regularly, the team reflects on how to become more effective, and
adjust accordingly

• Agile Principles
○ Variability and Uncertainty
1. Embrace helpful variability
2. Employ iterative and incremental development
3. Leverage variability through inspection
4. Reduce all forms of uncertainty simultaneously
○ Prediction and Adaptation
Randula Tharaka

Page 7
 Randula Tharaka

Page 8
 1. Keep option open
2. Accept that you can't get it right up front
3. Favor an adaptive, exploratory approach
4. Embrace change in an economically sensible way
5. Balance predictive up-front work with adaptive just-in-time
work
○ Validated Learning
1. Validate important assumption fast
2. Leverage multiple concurrent learning loops
3. Organize workflow for fast feedback
○ Work In Process (WIP)
1. Use economically sensible batch sizes
2. Recognize inventory and manage it for good flow
3. Focus on idle work, not idle workers
4. Consider cost of delay
○ Progress
1. Adapt to real-time information and re-plan
2. Measure progress by validating working assets
3. Focus on value-centric delivery
○ Performance
1. Go fast but never hurry
2. Build in quality
3. Employ minimally sufficient ceremony

• Comparison Summary of Plan-Drive & Agile Principles

Randula Tharaka

Page 9
 Randula Tharaka

Page 10
 Randula Tharaka

Page 11
 Randula Tharaka

Page 12
 Randula Tharaka

Page 13
 Randula Tharaka

Page 14
 UNIT 2: SCRUM
• Scrum
○ It’s a time-boxed, iterative incremental approach for agile software
development.
During each iteration, a self-organizing, cross functional team perform all
of the work.
Origin - 1993: Jeff Sutherland, Ken Schwaber and their team at Easel
Corporation

○ Benefits
○ Delighted customers
○ Improved ROI
○ Reduced costs
○ Fast results
○ Phases
○ Pre-game
 Understand/ clarify requirements
 Document, review and refine requirements - generate product
backlog
 Estimate the effort required for the phase
 Perform planning activities required for the phase
Deliverables
 Software requirements specification
 High-level Architecture & Design document
Randula Tharaka

Page 15
  Deployment model
 Project Schedule (high-level milestones, etc.)
 Quality Assurance Test Strategy/ Plan
User Stories
 Very slim and high-level requirements artifacts
○ Sprints
 Once team has committed, no changes to sprint scope, sprint
duration or to deliverables
○ Post-game
Requirements satisfied
 Sprint Demo
□ A walkthrough of all the functionalities developed in that
particular spring in order to collect client feedback
 Sprint Retrospective
○ Monitor Progress
○ Burn-down charts
 Iteration
 Release

○ Velocity
 Number of total story points ÷ One iteration
• Roles
○ Product Owner
Who Randula Tharaka

Page 16
 ○ Who
 The product owner represents the product's stakeholders and
the voice of the customer, and is accountable for ensuring that
the team delivers value to the business. Who,
 Share the product vision/goals with the team
 Identify, prioritize and clarify the requirements
 Provide feedback
○ Responsibilities
 Manage Economics
 Groom the product backlog - (groom-creating, refining
estimating and prioritizing product backlog items)
 Participate in planning
 Collaborate with the development team
 Collaborate with the stakeholders - to gather input and guide
 Define acceptance criteria (acceptance tests) and verify that
they are met
○ Characteristics/ Skills
 Domain skills
 People skills
 Decision making
 Accountability
○ Product Owner Team

○ Scrum Master
○ Who
 Scrum Master is the facilitator, focused on helping everyone
understand and embrace the scrum values, principles, and
practices. Who,
 Removes obstacles faced by the team
 Assist the team in achieving the iteration goals
 Coach the team on scrum principles (for both development team
and the product owner)
○ Responsibilities
 Coach
 Process authority
 Servant leader
 Impediment remover
Randula Tharaka
Change agent
Page 17
  Change agent
○ Characteristics/ Skills
 Knowledgeable
 Questioning
 Patient
 Collaborative
 Protective
 Transparent
○ Development Team
○ Who
 Cross-functional collection of architect, programmer, tester,
database administrator, UI designer etc.
○ Responsibilities
 Perform Sprint Execution
 Inspect and Adapt Each day
 Groom the Product Backlog
 Plan the Sprint
 Inspect and Adapt the product and process
○ Characteristics/ Skills
 Self-organizing
 Cross-functionally diverse and sufficient
 T-shaped skills
 Musketeer Attitude
 High-bandwidth communications
 Transparent communication
 Focused and committed
 Works at sustainable pace
 Long-lived

• Scrum Activities and Artifacts

○ Product Backlog
○ The Product backlog is a prioritized list of desired product
functionality. It is usually consisted of Product Backlog Items such as
features, defects, technical work, and knowledge acquisition which
are gathered from product owner and development team and other
stakeholders.
○ The product owner is responsible for prioritizing them, so that high-
valued items appear at the top of the product backlog.
○ Product backlog is a constantly evolving artifact. Activity of Creating,
refining, estimating, and prioritizing product backlog items is known
as Grooming.
Randula Tharaka

Page 18
○ Sprints
○ Work performed in iterations or cycles of one week up to a calendar
month called Sprints.
○ The work completed in each sprint should create something of
tangible value or a shippable product to the customer or user in
conformance with agreed definition of done.
○ Sprints are Time-Boxed meaning they have fixed start and end dates.
Generally they should be short and consistent in duration.
○ As a rule in general any goal-altering changes in scope or personnel
during a sprint are not permitted.
○ Time-boxing benefits
 Establishes a WIP limit
 Forces prioritization
 Demonstrates progress
 Avoids unnecessary perfectionism
 Motivate closure
 Improves predictability
○ Definition of Done is a checklist of the types of work that the team is
expected to successfully complete before It can declare its work to be
potentially shippable.
○ Sprint Planning
○ Sprint planning is a recurring, just-in-time activity that is performed
by product owner, development team, and scrum master at the
beginning of each sprint to determine the most important subset of
product backlog items to build in the next sprint.
○ During sprint planning, the product owner and development team
agree on a Sprint Goal that defines what the upcoming sprint is
supposed to achieve.
○ Combination of Product backlog items and Sprint Plan forms the
Sprint Backlog.
○ Inputs for Sprint Planning
Randula Tharaka
Product backlog

Page 19
  Product backlog
 Team velocity
 Constraints
 Team capabilities
 Initial sprint goal
○ Sprint Execution
○ Sprint Execution is the work the scrum team performs to meet the
sprint goal and which accounts for the majority of time during a
sprint.
○ Analyzing, designing, coding, testing
○ Flow Management
○ Flow Management is the team's responsibility to manage the flow of
work during sprint execution to meet the sprint goal.
○ It must make decisions such as,
 Parallel work and swarming?
 What work needs to be done
 When work should start?
 Who does the work
 How to organize task work
○ Daily Scrum
 Daily scrum is an inspection, synchronization, and adaptive
daily planning activity to help the development team to manage
fast, flexible flow of work within a sprint.
 It's a 15 minute, time boxed activity which takes place once
every 24 hours.
 The Goal is to get together and share the big picture of what is
happening so that they can collectively understand,
□ How much to work on
□ Which items to start working on
□ How to best organize the work among the team members
○ Communicating
Since the team size is small, scrum team uses simple charts such as
Task board and Burn-down and/or Burn-up charts to communicate
the progress.
 Task Board
The task board shows the evolving state of the sprint backlog
over time.

Randula Tharaka

Page 20
 Sprint Burn-down Chart
It’s a chart team members update during sprint execution to
display how much effort remains for each uncompleted task

 Sprint Burn-up Chart

Another chart helps to visualize progress through a sprint.

The work can be represented in either effort-hours or in story

points.
Randula Tharaka

Page 21
○ Sprint Review
Sprint Review is one of important inspect-and-adapt activities which
takes place at the end of the sprint and it focuses on the product itself.
Occurs after sprint planning and before the sprint retrospective
The goal of this activity is to inspect and adapt the product that has being
built so far.
Scrum team, internal and external stakeholders take part in this and can
ask questions, make observations or suggestions and have discussion
about how to best move forward given current realities.
○ Participants

○ Pre-work to complete for the sprint Review.

 Determine whom to invite Randula Tharaka

Page 22
  Schedule the activity
 Confirm that the sprint work is done
 Prepare for the demonstration
 Determine who will lead the meeting and who will give the demo
○ Approach
 Provides a summary of what has and has not been accomplished
 A demonstration of the increment
 Discuss the current state of the product, and adapting the future
product direction.
○ Outputs of the Sprit Review are Groomed product backlog and
updated release plan.
○ Issues
 Sing-offs - it's not clear if the sprint review is a proper sing off-
product backlog items should have already been "approved" by
product owner before the sprint review start.
 Sporadic attendance - isolated attendance
 Large development efforts - having multiple scrum teams make
it difficult to decide on attending

○ Sprint Retrospective
Sprint Retrospective is the second important inspect-and-adapt activities
which takes place at the end of the sprint after the sprint review is done.
Goal of this activity is to inspect and adapt the process used to build the
product.
○ During the sprint retrospective the development team, scrum master, and
product owner come together to discuss what is and is not working with
scrum associated practices, by asking questions such as
○ What worked well this sprint that we want to continue doing?
○ What didn't work well this sprint that we should stop doing?
○ What should we start doing or improve?
Based on their discussions, team members determine a few actionable
changes to make and the get on with the next sprint with an
incrementally improved process.
○ Pre-work
 Define the retrospective focus
 Select the exercises
 Gather objective data
 Structure the retrospective
○ Approach
 Set the atmosphere
 Create a shared context among the participants (even timeline)
 Identify insights that can lead to improvements determineRandula Tharaka
concrete

Page 23
 concrete
 Improvement actions to take during the next sprint
 Close the retrospective
○ Outputs
 A set of concrete improvement actions that the team has agreed
to perform in the next sprint
 A backlog of insights collected during the current retrospective
that the team will not address in the upcoming sprint but might
choose to address in the future
 Improved camaraderie

○ Issues
 Not doing the retrospective or low attendance
 All fluff, no stuff
 Ignoring the elephant in the room
 Poor facilitator
 Depressing and energy draining
 Blame game
 Complaint session
Replaces ad hoc process improvement Randula Tharaka

Page 24
  Replaces ad hoc process improvement
 Too ambitious
 Not follow-through
○ Requirements and User Stories
○ Estimation and Velocity

○ Scrum Planning
○ Principles
 Can't get the plans right up front
 Up-front planning should be helpful without being excessive
 Keep planning option open until the last responsible moment
 Focus more on adapting and re-planning than on conforming to
a plan
 Correctly manage the planning inventory
 Favor smaller and more frequent releases
 Plan to learn fast and pivot when necessary
○ Traditional Projects: Creates a detailed plan up-front before
development work begin
○ Scrum Projects: Does not believe it can be done in the very beginning
although it performs multiple level of up-front planning, and favors
just-in-time planning as the project continues.

○ Multilevel Planning
Plan at multiple level of detail and at multiple times throughout
product development.

Randula Tharaka

Page 25
 Portfolio Planning
Portfolio planning is an activity for determining which portfolio
backlog items to work on, in which order, and for how long. A
portfolio backlog item can be a product, a product increment
(one release of a product), or a project.
 Portfolio planning deals with a collection of products and is
therefore larger in scope and higher level than individual
product-level planning.
 Timing
□ A never ending activity
□ The output of product-level is an important input to
portfolio planning. - determines whether to fund the
product and how to sequence it into portfolio backlog
 Participants
□ Because portfolio planning focuses on both new Product
and in-process products, its participants include and
appropriate set of internal stakeholders, the product owners
of individual products and senior architects and technical
leads.
 Process
□ Scheduling
□ Managing inflows
Randula Tharaka
Managing outflows

Page 26
 □ Managing outflows
□ Managing in process products

Portfolio planning has two outputs.

 Portfolio backlog - prioritized list of future products
approved to develop, but hast not yet begun
 Set of active products - new products and in-process-
products which have been approved for immediate
development

 Product Planning (Envisioning)

It involves captures the essence of a potential product and
creating a rough plan for the creation of the product.
Envisioning begins with the creation of a vision, followed by the
creation of a high-level product backlog and frequently a product
roadmap.
 Product Vision
□ Provides a clear description of the areas in which the
stakeholders, such as users and customers, get value
 Product Roadmap
□ Communicates the incremental nature of how the product
will be built and delivered over time.
 Participants
□ Product owner
□ Internal stakeholders
□ Specialists in various areas

 Release Planning
Release planning is a high level long-term planning for multiple
sprints and also a guideline that reflects expectations about
which features will be implemented and when they are
completed and what the cost will be.
 Different schedules of releasing features
□ Release after multiple sprints
□ Release every sprint
□ Release every feature
 Inputs - outputs of Product Planning
□ The product vision
□ High-level product backlog
□ Product roadmap
 Participants
□ Collaboration between stakeholders and the full scrum
team Randula Tharaka

Page 27
 team
 Refine Minimum Releasable Features (MRFs)
□ "must have" features should be built to be in a release which
meet customer value and quality expectations.
 Sprint Mapping (PBI Slotting)
□ Sprint mapping is an activity to tentatively slot or map
appropriately detailed, estimated, and prioritized product
backlog items into specific future sprints.
□ approach - approximate a set of product backlog items for
each sprint by grouping together items whose aggregate
size roughly equals the team's average velocity.
□ Fixed-Date Release Planning
 Determine how many sprints are in this release
 Groom the product backlog
 Measure or estimate the team's velocity
 Multiply the slower velocity by the number of sprints
(will-have line)
 Multiply the faster velocity by the number of sprints
(might-have line)

□ Fixed-Scope Release Planning

 Groom the product backlog
 Determine the total size of the product backlog items
(PBIs)
 Estimate the team's velocity as a range
Randula Tharaka
Divide the total size of the PBIs by the faster velocity

Page 28
  Divide the total size of the PBIs by the faster velocity
(round up)
 Divide the total size of the PBIs by the slower velocity
(round up)
□ Calculating Cost
 Identify the team
 Determine the sprint length
 Based on team composition and sprint length,
determine the personnel costs of running a
sprint.
For a fixed-date release
◊ multiply the number of sprints in the release by
the cost per sprint.
For a fixed-scope release
◊ multiply both the high and low number of sprints
by the cost per sprint.

 Sprint Planning
 Daily Planning - via daily scrum- page 264

Randula Tharaka

Page 29
 UNIT 3: XP
• Extreme Programming (XP)
○ Extreme Programming eliminates working on long phases such as
planning, analysis, design and testing and their associated
documentation, although it performs necessary significant planning,
analysis, design and testing and coding every day.
○ Involves high-bandwidth communication, cross-functional and
practices tuned for short, time-boxed iterations which enables to
produce potentially shippable software at the end of the each
iteration.
○ Each iteration starts with a brief planning session and ends with an
internal review, product demo and retrospective
• The XP Team
○ On-Site Customers
Responsibilities
 Identify and communicate features and requirements and
stories
 Evangelize/promote the project's vision
 Create achievable plan by coordinating with programmers and
playing the planning game
 Defining software
 Manage risks

People
 Product managers
□ Maintain and promote the product vision
□ Incorporate feedback
□ Generate features and stories
□ Set priorities for release planning
□ Providing direction for the team's on-site customers
□ Review work in progress
□ Lead iteration demos
□ Involve with real customers
□ Deal with organizational politics
 domain experts
□ Spend most of their time with the team, figuring out the
details of upcoming stories and standing ready to answer
questions when programmers ask.
interaction designers Randula Tharaka

Page 30
  interaction designers
□ Focuses on understanding users, their needs, and how they
will interact with the product.
 business analysts
□ Clarify and refine customer needs and help programmers
express technical trade-offs in business terms.

○ Programmers
 Responsible for finding the most effective way of delivering the
stories in the plan
 Provide effort estimates, suggest alternatives, and help
customers create an achievable plan by playing the planning
game.
 Using test-driven development, they write tests, implement
code, refactor, and incrementally design and architect the
application.
○ Testers
 Help customers identify holes in the requirements and assist in
customer testing
 Provide information about the software's nonfunctional
characteristics, such as performance, scalability, and stability by
using both exploratory testing and long-running automates
tests.
○ Coaches
 XP leaders are called coaches. They lead by example, help to set
up conditions for energized work, and they assist the team in
creating an informative workspace.
 Take responsibility for any reporting needed.
 Programmer- Coach
 Project manager-Coach
□ Good at coaching, non-programming practices

○ Other Team Members

 Technical writer
 Analyst
 Product manager
□ Maintain and promote product vision

You don't have to have one person for each role-some people can fill
multiple roles.
Randula Tharaka
4 to 10 programmers (5 to 20 total members)

Page 31
 4 to 10 programmers (5 to 20 total members)
6 programmers - 4 customers, 1 tester, 1 project manager = 12 Team

• XP Practices
○ Pair Programming
 Doubles the brainpower available during coding, and gives one
person in each pair the opportunity to think about strategic,
long-term issues.
 Driver and the navigator
 Switch partners and roles frequently
 Produce code through conversation. Collaborate, don’t critique.
○ Energized Work
 Acknowledges that developers do their best, most productive
work when they're energized and motivated.
 Work only as many hours as you can be productive and only as
many hours you can sustain
○ Informative Workspace
 Gives the whole team more opportunities to notice what's
working well and what isn't.
 Broadcasts information into the room
 Includes story board with,
□ User story cards
□ Displaying not-started, in progress, done columns
□ Release and/or iteration burn down charts
□ Automated indicators showing the status of the latest unit-
test run
Often conduct daily standups meetings near their story boards.

Randula Tharaka

Page 32
 ○ Root-Cause Analysis
 Is a useful tool for identifying the underlying causes of problems.
 Prevent mistakes by fixing the process
○ Retrospective
 Provide a way to analyze and improve the entire development
process.
□ Iteration retrospective
□ Release retrospective
□ Project retrospective
□ Surprise retrospective

• Collaboration in XP
8 practices to help XP team and its stakeholders collaborate efficiently
and effectively
○ Trust
 A series of group dynamics
□ Forming, Storming, Norming, and Performing
 Build the trust by taking time to help others
 Need to trust the you'll be treated with respect when you ask for
help or disagree with someone
 Strategies to generate trust in the team
 Team Strategies
□ Customer-Programmer Empathy
□ Programmer- Tester Empathy
□ Eat Together
Team Continuity Randula Tharaka

Page 33
 □ Team Continuity
 Organizational Strategies
□ Show some Hustle
□ Deliver on Commitments
□ Mange Problems
□ Respect Customer Goals
□ Promote the Team
□ Be Honest
○ Sit Together
 The idea behind it is to stimulate the information exchange by
making it simple to just turn to the colleague and ask.
 Encourage free conversation leads to the much quicker
information exchange.
 Eliminates waste of time caused by waiting for an answer.

○ Real Customer Involvement

Is a key part of XP where the customer is part of the development
team.
The role of the customer is:
 To develop stories that define requirements
Randula Tharaka
To help prioritize the features to be implemented in each

Page 34
  To help prioritize the features to be implemented in each
release.
 To help develop acceptance tests which assess where or not the
system meets its requirements.
Contradictions: Danger of involving real customers
Alternatives:
○ Ubiquitous Learning
Involves designing and managing the code and the system as it
reflects language of the domain, so that the stakeholders like domain
experts and project managers can relate to and understand easily.
Naming classes, methods, and variables relate to language of the
domain.
○ Stand-up Meetings
A daily meeting up to 15 minutes where the XP team including
customer get together and identify items to be accomplished and
raise issues.
○ Coding Standards
Coding standards keep the code consistent and easy for the entire
team to read and refactor
Code must be formatted to agreed coding and standards.
○ Iteration Demo
A demonstration of the product increment and the team's progress
which take place once in every week end of the each iteration.
Usually last about 10 minutes
○ Reporting
 Weekly product demos
 Release and Iteration Plans
 Burn-up Chart
 Roadmap
 Status email
 Productivity reports
 Throughput reports
 Defects reports
 Time usage reports - to explain velocity

• Product Releasing in XP
○ "Done Done"
 It determines if bugs have been identified and fixed and
customers have reviews the story and agree its complete.
No Bugs Randula Tharaka

Page 35
 ○ No Bugs
Rather than fixing bugs, agile methods strive to prevent them.
 Test-driven development structures work into easily-verifiable
steps
 Pair programming provides instant peer review, enhances
brainpower, and maintains self-discipline
 Energized work reduces silly mistakes.
 Coding standards and a "done done" checklist catch common
errors
 On-site customers clarify requirements and discover
misunderstandings
 Iteration demos allow stakeholders to correct the team's course
 Customer tests communicate complicated domain rules.
 Simple design, refactoring, slack, collective code ownership and
fixing bugs early eliminates bug breeding grounds.
 Exploratory testing discovers team's blinding spots, and root-
cause analysis allows teams to eliminate them.
○ Version Control
Provides a central repository that helps coordinate changes to files
and also provides a history of changes.
○ Ten Minute Build
It acknowledges build, test and deploy entire product at any time
with push of a button.
○ Continuous Integration
○ It acknowledges to integrate every few hours and keep build, test and
other release infrastructure up to date.
○ Collective Code Ownership
With collective code ownership, everyone shares responsibility for
the quality of the code, as well as anyone can make any necessary
changes anywhere and everyone is expected to fix problems they
find.
○ Documentation
○ Work-in progress documents
○ Product documents
○ Hand-off documents
• Planning Process in XP
○ Vision
Reveals where the project is going and why it's going there
○ Release Planning
Provides a roadmap for reaching your destination Randula Tharaka

Page 36
 ○ The Planning Game
Comines the expertise of the whole team to create achievable plans
○ Risk Management
Allows the team to make and meet long-term commitments
○ Iteration Planning
Provides structure to the team's daily activities
○ Slack
Allows the team to reliably deliver results every iteration
○ Stories
Form the line items in the team's plan
○ Estimating
Enables the team to predict how long their work will take
• Product Development in XP
○ Incremental Requirements
Allow the team to get started while customers work out requirements
details
○ Customer Tests
Help communicate tricky domain rules
○ Test-Driven Development (TDD)
Allows programmers to be confident that their code does what they
think it should
○ Refactoring
Enables programmers to improve code quality without changing its
behavior
○ Simple Design
Allows the deign to change to support any feature request, no matter
how surprising
○ Incremental Design and Architecture
Allows programmers to work on features in parallel with technical
infrastructure
○ Spike Solutions
Use controlled experiments to provide information
○ Performance Optimization
Enables testers to identify gaps in the team's though processes

Randula Tharaka

Page 37