The third and fourth items of the Manifesto for Agile Software Development

  1. Customer collaboration over contract negotiation
  2. Responding to change over following a plan

What's the difference between these two?

If the fourth means "incremental delivery with some willingness to pivot, instead of big design up front", then what does the third mean?

Is the third the same as the fourth ...

  • Is the (deprecated) "contract negotiation" the same as "following a plan" -- meaning "big design up front"?
  • And "collaboration" and "responding" -- are they kind of the same thing as each other too?

... or different?

I welcome your explanation, even a reference to one of the original authors explaining it.

4 Answers 4


First I'd like to say that the points in the manifesto are not mutually exclusive (e.g.: working product over docs might also overlap with collaboration over contracts)

Having said that, I think the best way to explain where points 3 and 4 don't overlap is by example

In an overly contractual setting each party will usually defend their rights even if it is at their own expense to ensure that the other party knows that they won't tolerate any infringement of their rights. Obviously in a collaborative environment these sort of stances are less likely to be taken.

For example let's say the contract stipulates that all severity 5 defects are resolved in no more than a month, and the vendor hits a really tricky issue that would take months of man effort to resolve. The customer can then chose one of several paths

  • They could just drop the clause as a vendor that stays in business is better able to support the customer than one that is out of business :)
  • They could come to some other arrangement such delivering some feature enhancements which provide additional value to the customer instead of focusing on a low severity defect which doesn't really impact them
  • Or they can go for the overly contractual route and insist on the issue being resolved no matter the impact to both parties.

From experience the last path usually ends up hurting everyone, as the vendor is squeezed they spend less on improving the quality of the product, leading to more dissatisfaction leading to a more aggressive customer posture leading to more squeezing. A never ending cycle :(

Hope that illustrates the point

  • Nice example, I'd add one line for the optimal case where the customer is willing to slightly change the feature affected by the defect in a way that makes solving the defect super-easy instead of going by the contract. Then it becomes also clear that both points help each other, as it is much easier to react to external change in such a collaborative environment. Jan 21, 2020 at 12:38

Scott Duncan write a short book called "Understanding Agile Values & Principles: An Examination of the Agile Manifesto", published by InfoQ and freely available in PDF format, that takes a deep dive into the Manifesto for Agile Software Development and its values and principles. What follows is a summary of his thinking.

Duncan relates "customer collaboration over contract negotiation" to "individuals and interactions over processes and tools". While the "individuals and interactions" value refers to the internal workings of the development organization and development team, the "customer collaboration" value refers to how the development organization or development team interacts with the external stakeholders. The collaboration here refers to how the development team and external stakeholders find methods to understand requirements and user needs, verify and validate the functionality delivered, and exchange feedback on improving the interactions.

The "responding to change over following a plan" is centered on the waste associated with long-term planning. It acknowledges that software development is complex and unpredictable. Instead of estimating what is thought to be the entire scope of work up-front and delivering once, this value is about the iterative nature of regularly reviewing the work and adapting to the changing environment in which the software is deployed and used and changes in understanding user requirements. It's related somewhat to "working software over comprehensive documentation", and together these two values lead to iterative and incremental development models.

I do see some relation between the "customer collaboration" and "responding to change" values, as you point out. Sometimes, the lines between how the team works with stakeholders and what the team builds for stakeholders can get blurred when defining contracts and plans and requirements. However, the intention seems clear.

My suggestion would be to not take any of the four values in isolation. There are definitely interactions and relationships between all four.


It is important to understand that Agile Manifesto is a criticism of ways of work that were dominant in the time it was written. When you understand how software development was done back in that time, things start making sense.

Customer collaboration over contract negotiation

Back in the days, it was (and sometimes still is) perfectly normal practice for customer and the builder to sit down, and write down contract along with detailed specification. That contract would go into details of what and when the work should be done. The customer would then disappear, only to appear again when the work is supposed to be done, expecting to get software as defined in contract. Most experience tells us this cannot work. Instead, manifesto tells us that we should strive to involve customer in the development as much as possible. And collaborate with him on daily basis in building the software.

Responding to change over following a plan

Often, included in the contract above, would be detailed plan on how the implementation would progress. It would define phases and milestones and specific dates when those phases end and begin. This meant, that even if work in one phase was not yet finished, if plan told you that phase was meant to end, it would end. Also, once you were in a phase, it was difficult to go back to previous phase. So if you were in implementation phase, and found a design defect, it was not possible to go back to design phase to fix that problem. There was some flexibility, but that was often superficial or expensive. Of course, this was found out not to work. Manifesto tells us that this approach is way too risky and that we should structure our development plan in a flexible enough way that when problems are found, the plan can be changed to accommodate those problems.

  • Thank you. So according to you that "responding to change" was meant to mean (or include) not having a detailed construction schedule -- e.g. for building and then integrating components -- so it might be talking about "big bang integration" -- as much or more than "change" meaning a change in the customer requirements based on market feedback. So "collaboration" means "no big design up front" and "unplanned change" might mean "continuous integration"?
    – ChrisW
    Jan 22, 2020 at 8:27
  • @ChrisW I have hard time understanding your analogies.
    – Euphoric
    Jan 22, 2020 at 8:29
  • My analogies -- do you mean my jargon, like "big bang integration"? "Big bang" is if you say e.g., "the system will have four components -- e.g. front-end, back-end, middleware, and deployment/configuration -- and so we'll have four teams, one for each component, schedule them to finish at the same time, then integrate the components they've written". It's the opposite of "continuous integration". I thought that might be what you meant, when you wrote, about "phases and milestones" and using (in the implementation) components with unfixed "design defects" -- is that what you meant?
    – ChrisW
    Jan 22, 2020 at 8:44
  • @ChrisW By phases, I meant "Analysis", "Design", "Implementation", "Testing", etc.. Continuous integration is more in 2nd value "working software over comprehensive documentation".
    – Euphoric
    Jan 22, 2020 at 8:53
  • So by phases you mean "waterfall"; and "flexible development plan" might mean something, one of the "modified waterfall models" possibly. That -- i.e. iterative development -- seemed to me very similar to the previous item and I didn't see the difference. But now I think you're saying, that the third item ("collaboration") is about keeping the customer involved during iterative development, and the fourth ("responding") is expecting the development process (construction: design+code+test) to support iterative development. Is that right?
    – ChrisW
    Jan 22, 2020 at 9:05

Another perspective to describe the two principles is the following

Customer collaboration over contract negotiation

In many non-agile organizations, projects are started with armies of product managers/ business analyists and project managers collaborate together to make an agreement. Then the project starts. Period

In an Agile mindset, this is totally wrong. This kind of collaborations is not done ahead of time but day by day, with the customer (eg. represented from POs in scrum) present in every stage of the project

Responding to change over following a plan

Well, as an agile-change agent, I made my organization aware that project specifications are evil and a PO that meets the team at least 2 times per week is super cool. But the PO is not able to join this mindset so keeps talking about same things in backlog grooming meetings, he/she doesn't look for market feedback and is strongly convinced that the project has to follow predetermined requirements. This makes the previous point "pointless" because customer collaborations means nothing if there is no impact of the customer on the product

  • I understood the first, less so the second. Is the main point of the second that PO (or customer) is not "responding to change" when they don't look for market feedback? And that when the PO has no market feedback therefore they have no information to guide the evolution of their idea of what product should be? So in summary it's a "minimum viable product" kind of idea?
    – ChrisW
    Jan 21, 2020 at 23:17
  • Yes I think is what you were saying -- i.e. that the first is, "expect to work together instead of trying to define things in advance", and that the second is, "while you are working together, seek feedback and respond to change".
    – ChrisW
    Jan 21, 2020 at 23:53
  • @ChrisW there's definitely overlap in customer collaboration/responding to change, but I think the distinction between "contract negotiation" and "following a plan" is what justifies this being two separate points - one is saying "let's make our contractual agreements based on solving a problem together rather than on a predetermined deliverable," and the other is saying "let's be adaptive rather than trying to define everything up front." The two things definitely go hand in hand but one is focused on formal agreements and the other is focused on working practices.
    – Ant P
    Jan 22, 2020 at 10:09
  • @AntP That's a pretty clear explanation, thank you (and could be posted as an answer as-is, instead of a comment).
    – ChrisW
    Jan 22, 2020 at 10:14
  • @ChrisW the rationale of an MVP is to "provoke" the market, create something that just works to test an assumption, so the organization is looking for stimulus to which respond, is the "sense-probe-respond" approach that guides Agile Principles. Another point is: "you could follow a plan even if there is no contract on a plan" or "reacting to changes by continuosly changing the contract" but both are toxic agilized-waterfall approaches. So the true agile needs (among the others) two ingredients: to care about business/engineering interactions and continuous learning from the business context Jan 22, 2020 at 21:16

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.