Is Scrum incompatible with public tenders?

Question

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?

Answer 1

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.

Answer 2

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:

• Improving government outcomes through an agile contract format
• Agile Blanket Purchase Agreement
• Modular Contracting (breaking up large projects into smaller modular ones with agile development)
• Is your project using “agilefall”?

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.

Answer 3

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.

Answer 4

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.

Answer 5

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).

Answer 6

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...)

Answer 7

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.