Agile Way of Thinking
Domain 1, Agile Way of Thinking, tests whether you can explain why Scrum is built on empirical control rather than a predictive plan. Questions often ask you to classify a statement as Agile or non-Agile, connect Scrum values to behavior, or choose the best response in an uncertain product environment.
Core rules
- The Agile Manifesto values four pairs: individuals and interactions over processes and tools; working software over comprehensive documentation; customer collaboration over contract negotiation; responding to change over following a plan. Items on the right still matter; the left is valued more.
- The 12 principles emphasize early and continuous delivery, welcoming changing requirements, frequent delivery, daily business collaboration, motivated teams, face-to-face conversation, working software as the primary progress measure, sustainable pace, technical excellence, simplicity, self-organizing teams, and regular reflection.
- Scrum implements empiricism through transparency, inspection, and adaptation. It fits complex work where requirements, technology, and outcomes cannot be fully predicted.
- The five Scrum values are commitment, courage, focus, openness, and respect. They are behavioral, not ceremonial.
- A defined process assumes known steps and repeatable outputs. An empirical process uses short cycles, feedback, and adaptation. Agile planning is continuous and range-based, not absent.
Worked example
A sponsor asks for an 18-month fixed-scope plan with every requirement detailed before development. A weak answer accepts the plan and adds a change-control board. A better answer proposes an empirical approach: a transparent product backlog, short sprints, working increments, regular stakeholder review, and forecasts that are re-estimated as evidence arrives. The reasoning is that high uncertainty makes detailed long-range prediction unreliable; the plan should be a forecast, while scope and solutions adapt to feedback.
Traps
Do not equate Agile with no documentation or no planning. Do not treat ceremonies as the goal. Do not say self-organizing teams have no accountability. Do not confuse welcoming change with uncontrolled scope; the Product Owner still orders work. Do not use velocity as a value measure. Do not claim the right-hand items of the manifesto are forbidden.