1.1 Agile Manifesto & Lean Thinking

1.1 Agile Manifesto & Lean Thinking

Quick Answer: The Agile Manifesto consists of 4 core values and 12 principles created in February 2001 by 17 software practitioners. It does NOT state that traditional practices (processes, documentation, contract negotiation, following a plan) have zero value; rather, it explicitly states: "while there is value in the items on the right, we value the items on the left MORE." Lean Thinking complements Agile by focusing on waste reduction (the 7 wastes of Lean), flow optimization, pull systems, and continuous improvement (Kaizen).

To understand Scrum, candidate Certified ScrumMasters must first master the philosophical soil from which it grew: The Agile Manifesto and Lean Thinking. Scrum is not a rigid set of instructions; it is an operationalization of Agile values and Lean principles designed to handle complex, unpredictable work.

---

The Historical Context of the Agile Manifesto

In February 2001, 17 software methodology leaders—including Scrum co-creators Jeff Sutherland and Ken Schwaber, along with Extreme Programming (XP) pioneers Kent Beck and Ward Cunningham, and Pragmatic Programming authors—met at the Lodge at Snowbird ski resort in Utah.

Their shared goal was to find common ground among their respective lightweight methodologies. At the time, the software development industry was dominated by heavy, plan-driven methodologies (often referred to generically as Waterfall or Heavyweight Software Development Life Cycles). These legacy approaches relied on massive upfront requirements gathering, detailed upfront architectural documentation, strict stage-gate approvals, and rigid change-control boards.

The result of heavy plan-driven methods was widespread industry failure: projects routinely exceeded budgets, arrived years late, or delivered software that no longer matched customer needs by the time it was deployed. The 17 practitioners published the Manifesto for Agile Software Development, establishing a paradigm shift centered on adaptability, human collaboration, and rapid feedback loops.

---

The 4 Core Values of Agile

The Agile Manifesto is built upon four foundational value statements. On the CSM exam, questions frequently test your ability to interpret these values correctly without falling into extreme, incorrect assumptions.

Individuals and interactions  OVER  Processes and tools
Working software              OVER  Comprehensive documentation
Customer collaboration        OVER  Contract negotiation
Responding to change          OVER  Following a plan

Deep Dive & CSM Exam Interpretation

1. Individuals and Interactions over Processes and Tools

   • Meaning: People drive innovation and problem-solving, not rigid tooling or enforced workflows. High-performing teams talk directly, collaborate in real time, and adjust as human dynamics require.
   • CSM Exam Trap: "Agile teams eliminate all processes and tools." False! Tools (like Jira or physical whiteboards) and processes (like Daily Scrum) are valuable, but they must serve the people, not dominate or constrain them.

2. Working Software over Comprehensive Documentation

   • Meaning: The primary indicator of true progress is functional, usable software delivered to end-users. Writing a 300-page specification document creates an illusion of progress without validating whether the solution works.
   • CSM Exam Trap: "Agile means no documentation is written." False! Documentation should be created when it provides clear value (e.g., user guides, API contracts), but it should be concise, just-in-time, and secondary to delivering working increments.

3. Customer Collaboration over Contract Negotiation

   • Meaning: Software development is a collaborative discovery process between developers and customers/stakeholders. Rigid contracts that freeze scope create adversarial relationships where success is measured by legal compliance rather than customer satisfaction.
   • CSM Exam Trap: "Agile contracts don't exist or ignore scope." False! Agile contracts structure agreements around shared risk, flexible scope, and iterative delivery milestones rather than fixed-price, fixed-scope guarantees.

4. Responding to Change over Following a Plan

   • Meaning: In complex domains, change is inevitable due to evolving market conditions, customer feedback, and technical discoveries. Teams must structure their work to embrace change as a competitive advantage.
   • CSM Exam Trap: "Agile teams do not plan." False! Agile teams plan continuously at multiple horizons (Product Vision, Roadmap, Release, Sprint, Daily). However, they treat plans as hypotheses to be updated, not unalterable mandates.

---

Comparison: Agile Mindset vs. Legacy Waterfall

---

The 12 Agile Principles: High-Yield CSM Test Concepts

The Manifesto contains 12 underlying principles that operationalize the 4 core values. While all 12 are vital, the CSM exam heavily emphasizes the following six high-yield principles:

1. Early and Continuous Delivery (Principle 1): "Our highest priority is to satisfy the customer through early and continuous delivery of valuable software." Exam focus: Frequency of delivery drives risk reduction.
2. Welcome Changing Requirements (Principle 2): "Welcome changing requirements, even late in development. Agile processes harness change for the customer's competitive advantage." Exam focus: Changes requested late in a project are embraced if they add real customer value.
3. Sustainable Pace (Principle 8): "Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a constant pace indefinitely." Exam focus: Heroic overtime and crunch cycles burn teams out and destroy software quality; Sprints must maintain a repeatable cadence.
4. Continuous Attention to Technical Excellence (Principle 9): "Continuous attention to technical excellence and good design enhances agility." Exam focus: Cutting corners on quality creates technical debt, which slows future velocity.
5. Simplicity (Principle 10): "Simplicity—the art of maximizing the amount of work not done—is essential." Exam focus: Simplicity is about eliminating unnecessary features and avoiding over-engineering.
6. Self-Organizing Teams (Principle 11): "The best architectures, requirements, and designs emerge from self-organizing teams." Exam focus: Management sets goals, but the team decides HOW to achieve them.

---

Lean Thinking Foundations & Waste Elimination

Scrum is deeply rooted in Lean Thinking, a management philosophy derived from the Toyota Production System (TPS) pioneered by Taiichi Ohno and Shigeo Shingo. Lean focuses on optimizing the flow of value across the entire system while relentlessly eliminating waste.

The 5 Core Principles of Lean

1. Identify Value: Define value strictly from the perspective of the end customer.
2. Map the Value Stream: Identify all steps in the process, exposing non-value-adding activity.
3. Create Flow: Ensure work moves smoothly through the system without delays, queues, or bottlenecks.
4. Establish Pull: Produce work only in response to explicit customer demand (rather than pushing work based on forecasts).
5. Pursue Perfection (Kaizen): Continuously inspect and adapt processes to eliminate waste and optimize quality.

The 7 Lean Wastes (Muda) in Software & Scrum

In software development and Scrum, Lean waste (Muda) manifests in seven distinct forms. CSM candidates must be able to identify these wastes in real-world scenarios:

1. Partially Done Work: Code written but unmerged, un-tested, or un-deployed. It ties up capital and risks becoming obsolete without delivering value.
2. Extra Features (Gold-Plating): Building capabilities that customers did not ask for and may never use. (Relates directly to Principle 10: Simplicity).
3. Relearning / Lost Knowledge: Information lost due to poor communication, siloed hand-offs, or team turnover.
4. Hand-offs & Task Switching: Switching contexts between multiple project tasks causes severe cognitive friction and efficiency loss (up to 20-40% productivity loss per context switch).
5. Delays / Waiting: Waiting for code reviews, environments, external vendor dependencies, or Product Owner sign-offs.
6. Motion / Extra Steps: Unnecessary governance bureaucracy, overly complex approval workflows, or cumbersome tooling steps.
7. Defects & Rework: Bugs caught late that require re-analyzing, re-coding, and re-testing.

---

How Lean Synergy Powers Scrum Practices

---

Real-World CSM Scenario & Coaching Strategy

Scenario: A Vice President of Engineering demands that a Scrum Team pause feature development for three weeks to write a comprehensive 150-page Technical Architecture Specification document before building a new microservice. The VP argues that without this upfront document, the software architecture will be flawed.

CSM Coaching Approach:

1. Reference Core Values: Remind leadership of Working software over comprehensive documentation. Upfront documentation cannot replace empirical validation.
2. Identify Lean Waste: Explain that a 150-page upfront design is Partially Done Work and creates the risk of Relearning when real-world coding reveals flaws in the paper specification.
3. Propose an Empirical/Lean Alternative: Recommend building a thin, vertical slice of the microservice in the next Sprint (a spike or initial Increment). Test the architecture in actual execution, inspect the performance, and document the architecture iteratively as it emerges.