Executing Government Projects using Agile/Scrum

In traditional PM-based development, there are 4 "levers" that can be adjusted as needed to meet target dates (time, cost, scope, quality).   Examples are: add more people (cost), reduce time for testing phases (time, quality), deliver less than planned (scope), allow tech debt or bugs to be shipped (quality), etc.

In Scrum, three of the 4 levers are fixed.   Time is the duration of the iteration/sprint.   Cost is the $ for resources (people, utilities) over that time period.   Quality is maintained as a constant through the Definition of Done.   Therefore, the only "lever" that can be adjusted in Scrum is Scope.

So in answer to your question, a growing practice is iteration-based contracting, where the project is set at a fixed time duration (corresponding to # of sprints) where the goal is to deliver as much of the known scope in priority order, and to allow the scope to change as information is learned from sprint to sprint.

For example, you can simply agree to "contract" the services of a Scrum Team (cost) over a certain time period (# of sprints = time) where their delivered functionality (increment) must meet the defined DoD (quality).   The only variable is scope, and this flexibility allows for both scope and "deadlines" to change based on what is learned (empiricism).

How can Agile development be successful in Government IT Projects which are Tender based? In such RFPs(Tenders) the timelines or schedules are fixed, and the Project cost is also defined.

Might that depend upon how keen the Government body is to learn about the scope of their initiative, and about what value really means to stakeholders?

Are they keen to inspect and adapt, based on the lessons from releasing usable increments of work every Sprint?

Thanks for your suggestions and valuable inputs. 

Most of the Tenders floated by Government are of type Fixed cost and Time along with the scope, but the scope gets changed as you discuss and discover more with government officials. In order to win the contract, you have to estimate the project cost based on the underlying scope mentioned in RFP, which becomes very tricky as you don't know how many sprints you have to spend in getting the final release.