[ss48]

I would say yes. We work with several subcontractors for our software development (business systems and embedded standalone products). Our responsibilities and subcontractor's responsibilities need to be clearly defined, along with an expectation of what functionalities the final product will have. We would usually need to define a week or months worth of tasks and not be able to provide much more input until each deliverable is ready. Our subcontractors would use whatever development approach they want to achieve our deliverables, though.

When things deviate from a set of requirements, we can review and adjust the requirements accordingly so our expectations in working together can stay in line. We don't have a luxury to constantly keep changing things after releasing the software because a we work in a more regulated environment where changes will need to be reverified and validated before release, not just by ourselves, but by our customers. In the projects, we are heavily involved in ensuring a good user experience and integration testing of the software to ensure it meets our needs and solves the business problems we have.

I think it should be used when there is more than one company involved in developing an application between the companies at least, and should be avoided when exploring different design ideas and gathering requirements and scoping out the project. In any project, I strongly advocate towards doing whatever it takes to expose problems and areas of uncertainty that should be scoped out as soon as possible. It's a lot more expensive to build a solution around an existing solution than to incorporate it as part of the solution from the start.