More in Agile & Scrum — page 20
Explain the Product Backlog, Sprint Backlog, and Increment
Tests your understanding of Scrum's three artifacts and their commitments (Product Goal, Sprint Goal, Definition of Done). Define each, explain the flow from Product to Sprint Backlog, and how completed items form a usable Increment.
Sprint Review vs. Sprint Retrospective: Purpose and Audience
This tests your grasp of Scrum's dual feedback loops. A great answer defines Review as inspecting the *product* with stakeholders to adapt the backlog, and Retrospective as inspecting the *process* with the team to improve the next Sprint.
What is the purpose of the Daily Scrum?
This tests if you know the Daily Scrum is a planning event for Developers, not a status report. A great answer states it's a 15-min meeting for Developers to inspect progress toward the Sprint Goal and adapt their plan.
What are the three accountabilities in a Scrum Team?
Tests recall of Scrum fundamentals and separation of concerns. Name the three accountabilities (Product Owner, Scrum Master, Developers) and define their focus: PO on value, Developers on delivery, and SM on process. A red flag is adding non-Scrum roles.
How would you implement an Andon Cord for a software team?
Tests your understanding of CI, team ownership, and balancing speed with quality. Define a trigger (broken main build), an action (halt merges/deploys), and a team response (swarming to fix). Red flag: scheduling the fix or blaming an individual.
How would you identify and elevate your team's primary constraint?
This tests systems thinking over local optimization. A great answer outlines the 5 steps: identify the constraint (e.g., long queues), exploit it, subordinate other processes, elevate it, and repeat. A red flag is jumping straight to hiring or buying tools.
Relate 'Build Quality In' (Jidoka) to TDD and CI
Tests your ability to connect abstract Lean principles to concrete practices. A great answer defines Jidoka (stop the line on defect), then links TDD as the micro-level check and CI as the macro-level automated line-stop. A red flag is just defining the terms.
How does Agile's 'welcoming change' differ from chaos?
Tests if you know Agile flexibility requires engineering discipline. Answer by defining the difference (discipline vs. chaos), listing technical practices (TDD, CI/CD), and naming architectural patterns (modular design).
Explain the Lean concept of 'Muda' (Waste)
Tests applying manufacturing principles to software. Define Muda as non-value-adding work. Cite 3 software wastes like partially done work, extra features, or defects, and offer specific mitigations like smaller batches, YAGNI, or TDD.
How do you apply 'working software over comprehensive documentation'?
This tests your ability to balance velocity with maintainability. A great answer defines docs by audience and purpose (onboarding, ops), prioritizes "living" docs like tests, and uses a just-in-time approach. A red flag is treating this as "no documentation."
Explain 'Simplicity' and how you apply it as an engineer
Tests if you see simplicity as maximizing value, not just minimizing code. A good answer defines it as avoiding unneeded work, then explains how you'd build an MVP, defer gold-plating, and validate scope with product.
What is the goal of a sprint retrospective?
Tests if you see retrospectives as actionable process improvement, not just venting. A good answer defines the retro's purpose (inspecting the sprint's people, processes, tools) and explains how it creates concrete action items for the next sprint.
Individuals and Interactions Over Processes and Tools
Tests if you can apply Agile's core human-centric value. A great answer defines the principle, then links it to concrete team structures (co-located, cross-functional) and communication methods (face-to-face). A red flag is dismissing all processes and tools.
Agile Center of Excellence: Internal Consultants, Not Process Police
Think of an Agile CoE as internal consultants, not process police. They enable teams by providing coaching, tools, and shared standards. They're useful for scaling Agile consistently, but fail when they become a bureaucratic bottleneck instead of an…
Communities of Practice: Scaling Knowledge Across Teams
A Community of Practice is a cross-team guild for a specific skill, like 'frontend' or 'testing'. It's how large orgs prevent knowledge silos, standardize tooling, and mentor juniors. The footgun: they fail without dedicated time and a clear charter.
Nexus Integration Team: Air Traffic Control for Scrum
The Nexus Integration Team is like air traffic control for multiple Scrum teams, guiding them to a single, integrated product. It's used in the Nexus framework to coordinate 3-9 teams on one product, resolving cross-team dependencies and integration failures.
Nexus Framework: Scaling Scrum Without Breaking It
Nexus is a lightweight wrapper for 3-9 Scrum teams working on one product. It adds a coordinating Nexus Integration Team and shared events to manage dependencies and deliver a single, integrated increment each sprint.
Right-Shifting Forecasts: Why Your Deadlines Keep Moving
A forecast is like a GPS ETA in traffic; new tasks are like accidents ahead, pushing your arrival time further out. This happens when initial estimates are treated as fixed deadlines, ignoring new scope. The footgun is anchoring on the first date given.
Flow Efficiency: Are You Working or Waiting?
Flow efficiency measures the ratio of active work time to total lead time, revealing how much time tasks spend just waiting. Use it to diagnose why features take so long to ship. The biggest footgun is optimizing work speed when most delays hide in queues.
Classes of Service: Prioritize Work Beyond 'First In, First Out'
Classes of Service are policies that prioritize work by its business impact, not just arrival time. When a bug, a deadline, and normal work compete, CoS tells you which to pull first.