Litigation Risks and Practical Safeguards for Contractors in Agile Development (Part 4): The Critical Importance of Communication and Expectation Management with Users
Jul 04, 2025
- Blog
- Agile Development
- Contract Law
- Project Failure
- Project Management
- Risk Management
- Scrum
- Velocity
- Vendor Management
3 Causes and 5 Countermeasures for Agile Development Flame-ups
Although agile development emphasizes flexibility and rapid response, it also tends to increase man-hours, and it’s common for projects not to finish within the development period. Therefore, explaining this situation to the user is difficult, and failure often leads to trouble. This article explains the root causes and countermeasures for agile development flame-ups and considers ways to build a relationship of trust with the user.
What Are the Root Causes of Agile Development Flame-ups?
Most agile development flame-ups stem from a “perception gap” between the user (client) and the vendor (contractor). Despite being a development methodology that can flexibly respond to change, in reality, incidents of “flame-ups,” “litigation risks,” and “trust breakdowns” are endless. The root causes lie in structural perception gaps and a lack of visibility into the project’s status.
Cause 1: Structural Perception Gap (A Different Point of View)
A perception gap arises because the user focuses on “Results (Budget/Deadline),” while the vendor emphasizes “Process (Progress Sharing).” At the root of project flame-ups is the different landscape each party is viewing.
■ The User’s True Concerns
- Not exceeding the budget
- Receiving the expected results by the deadline
- Fundamentally finds involvement in the process bothersome
- Therefore, easily loses interest in regular meetings and backlog sharing
■ The Vendor’s Typical Misunderstanding
- They must understand the situation because they attend the regular meetings
- They must be assured of the progress because we show them the backlog
- Since it’s agile, they should naturally accept specification changes
Thus, this state where both parties’ expectations and interests are misaligned is the first step toward a project flame-up.
Cause 2: Typical Problematic Behavior from the User
When a perception gap occurs, the user is more likely to engage in “moving the goalposts” or shifting responsibility.
- Claiming afterward, “I didn’t know those were the specifications”
- Shifting responsibility by asking, “Why wasn’t this confirmed with me?”
- Failing to share important prerequisites or decision-making backgrounds, yet casually demanding rework
- Furthermore, having a low awareness of the cost of rework and thinking, “You should naturally handle this”
Behind these user actions often lies the misunderstanding that “Agile = We don’t have to finalize specifications until the end.” This behavior represents a structural risk where the “flexibility” merit of agile development is easily exploited.
Cause 3: A Psychology Not Resolved by Legal or Contractual Arguments
During a flame-up, even if the vendor insists, “This is a quasi-mandate contract,” the user will not be convinced. This is because the user values their return on investment (the relationship between money flow and results) more than legal arguments.
- They feel the strongest distrust when the relationship between money flow and results becomes unclear
- As a result, they are more likely to make claims like “I didn’t know” or “There was no confirmation”
- They then unilaterally corner the vendor, using it as justification for litigation or refusal to pay
Legal arguments are merely the last line of defense. Building a relationship and making information transparent before that point is what truly matters.
5 Countermeasures to Prevent Agile Development Flame-ups
To prevent perception gaps and avoid flame-ups, improving the “quality of dialogue” using numbers and metrics is essential.
Countermeasure 1: Improve “Quality of Dialogue” with Velocity and Story Points
Utilize velocity (team’s development speed) and story points (workload) to visualize that “Change = Cost.”
- Story Points: A unit for estimating the volume or complexity of work as relative “points”
- Velocity: The actual track record of story points the team can complete in one sprint (1–2 weeks)
Utilizing these metrics dramatically improves the quality of dialogue with the user.
- Allows the user to visually understand that “changes always rebound as costs”
- Enables discussion with objective data that “future rework cannot be absorbed at the current development speed (velocity)”
- As a result, it becomes easier to convince the user “why prior specification confirmation is important”
Countermeasures 2–5: Building a System Where the User Pays with Satisfaction
Ultimately, the trusting relationship with the user boils down to “whether they feel satisfied with the payment.” Here are the five elements necessary for this. (*Includes Countermeasure 1)
① Prior Agreement on Labor/Work Unit Prices
First, align mutual understanding beforehand regarding the unit price or value for each work content.
② Transparency of Work Content and Deliverables
Next, always visualize work progress and deliverables, such as code volume, in a way that non-engineers can understand.
③ Recording Changes and Accountability
In addition, when adding functions or changing specifications, always create minutes and share estimates of the impact scope.
④ Utilization of Velocity/Story Points (Countermeasure 1)
Then, use these metrics to raise the quality of conversation and create a state where “Rework = Impact on Cost/Deadline” is self-evident.
⑤ Sharing the “Uncertainty” of Man-Hour Estimates
Finally, share the limits of estimation accuracy and confidence intervals with the user to adjust expectations to a realistic range.
Conclusion: 3 Principles to Prevent Agile Development Flame-ups
In conclusion, agile is a “change-adaptive” development methodology, but it has no tolerance for “change-exploitative” behavior. In particular, dealing with the user’s last-minute claims or intentional withholding of information should be built into the project design phase.
To achieve this success, the following three principles must not be forgotten.
① Understand that relying on legal arguments is the last resort.
② Always utilize numbers and visualized information at the daily conversation level.
③ The vendor must take the lead and intentionally educate the user.
This kind of governance design is the key to leading modern agile development to success. Conversely, neglecting this, the project will end in failure due to a “breakdown of the trusting relationship” before a court renders judgment.
Therefore, even after the development kick-off meeting, it is essential to create and share a rough estimate for the entire development.
Question: What is the biggest cause of agile development flame-ups?
Answer: The root cause is a “perception gap” between the client (user) and the contractor (vendor). Users tend to focus on “Results/Deadlines,” while vendors emphasize “Process Sharing,” and this misalignment of expectations becomes the flashpoint for flame-ups.
Question: How can we prevent users from saying, “I didn’t know those were the specifications”?
Answer: It is effective to use velocity and story points to visualize that “Change = Cost.” By showing with objective data how rework affects deadlines and budgets, it becomes easier to convince the user of the importance of specification confirmation.
Question: What is most important for preventing agile development flame-ups?
Answer: Before relying on legal arguments, it is crucial to enhance the quality of dialogue using numbers and metrics (like velocity). The key is for the vendor to take the lead in educating the user that “changes cost money” and to build a system where the user feels satisfied with the payments.
You are welcome to contact us via the Contact Form to discuss and for more information.