The course originated when JRS (Party B), an IT service provider, was awarded the project to rebuild the “Qualification Certificate System” for the Examination Yuan (Party A). Rather than simply executing the contract, JRS took the initiative to propose and co-host an “Agile Consensus Workshop,” sincerely inviting Party A to join in.
JRS fully understood that most government contracts still adopt the traditional waterfall development model, which often proves cumbersome and inefficient in the face of fast-changing requirements and the need for incremental delivery. In contrast, software development thrives on adaptability and rapid iteration. Applying a rigid waterfall approach under such circumstances can easily lead to delays and missed delivery targets.
This workshop was not just a one-way lecture; it was a hands-on collaboration designed to foster mutual understanding, dialogue, and partnership between Party A and Party B. By establishing a shared language and aligned mindset, it opened a new window for applying Agile practices in government contracts.
I was honored to be invited as the trainer for this Agile Consensus Workshop. For me, it was a rare and valuable opportunity to design a session that brought together two very different entities—Party A, the government agency, and Party B, the IT vendor—for a joint Agile learning experience.
Though these two parties typically operate in separate rhythms and speak different “professional languages,” on this day they sat side by side in the same classroom, starting from a shared foundation. Together, they explored Agile, built common ground, and began meaningful conversations. This encounter was not just the beginning of collaboration—it was a spark for real change.
Turning Point: One Remark from the Director Changed Everyone’s Perspective
As the workshop drew to a close, Director Hsu of the Information Division at the Examination Yuan shared a powerful insight:
“In fact, government contracts don’t prohibit Agile. I’ve been thinking about where the space for Agile really lies—and honestly, there’s no conflict at all.”
That one remark shattered many participants’ misconceptions and sparked deeper conversations.
To build on his point, I added: “The most important flexibility doesn’t lie in the contract—it lies in the mutual understanding between people.”
Had this consensus workshop not taken place, and if only Party B had unilaterally attempted to implement Agile, the outcome would have been vastly different.
Is the “SOW Dilemma” Between Agile and Government Contracts Truly Irreconcilable?
Government contracts typically begin with a Statement of Work (SOW), detailing all functional requirements—regardless of their priority—which, in theory, must all be delivered.
However, during the actual development process, new and more critical needs often emerge. At that point, several viable paths are available:
- 1.Contract Change Process: Use formal procedures to add or adjust features.
- 2.Feature Swapping: Replace lower-priority items with new, higher-value requirements.
- 3.Cost Increases from Agile Iterations: Allocate flexible budget reserves for use after project closure.
- 4.Schedule Adjustments from Agile Iterations: Party A may explain the rationale for changes to the supervising authority—this is not considered a breach of contract.
- 5.Utilize National Development Council (NDC)’s Agile-Adapted Procurement Guidelines: Refer to Attachments 1 & 2.
All of these are proof that Agile and government procurement processes can, in fact, coexist.
Party B’s Perspective: Agile Insights Through the Eyes of JRS
This was JRS’s first time applying Agile methods to a government project. From their questions on Slido, it was clear they were grappling with real-world challenges—such as how to begin development amid uncertain requirements, or how to effectively manage changes. I addressed each question in turn, helping them realize that Agile isn’t just theoretical—it offers practical, workable solutions.
- Can product development conclude with just the most important features done right, and then move to the next phase? If so, how should a project handle this?
- What if requirements have been confirmed and development completed, but the client redefines specifications due to market demands or management directives?
- If Agile is used during the maintenance phase after project completion and further optimization is requested, how should the additional cost be estimated?
- Since public sector agencies must issue RFPs for bidding, how can these be adapted to suit Agile development? Should the role of the PMO evolve accordingly?
- CMMI emphasizes extensive documentation, which is helpful for handover and long-term maintenance. Agile values interactions and working software—how does this affect the organization’s knowledge management (KM) system?
- In traditional waterfall teams, roles like System Analyst (SA) and System Designer (SD) are clearly defined. Are these roles still needed in Agile?
- Should the Scrum Master role be filled by a senior executive, or can it be taken on by others? What personal traits contribute to success in this role?
- Scrum Teams seem to require high-performing individuals in every role. Isn’t it difficult to find such talent?
JRS highlighted a key pain point: in traditional projects, unclear requirements and vague, uncertain user expectations often lead to skyrocketing costs and significant schedule delays.
Agile, however, directly addresses these challenges:
- Unclear Requirements? Each iteration delivers an MVP for Party A’s review, enabling progressive discovery of true needs and hidden details.
- Tight Schedule Pressure? This usually stems from unclear requirements leading to rework. Once requirements are clarified, timelines can actually be shortened.
- User Dissatisfaction? Agile emphasizes involving users throughout the iterations—gathering feedback and making adjustments—ensuring the final product truly meets their expectations.
Here comes the challenge: What if users give conflicting feedback?
Party B raised a common dilemma:
“What if multiple users give conflicting feedback—some say OK, others say no?”
I gave a straightforward answer:
“That’s exactly why we have a Product Owner (PO).”
The PO, representing Party A, is responsible for consolidating all input and making the final call on product priorities. This role is essential in Agile—it ensures that despite differing opinions, the team has one clear voice to follow.
That’s how Agile maintains both efficiency and quality—by empowering the PO to make value-driven decisions on behalf of the users.
A Workshop Designed for Dialogue and Discovery
The entire workshop was intentionally designed to foster dialogue.
From the very beginning, I focused on creating space for meaningful exchange. I started by introducing three ideal models of Agile contracts:
- Time & Materials Contracts (T&M)
- Money for Nothing
- Change for Free
However, government contracts are typically fixed-price, making it difficult to fully adopt the Agile-friendly contract models mentioned earlier.
To address this, I guided the participants in transforming the original SOW into user stories and a Product Backlog (PBL). We then worked together to prioritize items and design an incremental delivery plan.
This shift sparked lively discussions around questions such as:
- How Can We Use the Contract Change Mechanism?
- Which Features Can Be Swapped (“Feature-for-Feature”)?
- What Flexibility Exists Within Contract Constraints?
Yes, Government Projects Can Use Scrum!A Powerful Moment of Co-Creation as We Built the Product Backlog Together.
Scrum in Government Projects? The Moving Moment of Co-Creating a Product BacklogThe most touching scene that day was watching Party A, the government agency, and Party B, the IT vendor, standing side by side to jointly write a Product Backlog that could be continuously prioritized and iteratively refined—replacing the traditional, once-and-for-all requirements document.When requirements are broken down into small, verifiable work items and continuously adjusted based on priority, everyone finally sees what Agile truly emphasizes: maximizing value and minimizing risk.
In the atmosphere of the consensus workshop, Party A was no longer just the demand provider, and the vendor was no longer just a task-taker. Both sides used whiteboards and sticky notes to discuss “which items would help generate value earlier.” This way, with every short iteration (Sprint), early feedback could be received and improvements could be made quickly.That moment made people realize: government projects can also be full of innovation and vitality—it only takes a space for mutual understanding and dialogue.
To those government agencies and IT vendors still on the fence, I want to say: Be brave and take the leap!The government has never banned Agile—in fact, the National Development Council (NDC)’s RFP recommendation templates have already incorporated relevant practices.
The biggest pain point of Waterfall is realizing—only at final acceptance—that the product delivered is far from what was imagined.
In a CSM course I once asked 25 mid-level government officers whether they had ever received an IT system that fully met their needs. Almost all of them shook their heads.Instead of complaining, why not create a platform: invite Party A to participate in consensus workshops and CSM courses, so a shared language and mutual trust can take root from the very beginning.
As long as we are willing to make “requirements, feedback, and adjustment” a daily routine, Agile is never about “it can’t be done”,
but always about “let’s do it together.”
I interviewed the project officer to confirm the flexibility of Agile contracts in government projects.
Government procurement has long been regarded as a “one-shot decision” executed in a traditional waterfall model. However, a recent system redevelopment project by the Examination Yuan demonstrates that—with thoughtful contract design and effective communication mechanisms—it’s still possible to retain a meaningful degree of Agile flexibility, even within fixed-price contracts.
Below are key takeaways from my conversation with the project’s business analyst, shared as reference for private-sector vendors interested in adopting Agile approaches in government projects.
1. Reserved Authority for Future Enhancements
The contract explicitly defines a “Phase 5,” allowing the agency to add up to 35% of the original contract value (varies by project) within two years after final acceptance. This additional budget is designated for feature optimization and customer support enhancement. This approach effectively pre-allocates an “iteration budget,” ensuring the project can continue to evolve based on real-world usage and feedback even after go-live.
2. “Feature-for-Feature” Mechanism
When initial requirements are not fully mature or priorities shift, the contract allows for low-priority features to be replaced with higher-value ones through formal change procedures. As long as the development costs of the original and replacement features are roughly equivalent, no budget adjustment is required. This arrangement enables the project to retain Agile flexibility for iteration and value delivery, without exceeding the original budget.
3. Schedule Adjustment and Breach Determination
If additional features result in extended timelines, Party A is responsible for informing the supervisory authority and obtaining approval in advance. As long as the delay is due to newly requested requirements and proper contract management documentation is maintained, it is generally not considered a breach of contract, and penalty clauses are not triggered. The key here lies in transparent communication and adherence to formal procedures.
4. Procurement Thresholds and Oversight Intensity
When additional budget increases move the project into a higher procurement tier under the Government Procurement Act, it triggers stricter approval and audit requirements. Vendors should carefully review the monetary thresholds and understand how they impact procedures and documentation. It’s essential to evaluate the administrative cost and allocate sufficient lead time before bidding.
5. Leverage National Development Council (NDC)’s Agile Procurement Guideline Documents
The National Development Council (NDC) has released the “Guidelines for Drafting Agile Development Tender Documents,” which include examples on requirement breakdown, milestone-based payments, and acceptance criteria. While not limited to a specific contract type, the guide provides a practical framework ready for direct application.
Vendors are encouraged to integrate these guidelines with familiar contract models—such as Time and Materials—when submitting proposals. This approach enables them to offer solutions that are both compliant with government regulations and flexible enough to support Agile delivery.
Reference materials and templates are available at the following links: