Frameworks like Scrum are tools. The Agile mindset is the foundation those tools are built on. Teams that adopt the practices without the mindset get the meetings and the overhead without the benefits. Understanding what Agile actually values — and why — is what separates teams that improve from teams that just go through the motions.
The four Agile values
The Agile Manifesto, published in 2001 by seventeen software practitioners, defines four values. 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 right side of each value isn't worthless — the manifesto explicitly says 'there is value in the items on the right.' The point is that teams get the balance wrong. They write exhaustive documentation instead of shipping working software. They negotiate contracts instead of collaborating with customers. They follow the plan even when reality has clearly changed.
The practical implication is that every team's instinct to add another approval gate, write another status report, or stick to the original plan because 'that's what was agreed' needs to be weighed against the Agile question: does this serve the customer and the work, or does it serve the process?
The principles that matter most in practice
The Agile Manifesto is supported by twelve principles. Three are especially worth internalising early. First: our highest priority is to satisfy the customer through early and continuous delivery of valuable software. This makes customer value — not adherence to plan — the north star.
Second: welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage. This is the principle that most conflicts with traditional PM instincts. Scope change isn't a threat to be controlled — it's information to be acted on.
Third: deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale. Frequent delivery forces real feedback. A team that delivers every two weeks gets twenty-six chances to learn and adjust in a year. A team that delivers once a year gets one.
Mindset vs method
The most common Agile failure is cargo-culting — adopting the ceremonies and artifacts without adopting the values. A team that runs daily standups as status reports to management, produces user stories that are really just decomposed requirements, and treats the retrospective as a formality has the form of Agile but not the substance.
True Agile mindset shows up in small moments: a developer asking whether a feature is the right thing to build, not just whether it can be built. A Product Owner showing a half-finished feature to a customer before it's polished. A team deciding together to change direction mid-sprint because new information made the original plan wrong.
As a PM working in Agile environments, your role shifts from plan-enforcer to impediment-remover and environment-creator. Your job is to protect the team's ability to inspect and adapt — to ensure they have the information, access, and safety they need to make good decisions quickly.
Course complete — what's next
The Agile mindset — built on the four values and twelve principles of the Agile Manifesto — is what makes frameworks like Scrum work. Practices without mindset produce overhead without benefit. The three most important principles for a beginner to internalise are: customer value above all, welcome change as information, and deliver frequently to learn faster.
You've now completed Agile Fundamentals. From here, the Intermediate courses will take you deeper. Scrum Master Essentials goes inside the facilitation and coaching skills that make Scrum work at the team level. Agile at Scale shows how to coordinate multiple Agile teams without losing the benefits of the approach.