I was asked by a public organization to give an informal workshop about the 101 of agile development explaining terms and concepts of Scrum, Kanban, and the like. I have worked in agile environments for about five years now, but I don't think of me as a Scrum evangelist.

After the workshop they liked the idea. However, they explained that the approach probably would not apply to them since they need to commission external software companies to develop software for them (they have only few developers themselves). This activity needs to be done in a public tender process that describes the result, price, and time-frame. This is a legal requirement to apply for a budget for this organization (a public research institute).

These constraints appear somewhat contradictory to the fundamental principles of agile development, don't they?

Is Scrum just incompatible in such an environment?

What would you recommend to this organization?

  • 5
  • 1
    If result, price and time-frame can all be done upfront, why bother with an agile process?
    – JeffO
    Commented Mar 7, 2018 at 15:21
  • 3
    Scrum is compatible with everything, by definition. The "The team owns the process" paradigm allows one to alter the process radically, so Scrum can become Waterfall, if needed. Being "agile" means NOT that you have to follow some process with zero deviation. It means that the process can be adopted to the needs. Note that this point is EXTREMELY unpopular with management - they want fixed processes, and they will call anything "agile" if they have been hooked on Agile/Scrum/Whatever.
    – Klaws
    Commented Mar 7, 2018 at 15:33
  • 3
    FWIW, IME, I have never, seen anything like Sebazzz describes. The contract says specifically what must be delivered. If it doesn't meet the requirements then you aren't done. And that's the entire problem with the "deliver what you have when funds run out" agile methods. It is a rare occasion when you can deliver a product that only does a subset of what the customer needs and it is actually of value to the customer. Usually that's the same as it doesn't work at all. Deviations can be requested, but if that deviation removes functionality then that almost certainly is combined with less funds
    – Dunk
    Commented Mar 7, 2018 at 22:34
  • 2
    @CortAmmon-What I've seen the government do is "smart" but not really agile. They still basically follow waterfall, they award the contract in phases instead of the full life-cycle development effort as they did in the past. They are also more prone to hiring more than one contractor, especially in the engineering phase, as that lets them competitively select the best solution that they want to transition to a manufacture-able product. That last phase is the most expensive. They want to see what they are getting before deciding to manufacture. A partially working product will not win.
    – Dunk
    Commented Mar 7, 2018 at 23:03

7 Answers 7


Scrum is probably not appropriate for this organization.

From the Scrum Guide, "Scrum is a framework for developing, delivering, and sustaining complex products." It's also designed for a team of 3-9 members of a Development Team working on the product, a Product Owner, and a Scrum Master (who may or may not be on the Development Team) for a total of 4-11 people total.

With respect to internal development, you mention that they only have a few developers. If there isn't a large enough team to form a Scrum Team, then it doesn't make sense to use all of Scrum. However, some Scrum practices may be useful to the organization.

For the contracted development, it's possible for one of the external parties to use Scrum. In this case, it is useful for the research institute to know about Scrum practices and understand the roles and how it works. They may still need to understand the specifics of how the external development organization uses Scrum practices as well as other practices, but it can help them understand how it works. For example, understanding the need to participate in Sprint Reviews or working with the organization (probably their Product Owner) on ordering the Product Backlog.

  • Excellent answer. It is very difficult although not impossible to get organizations like the one described by the OP to move toward an Agile approach.
    – user255194
    Commented Mar 7, 2018 at 12:12
  • 1
    @MisterPositive You may not need the research institute to become agile. However, they will likely need to be able to interact with external entities who are agile when they issue a contract. They can see the benefits of agile, for sure.
    – Thomas Owens
    Commented Mar 7, 2018 at 12:15
  • The really good part about this answer is IMHO that it does not fall into the trap of arguing about Scrum not suitable because "result, price, and time-frame" are fixed.
    – Doc Brown
    Commented Mar 7, 2018 at 15:16
  • 1
    @DocBrown Maybe because Scrum can be used where the price and time-frame is fixed. In my experience, when you're delivering rapidly and demonstrating things to stakeholders, they realize that what they originally thought they needed and what they really need are two different things. And then they will change the desired result within the original price and time frame.
    – Thomas Owens
    Commented Mar 7, 2018 at 16:00
  • Agree. Software is not like having an architect design a building. It is inherently a moving target, with the ground always sliding away under your feet. Next year, last year's efforts look passe.
    – user251748
    Commented Mar 8, 2018 at 14:57

18F, a digital services agency within the US government, has done a lot of work on how government can write contracts to allow for the use of agile methodologies in a way consistent with the law, specifying general results rather than detailed requirements for how the work is to be done. Some of their resources include:

An advantage of agile work methods is that they focus on discovering a solution to a problem after the contract is awarded, that is, during post-award execution, rather than specifying the detailed solution up front as with Part 15. An agile contract tries to specify problems requiring detailed solutions, often as Product Backlog Items that describe high level contract delivery areas.

Understanding this problem, the Office of Management and Budget and Office of Federal Procurement Policy directed agencies to stop using SOWs and shift to using a Performance Work Statement (PWS) for acquiring services. A PWS “should state requirements in general terms of what (result) is to be done, rather than how (method) it is done” Good contracting officers advise agencies that by buying expert services, it implies that you’re not the most knowledgeable in “how” work is done. As the mission owner, you are the expert in “what,” must get accomplished, but conflating the two puts your mission at risk and makes it harder for a contract to provide value.

Fundamentally, the approach is more like hiring a service provider to work with you to design a solution, rather than listing pages of detailed specifications in advance. The institution wouldn't hire an architect to design a new building by listing out "the design must be four stories, with a roof pitch of 37º. The third floor must have a 237 sqft kitchen containing four florescent light fixtures, controlled by a motion-sensitive light switch, in a drop ceiling." Rather, they would have a contract for the architect to provide design services in consultation with the client, and rely on their vendor, an expert in the field, to produce the resulting deliverables.

While the details will depend on the institution and the procurement policies and laws that apply, it does show that, amid all the failures of large government IT projects, there are groups working to move public tenders for software development over to more modern agile methodologies, given enough political will and trustworthy development partners. It does take a major shift in how such projects are conceived and managed (including a lot of ongoing time providing user feedback throughout the process), which the organization may or may not have any interest in pursuing.

  • 3
    This is a great answer, especially the last two paragraphs. This really is a great way of putting things that I haven't been able to put together in a coherent way.
    – Thomas Owens
    Commented Mar 7, 2018 at 23:46
  • 1
    Yes, this is the answer. The contract and how it was written is the problem. I can neither confirm nor deny that I have at some point in my life worked for such an organization or one similar to it, and when they switched over to a more results-driven contract, agile development has begun spreading like wildfire. Commented Mar 8, 2018 at 12:33
  • So it sounds like the 'architect' needs to help write the tender in the first place, before it can be budgeted and given a time-frame. It is a two-phase process, with the second phrase being: "you, build this, opening day is..."
    – user251748
    Commented Mar 8, 2018 at 14:30

No, SCRUM is not incompatible with public tenders. You need to state explicitly what you are buying in a public tender.

"Purchaser is looking to buy 10 2-week sprints of development, from an experienced SCRUM team containing 5 developers and a certified SCRUM master (purchaser will fill in Stakeholder role). Sprints will run from March 2018 to July 2018" is a pretty reasonable start of the tender. You'll need to list the team skills necessary, of course, and give an idea about the project they'll work on, but it is perfectly acceptable to have a tender in order to hire a team.

Of course, you're giving up on the "fixed scope" here. That is typical for SCRUM, after all. With a bit more wording in the tender (but we're getting in legal territory here) you can allow for a small scope extension, i.e. a small number of additional sprints. But if you decide you'd like an additional 10 sprints after the initial 10 sprints, you are probably going to need to re-tender.

  • 3
    Exactly ! This is an excellent and accurate answer. In this webinar projectmanagement.com/videos/290684/… an us gov official explains how it works in full details. The principle of shifting the purpose of the tender from the end product to the development service can also be organized under many other procurement legislations in a similar manner. The main difficulty is mainly the sometimes conservative attitude of some stakeholders, and not a so-said incompatibility.
    – Christophe
    Commented Mar 7, 2018 at 21:27
  • 1
    So they'd hire the cheapest scrum team they can find, and when the project needs more hours, they hire the second-cheapest team to take over mid development? This approach presumes that the client assesses the quality of the software team they hire. If they have such expertise, I wonder what they need to outsource the contract in the first place?
    – meriton
    Commented Mar 7, 2018 at 23:49
  • @meriton: Most tenders are by government, which usually is required to use the cheapest qualifying offer. SCRUM doesn't change that. However, SCRUM puts the product owner in an active role, which does help here.
    – MSalters
    Commented Mar 8, 2018 at 10:11
  • However, if contracted as you suggest, SCRUM changes the incentives for the service provider. They can no longer be held accountable for not meeting requirements, their only incentive is lowering price, while meeting the letter of the qualifying criteria, but not necessarily their spirit. It's easier for the purchaser to assess whether the software meets requirements, than whether the team is likely to produce software that does. But yes, your approach is one of the best ways to use SCRUM in the public sector. I just wanted to mention why purchasers might not want to adopt it.
    – meriton
    Commented Mar 8, 2018 at 14:43

It does sound typical. Once the tender has been written, offers are in and one of the contenders has been granted the contract... as far as the representatives of the public organization are concerned, the project is done.

This is why so many of these projects fail. After they went way over budget.

The point they are missing (or at least do not feel is any of their concern) is that they are stakeholders that should be attending meetings and demos.

So there is no conflict with Agile or Scrum whatsoever. It is people not picking up their roles. It is the way government works that causes this.

It is not like "we would like to have this system and we are willing to put some effort in it and see how far we can take it".

No. It is like "our democracy has decided we WILL have this system, by then". Which leaves no room between 100% success on the one hand and 100% failure on the other. Doomed from the start.

It is also an invite to the market to ask for ridiculous rates. Not doing the project because it is too expensive is not an option, the decision to do it has already been made before the tender was written.

Fair enough, even if the stakeholders would pick up their roles, they would be totally powerless. None of them would have a credible stick to take to those demos for the same reason.

  • 5
    This is not really answering the question. What would you recommend to this organization?
    – Philipp
    Commented Mar 7, 2018 at 21:18
  • 9
    Isn't this a cliché against governments that would be responsible for all failures, more than a constructive answer? I don't know in your country, but in my country there are a lot of successful government projects. I won't be able to change your mind, but here an interesting article based on objective facts and independent observations: mckinsey.com/industries/public-sector/our-insights/…
    – Christophe
    Commented Mar 7, 2018 at 21:57
  • 6
    "This is why so many of these projects fail. After they went way over budget". This trope is claimed all the time by people pushing agile processes. And yet, there are a ton of successful development companies that don't use any of the proposed agile methods. They tend to do so without problems. If anything, the real problem is the practice of hiring the cheapest bidder and not putting enough emphasis on past performance and domain expertise. Blaming the process is a red herring. Success can be achieved by any competent team using any reasonable process that they have skill with.
    – Dunk
    Commented Mar 7, 2018 at 22:48
  • OK, I did got a little carried away. I would still recommend to monitor progress and take that stakeholder role, after the contract was signed, assuming it is in everyone's best interest to deliver. And I am not claiming Agile is the key, I am claiming there is no conflict with Agile principles and pointed out a common underlying problem. Commented Mar 8, 2018 at 6:09
  • Re: "assuming it is in everyone's best interest to deliver": where I live we had a very expensive long-term project (for a utility expansion) fail, with the bankruptcy of the builder (a world-wide, century old mega-company) and the public service agency having gotten potentially illegal legislation passed, and the customers expected to bail everyone out. In government, these sorts of things are not supposed to happen, it is in everyone's interest for all parties to remain viable, ethical, and deliver what they promised. Not sure if processes can help with that or not.
    – user251748
    Commented Mar 8, 2018 at 14:51

It is difficult.

You obviously can't tender the work with an open-ended budget. So you have to look at what will need to be done and how much effort is required to do this.

Now the reason that many software projects fail is due to the fact that fixing, time, effort and scope up front is very error-prone. For example, a specification as given in a tender will almost always have some ambiguity.

So there is a fundamental issue not just with agile, but with the concept of open tenders for software development. The chances of someone going off and creating exactly what you wanted, in the time you specified, are low.

If you allow for some flexibility you can improve this.

It sounds like the process of putting work out to public tender is not flexible. However, once the contract is won, you may find there is wriggle room. You could, for example, allow agile working but you would have to accept (and get legal clearance) that this could affect the scope.

Now I believe that this would result in a better product as you will get to see what is happening early and make changes before they are baked into the product. Tight feedback loops and iterative development can make products that are better fitted to the actual requirements (which may or may not be what was put out to tender).

  • 3
    +1 I cannot count the number of times the work has gotten done because someone accepted a recognizably poor contract, and then used that connection to upsell the contract into something which is closer to what the customer actually wanted.
    – Cort Ammon
    Commented Mar 7, 2018 at 15:14
  • 1
    Let me highlight this - this answer says not Scrum is incompatible with public tenders, but contract based software development in general. Not that I disagree.
    – Doc Brown
    Commented Mar 7, 2018 at 21:53

It depends, but probably yes.

I'm willing to bet money that everyone who has ever worked with any government on any IT-related project will know that in practice, the 'hard limits' described in the tender are never all met. Things tend to go over budget, get delayed and/or the scope is changed. Usually multiple of those. If the governments are willing to admit that this is the truth and become willing to treat them like the guidelines they are, then scrum can work really well.

From personal experience (both my own and in my professional network) I know that requirements change frequently in the majority of government projects. The responsible committees also tend to have a lot of feedback when they finally get involved at the end of a project. These are problems for which Scrum is well suited.

However, this would require a fundamental change in mindset on the part of governments and their agencies. In most countries, it is very unlikely that this change will ever take place. Until that time, public tenders will continue to be incompatible with working with Scrum. (For that matter, in my personal opinion public tenders will continue to be incompatible with any sustainable software development practices, but that's another matter for another time...)

  • I was going to write a comment like your last parenthesized statement, but I will let you get the credit :)
    – user251748
    Commented Mar 8, 2018 at 14:45

What would you recommend to this organization?

At this point nothing.

What's lacking here is the story of what problems their current process is causing them. Scrum is not something to recommend blindly. It has a point. It is not one size fits all.

Ask them what problems their current process has caused them. Listen. Only recommend methods that address their real problems. They are going to be biased towards their current process. Tinders may seem like they dictate a development process but they don't. They dictate a delivery process. But that's a distinction this team likely has never had to make before.

Agile works best when the requirements change more than 3% over the life of the project. Otherwise waterfall is still very effective. It is still used in many places today. And of course many successful developers never formalize their process either way. Informal works well when the hard problems are technical, not about the people.

So talk to them about their current process and the problems it has. Tell them about what these methods help with. But if it ain't broke don't fix it.

Your Answer

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