Agile and Scrum Fundamentals: Empiricism, the Manifesto and Fitness for Purpose
The fundamentals domain checks whether you understand why Scrum is shaped the way it is, not just what its parts are called. Questions probe the Agile Manifesto values and principles, empirical process control, the five Scrum values and - most often - whether Scrum is the right fit for a given piece of work.
Empirical process control
Scrum is a lightweight framework built on empirical process control: decisions are made from observation rather than from a detailed up-front plan. Three pillars support it. Transparency means the process and the work are visible to those who fund and consume it, using a shared Definition of Done. Inspection happens in the five events, frequently enough to catch deviation but not so often that it disrupts the work. Adaptation follows inspection: if an aspect deviates outside acceptable limits, the process or the work is adjusted as soon as possible. The Scrum values - commitment, courage, focus, openness, respect - are what make the pillars work with real people.
The Agile Manifesto
Four value statements, each a preference rather than a replacement: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. The twelve principles behind them cover satisfied customers through early and continuous delivery, welcoming changing requirements, delivering frequently, self-organising teams, simplicity, and regular reflection and tuning.
Fit and misfit
Scrum is designed for complex work where requirements and technology are poorly understood and emerge as you go. It fits badly where the work is simple and fully specified, where a genuine Done increment cannot be produced every Sprint, or where the team is neither cross-functional nor able to self-manage.
Worked example
A sponsor asks whether Scrum suits a fixed-scope migration of 400 known data tables. Reasoning: the tables, target schema and rules are already known - the work is complicated rather than complex, and empirical control adds overhead without reducing risk. A plan-driven or flow-based approach fits better. Now change one variable: the target warehouse is new to the team and the business rules are still being negotiated. Requirements are now emergent, complexity is high, and Scrum becomes the better fit. The deciding question is the nature of the work, not the size of the project.
Traps
- Reading "over" as "instead of": the Manifesto still values documentation, contracts and plans.
- Confusing the three pillars (transparency, inspection, adaptation) with the five Scrum values.
- Calling Scrum a methodology or a process; it is a framework you complete with practices.
- Assuming Scrum implies speed or guaranteed value - it improves the ability to inspect and adapt under uncertainty.