My Scrum team needs an API to retrieve data. It's not overly complicated, essentially its just one request that gets sent to the API and then the API returns some data. This is the end of the journey.

Our problem is that the team designing the API is using Waterfall. The waterfall team is also designing the API to cater for numerous other teams needing differing versions of the data returned.

They seem to have layers and layers of project managers and programme managers sitting on top of the actual development team and they are not located in the same city. They use strict waterfall, so they want ALL our requirements up front and they use legacy approaches, e.g. they don't really know how AWS (where our service sits) works etc.

How do you recommend my Scrum team works with them or tries to work with them?

We were thinking of trying to arrange a regular chat between their development team and ours but we not really sure the project managers would allow that. They are also strict. No changes to the requirements. They want to lock down the requirements.

So we are a little unsure as we are not experienced with this way of working.

  • When it is only one request, why does the Waterfall team need so much communication about requirements? Would it be an option, to let only some of you developers talk / communicate with them in the way of a ticket "daily chat with XY"? Then they could bring back the new information in the daily about the ticket.
    – hamena314
    Commented Mar 2, 2020 at 12:08
  • 1
    In Scrum you can depict a lot of things as a ticket. In this instance, you could create a ticket "Daily chat with the waterfall-team" and allocate 1 or more developers to the ticket. The developer then will talk daily to the waterfall-team and get new informations and requirements. Then when the ticket comes up in the daily, the developer can give a short update to the team. If questions arise, the dev can gather the information and respond to the waterfall-team. While typing I've noticed, that this is probably not what you wanted, but I still wanted to answer your question regarding "ticket"
    – hamena314
    Commented Mar 2, 2020 at 13:01
  • 1
    @hamena314 It's not the waterfall team giving the agile team requirements, it's the other way around - and a key line here is "The waterfall team is also designing the API to cater for numerous other teams needing differing versions of the data returned.": Too many stakeholders making too many changes to an Agile project is an excellent way to slow, stall or scupper it entirely. Push too hard, and you risk the API team saying "the cost/benefit analysis of including your requirements in the first version of the API comes back negative. Prepare requirements for when we work on version 2" Commented Mar 3, 2020 at 15:39
  • 2
    As an extreme example: You walk into a restaurant, and ask for a cheese and tomato pizza. 5 minutes later, you ask if they can add green peppers. Another 5, you ask for chicken too. Then spinach. "Oh, it has to be gluten free." "Can you mix black olives into the dough?" "Make sure it's Vegan!" "Actually, not pizza: pasta, with the same toppings." "On second thoughts, gnocchi." and "why'd you leave out the chicken?!" - how do you ever expect to actually eat? Commented Mar 3, 2020 at 15:49
  • 1
    This question reminds me of the concept of 'bimodal IT' in the discussion of DevOps principals (DevOps originally being Agile Systems Administration) - techbeacon.com/devops/…
    – Cinderhaze
    Commented Mar 3, 2020 at 20:13

8 Answers 8


Pretend the Waterfall team is an outside contractor

Since you're interfacing with the Waterfall team's code solely via an API, just pretend you're hiring an outside contractor to create that code for you.

The Scrum rules for how you write your code don't apply to them. You submit your requirements to them, they write up a formal Statement of Work for what they will do for you, which might go through some back-and-forth before both sides agree. Once everyone's signed off on it, they go implement their code.

Meanwhile, someone on your team should create a dummy that uses the contracted API, so that you can start writing code that interfaces with it. As soon as the Waterfall team's code is usable, substitute it.

  • 4
    I came here to joke about putting the PO meditating under the waterfall so he can purify himself, but your answer is accurate and workable. Commented Mar 4, 2020 at 17:22
  • 1
    Even better if you share your dummy API with the other team as you make it, so they can make sure theirs is interoperable.
    – Euphoric
    Commented Mar 5, 2020 at 15:17
  • 1
    @Euphoric I assumed the API spec would be in the SoW agreed to by both teams. Commented Mar 5, 2020 at 18:20
  • 1
    @Euphoric The more I think about it, deliberately not sharing the dummy code is probably a good idea, because I'd want the Waterfall team to do a clean implementation of the API rather than one tainted by my team's code. I'm a big believer in the rule "A protocol can't be stable until there are at least two independent implementations that interoperate with one another." Commented Mar 13, 2020 at 17:00

First of all, make it known to your stakeholders that there is a project risk in your project. The waterfall team is asking for things (final, unchanging requirements) that you don't have at the start of your project.

To mitigate this risk, you can analyse your current backlog for items that may affect the data that you need to exchange with the system developed by the other team. Refine those stories to such a level that you can proactively write the requirements for what you might need in the future. In this process, also use the experience from the team to predict possible/likely future changes to the backlog that affect this.

In this process, you are probably asking for more than you will actually use, because some stories get dropped or predicted changes don't come about, but that is the cost of dealing with the waterfall team.

Additionally, you can try to negotiate a lenient and efficient change-request process with the waterfall team, so that it becomes easier to request changes after the initial requirements were baselined. If you have that in place, you don't have to analyse the backlog items as deeply and you can keep the less likely changes out of the initial requirements.

Count yourself lucky that you have a fairly narrow interface with the waterfall team (a single API call). Because of that, you can try to accommodate their process without sacrificing your process too much.


For what it's worth, APIs and protocols are an area you often do need things fixed. This has to be very deliberately and explicitly designed because if you need to change it later, every consumer will have to update their code. APIs which are often changing are a nightmare to work with especially if they implement backwards incompatibilities.

I do not see a reason that settling on an interface protocol cannot be done in a SCRUM setting, in several iterations even - but you need to be happy with it before sending that to the other party.

Of course you can make your interface extendable if you actually cannot decide all requirements, or you can design an interface that is flexible for future expansion without changes.


I have been in this situation a couple of times and it is very challenging.

Things that can help:

  • Spend some time with the waterfall team explaining how you work. Even if you can't resolve the conflicts between the approaches it still helps if they understand what you are trying to do.
  • Ask them to produce a mock/stub at the earliest opportunity to at least allow you to make progress without becoming totally blocked.
  • Prioritise the work associated with the dependency to at least get it out of the way as quickly as possible.
  • 1
    Flipside to the first point: understand how they work. There might be very good reasons as to why the API is being produced Waterfall - if nothing else, they may have to carry out risk assessments, waivers and other such data security clearance activities before confirming whether you are allowed to return certain data from the API! Commented Mar 3, 2020 at 15:25

When the API is not too complex, you could create your own mock API to experiment with which returns test data. When you got your requirements down, you can contact them to create a real API delivering real data.

  • But OP would rather avoid that. That would mean taking responsibility and saying "This is what we need". Scrum usually means "i want to be able to change anything and everything at any point, without taking the responsibility" :)
    – SeaBiscuit
    Commented Mar 6, 2020 at 1:53

They are also strict. No changes to the requirements. They want to lock down the requirements.

That is not really true though. They would like to restrict changes to the requirements, for sure, because that's the nature of waterfall development. In practise though it is never possible to avoid some changes to requirements, because issues will always occur during development where requirements need to be refined. It's also important to note that requirements probably will be locked down during development, so that developers can get their work done efficiently. After that, they'll look at any changes you ask for.

You may be using Scrum, but you should still have a representative set of use cases, shouldn't you? If you have your use cases, you should know what data you're likely to need from their API. That gives you the requirements to pass to them, or at least enough requirements that minor later refinements can be treated like any other bugfix.


Remember, Scrum can be applied to anything, not just software development. It can be applied to fleshing out API requirements too.

I assume your entire project does not revolve on this one API call. Just put a priority of fleshing out your API requirements.

In this you are your own product owner. Put the API-related feature / code at the top of your product backlog, write up your API requirements, and go. Sprint through it as if API existed, and then figure out what else your API needs, repeat until you are done with API-related stuff. Give the finished product (API requirements) to the waterfall team.


When you are designing an API which will be consumed by many business units (and maybe by external customers), a Waterfall approach with fixed and rigidly-stated requirements might very well be exactly what should be done. The business impact of such a layer of software is enormous. "This one scrum team" is only one of the many clients that this layer has.

I believe that even the Agile team must comply with their demand for fixed requirements. Build a mock-API to allow you to continue development on your project before the actual API is delivered. Design the software which consumes this API to be easily changed if when the implementation changes.

Your Answer

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

Not the answer you're looking for? Browse other questions tagged or ask your own question.