Agile software development delivers small improvements, gathers feedback, and adapts as needs change. It favors collaboration and customer value over rigidly following an initial plan. Work is planned and tested throughout the project rather than left until the end. section 7.1.2 section 7.1.3
Two common ways to organize agile work are:
- Scrum: A team selects backlog work for a fixed-length sprint and aims to deliver a potentially releasable increment. Sprint planning, daily scrums, reviews, and retrospectives help the team coordinate and improve. section 7.1.2
- Kanban: A team visualizes work and limits work in progress to improve flow and reduce cycle time. section 7.1.2
Table 7.1 Scrum terminology (view table figure)
| Scrum term |
Definition |
|---|---|
| Sprint |
A fixed time-boxed iteration during which the team works on a subset of the product backlog, with the goal of delivering a potentially releasable product increment |
| Backlog |
A prioritized list of product features, enhancements, or fixes that the team works on during a sprint |
| Product owner |
The person responsible for managing the product backlog, prioritizing the work, and ensuring the team delivers value to the stakeholders |
| Scrum master |
The person responsible for ensuring that the team follows the Scrum process, removing any obstacles, and facilitating collaboration and communication |
| Sprint planning |
A meeting held at the beginning of each sprint during which the team reviews the product backlog, selects the items for the sprint backlog, and defines a sprint goal |
| Daily scrum |
A 15-minute time-boxed meeting during which the team members discuss their progress, identify any obstacles, and plan the work for the day |
| Sprint review |
A meeting held at the end of each sprint during which the team demonstrates the completed work to stakeholders and receives feedback |
| Sprint retrospective |
A meeting held at the end of each sprint during which the team reflects on their performance, identifies areas for improvement, and creates a plan for the next sprint |
| User story |
A short, simple description of a product feature from the perspective of a user or customer |
| Velocity |
A measure of the amount of work completed by the team during a sprint or over multiple sprints |
Use the terminology table to distinguish a sprint, backlog, product owner, scrum master, and planning meeting. section 7.1.2
Agile expects requirements to evolve; waterfall plans and executes sequential phases against requirements defined early. Agile is useful when needs are uncertain or change often, while waterfall can suit a project with a clear end goal. Neither choice fits every organization. If choosing agile, allow for change in the time and budget plan. section 7.1.3
Table 7.2 Agile vs. waterfall (view table figure)
| Criteria |
Agile |
Waterfall |
|---|---|---|
| Definition |
An iterative and flexible approach to project management that emphasizes collaboration, adaptability, and customer satisfaction |
A linear and sequential approach to project management that emphasizes planning, documentation, and strict control |
| Focus |
Customer satisfaction and delivering value |
Meeting project requirements and staying within budget |
| Planning |
Continuous planning throughout the project |
Comprehensive planning at the beginning of the project |
| Requirements |
Requirements not fixed and can change as the project progresses |
Requirements fixed and defined at the beginning of the project |
| Testing |
Continuous testing throughout the project |
Testing at the end of each phase |
| Feedback |
Regular feedback from customers and stakeholders |
Limited feedback from customers and stakeholders |
| Risk management |
Constantly monitoring and mitigating risks |
Risk management done at the beginning of the project |
| Time frame |
Shorter development cycles (two to four weeks) |
Longer development cycles (three to six months or longer) |
Compare how the two approaches handle planning, requirements, testing, and feedback. section 7.1.3
A daily meeting is not enough
A team moving from waterfall to Scrum holds daily scrums but skips sprint reviews and retrospectives. It meets regularly without creating the feedback loop needed to improve its process. A constructive next step is to propose retrospectives with stakeholders, explain the benefit, and discuss constraints with the project manager. section 7.1.2 section 7.4.1
On a client project, smaller milestones and regular feedback can reveal budget pressure or scope creep early. Discuss priorities and tradeoffs while there is still time to adjust. Where continuous delivery is used, automated testing and integration can help catch defects early. Keep the feedback activities that let the team act on what it learns. section 8.2.2 section 7.1.2
