9 Agile & Scrum
Acknowledgements
Perplexity was used for a literature search and Gemini was used for brainstorming and organization during the creation of these notes.
Introduction
Last week we discussed
- Project initiation
- Developing a project charter
- Stakeholder analysis
- Defining project success
Technical projects have a lot of uncertainty, making the waterfall approach
- Cumbersome
- Inflexible
- More risky than necessary
Agile philosophy
Agile as a response to these challenges. It is
- A mindset
- A philosophy
- Not a process
Today’s objectives
By the end of this lecture, you’ll be able to:
- Explain the core values and principles of the Agile Manifesto.
- Describe the roles, events, and artifacts of the scrum framework.
- Understand the “why” behind the scrum ceremonies and practices.
The Agile Manifesto
The Agile Manifesto for Software Development, created in 2001 is
- Based on four core values
- A guide for developing software in a different way
The authors were not prescriptive — they were saying, “let’s value these things more.”
Four values of the Agile Manifesto
- Individuals and interactions over processes and tools
- Example: A team solves a technical problem by talking to each other for five minutes, rather than waiting a week for a formal, documented process to be followed.
- How would this value benefit a project you have worked on?
- Working software over comprehensive documentation
- Example: A user can click a button and see a new feature, even if the feature’s entire technical specification isn’t yet written.
- How would this value benefit a project you have worked on?
- Customer collaboration over contract negotiation
- Example: A team regularly checks in with a client to get feedback on a prototype, rather than only presenting the final product at the end of the project based on the original contract.
- How would this value benefit a project you have worked on?
- Responding to change over following a plan
- Example: When the market shifts, a team quickly pivots to build a new feature that the customer needs, even if it wasn’t in the original project plan.
- How would this value benefit a project you have worked on?
12 principles of the Agile Manifesto
These 12 principles follow from the four values discussed above.
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.
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.
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.
Introduction to Scrum
Scrum is a framework stemming out of the agile philosophy for working within the constraints of a complex project to
- Develop solutions
- Deliver results
- Sustain / maintain products
Properties of the scrum framework:
- Lightweight
- Iterative
- Incremental
See Singh et al. (2024) for a review of implementing scrum in industry.
The “3-5-3” of Scrum
A simple way to remember the framework:
- 3 roles
- 5 events
- 3 artifacts
3 roles
- Product Owner (PO)
- Responsibility: The sole person responsible for managing the Product Backlog. They represent the voice of the customer and the business.
- Key traits:
- Domain expert
- Decision-maker
- Available to the team
- Scrum Master (SM)
- Responsibility: A servant-leader to the team. They ensure the team follows Scrum practices, removes impediments (roadblocks), and facilitates the events.
- Key traits:
- Coach
- Facilitator
- Protector of the team
- Development Team:
- Responsibility: A self-organizing, cross-functional group that does the work of building the product. They are collectively responsible for the Sprint Backlog.
- Key traits:
- Collaborative
- Skilled
- Empowered
5 events
- Sprint:
- A fixed-length timebox (usually 1-4 weeks) during which a product output is created
- Output: The product increment - a complete, usable, and potentially shippable increment of the product
- Analogy: Think of a sprint as a mini-project with a specific goal
- Sprint planning: (beginning of sprint)
- The entire team collaborates to define the sprint goal and select the product backlog items they can complete during the sprint.
- Output: The sprint backlog
- Daily scrum (stand-up meeting): (Every day)
- A short (15-minute) meeting for the development team to synchronize activities and create a plan for the next 24 hours.
- Common questions:
- What did I do yesterday?
- What will I do today?
- Are there any impediments?
- Sprint review: (end of sprint)
- The team demonstrates the completed work to stakeholders and the product owner.
- It’s a chance to inspect the increment and adapt the product backlog.
- Output: An updated product backlog.
- Sprint retrospective: (end of sprint, after review)
- A meeting for the scrum team to inspect itself and create a plan for improvements to be enacted during the next Sprint.
- Common questions:
- What went well?
- What could we do better?
- What will we commit to improving in next sprint?
3 artifacts
- Product backlog:
- The single source of truth
- An ordered list of everything that might be needed in the product
- It’s dynamic and always evolving
- The product owner is responsible
- Sprint Backlog:
- The plan for the sprint
- The set of product backlog items selected for the sprint
- Plus the plan for delivering the product increment and realizing the sprint objectives
- Product increment:
- The usable product
- Definition: The sum of all the product backlog items completed during a sprint plus the value of all previous increments
- It must be “Done” and ready to be used
Visualizing Workflows with Kanban
Kanban is a different approach to implementing agile principles (Hey and Heroux 2017).
- Scrum focuses on time-boxed iterations
- Kanban focuses on continuous flow
Core Kanban principles
- Visualize the workflow
- Use a Kanban board with columns like “To Do,” “In Progress,” and “Done”
- This makes the state of work transparent and easy to understand at a glance
- Limit Work in Progress (WIP)
- Set a limit on the number of tasks that can be in the “In Progress” column at any given time
- Prevents multitasking
- Reduces context switching
- Helps the team focus on completing work
- Manage Flow
- Goal is to move items from “To Do” to “Done” as smoothly and quickly as possible
- Identify bottlenecks and continuously improve the process
When to use Kanban vs. Scrum
Scrum is ideal when
- Projects with a clear product roadmap and a stable, dedicated team
- New product development where work can be broken into repeatable, time-boxed cycles
Kanban is ideal when
- Constant stream of unpredictable work, such as IT support, maintenance, or operations
- Ideal when new work can arrive at any time and needs to be addressed quickly without waiting for a new sprint
Ozkan et al. (2022) has a good paper discussing studies about when to use one over the other. Many employ a hybrid method where both frameworks are used together.
Why Scrum & Kanban Work
- Empiricism:
- Both are based on a cycle of inspection and adaptation
- The team learns by doing and adjusts based on feedback
- Transparency:
- All artifacts and processes are visible to everyone
- This builds trust and accountability
- Focus on Value:
- The goal is not just to build something, but to build something valuable to the customer