Before I start, I just want to point out that this is a hypothetical question that I was recently asked in an interview. I'd like to be able to answer it with conviction if it ever comes up again. Any views or links to valuable resources would be appreciated.

As a product owner you are working using agile methodologies with your team on an application. One of the other departments in the business that you rely on for delivering this software uses a waterfall process. They will not change. How can you continue to be agile in your approach whilst working with this waterfall team?

closed as too broad by Todd A. Jacobs Mar 26 at 13:30

Please edit the question to limit it to a specific problem with enough detail to identify an adequate answer. Avoid asking multiple distinct questions at once. See the How to Ask page for help clarifying this question. If this question can be reworded to fit the rules in the help center, please edit the question.

  • Can you add some context to how you "rely" on the other team delivering the software? – Erik Jan 10 at 10:14
  • As I said, it was a hypothetical question with no real context offered. Perhaps as an example, you are building an app which consumes data from a database developed by a different team. The DB team use waterfall and your team - the app developers - use agile. – Simon Jan 10 at 10:18
  • Check out pm.stackexchange.com/q/22853/29755. There is some good stuff there. – Mark Cramer Jan 11 at 0:11
  • While the question title contains a good question that is probably a common issue, the body of the question seems too open-ended and lacks sufficient context to provide a canonical (or even semi-canonical) answer. Give more details or a more concrete situation, I think this could be a great question for the site, but as it stands it’s both too broad and largely an opinion poll. – Todd A. Jacobs Mar 26 at 13:32

This is something a lot of teams run into, at least the ones I've worked with and hear about from colleagues. And, as you might expect, there's room for a lot of tension between the two parties that use different methodologies for delivery. The fact is, if this is something that is simply necessary (there may be reasons), both teams will have to understand the trade offs of compromise. It really revolves around two concepts: change and planning. Conventional wisdom will say the agile team is more comfortable with change while the other team is more comfortable with a set plan. Both can be valid throughout the life cycle of a solution, but it's vital to understand which is best for satisfying the intended customer at any given time.

To answer your question about continuing to be agile in the midst of working with a more traditional waterfall team, I've found being abundantly transparent is vital to help spur collaboration and interactions. Transparency breeds discussion, which is a good thing so long as everyone understands the goal for why you're building what you're building. This is often times different from personal and professional motivations.

Do we know enough about how this will impact our customer to plan out x, y, and z 6 months in advance? Waterfall and agile can co-exist here.

Do we need more information about how this will impact our customer before fully delivering a big bang feature? It's probably better to compromise on a plan to deliver on incremental, iterative experimentation.

It's a tricky situation, but at the end of the day collaboration and the willingness to choose the best approach based on customer impact usually helps mitigate a lot of the issues such a situation can present. Snags and hiccups will happen; no one methodology will win. But life becomes easier when everyone is aligned on being transparent, the trade offs of making a decision, and ultimately doing what's best for the customer.


One simple (if not easy) approach to a Scrum team relying on the work of waterfall teams is to simply treat it as a constraint. Can the team work around it? Can the team make the constraint less impactful on their work?

You can look at things like the Five Focusing Steps approach in Goldratt's Theory of Constraints as a way to work through this challenge. I did a quick look around online and this page does a pretty good job talking about the Theory of Constraints:



The biggest impact of waterfall in agile principles is that is not prepared for changes, so the approach I would take is to reduce the size of the waterfall by spliting it into multiple smaller waterfalls, this way between them you can introduce changes without affecting the methodology of that department. So as a PO you have to make sure your backlog consists in smalls items which can be completed in a short period.


I have that in my environment as well: The management runs in Waterfall and the development is fully agile. And of course both does have impact on the other party.

I basically defined three steps:

  1. Reduce complexity: We have defined max. length and max. number of dependencies of tasks for the management. The spring length for the devs is set to 7 days.

  2. Increase communication: Both parties are exchanging they results much more often. We meet on a weekly base, but always with time boxing.

This goes together with new features for hybrid project management in my software as the third step: Merlin Project

Important Disclaimer: Merlin Project is commercial software and I am the CEO of that company.

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