Week 3 Study Notes
Agile Software Development
Based on Pressman & Maxim — Software Engineering, Chapter 5
KEY DEFINITIONS
Agile Development: An approach to software development where requirements and solutions
evolve through collaboration between self-organising cross-functional teams. It promotes
adaptive planning, early delivery, and continuous improvement.
Agile Manifesto: A 2001 declaration by 17 software practitioners outlining core values and
principles for agile software development. It prioritises individuals, working software, customer
collaboration, and responding to change.
Increment: A working, usable piece of software delivered at the end of a short development
cycle. Each increment adds functionality to the previous one.
Iteration: A short, fixed-length cycle (usually 1–4 weeks) during which a team designs, builds,
and tests a portion of the software.
Extreme Programming (XP): An agile method developed by Kent Beck that applies iterative
development to the extreme — with very short release cycles, test-first coding, continuous
integration, and pair programming.
Scrum: A lightweight agile framework for managing and controlling software development. It
organises work into fixed-length Sprints, defines three specific roles, and uses a set of artifacts to
track progress.
Sprint: A fixed time-box (1–4 weeks) in Scrum during which the team produces a working
product increment. Sprints have a fixed length and do not change mid-sprint.
User Story: A short, informal description of a software feature written from the perspective of the
end user. Format: 'As a [user], I want [goal] so that [reason].' Used in XP and Scrum to capture
requirements.
Product Backlog: An ordered list of everything that needs to be done on a product, maintained
by the Product Owner. Items are written as User Stories and prioritised by business value.
Sprint Backlog: The subset of Product Backlog items the Scrum team commits to delivering
during a single Sprint, along with a plan for doing so.
Test-First Development (TDD): A practice where automated tests are written before the actual
code. The developer writes a failing test, then writes the minimum code to pass it, then refactors.
Ensures code meets its specification from the start.
Refactoring: The process of restructuring existing code without changing its external behaviour.
Goal is to improve readability, reduce complexity, and make future changes easier.
Pair Programming: An XP practice where two developers work together at one computer. One
writes code (the 'driver') while the other reviews it in real time (the 'navigator'). Roles rotate
regularly.
Continuous Integration: The practice of merging all developers' working copies into a shared
codebase several times a day, followed by an automated build and test run.
Burndown Chart: A graphical representation of work remaining versus time. Used in Scrum to
track Sprint or release progress. A downward-sloping line shows work being completed.
WIP (Work in Progress): Tasks that have been started but not yet completed. Limiting WIP
(especially in Kanban) is a key practice for reducing bottlenecks and maintaining flow.
Refactoring: Restructuring existing code to improve its internal structure without changing
observable behaviour. Examples include renaming variables, removing duplicate code, and
extracting methods.
Velocity: A Scrum metric measuring how much work a team completes per Sprint (usually in
story points). Used to forecast how much can be done in future sprints.
Epic: A large, high-level User Story that is too big to complete in a single Sprint. Epics are broken
down into smaller User Stories during backlog refinement.
Definition of Done: A shared team agreement on the criteria a product increment must meet
before it is considered complete (e.g. coded, tested, reviewed, and deployable).
1. WHY AGILE?
Traditional plan-driven development assumes stable requirements — define everything upfront,
then build. This fails in modern business where requirements change constantly.
Core idea of Agile:
• Interleave specification, design, and implementation instead of separating them
• Deliver working software in short cycles (increments)
• Involve the customer throughout, not just at start and end
• Minimise documentation — focus on working code
Agile works best when:
• Building small or medium-sized products
• Customer is available and committed to ongoing involvement
• Requirements are expected to change
• Few external regulations or compliance requirements
Agile struggles when:
• Customer cannot commit time to the development team
• Teams are large or geographically distributed
• Heavy regulatory or safety requirements apply
• Team members lack experience with self-organising work
Note: Key difference from plan-driven: In plan-driven, iteration happens within each stage. In agile, iteration
happens across all stages simultaneously.
2. THE AGILE MANIFESTO
Written in 2001 by 17 software practitioners. The manifesto does not reject process — it
re-prioritises what matters most. Four core values:
We value MORE... ...over LESS (but still valued)
Individuals and interactions Processes and tools
Working software Comprehensive documentation
Customer collaboration Contract negotiation
Responding to change Following a plan
Note: Important: The right column is not worthless — the manifesto says the left column is MORE valuable,
not that the right is ignored entirely.
3. AGILE PRINCIPLES
Five key principles guide how agile teams work:
Principle What It Means
Customer involvement Customer continuously provides and prioritises requirements, and evaluates each iteration —
Incremental delivery Software is built in small, usable pieces. The customer specifies what goes into each incremen
People not process Trust the team to define their own working practices. Don't over-prescribe how work gets done
Embrace change Design the system expecting requirements to change. Build in flexibility from the start.
Maintain simplicity Actively remove complexity from both the software and the development process. Simplicity re
Difficulties with Agile in practice:
• Requires a committed customer who can spend regular time with the team
• Some developers don't suit the intense collaboration style
• Prioritising changes when many stakeholders disagree is very difficult
• Maintaining simplicity actually requires extra ongoing effort
• Large organisations resist informal, team-defined processes
• Contracts are hard to write — agile prefers time-based contracts over fixed-scope ones
4. PLAN-DRIVEN vs. AGILE
Neither approach is universally better. The right choice depends on the organisation, team skills,
and nature of the product. Most real projects use a mix.
Aspect Plan-Driven Agile
Structure Separate stages with defined outputs Design & implementation are central; other activities embedd
Iteration Within each stage Across all stages simultaneously
Documentation Extensive and formal Minimal — focus on working code
Requirements Defined fully upfront Evolve throughout development
Best for Safety-critical, regulated systems Fast-changing business software
5. EXTREME PROGRAMMING (XP)
Developed by Kent Beck in the late 1990s. XP is the best-known agile method. It takes an 'extreme'
approach — if incremental delivery and testing are good practices, do them as often and as
thoroughly as possible.
Defining features of XP:
• New builds may be created several times per day
• Increments delivered to customers every 2 weeks
• All tests must pass before any build is accepted
XP is most influential through its specific practices. Many teams adopt individual XP practices
without following the full XP process. The four most widely adopted are: User Stories, Refactoring,
Test-First Development, and Pair Programming.
XP Practices — Full List
Practice Description
Incremental planning Requirements written on story cards. Team breaks them into tasks for scheduling and cost estimat
Small releases Deliver the minimal useful functionality first, then grow incrementally. Releases are very frequent.
Simple design Only design enough to meet current requirements. No speculative future-proofing.
Test-first development Write automated tests before writing the code. Forces clarity about interface and behaviour before
Refactoring Continuously restructure code to keep it clean and simple. Do it constantly, not in a big batch later.
Pair programming Two developers share one computer. One writes, one reviews. Roles swap regularly.
Collective ownership Any developer can change any part of the codebase. No silos of expertise — everyone is responsi
Continuous integration Completed tasks integrated into the full system immediately. All unit tests must pass after every int
Sustainable pace No excessive overtime. Overwork reduces code quality and medium-term productivity. Work at a p
On-site customer A customer representative is a full-time member of the XP team, available to answer questions and
6. REFACTORING
Conventional wisdom in software engineering says 'design for future change.' XP disagrees — you
cannot reliably predict future changes, so don't waste time trying. Instead, keep current code clean
so that when changes come, they're easy to make.
Benefits of refactoring:
• Improves code understandability, reducing need for documentation
• Makes future changes easier to implement
• Spreads knowledge — the whole team benefits when any developer improves shared code
Common examples of refactoring:
• Reorganising a class hierarchy to remove duplicate code
• Renaming variables, attributes, or methods to make their purpose clearer
• Replacing inline code with calls to reusable library methods
Note: Limitation: Architecture-level refactoring (restructuring the whole system design) is expensive and
cannot always be done incrementally. This is a known weakness of the XP approach.
7. TESTING IN XP
Testing is a first-class activity in XP, not an afterthought. It is built into every stage of development.
Four key features of testing in XP:
• 1. Test-first development — write the test before you write the code
• 2. Incremental test development from scenarios — tests built from user stories, not added at
the end
• 3. User involvement — on-site customer helps write and validate acceptance tests
• 4. Automated testing frameworks — tests are executable components run automatically (e.g.
JUnit)
Test-First Development in Detail
Writing a test first forces you to clarify the interface and expected behaviour before implementation.
This prevents 'test-lag' (writing tests as an afterthought when the design is already fixed).
The customer (on-site) is responsible for writing acceptance tests for each user story before the next
release. However, this is often a problem in practice:
• Customers don't always have enough time available
• Some customers feel their job ended when they wrote the requirements
• Acceptance tests may be incomplete or delayed as a result
Test Automation
All tests are written as executable components. An automated test framework (like JUnit) runs all
tests whenever new code is integrated. This immediately catches any breakage introduced by new
changes.
Problems with test automation in practice:
• Programmers prefer coding — may write incomplete tests that don't cover edge cases
• Complex user interfaces are difficult to test incrementally
• It is hard to know when a test suite is 'complete enough'
8. PAIR PROGRAMMING
Two developers sit at one computer. One writes the code (driver), the other reviews it in real time
(navigator). Roles swap regularly, and pairs rotate so all team members work with each other.
Benefits:
• Every line of code is seen by at least 2 people — acts as a continuous, informal code review
• Knowledge spreads across the entire team — no single person holds critical knowledge
• Reduces project risk if a team member leaves
• Encourages refactoring — both people benefit when the code improves
• Evidence suggests a pair can be more productive than 2 individuals working separately
9. SCRUM
Scrum is a lightweight agile framework — it tells you how to manage a project, not how to write the
code. Work is structured into fixed-length cycles called Sprints (1–4 weeks).
Goals of Scrum: improve communication, maximise cooperation, protect the team from external
disruptions, and maximise productivity.
The Three Roles
Role Responsibilities
Product Owner Single voice for the product. Owns and prioritises the Product Backlog. Defines what to build and in w
Scrum Master Facilitates the Scrum process. Removes obstacles. Shields the team from external interruptions. Enfo
Scrum Team 5–10 cross-functional people (developers, QA, designers, etc.). Self-organising and full-time. Team m
The Sprint Cycle — Step by Step
Step Meeting / Activity Description
1 Backlog Refinement Product Owner and team split large vague items (epics) into smaller User Stories. Stories
2 Sprint Planning Meeting Product Owner + Team negotiate which stories to complete in the Sprint. Takes 8 hours,
3 Sprint Execution (1–4 weeks) Team builds the increment. Daily Scrum meetings happen every day throughout the Sprin
4 Daily Scrum 15-minute daily standup. Three questions only: What did you do? What will you do? Wha
5 Sprint Review Team demonstrates working software to the Product Owner. Feedback is gathered for the
6 Sprint Retrospective Team reflects on the process: what went well, what to improve in the next Sprint.
Scrum Artifacts
Artifact Description
Product Backlog Master prioritised list of all requirements written as User Stories. Maintained and ordered by the Produ
Sprint Backlog The subset of Product Backlog items the team commits to for the current Sprint. Includes a plan for de
Burndown Chart Graph of work remaining vs. time. Three types: Sprint Burndown (progress in current sprint), Release
Advantages and Disadvantages of Scrum
Advantages Disadvantages
Fast, efficient delivery of deliverables Scope creep risk — no fixed end date
Efficient use of time and money Requires experienced, committed team members
Large work broken into manageable sprints Hard to scale to large teams
High team visibility via daily standups Daily meetings can feel burdensome
Customer feedback incorporated easily Team member leaving mid-sprint is highly disruptive
Clear individual accountability Quality is hard to guarantee without rigorous testing process
10. EXAM TIPS — COMMON QUESTIONS
Compare XP and Scrum:
XP focuses on engineering practices (how to write code). Scrum focuses on project management
(how to organise the team and track progress). You can use Scrum without XP practices, and vice
versa.
Why does Agile prefer time-based contracts?
Because requirements change throughout the project. A fixed-scope contract becomes invalid every
time requirements change. Time-based contracts charge for developer time, not a fixed deliverable.
What is the biggest risk of Agile/XP?
Customer availability. Almost every agile method assumes a customer is actively involved. If the
customer cannot or will not participate, many agile practices break down.
What is the difference between a Product Backlog and a Sprint Backlog?
The Product Backlog is the full list of everything the product needs (maintained by the Product
Owner). The Sprint Backlog is the small subset the team picks to complete in the current sprint.
Why does XP reject 'design for the future'?
XP argues that you cannot reliably predict future requirements. Spending time designing for
changes that may never happen is wasteful. Instead, keep code clean now so any future change is
easy to make.
Week 3 Study Notes | Agile Software Development | Pressman & Maxim, Chapter 5