Agile and Scrum fundamentals

A specific industrial practice, not documentation or planning in general. In 2001 the dominant model was a sequenced project: a requirements phase producing a signed specification, a design phase producing a document set, then build, then an integration and test phase at the end, with change controlled through a formal board because change was assumed to be a defect in the original analysis. The observed failure was that the specification was wrong by the time it was built, and nobody found out for a year. Everything in the manifesto is a response to that single feedback-latency problem, which is why the useful reading of it is about shortening the loop between a decision and evidence about the decision. Read as a statement about disliking paperwork it becomes an excuse, and that misreading is where most of the subsequent damage came from.

The values are quoted constantly and their second halves are dropped, which is where the misuse begins.

value                       reacting against            how it is misused now
--------------------------  --------------------------  -------------------------
Individuals and inter-      staffing plans that         "we do not need process".
actions over processes      treated engineers as        Removing all structure and
and tools                   interchangeable resources   calling the result agile.
                            slotted into a defined
                            process

Working software over       a year of documents, a      "we do not write anything
comprehensive               signed spec, and no         down". Losing the design
documentation               running system until        record and the decisions,
                            month nine                  then relearning them

Customer collaboration      a contract that fixed       "the customer is always
over contract               scope, price and date up    available", when nobody
negotiation                 front, so both sides        has actually secured a
                            spent the project           decision-maker's time
                            defending their position

Responding to change        a change control board      "no plan". Reacting to
over following a plan       that treated new            whatever arrived last
                            information as a threat     week, with no thesis about
                            to the schedule             where the product is going

The sentence people forget:
  "That is, while there is value in the items on the right, we value the
   items on the left more."

The clause at the bottom is the whole of the answer to a hostile follow-up. The manifesto asserts a preference under conflict, not a prohibition, so a team that has stopped documenting anything has not applied the second value — it has deleted the right-hand side that the authors explicitly said had value.

The third row is the one worth dwelling on in an interview, because it is the value that fails for structural reasons rather than cultural ones. Collaboration over contract negotiation assumes a customer who can be present and can decide. In a fixed-price outsourced engagement, or with an internal stakeholder whose diary is full, that assumption is false, and every ceremony downstream of it — refinement, review, mid-sprint clarification — degrades quietly into the team guessing.

The fourth row is where the honest criticism lands. Responding to change without a plan is not agility, it is churn, and it is the most common lived experience of agile for engineers: a backlog reordered weekly, nothing finished, and no statement of what the product is for. The defensible position is that you keep a direction and hold the increments loosely, which is a harder discipline than either extreme.

Agile is a set of values and principles with no mechanics; Scrum is one lightweight framework that implements them with specific accountabilities, events and artefacts. The relationship is that Scrum is an instance, not a synonym, and several other instances exist — Kanban, Extreme Programming, and various in-house hybrids. This matters in an interview because the two questions have different answers: "are you agile" is about feedback loops and who decides, while "do you do Scrum" is about whether you have a product owner, a sprint and a retrospective. A team can run every Scrum event faithfully and be entirely un-agile if the backlog is dictated, the increment is never shown to a user, and the retrospective produces nothing. The reverse also happens, and a team shipping daily against real user feedback with no sprints at all is the stronger position to defend.

Because the principles are specific enough to be falsified, and the values are not. "Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter timescale" makes a claim you can check against a team's release history; "individuals and interactions over processes" does not. The principles are also where the parts everyone skips live: a sustainable pace indefinitely, technical excellence and good design enhancing agility, the best architectures emerging from self-organising teams, and simplicity defined as maximising the work not done. Those four are the ones a team under pressure abandons first, and they are the ones that make the rest possible. Quoting a principle rather than a value is also a quick signal in an interview that you have read past the poster.

Where decisions are made and how fast evidence arrives. In a genuinely agile team the people doing the work decide how it is done, the increment reaches someone who will use it inside a few weeks, and what is learned changes the next increment. In a performing team the events happen on the calendar, the board is tidy, the artefacts exist, and the sequence of decisions is unchanged from the plan-driven model — scope is handed down, the date is fixed, and the sprint is a reporting interval. The cheapest diagnostic is to ask what the team changed last month because of something it learned. A team that cannot answer has ceremonies without feedback, which is the expensive combination: all of the meeting cost and none of the adaptation benefit.

Because most engineers have met it as an increase in surveillance rather than autonomy. The lived version is a daily meeting where you justify yesterday to a manager, estimates that become commitments and then become deadlines, points tracked as productivity, a backlog reordered without explanation, and a retrospective that produces the same three items every fortnight. Every one of those inverts what the practice was for, and the inversion is usually not malicious — it happens because the artefacts of agile are legible to management while the substance is not, so the visible parts get adopted and measured. The honest thing to say in an interview is that the cynicism is earned, and that defending the framework rather than acknowledging it is the fastest way to lose an engineering audience.

When the cost of an increment is very high or the requirement genuinely cannot change. Certification-bound work where each release triggers a regulatory submission, hardware with a fixed tape-out, or a contractual integration against a frozen external specification all have feedback loops measured in quarters, and iterating faster than the loop returns evidence just produces churn. The nuance worth adding is that this is a statement about release cadence rather than about working practice: an avionics team can still work in short internal iterations, keep the build integrated continuously and hold retrospectives, while releasing annually. So the wrong answer is dogmatic Scrum with a two-week sprint review nobody can attend, and the right one is picking the loop length from the domain rather than from the framework.