Agile Philosophy
Scrum:
→ Roles
→ Events
Until early 90s, software development relied on waterfall methods
These methods followed a strict direction and did not allow much room for change
Once a requirement is gathered, or a decision is made, the project moves to the next step
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.
The Agile Values are backed by 12 principles
These principles reflect their vision of a development process that is iterative and focus on people
Agile is a philosophy, it does not provide a framework to perform the work
Many frameworks were created:
→ Scrum, Kanban, Extreme Programming (XP), Test-Driven Development (TDD), etc.
Scrum is a framework that implements Agile
It follows specific set of events, stipulates a number of roles, and also produces a specific set of artifacts
The Scrum Official Guide can be downloaded for free following this link
In what follows, we will discuss scrum roles and scrum events
In our next lecture, we will discuss scrum artifacts
Group working towards a specific objective
Cross-functional: contain all necessary skills
Self-managing: make their own internal decisions
Accountable for everything related to the product
There are three roles in a scrum team:
→ Developers
→ Product Owner
→ Scrum Master
Teams are self-organized, there is no hierarchy or defined job titles
People actually doing the work
Technicaly: people creating any aspect of a usable Increment during each Sprint
Self-organized group of professionals
Includes: front-end and back-end developers, UI designers, data scientists, DevOps, etc.
Delivering the work throughout the Sprint
Adhering to a Definition of Done
Help creating a Sprint Goal and a Sprint Backlog
Represents the business side of the team
Balances the needs of all stakeholders
Ensures that the team is delivering the most value
Creating and communicating a Product Goal
Writing, ordering, and reviewing the Product Backlog
Help creating a Sprint Goal and a Sprint Backlog
Managing stakeholder expectations
The scrum master is the oil that lubricates the scrum engines
It is a servant leader that helps the PO, developers, and the organization as a whole
Ensures a proper implementation of the Scrum Framework
Helping with self-management and cross-functionality
Removing impediments (roadblocks)
Ensuring that all scrum events happen and are effective
Finding techniques to define the Product Goal and to create the Product Backlog
Helping the team understand the Backlog items
Establishing empirical product planning
Scrum adoption and implementation
Removing barriers between teams and stakeholders
Development takes place during a series of sprints
During each sprint, a number of items of the product backlog are selected and resolved
Sprints are where ideas are turned into value
All work necessary to achieve a Product Goal happen during sprints
Fixed-length: between 2 to 4 weeks
"The sprint is dead, long live the sprint"
The Sprint Goal should not be changed
Clarifications and renegotiations can occur
The Product Backlog might be refined
Background work and quality assurance happen during the Sprint
→ Sprint Planning
→ Daily Scrum
→ Sprint Review
→ Sprint Retrospective
Main Goal: Selection of items from the Product Backlog
Event that kicks-off the Sprint
Time-boxed: no longer than 2 hours/week
All team members participate: PO, Scrum Master, and Developers
Addresses the why, what, and how of the Sprint
why is this Sprint important: Sprint Goal
what work will be done: Sprint Backlog
how will the work be done: plan
Main Goal: Share progress and challenges and plan work for the day
Short Meeting: 15 minutes more or less
Same time and same place every day
Primarily for Developers
PO and Scrum Master might participate if necessary
Inspect progress towards Sprint Goal
Adapt the Sprint Backlog
Adjust upcoming work
Improve communications, self-management, and identify impediments
Main Goal: Demonstrate the work that was done
Second to last event during a Sprint
Time-boxed: no longer than 2 hours/week
The entire team participate
Can also involve other stakeholders
Demonstrate of the work that was done
Track progress towards the Project Goal
Discuss changes in the environment
Review the Product Backlog
Developers demonstrate what was "done"
PO goes over the Product Backlog progress
Discussion about what to do next
Main Goal: Discuss what went wrong, and how to improve
Last event during a Sprint
Time-boxed: no longer than 1.5 hours/week
The entire team participate
Developers discuss what went well, problems, and solutions
Plan ways to increase quality and effectiveness
Review Product Backlog, Working Agreement, and Definition of Done
Scrum Guide (required)
Scrum Events (required)
Scrum Roles (required)