The other two agile families, and how they work with Scrum
Kent Beck, 1999. Born from a real project at Chrysler. Built around the idea that if a practice is useful, you should do it all the time, to the extreme.
Five values
Communication
Talk early, talk often. Documentation is not a substitute for conversation.
Simplicity
Do the simplest thing that could work. Build only what is needed now.
Feedback
From tests, from users, from each other. Shorten every feedback loop.
Courage
Tell the truth about progress. Change course when needed. Refactor.
Respect
Everyone on the team matters. No finger-pointing, no silent heroes.
Key engineering practices
Pair programming
Two developers, one screen. One drives, one thinks ahead. They swap often.
Test-driven development
Write the failing test first. Make it pass. Refactor. Repeat in short cycles.
Continuous integration
Merge to the shared branch many times a day. Every commit triggers the build and tests.
Refactoring
Improve the structure of the code without changing its behaviour. Tests protect you.
Simple design
You aren't gonna need it. Build for today, not for a future that may never come.
Small releases
Ship working software to real users often. Small steps, tight feedback.
Collective ownership
Anyone can improve any piece of code. No code is owned by one person.
Sustainable pace
No heroics, no death marches. Tired developers make bad code.
David Anderson adapted Kanban for software in the mid-2000s, drawing on the Toyota Production System. Unlike Scrum, Kanban has no fixed iterations, no prescribed roles, and no sprint commitment. It focuses on flow.
A kanban board in action
Backlog
In progress
WIP 3 / 3Review
WIP 1 / 2Done
Each column can carry a WIP (work in progress) limit. When In progress is full, you cannot pull another item, you have to help clear the bottleneck first. This single rule forces the team to finish before starting, which is usually the hardest habit to learn.
Six core practices
A quick side-by-side. None of these is strictly better. They answer different questions.
| Scrum | XP | Kanban | |
|---|---|---|---|
| Rhythm | Fixed sprints, 2 to 4 weeks | Short iterations, 1 to 2 weeks | Continuous flow, no iterations |
| Roles | Product Owner, Scrum Master, Developers | Customer, Coach, Programmers, Tester | No prescribed roles |
| Commitment | Sprint Goal for the iteration | Iteration plan, may adjust | None, pull when capacity frees up |
| Primary focus | Framework, cadence, stakeholder feedback | Engineering practices and code quality | Flow, bottlenecks, steady throughput |
| Change mid-stream | Protected during a sprint | Flexible within an iteration | Can happen any time |
| Natural fit | New product development | Teams needing strong engineering discipline | Support, ops, maintenance, unpredictable demand |
Scrum is deliberately silent on how the team builds the increment. XP fills that gap. Most professional agile teams today run Scrum as the outer framework and XP practices inside each sprint. The combination is so common that many people call it "Scrum" without realising the engineering half is XP.
The framework
The engineering
A week in a Scrum plus XP team
What this means for your group project
You do not have to pick one. Your team can run Scrum for the framework (roles, sprints, ceremonies) and adopt the XP practices that matter most for your context. For a student project, the highest-value XP practices are usually: pair programming during tricky sections, continuous integration through a simple GitHub Actions pipeline, and small releases at the end of each phase. Kanban thinking can help too: limit how many stories your team works on at once. Finish what you start before picking up something new.